True, something like a network failure would cause the device to be out of contact for some time. If, in that situation, it is critical that when the network comes back up the current device state is considered the master rather than the broker then the solution is to make sure the device sends its current setting on mqtt connection.
In the case of Tasmotta I am pretty sure it can be configured with a rule to send the current switch state on mqtt connection (if it doesn't do that automatically, I don't know).
Have a look at LWT, that will tell you if the device disconnects from the broker. I know it is theoretically possible for the device to be connected and communicating with the broker, but not working at a higher level so commands don't get through, but I have never met that. It would almost certainly have to be a bug I think. I rely on LWT for telling me there is a problem.
Yes, if it is desired that the switch is the master following a failure then that would be one way of recovering.
Of course another thing to think about is what happens when there is, for example, a power failure at the device (but not the pi). What do you want to happen when that recovers? All these possibilities need to be considered and the appropriate action taken for each one.
Yes, but only if you have enabled the retain feature to force the broker to send the value to the client (node red here) again after subscribing. The tasmota device will not send it again. It only sends the change once to save energy. And if your server hasn't been started in time, you lost that change.
Retain will help here, BUT it's not guaranteed, that retain is enabled.
Tasmota device might lost the retain flag after restart, or after a firmware update, or for whatever reason...
I would like to have the 100% guarantee, and this is not possible without a startup event, where I can just ask every device, if they are in the expected state and force them to enable their retain flag (which is not default unfortunately).
Only partly. That determines what the switch does but not what the rest of the system does. The whole system needs to be considered and each situation (power failure of various bits, newtwork failure, system restarts etc) has to be considered and the requirement in that situation coped with.
But even my broker is off during the restart of course. If you change the position of a switch during the reboot (or "hours" during a software update) your tasmota device fails in sending the change to the disconnected broker. The change gets lost.
Of course, it's not about light switches for me.
But I chose extra node red because I want automatic notifications and processes for my aquariums and 3D printers.
If the pumps in my saltwater aquarium fail, animals die within a few hours.
Or if the smoke alarm is active when I'm not at home.
Therefore correct states are important to me.
Greetings from Murphy...
Yes, as I said that is the one condition that retained topics do not cope with.
As I said, if that really matters to you then I suggest setting up a rule in tasmota that sends the current switch state on MQTT connection.
For me it is more important that the switch initialises to the state that node red and the broker thinks it should be, rather than anything the switch thinks is important, but the choice is yours.
Can you explain in a bit more detail exactly what the scenario is where the retained topics won't work for you please? I don't see how those comments relate to the issue.
If an alarm occurs and the server (with mqtt broker + red node) is down for whatever reason, the alarm gets lost. Even with retained topics. And even if your server is up again, afterwards.
But with a special node, which will be called once during the initial startup, I can ask all devices to update their states. Then I can detect the alarm condition and will be notified.
Ah, the inject node does this!
I misunderstand the checkbox there.
I thought, that you always have to click on the button manually.
But this seems to work, nice.
I thought that if the client attempts to send a message with QOS 2 but the broker is down, it would complete the transfer when the broker is back up, but it seems not to be so:
On broker, sudo systemctl stop mosquitto
On client, publish with QOS 2 (and retained)
On broker sudo systemctl start mosquitto
Node-Red on broker Pi gets Birth message but not the published one.
Sudo systemctl restart nodered - no extra message appears.
I can see how to request status with an inject node at node-red start, It seems less straightfoward if mosquitto is down (Only likely I guess if broker, client and Node-red are all on different machines)
Beside the fact, that I don't want to use tasmota only.
I'm pretty sure, that a device which fails to send a request via MQTT will not retry it endlessly until the broker is up again. I guess, the rule trigger will be active after the device will woke up again by the next event. But without an event nothing will happen. Just a guess.
Just think about battery driven devices...
