ostrya/PresencePublisher

Feature Request: Retain option

hamstie opened this issue · 4 comments

hamstie commented

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 commented

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 commented

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 commented

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 commented