WTH is there no binary sensor custom Device Class?

Archive Month of "What the heck?!" 2022
1

Rather than maintaining an ever growing list of binary sensor device classes to support things like people having windows that open horizontally or gates or mailboxes, etc…

WTH not implement support for custom device classes that could possibly be defined like this:

device_class:
  - <domain>
      - <class>
          state_on: <on state word>
          state_off: <off state word>
          icon_on: <mdi icon for on state>
          icon_off: <mdi icon for off state>

The class would have to be unique and not clash with existing core device classes for the domain.

For example:

device_class:
  - binary_sensor:
      - gate:
          state_off: 'Closed'
          state_on: 'Open'
          icon_off: 'mdi:gate'
          icon_on: 'mdi:gate-open'
      - maibox:
          state_off: 'Empty'
          state_on: 'Full'
          icon_off: 'mdi:mailbox'
          icon_on: 'mdi:mailbox-up'

All configuration options could be optional with undefined options defaulting to the device_class: none states and icons.

This could also be extended to other binary state domains like switches and covers:

device_class:
  - binary_sensor:
      - gate:
          state_off: 'Closed'
          state_on: 'Open'
          icon_off: 'mdi:gate'
          icon_on: 'mdi:gate-open'
      - maibox:
          state_off: 'Empty'
          state_on: 'Full'
          icon_off: 'mdi:mailbox'
          icon_on: 'mdi:mailbox-up'
  - switch:
      - television:
          icon_off: 'mdi:television-classic-off'
          icon_on: 'mdi:television-classic'
  - cover:
      - double_garage:
          state_off: 'Closed'
          state_on: Open'
          icon_off: 'mdi:garage-variant'
          icon_on: 'mdi:garage-open-variant'

The cover also has optional opening and closing states. If this preculdes its inclusion, so be it. The main request is for binary_sensor custom device classes.

This request specifically does not include custom device classes for the sensor domain. Control over the classes in that domain needs to be maintained (e.g. for energy dashboard).

I also relaise this request may have become a bit more complicated due to recent improvements to the automation editor, as it is now able to show translated states.

There is a currently open feature request for this that has garnered 78 votes at the time of publishing this post.

Thank you for your consideration of this request and continued interest in user feedback.

2

I very much like this idea!

I don’t think this is a real issue. As users can set the strings to reflect their manual states in their own native language if they choose so. So HA only needs to reflect the set state when on/off and does not need to be able to translate certain strings that are not located in Lokalise.

3

I’m using “translated” here to mean that and the translation from the states on/off to the device class words for on and off.

4

Is part of the problem that these sensors aren’t really binary? e.g. a battery might have a threshold where you consider it to be low, etc.

Still you could imagine a binary_sensor threshold_sensor etc, you can certainly imagine classes.

5

No. This is specifically targeted at domains with binary states that currently support binary device classes.

Binary sensors and switches.

And maybe covers - though that domain has binary states for open and closed it also supports opening and closing and optionally a position. So it really is a “maybe include it if possible” as far as this wth goes.

6

@tom_l You closed WTH can't I specify on and off icons for toggle helpers? as a duplicate but it really wasn’t. Your proposal is more complex and while it may work to get custom icons on a binary sensor it is overkill. As the OP of the other WTH was asking, I would like to simply be able to set an additional icon for the binary sensor. Right now it allows you to change the icon but it is static, if they add the option to set a default on and off icon you can make it dynamic without needing a template.

1 Like
7

Thanks @aruffell !

To be honest I was completely confused by @tom_l 's suggestion so, I couldn’t tell if it did what I was suggesting.

1 Like
8

It’s not overkill, it’s how home assistant works. Binary states (and icons) are translated by device classes.

1 Like
9

@tom_l It is overkill when all I want is to define 2 icons for a toggle. Your proposed solution makes sense when needing to define a class that HA doesn’t define yet and that would be used extensively in a user’s scenario but in my case, for example, I create a toggle to keep track of whether my (invented example) electric fireplace is on or off using nice icons for both states. I have 1 fireplace so why bother with the added complexity of a new device class when I can address the need with a simple toggle? Right now I would be able to set a flame for it, and it would change color if on but the icon itself would be static. The feature requested is simply to allow for another icon, something that can be done with templates but in a more complicated way. I use toggles extensively for controlling settings of my automations in node red, none would benefit from custom device classes… but don’t get me wrong, I see the clear value of your proposal, just not in @templeton_nash and my use case.

Edit:

My icon here is for an alert regardless of whether I have an issue or not. The feature would easily enhance this.

Screenshot_20221023-082057_Home Assistant
Screenshot_20221023-082057_Home Assistant1440×3200 147 KB

2 Likes
10

it would be as simple as this:

device_class:
  - binary_sensor:
      - fireplace:
          icon_off: 'mdi:fire-off'
          icon_on: 'mdi:fire'

I’ve opened the other topic again. Go nuts.

1 Like
11

Bare minimum it would need to work a little different. It would need to handle state translations and icons for yaml.

device_class:
- binary_sensor:
  - name: Fireplace
    state:
      'on': 'Lit'
      'off': 'Off'
    icon:
      'on': mdi:fire
      'off': mdi:fire-off

I’d argue that it should be a helper that creates an entity with the state that counts the number in use.
The system would have to register the device_class and ensure that it doesn’t interfere with existing device classes. And it would need to be usable in the UI for Display As selections. The UI version of this would have a similar setup with states and icons. Under the hood, it would dynamically generate the translation files that the device_class integration uses instead of having a hardcoded externally managed translations file like the other integrations.

12

So my minimal example would work if they were happy keeping the on/off state and only wanted to change the icon.

13

Like this feature! I’d add that it would be good to be able to override the default device classes too.

1 Like
14

like this idea!