Custom Device Class for Binary Sensors

[okridgway]

Context

Currently, there are 29 different classes of binary sensors. These classes range form "running" to "safety" to "cold" and everything in between. All of these classes are aimed at providing additional behaviors by default based on the device class so that the icon/color/state may be more intuitive when viewed in the front end UI.

Proposal

I would like to propose the addition of a "custom" class that would enable the user to specify what icon, color, state text, etc. should be used when on/off.

Consequences

The IOT world is exploding and if people find that HA can't easily represent their needs (and a spouse keeps wondering what it means when it says "cold" is "on") they are less likely to stick with HA which would ultimately result in less support.

A custom device class for binary sensors would open up a WORLD of possibilities that are currently not possible with the existing list. To illustrate this point, consider which binary sensor you would use for the following scenarios:

• plant watering sensor (not thirsty/thirsty)
• status of alarm system (armed/disarmed)
• cat bowl feeder (empty/not empty)
• mail in mailbox (you have mail/no mail for you)
• broken glass detector (no break in/ possible break in!)
• bath tub (filling/filled)
• etc

You may argue that all of these things can be answered with a simple "true" or "false" / "on" or "off", but that is besides the point given that all binary sensors can by definition be answered with a true or false. The purpose of the additional classes is to provide added customization for scenarios that don't quite make sense with just an "on" or "off" label. Thus, instead of having to manually go through each users request to add an additional class, I would like to propose the addition of a custom class to take care of this issue once and for all.

From a development perspective, it does not make sense to continue adding device classes when someone comes up with another class that they need. It would be far easier to just have a handful of default ones (perhaps the existing 29) and then a custom option so that users can fiddle with it until their hearts content.

[balloob]

The purpose of device classes are not to have a better translation in the UI, it's to standardize the device type in the core. Which has as side effect better UI. Device classes allows HA to export entities correctly to other home automation systems like Google/Amazon/HomeKit and other consumers of our API. Making up your own device classes won't do this.

If you just want to have an entity with your own UI strings, use a sensor and just set the value to "filling"/"filled" etc.

[LxFx]

@balloob can different icons be used this way for both states?

[frenck]

@LxFx All entities have an icon property that can be implemented.

[LxFx]

@frenck a single icon per entity, yes. But an icon for each state?

[thecode]

When implementing an entity you can return a different icon for each state (taking in mind that architectural discussions are for someone who wants to implement something in core). A user can use template you can have a different icon for each state. Anyhow it makes more sense to add support for easy customization of binary sensors icons rather than a custom device class.

[jeeftor]

I'd love to have a generic ENABLED/DISABLED entity class for sensors instead of on/off

[nistvan86]

I think multiple icon fields for entities would solve this, similarly how MQTT entities do payload mapping to different states (payload_off, payload_on, etc.).

eg. I'm currently implementing my own thermostat automation in Node-RED which publishes its own MQTT device and sensors to HA, and it would be nice for the "heating state" sensor to have distinct icons for turned on/off states (icon_on: mdi:radiator, icon_off: mdi:radiator-off). None of the device_class ones usable in the discovery data format match my use case.

[Swamp-Ig]

it would be nice for the "heating state" sensor to have distinct icons for turned on/off states (icon_on: mdi:radiator, icon_off: mdi:radiator-off)..

If you're using node red, you can dynamically change the icon attribute depending on the state.

[frenck]

Closing this architectural proposal. The use of custom device classes has been completely removed (across the board) and typing for that has been stricken.