I’ll try this shortly. Thanks.
I am having this issue since the 2022.2 update and find it quite annoying. I have several 433mhz door/window sensors that are connected via an sonoff rf bridge (tasmotized). Ever since this update my sensors are moving to an “unknow” state after restarting HA or after a extended period of time. Is there an official work around for this? Is there a Tasmota command to force it to “retain” sensor states? I would prefer that these sensors display their last “know” state instead of changing to unknown.
Anyone?
interesting. Only my battery level does this (because it doesn’t broadcast “good”. How do you have your sensors setup? I believe I have it retain last state.
I use the demux option.
d = { '9F799A':['sensor1','ON','true'],
'9F799E':['sensor1','OFF','true'],
'9F7996':['sensor1_battery','ON','true'],
I believe the true retains it.
Sensors reported through the bridges are “stateless” if your setup is anything like mine.
My bridges just report the code received, which is then decoded by a python script into the state topic to be published. Thus no setting on the bridge can have an effect.
My short term fix is to publish on “off” state for every binary sensor in “unknown” at startup. I’ll post my automation once the weekend is over.
My preferred long term solution is to have an assumed state option on any MQTT binary sensor or switch, but I don’t hold out much hope for that happening.
2 Likes
This is exactly what I want! That would be great. I did find a python script that might do it, but I’ll wait for your info.
1 Like
use strategy 2 :
Works perfect.
I use strategy 2 - when you say “works perfect” do you mean your sensors don’t come up as “unknown” after reboot?
Yes. You just need to set them as retained.
This doesn’t work if it is battery sensor or leak detector.
Ok - the problem occurs when a sensor only has one state - “on” - and no off state…
Sensors that publish both an on and off are fine.
I am going to have to think of another strategy to handle these.
1 Like
Are you using off_delay?
Or are you saying that option has ceased to work correctly after the recent introduction of an unknown state for MQTT sensors?
I get what you guys mean with the “unknown” state at Home Assistant reboot, I have the same.
And in my automations I did a test of the button going from “OFF” to “ON” but the button is only a pushbutton and will never send an OFF signal to RF.
Result after reboot HA the state is OFF, when I push the button it goes to “ON” and because I set an off_delay of 1 after one second the state will go to OFF.
Issue: the first time after reboot the button will not work as it goes from “Unknown” to “ON” and not “OFF” to “ON”
Example of 1 of my buttons:
- platform: mqtt
state_topic: "home/sonoffRemoteB1"
name: 'Sonoff Remote Button 1'
off_delay: 1
Python script:
d = { 'code8E7218':['sonoffRemoteB1','ON','false']
}
p = data.get('payload')
if p is not None:
if p in d.keys():
service_data = {'topic':'home/{}'.format(d[p][0]), 'payload':'{}'.format(d[p][1]), 'qos':0, 'retain':'{}'.format(d[p][2])}
else:
service_data = {'topic':'home/unknown1', 'payload':'{}'.format(p), 'qos':0, 'retain':'false'}
logger.warning('<rfbridge_demux1> Received unknown RF command: {}'.format(p))
hass.services.call('mqtt', 'publish', service_data, False)
The Solution to get an “OFF” state in stead of “Unknown” after reboot of Home Assistant:
Make a script to set the state of the devices to “OFF”
s:
alias: Startup RF Devices
sequence:
- service: mqtt.publish
data:
topic: home/sonoffRemoteB1
payload: 'OFF'
mode: single
add an automation that runs after startup of Home Assistant:
- id: '1549662264057'
alias: Home Assistant ON
trigger:
- event: start
platform: homeassistant
action:
- service: script.s
data: {}
Ofcourse you can add the MQTT publish directly in the startup-automation, but I like to keep it organised.
Hope this helps you guys.
2 Likes
Thanks. Will try this.
edit: This worked. Set state to OFF! Thanks.
Yes I am using off_delay, these sensors have worked for a while (years) but the behaviour has changed in a recent release (2022.2).
That’s fine - I just need to come up with a strategy for handling it. The issue is not that it’s not turning off after triggering in HA, it’s that the state on restart is now unknown. I will manually publish an off state like the example given and it should be ok.
1 Like
The issue here is that a binary_sensor that employs off_delay doesn’t store its state value on the MQTT Broker. When off_delay automatically sets the value to off it’s held exclusively in Home Assistant’s state machine. When Home Assistant starts, it subscribes to the binary_sensor’s MQTT topic and receives … nothing (because there’s no stored value available). In the past, it would report off even though it received nothing (now it reports the value is unknown which is a more accurate assessment of the situation).
One way to ensure the off value is available to Home Assistant on startup is to publish it as a retained message whenever off_delay sets it to off. “Retained message” means the value is stored on the broker and ensures it’s available to Home Assistant when it connects to the broker and subscribes to the binary_sensor’s topic. To achieve this, all that’s required is a simple automation employing a State Trigger and MQTT Publish.
Another way is what DaBIGOne suggested and that’s to publish off to the binary_sensor’s topic exclusively on startup. Basically it’s the same principle (ensure the broker is primed with the desired state value) but only done on startup.
Whichever one you choose to implement, both can be made to support multiple binary_sensors with just a single automation.
EDIT
alias: Publish off
trigger:
- platform: state
entity_id: binary_sensor.whatever
to: 'off'
action:
- service: mqtt.publish
data:
topic: topic/for/whatever
payload: 'OFF'
retain: true
1 Like
Happy to report that the overall solution provided by @francisp and the battery state off script/automation provided by @DaBIGOne solved my issue(s). My door/window sensors are now showing their retained state on a HA restart and the batteries are showing a normal (off) state as well.
This is a great community that always has a solution for me 
1 Like
If the binary_sensor reports on, to indicate low battery, what will happen when you restart Home Assistant? The startup automation will set it to off.
How is your low-battery binary_sensor configured to mitigate this?
I agree. Great community!
I am thinking about setting my battery sensor(s) to retain the settings in MQTT (change the false to true in my d below. Then only set the automation to an off state if the sensors are in an unknown state
d = { 'E3E20A':['sensor1','ON','true'],
'E3E20E':['sensor1','OFF','true'],
'E3E206':['sensor1b','ON','false'],
'E3AC0A':['sensor2','ON','true'],
'E3AC0E':['sensor2','OFF','true'],
'E3AC06':['sensor2b','ON','false'],
'F3AA0A':['sensor3','ON','true'],
'F3AA0E':['sensor3','OFF','true'],
'F3AA06':['sensor3b','ON','false']
}
Yup, a bit more to consider than merely forcing everything to off on startup. In addition, don’t forget to take into account what happens when Reload Manually Configured MQTT Entities is executed (unless the entities are configured via MQTT Discovery).