Dear Sir, Madam,
I have a technical question regarding the RevPi and MQTT communication.
I’m currently running a system with 2x Core-3 and some I/O modules.
Communication between RevPi’s and Mosquito and Node-Red are up & running.
So far so good.
But, what I can’t figure out is how to set:
- the connection control settings: e.g. “birth”, “close”, “last will”
- the message “retain” and "QoS" settings
These are all common MQTT settings, but appear to be missing from the “/etc/revpipyload/revpipyload.conf” file?
Please advise.
Thanks.
MQTT connection and retain settings
-
RevPiModIO
- KUNBUS
- Posts: 335
- Joined: 20 Jan 2017, 08:44
- Contact:
Re: MQTT connection and retain settings
Hi svdkuijl!
Right, the values are not jet implemented
But I will do it for you 
Let's talk about the expected behavior: I can add that values to the .conf file and you are able to set e.g. QoS and retain globally for all IOs, which are tagged as "exported" in piCtory.
So what will happen:
QoS: Okay, that is simple, all IOs will take that value.
retain: Simple as well, all IOs will be send with retain flag
last will: Maybe a parameter in the .conf file for "lastwill_topic" and "lastwill_value" ?
birth / close?
I'm excited on your ideas - Let's develop this features
Sven
Right, the values are not jet implemented
But I will do it for you Let's talk about the expected behavior: I can add that values to the .conf file and you are able to set e.g. QoS and retain globally for all IOs, which are tagged as "exported" in piCtory.
So what will happen:
QoS: Okay, that is simple, all IOs will take that value.
retain: Simple as well, all IOs will be send with retain flag
last will: Maybe a parameter in the .conf file for "lastwill_topic" and "lastwill_value" ?
birth / close?
I'm excited on your ideas - Let's develop this features
Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Re: MQTT connection and retain settings
Dear Sven,
Thanks for the quick and promising reply!
I am pretty sure you know much more about MQTT then I do, especially since I’ve noticed a certain “Sven” as author in many python source files for the RevPi
Anyway, let’s share some ideas as you suggest and see what you can make of it.
Here goes.
We use similar I/O devices from Advantech and they work as follows.
On normal connect to the broker, all clients receive a “Birth” message:
topic: xxx/device_status
payload: {"status":"connect","name":"ADAM6066","macid":"00D0C9FD2BAC","ipaddr":"192.168.10.150"}
Note: I guess this message is actually send by the device itself, not by the broker.
On normal disconnect from the broker, all clients receive a “Close” message:
topic: xxx/device_status
payload: {"status":"disconnect","name":"ADAM6066","macid":"00D0C9FD2BAC","ipaddr":"192.168.10.150"}
Note: I guess this message is actually send by the device itself, not by the broker.
On unexpected disconnect (e.g. network timeout) from the broker, all clients receive a “Will” message:
topic: xxx/device_status
payload: {"status":"disconnect","name":"ADAM6066","macid":"00D0C9FD2BAC","ipaddr":"192.168.10.150"}
On new data (cyclic or event driven) , all clients receive the following message:
topic: xxx/data
payload: {"di1":true,"di2":true,"di3":true,"di4":true,"di5":true,"di6":true,"do1":false,"do2":false,"do3":false,"do4":false,"do5":false,"do6":false}
Where "xxx" is similar to the "basetopic" from the /etc/revpipyload/revpipyload.conf file.
It is very convenient that the device name/type, mac and ip addresses are send in the connection messages.
It is also convenient that these messages are JSON formatted, same for the regular I/O data messages.
All this is fixed and non-configurable on the mentioned Advantech devices.
I would really recommend that you consider optional support for JSON formatted I/O, similar as the Advantech:
topic: xxx/data
payload: {"di1":true,"di2":true,"di3":true,"di4":true,"di5":true,"di6":true,"do1":false,"do2":false,"do3":false,"do4":false,"do5":false,"do6":false}
In our experience this is much more convenient to process client-side.
In addition, I would recommend to make the /io and /event topic names configurable as well.
That way, they can be configured as identical topic (e.g. /data) and handled as such by the client.
In our experience this is more convenient to process client-side, because at the moment a client must now handle both topics to be sure it gets the data.
A client usually doesn’t really care “why” the data was send, it just wants to process the data.
For example, to add to the revpipyload.conf file:
io_topic = io (appended to the basetopic/ for periodical messages: default /io, alternative: e.g. /data)
event_topic = event (appended to the basetopic/ for event messages: default /event, alternative: e.g. /data)
device_topic = device (appended to the basetopic/ for device related messages, including connection state, device type, mac and ip address)
data_retain = (global setting for all regular messages)
data_qos = (global setting for all regular messages)
data_json = 0 or 1 (if enabled, I/O data will be send in one JSON message on topic basetopic/io_topic or basetopic/event_topic containing the data of all I/O’s with “exported” in piCtory)
birth_message = 0 or 1 (if enabled, device message will be send after regular connect)
birth_retain = (specific setting for “birth“, leave blank to use the global setting)
birth_qos = (specific setting for “birth“, leave blank to use the global setting)
close_message = 0 or 1 (if enabled, device message will be send after regular disconnect)
close_retain = (specific setting for “close“, leave blank to use the global setting)
close_qos = (specific setting for “close“, leave blank to use the global setting)
will_message = 0 or 1 (if enabled, device message will be send by the broker after an unexpected disconnect)
will_retain = (specific setting for “will”, leave blank to use the global setting)
will_qos = (specific setting for “will”, leave blank to use the global setting)
Actually I am not sure if the broker has a service to send the birth/close message or if the device needs to do that by itself.
Example of device_topic message after connect with: birth_message = 1
topic: revpi0000/device
payload: {"connected":true,"type":"RevPi Core V1.2","macaddr":"00D0C9FD2BAC ","ipaddr":"192.168.10.150"}
Example of device_topic message after network timeout with: will_message = 1
topic: revpi0000/device
payload: {"connected":false,"type":"RevPi Core V1.2","macaddr":"00D0C9FD2BAC ","ipaddr":"192.168.10.150"}
Let me know what you think.
Best regards,
Sander.
Thanks for the quick and promising reply!
I am pretty sure you know much more about MQTT then I do, especially since I’ve noticed a certain “Sven” as author in many python source files for the RevPi
Anyway, let’s share some ideas as you suggest and see what you can make of it.
Here goes.
We use similar I/O devices from Advantech and they work as follows.
On normal connect to the broker, all clients receive a “Birth” message:
topic: xxx/device_status
payload: {"status":"connect","name":"ADAM6066","macid":"00D0C9FD2BAC","ipaddr":"192.168.10.150"}
Note: I guess this message is actually send by the device itself, not by the broker.
On normal disconnect from the broker, all clients receive a “Close” message:
topic: xxx/device_status
payload: {"status":"disconnect","name":"ADAM6066","macid":"00D0C9FD2BAC","ipaddr":"192.168.10.150"}
Note: I guess this message is actually send by the device itself, not by the broker.
On unexpected disconnect (e.g. network timeout) from the broker, all clients receive a “Will” message:
topic: xxx/device_status
payload: {"status":"disconnect","name":"ADAM6066","macid":"00D0C9FD2BAC","ipaddr":"192.168.10.150"}
On new data (cyclic or event driven) , all clients receive the following message:
topic: xxx/data
payload: {"di1":true,"di2":true,"di3":true,"di4":true,"di5":true,"di6":true,"do1":false,"do2":false,"do3":false,"do4":false,"do5":false,"do6":false}
Where "xxx" is similar to the "basetopic" from the /etc/revpipyload/revpipyload.conf file.
It is very convenient that the device name/type, mac and ip addresses are send in the connection messages.
It is also convenient that these messages are JSON formatted, same for the regular I/O data messages.
All this is fixed and non-configurable on the mentioned Advantech devices.
I would really recommend that you consider optional support for JSON formatted I/O, similar as the Advantech:
topic: xxx/data
payload: {"di1":true,"di2":true,"di3":true,"di4":true,"di5":true,"di6":true,"do1":false,"do2":false,"do3":false,"do4":false,"do5":false,"do6":false}
In our experience this is much more convenient to process client-side.
In addition, I would recommend to make the /io and /event topic names configurable as well.
That way, they can be configured as identical topic (e.g. /data) and handled as such by the client.
In our experience this is more convenient to process client-side, because at the moment a client must now handle both topics to be sure it gets the data.
A client usually doesn’t really care “why” the data was send, it just wants to process the data.
For example, to add to the revpipyload.conf file:
io_topic = io (appended to the basetopic/ for periodical messages: default /io, alternative: e.g. /data)
event_topic = event (appended to the basetopic/ for event messages: default /event, alternative: e.g. /data)
device_topic = device (appended to the basetopic/ for device related messages, including connection state, device type, mac and ip address)
data_retain = (global setting for all regular messages)
data_qos = (global setting for all regular messages)
data_json = 0 or 1 (if enabled, I/O data will be send in one JSON message on topic basetopic/io_topic or basetopic/event_topic containing the data of all I/O’s with “exported” in piCtory)
birth_message = 0 or 1 (if enabled, device message will be send after regular connect)
birth_retain = (specific setting for “birth“, leave blank to use the global setting)
birth_qos = (specific setting for “birth“, leave blank to use the global setting)
close_message = 0 or 1 (if enabled, device message will be send after regular disconnect)
close_retain = (specific setting for “close“, leave blank to use the global setting)
close_qos = (specific setting for “close“, leave blank to use the global setting)
will_message = 0 or 1 (if enabled, device message will be send by the broker after an unexpected disconnect)
will_retain = (specific setting for “will”, leave blank to use the global setting)
will_qos = (specific setting for “will”, leave blank to use the global setting)
Actually I am not sure if the broker has a service to send the birth/close message or if the device needs to do that by itself.
Example of device_topic message after connect with: birth_message = 1
topic: revpi0000/device
payload: {"connected":true,"type":"RevPi Core V1.2","macaddr":"00D0C9FD2BAC ","ipaddr":"192.168.10.150"}
Example of device_topic message after network timeout with: will_message = 1
topic: revpi0000/device
payload: {"connected":false,"type":"RevPi Core V1.2","macaddr":"00D0C9FD2BAC ","ipaddr":"192.168.10.150"}
Let me know what you think.
Best regards,
Sander.
Re: MQTT connection and retain settings
Hello Sven, any news on this request?
-
RevPiModIO
- KUNBUS
- Posts: 335
- Joined: 20 Jan 2017, 08:44
- Contact:
Re: MQTT connection and retain settings
Hi Sander!
Sorry for the late response! I had to update some other things for RevPiModIO and the PyLoad/PyControl system first - that's done!
The first release of the MQTT function was very simple and basic. You successions sounds very nice! Especially the JSON part makes muuuuch sense!
I know this little Advantech devices - have one at home. I will check them out and try to redesign the functionality for the RevPiPyLoad system. After that I will build a beta version for testing proposes. I would be very pleased, if you could test the update.
Regards, Sven
Sorry for the late response! I had to update some other things for RevPiModIO and the PyLoad/PyControl system first - that's done!
The first release of the MQTT function was very simple and basic. You successions sounds very nice! Especially the JSON part makes muuuuch sense!
I know this little Advantech devices - have one at home. I will check them out and try to redesign the functionality for the RevPiPyLoad system. After that I will build a beta version for testing proposes. I would be very pleased, if you could test the update.
Regards, Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
Re: MQTT connection and retain settings
Hi Sven,
Looking forward to the beta.
Of-course we would like to test the update
Best regards,
Sander.
Looking forward to the beta.
Of-course we would like to test the update
Best regards,
Sander.
