Custom device classes

Voted :+1:

Please also consider to vote for the possibility to have an option like device_class for old-style groups:

1 Like

+1 from me!

1 Like

This is not something exotic that occurs in an edge case or here and there. I literally have multiple occasions where I scratched my head why this is not possible and I have to define duplicate template sensors.

One more vote from me. I have needed this several times for things like the screen is up or down. The bin is full or empty. I could go on.

1 Like

+1 vote! Was searching for a way to do this and…nope.

Another +1 here. Would LOVE to have this option.

And include “valve” as well for better representation of the ever increasing number of valves we control

I find it so annoying that this has never been implemented. There have been suggestions made around this topic for close to 5 years but absolute tumbleweed from the developers on it. I’m yet to see a single comment about why it would be a bad idea to have this.

It’s all very well declaring 2023 to be the “Year of the Voice” and having big plans for the whole year, but it would be nice if they could address some simpler functionality such as this, which would make a huge improvement.


I found this thread because I was looking to define my own device class. So I voted yes. This really seems to fit with the HA customization/configuration paradigm.

1 Like

Got my vote on this. Came across the situation while building a bed occupancy entity.

Please add this feature. Would make custom sensors (esp32/8266) much nicer to use.

The problem with this feature, is that it is disconnected between frontend and backend:

Meaning if we want to add a new class it needs to be updated in both the core and the frontend. As the icon information for example is clearly only available in the frontend (see code snippet above) while the textual content is available in the core:

What I am trying to say that my feeling is that to implement the functionality to be able to redefine the icons and state texts from config may be a bit bigger task. I will think about it a bit more, maybe there is a nice solution.

Ok looking a bit deeper, I think with the introduction of the “custom” device class it is possible to do it, as the current implementation in the frontend has access to the stateObj, so we can pass the icon name from the backend(core) to the frontend eith minimal change to the code and keeping backward compatibility like this:

export const binarySensorIcon = (state?: string, stateObj?: HassEntity) => {
  const is_off = state === "off";
  switch (stateObj?.attributes.device_class) {
    case "custom":
      return is_off ? stateObj?.attributes.icon_off : stateObj?.attributes.icon_on;

Of course for this the custom needs to be implemented in the core as well.

1 Like

Opened a pull request on the Frontend, will prepare one for the core too:

Just want to wait for the feedback on the Frontend.


Any progress? I, too think it would make a really nice improvement.


This would be exactly what I need, I am still fairly new and starting to really dial in my dashboard look, having a custom device class to create a “normally open” door so I can reverse my colors easily would be perfect, I want expected state to be green, and unexpected state red, but my exterior doors and interior doors have different expected states.

Adding my +1 - would be super handy for a few different types of doors/windows, as well as some sprinklers I have that show up as switches.

+1, found this thread after trying to do the same myself

very great feature!