Feature Request : MQTT Manager
akkord64 opened this issue · 4 comments
Enable an MQTT manager who can subscribe to alert levels send standardized MQTT messages to an MQTT broker. This will allow for expanded integration of AlertR other management platforms.
I am working on a fork that includes MQTT support. I initially have it working with the client templates, but I think this is not what I want. I need to reverse engineer the mobile manager in order to see the clear sensor events and not just triggered and alert stop.
This is a great idea. And even greater is your attempt on working on it :)
My problem is I have no clue about the MQTT protocol and have no devices or what so ever that uses it. What devices have you at your home/environment that uses it? Perhaps these devices are interesting for me as well :)
To the implementation:
At the moment the clients are differentiated as follows:
sensor: has just the ability to send a sensor alert, state change of a sensor or a complete status update of all sensors to the server. The sensor client is not allowed to trigger any other action.
alert: only sends "keep alive"s to the server to have a constant connection to it. The server sends a "alert level triggered" or a "switch off all triggered alerts". Any other action is denied.
manager: is only allowed to send an "option change" to the server (at the moment only used for activate/deactivate system). It gets informed about all triggered sensors and state changes of a sensor. Regularly and event based it gets the complete state of the alertR server sent. This way it always know the current state of the alertR system (the mobile manager for example updates a database which is read by the website).
When I understand the protocol correctly, the MQTT client should be able to
a) send triggered sensors to the alertR server
b) send "alert triggered" and "shut down triggered alert" messages to the MQTT devices
c) should be able to change options of the alertR server (activate/deactivate it) on a received MQTT message
For this I think we have to add a new type of alertR client (for example "bridge") to it. This "bridge" should be allowed to do all things that are done by the three client type definitions.
I do not know if you had seen it, but a detailed schema of the alertR protocol (which is only json) can be found here: /docs/protocol.txt
Hey,
mqtt is a great idea and a way to save a lot of sms or e-mail traffic :)
With node-red it is then easily possible to trigger other events and expand the functions with ease.
MQTT also supports encryption - to communicate over MQTT imho its very important, without it anyone can publish messages to a broker... that wouldnt be good for this system....
At the moment i set up a new environment with two rPI and some reed-switches, i will also set up mosquitto server and node red - if you need some dev testing, let me know!
best regards & a happy new year
Closing these issue because of no responses.