MQTT connection and retain settings

Topics about the Software of Revolution Pi
Post Reply
svdkuijl
Posts: 4
Joined: 04 Jul 2019, 14:24
Answers: 0

MQTT connection and retain settings

Post by svdkuijl »

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.
User avatar
RevPiModIO
KUNBUS
Posts: 322
Joined: 20 Jan 2017, 08:44
Answers: 0
Contact:

Re: MQTT connection and retain settings

Post by RevPiModIO »

Hi svdkuijl!

Right, the values are not jet implemented :( But I will do it for you :D

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 :D

Sven
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
svdkuijl
Posts: 4
Joined: 04 Jul 2019, 14:24
Answers: 0

Re: MQTT connection and retain settings

Post by svdkuijl »

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.
svdkuijl
Posts: 4
Joined: 04 Jul 2019, 14:24
Answers: 0

Re: MQTT connection and retain settings

Post by svdkuijl »

Hello Sven, any news on this request?
User avatar
RevPiModIO
KUNBUS
Posts: 322
Joined: 20 Jan 2017, 08:44
Answers: 0
Contact:

Re: MQTT connection and retain settings

Post by RevPiModIO »

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
python3-RevPiModIO - https://revpimodio.org/ || Der RevPi ist das Beste, was passieren konnte!
svdkuijl
Posts: 4
Joined: 04 Jul 2019, 14:24
Answers: 0

Re: MQTT connection and retain settings

Post by svdkuijl »

Hi Sven,

Looking forward to the beta.
Of-course we would like to test the update :-)

Best regards,
Sander.
Post Reply