Feature Request: Retain option

[hamstie]

Hello Kai, i am testing you app for a month, for my home presence system. It woks like a charm, but i think you can improve the published topic with a retain option:

Without MQTT retain: t= 0min: Bob is coming in and his app is publish his home state (he will re-publish his state in 20 min) t=5 min: Alice is starting her MQTT Dashboard, she was subscribed Bob's state, the state is
unknown because the topic wasn't flaged as retained. Bobs state will be set at Alice Dashboard in 15min.

If you implement the MQTT retain option: t= 0min: Bob is coming in and his app is publish his home state retained. t=5 min: Alice is starting her MQTT Dashboard, she was subscribed Bob's state, the state will be set from the MQTT broker to the last known state (preset) immediately

Regards Mark

[ostrya]

Hi Mark, sounds reasonable enough. Since my intended use case assumes the client listening on the MQTT channel is a home automation server that is always connected, I would like to keep the default behavior and make this configurable. Is it fine with you if the configuration for retain flag (and I'll add QoS as well) is set globally? Or would you want to configure this per topic (online message / offline message / battery message)?

[hamstie]

Hi Kai, the most gui interfaces using a retain checkbox for each published topic, but i think a global checkbox is enough.

Quality of Service: There a many disadvantages for an increased level (in our use case):

• the network traffic will be increased (for the acknowledged and retried messages)
• the app need more cpu cycles for the app to wait for each ack
• the app have no usage for the acknowledge info
• anyway the app will publish in a timeslice not only on change

But i think there is another nice feature of mqtt, that is very useful in your app. Do you know the lwt (LastWillandTestament):

If the MQTT client connection dies (mqtt keep alive fails) the broker will be publish the last will payload for the mqtt-client: The client can reuse the topic for the online message: example: Topic Presence: home/person/bob payload:online Topic Last Will : home/person/bob payload :offline (Retain:True, QoS:1 this are the flags for the broker<->subscribe connection) The keep alive timeout need to be set nearby the presence publish cycle time.

I think this is much saver as an active presence offline publish over a second network.

• if the mqtt keep alive was arrived at the broker (over WIFI) the payload is online if the keep alive fails, the broker will set the payload to offline

But i don't know the mqtt handling in android if the app is suspended, is the keep alive working or do you open and close the connection for each presence publish?

[ostrya]

I am aware of the LWT feature, but at the moment, the app only connect shortly to the broker to send the messages, then it immediately disconnects. This is because

a) maintaining a constant connection would mean that the app runs continuously and drain more battery, and b) Android 6+ disconnects all apps when the device is in standby (see https://developer.android.com/training/monitoring-device-state/doze-standby#understand_doze)

So for now I do not plan to go this way.

[hamstie]

i am tested a combination with:- lwt

• clean_session=False (persistent connection)
• Keep Alive >0 (attached script)

Result: lwt is working for persistent connections, if the connection dies, without a clean mqtt-disconnect the lwt will be triggered.Keep Alive >0 for the disconnected tcp-connection but persistent will not be triggered unfortunately. conclusion for persistent connections: only a little advantage to to use lwt if the keep alive timeout only checks the tcp connection not the logical one

Am Mittwoch, 7. Oktober 2020, 19:49:40 MESZ hat Kai Helbig <notifications@github.com> Folgendes geschrieben:  

I am aware of the LWT feature, but at the moment, the app only connect shortly to the broker to send the messages, then it immediately disconnects. This is because

a) maintaining a constant connection would mean that the app runs continuously and drain more battery, and b) Android 6+ disconnects all apps when the device is in standby (see https://developer.android.com/training/monitoring-device-state/doze-standby#understand_doze)

So for now I do not plan to go this way.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.