Retained MQTT messages not received on app restart

[freol35241]

Hi, first of all thank you for AppDaemon, great work!

I am currently pursuing a MQTT-based home automation system, utilizing retained messages to keep a "state" in the system. This works quite well but I am having some problems with AD with this.

Correct me if I am wrong, but as AD manages all mqtt events centrally and distributes these as AD events the retained information is essentially lost? I.e. if a single app is restarted, listening to events for a certain topic, it wont receive retained messages from the broker as the central AD mqtt handler does not keep state? The first message received by an app is essentially the first "new" message to come trough from the broker.

paho seems to support a retained flag on received messages message.retain, see here: https://www.eclipse.org/paho/clients/python/docs/

message
an instance of MQTTMessage. This is a class with members topic, payload, qos, retain.

would it be possible to take advantage of this in AD to make sure that apps are provided with any retained messages on restart?

[Odianosen25]

Hello @freol35241,

Yes if only the app restarts, it will not get a retained message as you said the central plugin does not get the retain messages.

I am not sure there is a way to get around this, unless you find a way for the app to request the data over MQTT when it restarts. That is what I do.

[freol35241]

Ok, thanks for your reply. So if i understand it correctly you have implemented some kind of logic on top of MQTT and appdaemon to arrive at the wanted behavior?

A curious question: What is the benefit of having a single, centralized mqtt handler in appdaemon rather than a "per-app" mqtt handler? In such a case, each app could benefit from all features of the mqtt protocol? Any drawbacks in terms of AD interoperability? I realize that it would affect the number of connected clients to the broker but in general mqtt brokers are well capable of handling lots of connections.

[Odianosen25]

Hello @freol35241,

First the beauty of AD and the MQTT plugin, is that you can connect to as many brokers as you like at the same time. You can also connect to the same broker, using different plugin instances as you like @ReneTode does that. I connect to 4 different brokers at the same time with different levels of authentication.

Anyways what I meant was like in my case, I have some MQTT based devices like device trackers using OwnTracks, zigbee2mqtt, MQTT based home presence systems e.t.c. Now when my apps restarts, I ensure the apps send an MQTT command to these devices, requesting their status, and it is then populated. This method I suggested you use.

Don't think you are limited in the number of plugin instances you can use. AD is extremely flexible and it will cope with it. If Rene reads this, maybe he can advise on how to approach your case as I think his setup is closer to what you want, than mine.

Kind regards

[ReneTode]

A curious question: What is the benefit of having a single, centralized mqtt handler in appdaemon rather than a "per-app" mqtt handler?

@freol35241 a connection to MQTT is a continious loop.
if you do that inside the app it keeps the app and so the thread from the app busy.

i connect indeed several times to the same plugin. in appdaemon.yaml i use:

    MYSENSORS_ZOLDER:
      type: mqtt
      verbose: False
      client_host: ip
      client_port: port
      client_id: AD_mysensors_zolder
      namespace: mysensors-zolder
      event_name: mysensors-zolder
      client_topics:
        - mysensors-zolder-out/#
    MYSENSORS_FRIETKEUKEN:
      type: mqtt
      verbose: False
      client_host: ip
      client_port: port
      client_id: AD_mysensors_frietkeuken
      namespace: mysensors-frietkeuken
      event_name: mysensors-frietkeuken
      client_topics:
        - mysensors-frietkeuken-out/#
    MYSENSORS_HUISKAMER:
      type: mqtt
      verbose: False
      client_host: ip
      client_port: port
      client_id: AD_mysensors_huiskamer
      namespace: mysensors-huiskamer
      event_name: mysensors-huiskamer
      client_topics:
        - mysensors-huiskamer-out/#

we are working on an DB plugin, so that AD can remember the last state, but until then you could of course save the last retrieved payload in any way you like and retrieve that at startup.

[acockburn]

Closing this - hopefully we answered your questions.