Node red design for Observatory Dashboard control 
I am slowly automating my observatory to the point of complete remote operation. 
Sadly, the observatory isnlt quite run of the mill and wont take some 'standard' after-market add-ons so I have to make some of them my self. 
In thic case this topic is about the node-red dashboard that controls it all. 

Node red is an an event-driven workflow engine that runs on top of node.js and provides a very low entry ( ie relatively easy) to flow-oriented programming, passing event messages to perform activitiues like turn lights on or respond to weather events. 
Node-red also provides a range of basic pre-canned functions such as web call,s dashboard GUI items , alexa integration and a whole lot more. 
finally node-red is multi-platform and open-source. 

So I have taken Node-red to be the basis of my web dashboard, providing various tabbed pages to monitor visual elements and devices in teh observatory. 
Examples of these include, the ASCOM Safety driver, the ASCOM Observing conditions driver, central monitor for remote systems health, central all sky monitor page, central ASCOM remote switch monitor page and third party liunks jump page. 
Planned extensions include using the Alexa interface to provide voice automation and reporting of the observatory status. 
Underpinning all of this is the use of MQTT messaging in Node-red. MQTT is a subscribe/post messaging system that is often used for pushing data and events to a central server where other listeners subscribe to mailboxes to do somthing about an icoming message, when it arrives. 
For this reason its really good for central logging of sensor data and workflow operations. Here I use it for weather, environment sensors and ASCOM ALPACA driver states. 

Here's a page from the system dashboard. It shows the heartbeat responses over time for all the listening/awake devices. If devices are responding,  the graph climbs to midday when it resets. 
I post a heartbeat message to the heartbeat message tree and all the devices subscribe (or listen) and react when they hear the call. 
In this graph each of these devices are remote ALPACA devices or other small embedded devices.

The MQTT reporting structure is broken up according to the diagram below. 
The sensors report their health by posting messages to the sensor branch when hearing the heartbeat message. 
The ASCOM driver devices report their ASCOM status to polling clients via web calls but also by posting events to the function branch. In this way, devices which need to repond to ertain ASCOM actions can listen for the action outcomes and make a choice on whether they need to do something. 

The sensor message branch receives data from the weather, dome environment and rain sensors. This also feeds into the Observing Conditions driver which summarises the available data into the Safety driver which summarises the data into a decision on whether its safe to proceed. 
Tools like Voyager and SGP can then query for this safety output to make decisions on wehter to continue ro close up shop due to rain or some other external event. 
.