Dan
I have a version working, getting data from OSPI, and detecting when a station is switched on/off. It sends a message to my TV when a station switches on eg “Front lawn sprinklers started”. When the station switches off it logs the duration to EmonCMS (Emoncms time stamps it). It needs some tidying up, extension to more than one board, and lots of error checking. In the process of developing it I learnt more about Node-red. Some of the tidying up needed came from that learning. eg One thing I will do is change it so that instead of logging straight to Emoncms it will publish to an MQTT topic. A separate flow will subscribe to that topic and log to Emoncms. This will make it easier to log to different databases and will also result in more reuseable code.
However I learnt another capability of Node-red that offers an interesting possibility. Node-red has global context variables that are available to all functions running. I am using the station names, the station number of the master valve, the number of stations, and the station status, so I am thinking to develop a plugin for OSPi that publishes these values to an MQTT topic on startup, and whenever there is a change. These values don’t change that often, so the MQTT traffic will be minimal.
In Node-red I will develop a flow that subscribes to this topic and places these values into global context variables. (It will be necessary in Node-red to have a startup initialisation via the JSON calls I used previously as Node-red and OSPi can’t be relied on to startup sequentially!). This effectively exposes near real time values of OSPi variables within Node-red! I will then complete the flow that populated the global variables. This will send the station swithon and off messages as before. Other flows could be developed to use the same variables to achieve different results if required.
The same could be done for other related sets of variables from OSPi eg weather related variables for adjusting watering times.
This approach will be more efficient, and is scaleable as more applications are developed (the way I have done it involves my application doing JSON calls to the OSPi web server every second or so, so it is not very scaleable. I haven’t yet tested it at 1 second intervals for example).
One thing I need to do is to develop a structure for the MQTT topics eg Garden/OSPI/stationrun, Garden/OSPI/stationrun/s1,2,3,… ,Garden/OSPI/stationrun/error, Garden/OSPI/stationrun/error/API/errornumbers (such as 400, etc) and so on. Stationrun would refer to this application – if someone developed a similar weather related application, they could use Garden/OSPI/weather for example.
What do you think?
Ian