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.
But I will do it for you 
