Skybadger Observatory


Skybadger Observatory Web dashboard

Node red design for Observatory Dashboard control

I am slowly automating my observatory to the point of complete remote operation. Sadly, the observatory isn't 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 this case this topic is about the node-red dashboard that controls and monitors it all. Node red is an event-driven workflow engine that runs on top of node.js and provides a very low cost entry ( i.e. relatively easy) to flow-oriented programming, passing events and messages to perform activities like turn lights on or respond to weather events. Node-red also provides a range of basic pre-canned functions such as web calls, dashboard GUI items, alexa integration and a whole lot more. Finally node-red is multi-platform and open-source. I run mine on the observatory PC which runs 24x7 and it consumes a few percent of the i7/16GB processor capacity available. Current situation I have taken Node-red to be the basis of my web dashboard, providing various tabbed pages to monitor visual elements and devices in the observatory and It can also behave as an entire website so can implement ASCOM drivers on the ALPACA model which are natively integrated into the MQTT publish/subscribe model. Examples of these drivers include the ASCOM Safety driver and the ASCOM Observing conditions driver. The rest is the dashboard for central switch control, central monitor for remote systems health, all sky camera monitor page, environment sensing and weather pages and finally essential third party links. Data collection & MQTT The data for the dashbvoard is collected via the Message Queuing text transfer (MQTT) pub/sub model . This is where devices can subscribe to a message box and listen for a message and decide to do something to respond to that. Similarly, the same devices also report their system health and collected data by oisting the data to message boxes hosted in Node Red by the MQTT Service. An address might look like /Skybadger/devices//attribute Subscribing to the health monitor heart beat is what causes the devices to respond with their health status ie they listen to /skybadger/devices/heartbeat and post a response to /skybadger/device/health/. The host health graph looks like this : Continuously available devices cause a slowly rising graph. the data resets at midday hence the jump. Only a few are meant to be there all the time. Others are powered up as required as part of opeing and closing the observatory to consever battery power. 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 battery voltages are recovered from ADCs in the switches so that chargers can be turned on as required if the solar power isn't enough. Weather Sensing 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. . ASCOM Drivers the structure of a typical ASCOM driver implemented in node-red looks like this:
There are a bunch of sensors reporting to the server. They all report to the central MQTT reponse handler and then get despatched to the consuming components e.g weather dashboard, observing conditions etc. Future work Planned extensions include

  • Implementing a device interface using the Alexa interface nodes to provide voice automation and reporting of the observatory status via phone and echo devices.
  • Graphical mapping of Basignstoke Astro Soc observers activities so we can see who is out, what is being observerd and what the local weather conditions are