Configuration of binary sensors? Value is now unknown?

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.

Can you get the devices to send retained mqtt messages?

That way Home Assistant will read the retained states in the broker when it starts.

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.

Thanks for your help.

Yeah that precludes using retained messages.

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'.

I’ll keep that in mind. Is there anyway i can change how the sensors look on the dashboard ?

Actually i don’t seem to mind to much about the original ‘unknown’ value. They change to the right state once something has been detected.

Thanks for your help.

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.

1 Like

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).

Streamlining! :rofl:

I would consider a binary_sensor that could only report one of its two states very streamlined … to a fault. :wink:

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).

1 Like

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?

Can you post a screenshot of a binary_sensor whose state is unknown but is displayed as on in the Lovelace UI?

I was wondering what you meant by a “button icon” and now I understand you are referring to a badge.

Badges are widgets that sit at the top of a Lovelace panel, above all the cards.

You’re right, they don’t indicate the binary_sensor’s true state when it’s unknown. I suggest you report it as an Issue in the Frontend repository.

Sorry, your right. Here is one with a button…

If you mean Button Card then you can report that one as well.

I’ll leave that one to you. I’m afraid I might confuse folks with my limited ability to properly describe the problem. Thanks for your assistance.

Then it won’t get done and you’ll have to accept the way it works now (or rather the way it doesn’t work).

I’m unaffected by misleading badges and Button Cards (due to various reasons) so I have no need (or interest) to report it.

1 Like

Well, maybe I also can give it a try…

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.

1 Like