Customize text of `binary_sensor` on/off state

I surf the pull requests regularly to get a heads up on what’s coming and I haven’t seen anything.

1 Like

The community site isn’t letting me vote for this request for some reason, but I too would love to see this kind of customization. It seems pretty straightforward to do; I might try implementing it and submitting a pull request.

1 Like

Were you on mobile by any chance? I seem to have issues voting if I am on anything but the desktop.

Nope, I was on my desktop (Windows 10 + Chrome). I tried Edge, too, but got exactly the same behavior. Clicking the “Vote” button does nothing the first time, then subsequently pops up a small empty white box. Clicking again hides the box, and the cycle repeats with no votes being counted.

Anyway, that’s not too important.

I tried my hand at the modification last night, and I was able to make some progress. However, I ran into an issue in that other parts of the code (e.g. icon CSS class determination) depends on the state value being “off” or “on” exactly. I’m still trying to find the correct point(s) in the core or frontend code to rewrite the displayed output but leave the rest of the binary sensor logic untouched.

Here’s a question: for an aliased output of “Open” or “Closed,” would it be better for the state history to log the same thing (“Open” or “Closed”), or should it remain as the original “on” or “off” despite the alias?

I’d say the history should log Open/Closed.

Well… if it’s just an alias, then the sensor is really on/off. So I take back my previous statement, and say it should log on/off.

I could see this being very useful and mostly a cosmetic change.

I agree that this would be a useful thing to have

I’ve never understood what the function of a sensor class is if not to set the state values.

If something is an Opening class and HA knows that, why wouldn’t the state values be Open/Close instead of on/off?

I’d settle for this support in the interim of being able to set the values in something other than a template sensor. It just makes no sense to me that in order to get an Opening class sensor to read Open/Close that I have to create yet another sensor via a template and display that sensor instead. It creates another level of complexity and overhead when the info is already known to HA.

But to be fair; I’m not a dev and there may be a perfectly valid reason why it doesn’t work this way. If there is, I wish someone would explain it to me.

My guess would be so that there is consistency between all the binary_sensor components. You only need to check on/off for all binary_sensors instead of on/off, open/close, moving/stationary, etc. The binary sensors do have the is_on property that could be used instead of checking state == on, which might be the better approach but someone would need to ensure that every component specifies is_on and every place that checks the state of a binary sensor uses is_on rather than state == on. This may or may not require updates in a lot of different places (I know the frontend uses data-state=“on” to set the color when they are on, so at the very least that part would need to be updated).

Also, there is a PR up that could at least let you accomplish this, although not exactly very easily. You would still need a template sensor to customize the text and then create a custom state card that looks for Open/Close and sets the color how you want.

2 Likes

So what is the sensor class used for then? It looks like that was the intention somehow but it never got fully developed.

Thanks for this insight, you explained it really well. Also thanks for the heads up on the PR. I’m going to have to delve into that further!

As far as I can tell, it’s only used for the icon image.

1 Like

Thanks; this makes sense and it’s been bugging me for awhile!

If that’s the case, that it only sets the icon image, maybe it could be extended to change the text too? If just the opening device class were expanded to include this visual text change it would be trivial for users to implement (or possibly completely transparent for them to implement if they’ve already implemented it for the icon change). It should probably not be more than just cosmetic though - if you setup an automation and base it on the condition of a binary sensor and use its alias, you’d want it to act accordingly as if you had used on/off instead. As long as open/closed was just a visual/cosmetic change, I imagine that would be fine.

Just some additional thoughts, I do like this idea. Has anyone started on this yet? Anything similar being considered?

Thanks!
-Chad

is there any final solution to this - just facing this myself

I too would love an official solution for this!

1 Like

This is the solution:

HI,

I managed to get the open / closed state by adding entry in customize.yaml for the sensor i want.

binary_sensor.sensor:
friendly_name: ‘Bedroom window’
sensor_class: opening
device_class: window

3 Likes

Hi,
I have à Fibaro door sensor V2. I have this configuration for this sensor:

Porte de garage

  • platform: template
    sensors:
    garage_door:
    device_class: garage_door
    friendly_name: “Porte de garage”
    value_template: >
    {% if states.sensor.capteur_garage_access_control.state == ‘22’ %}
    true
    {% elif states.sensor.capteur_garage_access_control.state >= ‘23’ %}
    false
    {% endif %}

I can only use ‘true’ and ‘false’ which display ‘Open/Closed’ on Front from HASS and ‘on / off’ value in the states from HASS. Other values than ‘true/false’ doesn’t work but I’m French and need to display state ‘Ouvert/Fermé’. Is it possible to customize the states ? In several posts from the forum they use ‘open/closed’ or ‘on/off’, also I don’t understand why I can only use values ‘true/false’. Does anyone have an explanation ? Thank you in advance for your answers.

Hello @Zigloo, I’m Frenn too and I would like to do the same things. Display “Ouvert” instead of Open and “Fermé” instaed of Close.

Did you find a solution?

We can speak in French in private if it’s easier for you.