Mqtt binary_sensor entities start up status inconsistent starting with 2022.2

1

Hello,
I created issue 65867 over on github in an effort to better understand the behavior I started seeing with my mqtt binary_sensor entities in 2022.2 and didn’t get any responses. Eventually the issue was marked stale and auto-closed. Perhaps someone here can help me?

Here is the full text of my original issue submission:

Previously, my mqtt binary_sensor entities would always start up (i.e. after HA restart) in ‘unavailable’ state. In an ideal world they might hold onto their previous state, but I was okay with unavailable because it was predictable and frankly most accurate because the rebooted instance of HA would not have seen the last periodic update of sensor status. Once the first report comes through, the entities reflect the correct status.

Now, however, after installing 2022.2, I’m noticing that these devices seem to be starting up in a random state. Some start up as ‘on’ and others as ‘off’ while some still show up as ‘unavailable’. This appears to be different on every restart. This is a problem for me because if my alarm is armed when I reboot and one of the sensors is ‘on’ upon startup, the alarm will trigger. Previously this wasn’t an issue because they came up ‘unavailable’.

Please advise, thanks for your support.

Thanks!

2

I don’t know how your mqtt binary sensors are defined, but the solution is obvious : make sure your sensors have the ‘retain’ flag set on your broker. So the (correct) state of them is known as soon as HA restarts.

1 Like
3

Thank you for the feedback @francisp, but not sure the solution here is ‘obvious’ although I appreciate the suggestion regarding the broker ‘retain’ flag. Perhaps I’m not fully understanding the implications of ‘retain’ but my concern with that is I could be masking legitimate communication issues from my sensors.

Regardless, this doesn’t explain the clear behavior change that I observed with the upgrade to 2022.2. Nothing in my broker changed, but the behavior of the binary_sensor entities did change. There were many changes to MQTT, but I could not identify what change could have caused this behavior. My configuration has worked consistently for well over a year and I only observed the different behavior post-2022.2 update.

If it helps, I’ll provide a bit more context on my configuration. I have rtl_433 running to capture RF sensor status. These sensors provide an hourly supervisory signal. rtl_433 posts to my Mosquitto MQTT broker that is running in supervisor. Below is an example binary_sensor configuration for these sensors including the expire_after configuration I’m using to force these sensors to unavailable state after 1.5hrs of no updates.

# Front Door Sensor
- platform: mqtt
  name: Front Door
  state_topic: 'rtl_433/74930c0d-rtl433/devices/Interlogix-Security/contact/aaaaaa/switch1'
  payload_off: "CLOSED"
  payload_on: "OPEN"
  ### Sensor will become unavailable after one and a half hours of no updates
  expire_after: 5400
  device_class: door
- platform: mqtt
  name: Front Door Sensor Battery
  state_topic: 'rtl_433/74930c0d-rtl433/devices/Interlogix-Security/contact/aaaaaa/battery_ok'
  payload_off: 1
  payload_on: 0
  ### Sensor will become unavailable after one and a half hours of no updates
  expire_after: 5400
  device_class: battery
4

If you enable LWT (last will and testament messaging) this will not be an issue.

5

Thanks for this idea @tom_l. Would this mean each rtl_433 message would need to be preceded/paired with a LWT message? I’m not super familiar with MQTT, but assuming the publisher/rtl_433 would need to provide this functionality?

Full disclosure, I’m really not sure where/how to set the ‘retain’ flag on the addon broker either and/or if I would simply need the ‘retain’ flag set on the rtl_433 messages. I’ve poked around the documentation trying to better understand this, but not making a ton of progress there. Any insights are appreciated.