Closed glsf91 closed 3 years ago
Yes. In an MQTT system you should set your state topics to be RETAINED. Any time a new MQTT client subscribes to it then, it'll be passed the LAST value of those topics, and restore its internal state. Command topics should NOT be retained for the opposite reason. You DON'T want "last command" replayed to every subscriber when they subscribe.
I will look at updating documentation this weekend maybe on the new topics that were added this week.
Ok, I will try this first. It will not always be enough. Especially when the mqtt server is restarted and status is changing in between (messaged are not queued in this case). But I give it a try.
Turning on persistence on your MQTT broker and setting retained correctly on messages solves all of that. Any subscriber will ALWAYS get the last published message to a given topic when it first connects if it is marked retained, allowing you to stay in sync even if the message was published before you subscribed.
It does not solve everything. When MQT broker is down and Domoticz device are still changing, then these changes are not published to MQTT broker anymore. They are lost. So when broker is back it has missed some state changes. But I will first try it.
You're right, I missed a point. You need
Closing as general MQTT usage issue.
HomeAutio.Mqtt.GoogleHome is remembering the state of the devices. But when stopping and starting again the state is lost. Because for google also the state is unknown and then for example I cannot change the temperature of a thermostat on my google hub for example. I have to set the state first. So I have to push the current status of all my devices to MQTT after I (re)start HomeAutio.Mqtt.GoogleHome.
I could handle this when HomeAutio.Mqtt.GoogleHome sends a message to a to be defined topic.
Maybe also an idea to summarize the topics which are there (like sync and query) and there meaning in the wiki.
By the way: thanks for your always quick responses to questions and making software changes