Can a MQTT Binary Sensor retain it's status or do I need an Input_Boolean?

Configuration
1

EDIT Goto post 26 for final solution.

Pretty much as the title.

I have a few Door / Window sensors that are RF connecting to an SonoffRF Bridge.
They work fine, but if I restart HA the status is lost. They go back to closed state regardless of if the door was closed or not prior to restarting HA.

Is there a way to get the binary sensor to retain it’s state during a restart?
Or do I need to have MQTT set an input_boolean and then use a binary sensor off that input_boolean?

I have tried retain: true and also retain: false

Below is an example of the code being used:

binary_sensor:

# No1
  - platform: mqtt
    name: "Front Door"
    payload_on: "ABCDEE"
    payload_off: "ABCDE7"
    device_class: door
    state_topic: tele/sonoffBridge/RESULT
    value_template: '{{ value_json.RfReceived.Data }}'
2

I believe you have to be able to configure retain=true in the sensor(s). That way the MQTT broker retains the last message and replays it to HA after the restart. Is there a web interface for the sending device where you can configure that?

3

I have tried again with retain: true and still reverts back to closed upon restart.

binary_sensor:

# No1
  - platform: mqtt
    name: "Front Door"
    payload_on: "ABCDEE"
    payload_off: "ABCDE7"
    device_class: door
    state_topic: tele/sonoffBridge/RESULT
    value_template: '{{ value_json.RfReceived.Data }}'
    retain: true

Or do you mean adding a command to my SonoffRF Bridge in the console?

4

The device sending the MQTT message to the MQTT broker needs to set the retain flag, looks like this is your SonoffRF Bridge. HA is on the receiving end…

I’m still fairly new to MQTT but this is my understanding of it.

EDIT: [https://www.hivemq.com/blog/mqtt-essentials-part-8-retained-messages/](Retain explained)

5

I have had the same problem with the Sonoff basic with tasmota. I used the “PowerRetain 1” command, I don’t know how the bridge works with the commands. If you are using tasmota firmware on the bridge you can look here.

6

Setting retain true in HA will not do what you want. If it was a switch in HA that would retain the MQTT topic when it is turned on/off in HA.
You need it the other way around. The device publishing the MQTT message to send the retain flag. In this case the Sonoff Bridge. That way when HA restarts and checks the MQTT topics the message is still there for it to read.

7

It is not me having the problem :wink:, you should reply to wills106.

Merry Christmas.

8

I know sorry I hit the wrong reply the tried editing it but it wont let me change who I replied to. I tried deleting the post and recreating it but was told the post was the same as a previous reply :frowning:

9

Thanks for trying to help guys.

I have just tried PowerRetain 1

For my various switches I have an automation to check status on power up like:

- alias: "Power state on HA start-up"
  trigger:
    platform: homeassistant
    event: start
  action:
    - service: mqtt.publish
      data:
        topic: "cmnd/sonoffs/power1"
        payload: ""
    - service: mqtt.publish
      data:
        topic: "cmnd/sonoffs/power2"
        payload: ""

So I tried to add:

    - service: mqtt.publish
      data:
        topic: "tele/sonoffs/RESULT"
        payload: ""

Which hasn’t helped either.
I will set some more Input_Boolean’s and try that method.

10

I assume the RF Bridge publishes to an MQTT Broker. What kind of firmware is it using?

If it is Tasmota, I believe you need to set SensorRetain 1 to make it publish with retain=true. This instructs the MQTT Broker to retain a copy of messages published to it by the RF Bridge. As a result, subscribers connecting to the MQTT Broker (like Home Assistant after a restart) will get the current state of sensors handled by the RF Bridge.

11

Yes I am using Tasmota firmware.

I will give that ago thanks @123

12

OK, but be sure to review the documentation. There are commands for PowerRetain, SensorRetain, and SwitchRetain.

I don’t use Tasmota but it’s my best guess that, for an RFBridge, it’s the SensorRetain command that applies for your door/window sensors.

13

I have tried PowerRetain, SwitchRetain and SensorRetain and none seem to work.

I have also tried the recorder function:

recorder:
  include:
    entities:
      - binary_sensor.master_bedroom_window

Also tried

recorder:
  include:
    domains:
      - sensor

But again no luck :disappointed:

Will give boolean_inputs ago, but makes for a more messy setup.

14

Let me know if this is correct:

  • There is just one topic, tele/sonoffBridge/RESULT, representing the states of multiple sensors.
  • You use the contents of the payload to differentiate between the sensors. Effectively, the payload is used like a fingerprint to identify the sensor.

If all of the above is true then I don’t believe you can use retain to have the MQTT Broker store the state of each sensor. All sensors are represented by only one topic and only that single topic’s messages can be retained. In practice this means (at best) that at the moment Home Assistant reconnects to the Broker, it only has the state of the last sensor to have published something.

You’ll need another means to store the sensor’s state. I believe the value of an input_boolean survives a restart. It can be used (via automations) to store the binary_sensor’s state-changes and restore its state upon startup. It’s not pretty but that’s the current state of things (no pun intended).

1 Like
15

Yes I am just getting the RESULT bit ie

16:37:53 MQT: tele/sonoffBridge/RESULT = {“RfReceived”:{“Sync”:9510,“Low”:340,“High”:910,“Data”:“1234E7”,“RfKey”:“None”}}

or

16:38:01 MQT: tele/sonoffBridge/RESULT = {“RfReceived”:{“Sync”:9510,“Low”:340,“High”:910,“Data”:“1234E8”,“RfKey”:“None”}}

Etc and just using the “Data”
It doesn’t even retain the last value sent.

Not to worry I will setup some input_boolean’s

It’s also a shame the Door Class isn’t tri state instead of being just on / off as these sensors have a tamper code as well.
I will look into perhaps setting up a cover. Or I may just have a separate tamper sensor?

16

FWIW, my sensors publish on separate topics and use retain=true so their messages are retained by the Broker. Upon startup, HA gets the current state of all sensors (when it re-subscribes to all sensor topics). However, in your situation (with a single topic), it’s no longer worthwhile to explore why the last published message isn’t being retained.

Or I may just have a separate tamper sensor?

That’s what I’d do. For example, the climate component does not support the fan’s current state so I handle it using an MQTT Sensor.

  - platform: mqtt
    name: "HVAC Fan Status"
    icon: mdi:fan
    state_topic: "premise/home/thermostat/fanstatus"
    value_template:  >-
      {% set values = { '0':'Off',  '1':'On' } %}
      {{ values[value] if value in values.keys() else '?' }}
17

I have swapped it over to an input_boolean
Little bit messy but not too bad.

input_boolean:
  master_bedroom_window:

automation:
- alias: Window Open
  trigger:
    platform: mqtt
    topic: tele/sonoffBridge/RESULT
  condition:
    condition: template
    value_template: '{{ trigger.payload_json.RfReceived.Data == "1234EE" }}'
  action:
    service: homeassistant.turn_on
    entity_id: input_boolean.master_bedroom_window

- alias: Window Close
  trigger:
    platform: mqtt
    topic: tele/sonoffBridge/RESULT
  condition:
    condition: template
    value_template: '{{ trigger.payload_json.RfReceived.Data == "1234" }}'
  action:
    service: homeassistant.turn_off
    entity_id: input_boolean.master_bedroom_window

Just need to decide if to try a cover or install custom-ui to get the icons how I want them.

Shame you can’t use device_class: door on an input_boolean

18

I’ll throw out this idea as an alternative. I would continue to use a binary_sensor to represent the device’s state. It provides the best representation via its support using device_class.

The input_boolean would only serve to store the sensor’s state. In fact, it would be concealed from the UI using its hidden parameter. An automation, triggered upon Home Assistant’s startup, would use the input_boolean’s state to set the corresponding binary_sensor’s state.

There are other ideas in the following thread for storing values in some form of ‘global variable’ that can survive a restart.

1 Like
19

Here’s an interesting option.

20

That solution is an enormous kludge. Nevertheless, given the available options, it’s a good kludge. :slight_smile:

In nutshell, it’s splitting a single topic (representing many devices) into multiple topics (one per device). It allows you to subscribe to each unique sensor.

HA subscribes to the RF Bridge’s single topic, parses the received message into separate topics and publishes each one (with retain=true). Then it subscribes to each one of the topics it just published (where each topic now represents a unique sensor).

FWIW, if you are already running Node-Red, you can create a flow to do the same thing. It would subscribed to the RF Bridge, parse the incoming messages, and publish each sensor’s message in a separate topic (with retain=true). Now your binary_sensors can subscribe to unique topics whose messages are available when HA restarts. Nice.