I understand some changes were made in the latest updates. Unfortunately i don’t know enough on how to have these binary sensors reflect the correct state or how to fix my dashboard.
I see this with :
# 433Mhz PIR sensors, also added in group.yaml
- unique_id: studyroom_pir_motion_sensor_1
platform: mqtt
name: 'Study Room PIR Motion Sensor 1 motion'
state_topic: 'home/studyroom_pir_motion_sensor_1'
off_delay: 5
device_class: motion
and the EufyMqtt integration as well, the state is all unknown. I understand unknown is now the default startup value? How can i fix these sensors so that they show like they did before ? It seems to affect MQTT mainly.
Not sure about the old Eufymqtt integration, but for the regular 433Mhz sensors, I can yes. But not sure if it will work they way it should. I’m following strategy 2 as listed by @123
And he mentions that:
The other two sensors (motion sensor and button) don’t report their off state. We use the off_delay option to automatically reset them to off. However, this technique does not publish off to their respective MQTT topic (i.e. once set to on the topic will always show on). Therefore the automation should publish to their topics using retain: false. Otherwise,if using retain: true, when you restart Home Assistant, it would erroneously set these sensors to on.
So not sure if that will work for my 433 motion or flood sensors.
It shouldn’t affect your automations too much. Just be wary of using from in your state triggers. If you want to trigger when changing to: 'on' it could now be from: 'off' or from: 'unknown'.
The display actually now reflects the real state of the sensors. Until an update is received, the state isn’t actually known. Previously it was just assumed the state had not changed since a restart. This is now the same behaviour as all other sensors in HA.
Seems to me that one could create an automation, with a State Trigger, to monitor binary_sensors that don’t report their off state. When it detects a change from any state to off, it publishes off to the binary_sensor’s topic (as a retained message). Now when Home Assistant restarts, off is received from the MQTT Broker (as opposed to no value at all, which Home Assistant reports as unknown).
I would consider a binary_sensor that could only report one of its two states very streamlined … to a fault.
Seriously, this kind of sensor cuts its communications traffic in half by not reporting when it turns off. For home automation purposes, that’s not particularly practical so Home Assistant allowed one to fake the off state using expire_after.
The problem is that it’s fake; it’s a state value that can never be acquired from the binary_sensor. So on startup, the truth is that the binary_sensor’s state is unknown. In the past, Home Assistant simply made an assumption that the binary_sensor’s state is off (on startup) but that’s no longer the case. It now reports that it doesn’t know the binary_sensor’s state (i.e. it’s unknown).
If a user doesn’t want to see the truth (that the state is unknown) they have to create a mechanism to record the off state (such as with the technique I described above if it’s an MQTT Binary Sensor).
From a practical perspective, the real issue seems to be that the button icons, which many still use, reports “on” for an unknown state. That was good to alert us of the change and our need for action, however it’s wrong. If the “From” “off” is simply removed from an automations trigger, automations seem to respond to an “on” state from either “unknown” or “off”. It would seem reasonable, for use cases that I’m familiar with, to allow the default icon state for unknown to be “off” or perhaps a third icon state for unknown?
If you have a binary PIR motion sensor which only sents a RF code when triggered. The initial state in former HA versions was Not Detected. Now the initial state is ‘Unknown’. In the tutorial from Drzzs, he made an automation that, if triggered from ‘On’ to ‘Off’ the motion is detected (MQTT signal translated by the Bridge) AND a fake change tot ‘Not detected’ after a few seconds.
BUT now the very first time after HA is booted, there is NO RF signal from the PIR sensor, so the state is ‘unknown’ AND the automation is not triggered because de triggerchange is from ‘unknown’ to ‘on’, instead from ‘off’ to ‘on’.
In my opinion you should be able to define the initial state, at startup. I know it can be done by running a script at startup to define al unknown sensors to ‘off’ but, that is not the question.
Just wondering.
Why there is no initial_state: like for other sensors?
It would solve all problems. Who needs a binary that starts with off, could do there, insted of reinventing the wheel.
Anyway, a BINARY with 3 states it’s not BINARY.
