Some help with MQTT settings please

Configuration
1

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:

  1. After Hassio restarts, the binary sensors show their current state.
  2. After Hassio power loss and subsequent restart, the devices are in the same state they were before power loss.
  3. 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.

Any suggestions will be much appreciated.

2

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.

1 Like
3

Here is a link to a helpful video that deals with your questions:

1 Like
4

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
1 Like
5

Thank you all!

6

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?

7

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.

8

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).

9

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.

1 Like
10

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.