The weak point in my system that I need to address is device behaviour after network loss, Hassio reboot, or Hassio power loss.
I need some help understanding what settings to have both in my devices (mostly Tasmota flashed) and in my device config in Hassio.
I want to ensure that:
After Hassio restarts, the binary sensors show their current state.
After Hassio power loss and subsequent restart, the devices are in the same state they were before power loss.
After a device loses network connection it will look for what it was requested to do by Hassio and then assume that state once it regains connection.
I have some understanding of this but itâs by no means complete. Having read the docs Iâm still confused by optomistic, retain, power on state, power retain etc.
I started with mosquitto broker and Node-Red on Raspberry Pi 3 long before the decision was made on HassIO for Home Automation on another PI.
Advantage: The MQTT Broker runs independently. Never had to restart the NodeRed/mosquitto for months.
Messages with qos=1 and retain-flag=true are held by the broker and read correctly by HassIO after Restart.
No need to combine it with Hassio, in my opinion.
For more info about MQTT, I recommend zhe videos by Steve Cope on âAn Introduction to MQTT for Beginnersâ on youtube for example.
In addition to the excellent video posted above there is a nice HA Trick to ensure that all the âTasmotaâ Devices are in their correct state after a reboot, whether the retain flag is set or not.
Simple create an Automation that publishes to the Tasmota Grouptopic after HA restarts:
- id: '1540498257039'
alias: _Read MQTT States from Tasmota on Startup
trigger:
- event: start
platform: homeassistant
condition: []
action:
- data:
topic: cmnd/group-topic-name/POWER
service: mqtt.publish
Can you explain what the automation does? If I understand it correctly, upon Home Assistantâs startup it publishes to the topic cmnd/group-topic-name/POWER. What is the message it is publishing to this topic?
It doesnât actually publish any payload to the group topic. Consider it like a ping on which the devices publish their actual state in their own state topic. Like a forced refresh.
Please help me understand this so-called âpingâ concept because it doesnât correspond to anything Iâve learned about how MQTT works.
Is it possible that the automation is publishing an empty-string ("") as opposed to absolutely nothing (i.e. NULL value)? Therefore subscribers to the command_topic receive an empty-string. Normally, this results in no action because, effectively, the subscriber has received, effectively, an invalid command. However, youâre saying that upon receipt of an invalid command, the Tasmota firmware responds by publishing its state_topic? Is this an undocumented feature?
I donât have any switches with Tasmota so I canât test this theory. The recommended solution is to make the Tasmota switch publish its state_topic with retain=true. This is explained at timemark 8:13 in the video. Therefore the MQTT Broker will retain the switchâs current state and provide it to Home Assistant upon reboot (and so it shows the switchâs current state).
The syntax in the automation will send a null payload
How the client interprets the lack of payload is entirely up to the client. There is nothing invalid about it unless the client does not understand what it is meant to do.
The tasmota client interprets an empty payload as a request to send the current status. There is nothing invalid about it.
No it is documented on the tasmota web site. I found it when I was helping someone with a different problem.
I agree, the standard MQTT way of handling this situation would be to have the status message sent with retain flag set, so that any client would receive the message when it subscribed to the topic. But this only works if the broker supports it, and for a long time the embedded broker did not (it may still not), so this is a useful work around.
Thanks for the detailed response! My mistake was to view this technique through the lens of generic MQTT as opposed to how Tasmota has implemented it.
Normally, a NULL payload isnât going to result in anything useful (hence my use of the term âinvalid commandâ). However, as you pointed out, itâs a valid command for Tasmota which handles it as a status request. I shouldâve done my Tasmota homework; itâs documented here:
Side Note: For many commands, an empty payload is a query . If you are using mosquitto_pub , you can issue an empty payload using the -n command line option. If your MQTT client cannot issue an empty payload, you can use the single character â?â instead.
Being a stickler for clarity, I think I prefer the option of publishing a ? as opposed to NULL payload.
Upshot is this behavior is unique to the client (Tasmota). The default MQTT behavior for receipt of NULL payload is undefined.