November 20, 2014 at 1:00 am #34738
This plugin works with the plugin notify_change to send an MQTT message to an MQTT Message Broker whenever an event listed below occurs. The message can be configured to contain text strings, time stamps and the content of most OSPi internal variables such as station status, or station names. This allows external programs to provide additional functionality, such as logging of configuration changes, and station run times to an external database. It also provides a more efficient alternative for external programs instead of continuously polling OSPi to keep up to date with the internal status of the system. The MQTT plugin provides a web page to configure the messages, whereas the notify_change plugin sends the MQTT messages whenever an event occurs. Both are required.
A sample Node Red application is also provided to demonstrate the possibilities these plugins open up. This sample application logs station runtimes to an external database (Emoncms), and sends notification of system reboots, people logging in, station start and stops and station name changes to email and to XBMC (for display on the TV). It also interrogates the OSPi system for most significant program internal variables and copies these to corresponding Node Red global variables. This occurs on startup to establish the initial status of the system, and on an hourly basis from then on to ensure lost messages do not cause the systems to diverge over time. This hourly “heartbeat” will in future be used to monitor the availability of the OSPi system.
It has been tested with the Mosquitto message broker. Plugin MQTT allows you to configure which events you want MQTT messages sent for, what the topic will be and the content of each message. It also allows you to configure the host and port of the MQTT broker.
The MQTT.doc file is a Word document describing the system and providing installation instructions and advice on using the system.
As I have stated previously I am not up to date with Git enough to make this plugin available through that means at this stage. So I will attach the necessary files to this post (and a separate one as I can only attach 4 files at a time). The .html and .py files will have a .txt extension added to allow me to attach them to the post. You will have to rename them.
Please let me know how you get on, and if you have any suggestions for improvement – both in the documentation and the application!).
Please note = all these files have recently been updated. Please be sure to use the latest versions.
IanNovember 20, 2014 at 1:17 am #34744
Additional files. .dat.txt files for the /home/pi/OSPi/data directory after renaming to remove the .txt extension.
The Nodered.txt file is the sample Node Red application. Open this file, copy it to the clipboard, and in Node Red import it from the clipboard.November 25, 2014 at 1:34 am #34823
I have been thinking a bit further in how my plugin integrates with the rest of the system, and I think it may need some more work!
I have hijacked your notify_change routine which had stubs for code. However the manner in which I have implemented it means it simply sends the appropriate MQTT messages as I intended, but it does not allow other routines, systems or internal plugins to be notified of the changes.
If the Blinker system allows the signal to be received in multiple places, then each plugin could simply implement the same code as in notify_change.py that responds to the signal.
If not then the notify_change plugin will need to know who wants to know of these events, and then call a series of routines similar in purpose to my publish_mqtt function.
It could be that other external systems require to be notified of changes eg the mobile app. If MQTT is defined as the standard way this will happen, then the plugin I developed will meet this need. If however they need/want direct notification then some changes will be required.
I am happy for my plugin to be adapted to fit in with any overall plans for OSPi.
- You must be logged in to reply to this topic.