Thanks for pointing me to Node Red. It’s been a lot of fun exploring it, as well as thinking of how it might be extended. I’m poking around OSPI now to figure out how to publish MQTT publishing from within OSPI. I have it working from within Python now, and played around with a fork of Dan’s Github gv.py, adding:
[“MQTT Host”, “string”, “mhost”,”Address of MQTT server for reporting events.”, “System”]
[“MQTT Topic”, “string”, “mtopic” , “Topic to which this OSPI server will post”, “System”]
[“MQTT Payload”,”string”, “mpay”, “What logging to perform”,”System”]
[“MQTT pub?”, “boolean”, “mpub”,”Whether to publish events via MQTT”,”System”]
re: your comments about needing to develop a structure for topics… I agree 100%. This is a very deep subject, and a problem that is rarely handled well (I spent 40 years in medical informatics, and this problem is everywhere). One approach that might be applicable is Topic Maps http://en.wikipedia.org/wiki/Topic_Maps
I think that this is one of the most powerful things the open source community can do: converging on an open, extensible definition of MQTT topics rather than Apple pushing “iTopics” or Google pushing “Gtopics” and having corresponding topic-wars.
I am also interested in “Promise” software technology: http://en.wikipedia.org/wiki/Futures_and_promises This is kind of related to an MQTT’s “last will and testament” of a server, to handle fail-over. (each OSPI could be a failover server for MQTT). An OSPI client, for example, could promise to send a “heartbeat” message every 10 minutes, which would trigger activity only when the promise was broken. Sprinkling programs could be communicated as “promises” which would run silently unless the promise was broken.
I’m just starting with OSPI and Github stuff. I used to be able to leap tall buildings with a single line of code, but that was many years ago, I’m afraid I’m a bit creaky. I hope to get up to speed with Python, Node.js, Node JS, and other tools real soon now 🙂