"yes/no" binary sensor new device class

Feature Requests
1

Please consider adding the following device class:

yes for on
no for off

:slight_smile:

2

if you want this to be considered you’re going to have to add a bit more information like why you need it and can’t use the existing binary sensor.

3

because isn’t available? :slight_smile:

This is not really unpopular, and it kind of make sense it itself.
I would like not to have tens and tens of additional custom binary sensors with a template.

example “Firmware available?” yes or no

4

Duplicate of Binary sensor "yes" and "no" device_class for date ranges which has a few more possible use cases listed

5

tbh I don’t like at all that binary sensor has so many variations. It should be boolean true/false and nothing more. Open/Close, On/Off, yes/no, Safe/Unsafe, detected/clear and more should be choice of GUI layer

5 Likes
6

You can create a value template and make a binary sensor display anything you like. I know it can be a bit arcane and frustrating at first, but once you figure out the recipe for certain things, they’re easy to reapply. There’s even a utility for checking out your templates built into the GUI. It’s under Developer Tools >> TEMPLATE.

https://www.home-assistant.io/docs/configuration/templating/

https://www.home-assistant.io/integrations/template#renaming-sensor-output

Here’s an example from my configuration.yaml:

      alarm_panel_siren_active:
        value_template: >-
          {% if is_state_attr('alarm_control_panel.visonic_alarm', 'Panel Siren Active', false) %} Off
          {% elif is_state_attr('alarm_control_panel.visonic_alarm', 'Panel Siren Active', true) %} On
          {% endif %}

In this case, the integration’s <entity>.<attribute> outputs true/false and the template replaces them with a new entity that outputs On/Off.

1 Like
7

Yeah and to have as twice entities as needed :wink: I wouldn’t say it’s efficient solution. At best is a workaround. I would like to see consistent and efficient design. not system which requires hacks wherever you look at. this is what FRs are for.

1 Like
8

not efficient, and this needs to be replicated for many instances. It seems very versatile to have a yes or no status, I am very surprised to see many other got implemented first before this basic one…

2 Likes
9

Integration developers create whatever variable outputs they want. If I were in hell, I’d love to have some ice water. :wink:

1 Like
10

Perhaps there’s a better way than what you propose. If there was a standard way of remapping states from native to custom in GUI form (whether binary or multiple states), it could work similarly to declaring a Friendly Name. I envision it would be opt-in for the developer. Edit: Essentially, a generalized version of what @maxym described.

Of course, once this is done, there would be requests for numeric options. This would result in someone saying “there’s this thing called a ‘value template’.”

2 Likes
11

Yes, it’s an old request, but with the new helpers and stuff it’s relevant again.

I have for example a Template binary sensor that shows me whether the sun is within the specified corridor or not. True/False is enough for the logic, so it works, but since there is this thing called ‘Device class’, there should be a ‘Yes/No’ class if you ask me.

Now it shows on/off and there is no class that essentially returns/shows Yes/No or even True/False in the GUI/dashboard.

Yes/No or True/False, both are fine for my use case, but there currently is no option for as far as I know.

2 Likes
12

Make your case here:

I suggest BinarySensorDeviceClass.AFFIRMATION.

13

This topic is in the Feature Requests section. I don’t know what you’re try to say with making my case ‘here’.

14

You’re right. Somehow, I thought you were suggesting a similar, but different device class.

Apologies.

15

There’s already a duplicate request with over twice the votes as this one linked above. I suggest you make your case there & vote on that one