If the RF bridge doesn’t publish its payloads as a retained message, the payload is not stored on the MQTT Broker. When Home Assistant restarts it re-connects to the MQTT Broker and receives no information about the binary_sensor’s current value. As of 2022.2 that situation is reported, quite truthfully, as unknown.
In previous versions, it wouldn’t reflect the actual situation (that it didn’t know the device’s state because it didn’t receive any information) but simply fake it and report (without any evidence) that it’s off.
This issue of “not knowing” is eliminated if the RF bridge publishes its payload as a retained message because it’s stored on the MQTT broker. On startup, Home Assistant connects to the broker and immediately receives the stored value.
I understand. I wasn’t able to make the RF Bridge send MQTT with the retain flag. I’m not learning intricacies of Tasmota rules and payloads for this. Tried with help of Tasmota Discord, couldn’t do it.
Fair enough; it’s why I stated earlier that the problem goes away if you’re using one of the two strategies in the linked post (it re-publishes the received data as a retained message). Anyway, that ship has sailed because you’re eliminating the RF bridge.
You should known that the unknown state is now a valid state for all binary_sensors. So don’t be too shocked if you see it appear elsewhere, like with the Zigbee sensors you’re purchasing.
You could technically store the state prior to restart in a variable (using a custom integration called “hass-variables” that survives restarts) and then set those entities to those states after startup using the set_state script.
the only time that it wouldn’t be reliable is on the very rare occasion that the door, etc gets opened/closed during the time it takes for HA to startup.
TBH, if I had this issue I would likely do it that way myself. especially if it was just a few entities. And it’s cheaper than buying new devices since the code is free.
I’ll probably repurpose them for something else, I mean the Zigbee sensors are $16 for two of them. I don’t want to waste any more time on this stuff. I love tinkering with HA but this was getting a bit much
So do your RF binary_sensors. The difference is how Home Assistant integrates with them (meaning how the integration handles device information, specifically on startup).
The irony is that it’s subject to the same issue that caused you grief with the RF bridge, namely how payloads are published to the MQTT broker (retained or not).
Ensure your devices, in Zigbee2MQTT’s configuration.yaml file, are configured appropriately.
I have the same problem after updating to 2022.2. My RF bridge sensors all show ‘unknown’ after a HA restart. Using the demuxing strategy for rf bridge receiving data and retaining them only works if the sensor both sends the ‘on’ and ‘off’ state like the door contact sensors. But motion sensors only sends ‘on’ when motion is detected and never off. This means those sensors stay in ‘unknown’ state until motion happens. And the off_delay does not work with ‘unknown’ states. So it would really help if at HA startup a script can force the unknown entity states to a default known state, whatever that may be.
It will maybe contradict with the HA philosophy, but at least let this be possible with a script for those who explicitly want this behaviour (forcing the state of entities).
I’m not sure what I’m doing wrong. 1. I couldn’t figure out how to install the python script via a HACS repository so I manually installed it. 2. I cant get it to reset my motion detector (the developer tools menu works fine). Here’s the code I’m using:
service: python_script.set_state
data:
entity_id: binary_sensor.smart_motion_sensor
state: off
Ive tried off, 0, ‘off’ and false in the state param with no success. Any help appreciated. PS: It seems crazy that there is a developer tool that we can use in the UI but not programatically!
Any help appreciated
This works great, thanks! I’ve looking for something like this to set the status of my “smart” shutter to something other than unknown. It never occurred to me to set it via API calls.
It is frustrating that there isn’t a baked-in command for setting the initial state of sensors. My smoke alarms come up as ‘unknown’ until smoke detection fires off an MQTT message. ‘Unknown’ bothers me, I want it to say ‘clear’. Unless there’s smoke, of course.
So, here’s the solution:
Get the set_state.py python script
Save the script in config/python_scripts (you’ll have to create this directory)
Add the line “python_script:” to your configuration.yaml
Create an automation that calls the service “python_script.set_state”, with the data “entity_id: [name of your sensor entity]” and “state: [desired state text]”.
Your automation (viewed in YAML editor) should look something like this:
alias: Init Sensors
description: Set initial state at HA boot for sensors that only update on change
trigger:
- platform: homeassistant
event: start
action:
- service: python_script.set_state
data_template:
entity_id: sensor.smokebsmt
state: Clear
mode: single
What good is it to set an entity state?
Home Assistant Developer Tools → States clearly says: “Set the current state representation of an entity within Home Assistant. If the entity belongs to a device, there will be no actual communication with that device.”
So setting a state doesn’t do anything, as far as I understand…
well, then why did someone bother to make a python_script.set_state when setting the state does nothing ?