Customize text of `binary_sensor` on/off state

Feature Requests
1

I just got 2 z-wave door sensors. In my configuration I customized them to be opening type sensor_class.

# doors
binary_sensor.ecolink_doorwindow_sensor_sensor_5:
  friendly_name: 'Side Door'
  sensor_class: opening
binary_sensor.ecolink_doorwindow_sensor_sensor_6:
  friendly_name: 'Front Door'
  sensor_class: opening

I can then add them directly to my frontend in a group.

Doors:
  - binary_sensor.ecolink_doorwindow_sensor_sensor_6
  - binary_sensor.ecolink_doorwindow_sensor_sensor_5

And that looks like this:

But, if I want to display Open/Closed instead of On/Off, I have to create a sensor template. I’ve done this for my garage door for example.

sensor:
  platform: template
  sensors:
    garage_door:
      value_template: >-
        {% if states.binary_sensor.ecolink_garage_door_sensor_sensor_3.state == 'on' %}
          Open
        {% elif states.binary_sensor.ecolink_garage_door_sensor_sensor_3.state == 'off' %}
          Closed
        {% else %}
          n/a
        {% endif %}

And the customization for the garage door:

sensor.garage_door:
  friendly_name: 'Garage'
  icon: mdi:glassdoor

And that looks like this:

However, because this is now a sensor and not a binary_sensor, you can’t set the sensor_class and it will no longer use an icon that changes based on the state of the sensor.

I think it would be neat to be able to customize the text displayed for on/off states of binary_sensor's.

You could handle this in customize possibly, like so:

# doors
binary_sensor.ecolink_doorwindow_sensor_sensor_5:
  friendly_name: 'Side Door'
  sensor_class: opening
  alias_on: 'Open'
  alias_off: 'Closed'
binary_sensor.ecolink_doorwindow_sensor_sensor_6:
  friendly_name: 'Front Door'
  sensor_class: opening
  alias_on: 'Open'
  alias_off: 'Closed'

And then that would get you something like this in the frontend:

6 Likes
2

Would be so much easier and cut down on a number of templates I have!

2 Likes
3

Does using a binary template not do this?

4

The idea is to have this done in customize and not use a template for reformatting something as simple as the names of the states. Please reread the OP.

5

A binary_sensor template is only allowed to have the value of on or off, nothing else. If you try to make a binary_sensor template with values other than on or off it will not work. So like I showed for my garage door, you can make a sensor template. But then you wipe out the icon and sensor_class functionality of a binary_sensor.

1 Like
6

I understand. This goes along with my feature request here Where i wanted to customize the icon based on state.

While I know it does not solve your issue I was more or less curious if using a binary sensor template changed the icons based on state.

7

Makes sense. Thank you.

8

Using a binary_sensor template will change the icon based on state and what sensor_class you set for it. But the text will always be on or off.

9

Would love this feature to allow us to customize a binary sensor to report ‘Open’ or ‘Closed’. Setting up a binary sensor for garage roller door looks odd as ‘On’ or ‘Off’. Whilst I know we can do a regular template, I like the icon status changing based on condition.
Anyone know if it is on any roadmaps?

10

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

1 Like
11

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
12

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

13

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?

14

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

15

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.

16

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

17

I agree that this would be a useful thing to have

18

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.

20

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
21

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!