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

3 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