Custom device classes

Feature Requests
16

besides this (+1 mine is there) I also wroteup add on/off options for icon · Discussion #13700 · home-assistant/frontend · GitHub

so we can set an on/off icon on any entity, and not only a generic icon and not specifically requiring a device_class at all.
Tbh, its a bit if a mystery the current HA frontend lacks that rather basic functionality in UX and feedback.

(just so you are aware: all of these options/wishes on states used for the icon selecting mentioned above are available with custom-ui, but I dont want to advertise that anymore…)

18

I think an easier starting point is simply if I assign an icon x=mdi:gate
then if x-open exists (mdi:gate-open), then use it when the state is on/open.
Most icons are already named like this. It wouldn’t need any definitions at all.

1 Like
19

This proposal far more flexible and powerful. Feel free to open your own request.

20

But not all and therein lies the problem… There’s no control over the MDI set (from HA) and there are other sets people use too. This is what’s called a tight coupling between “systems” which generally is a bad idea.

2 Likes
21

Another vote from me!

1 Like
22

Voted :+1:

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

1 Like
23

+1 from me!

1 Like
24

Yes, PLEASE!!
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.

25

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
26

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

27

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

28

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

29

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.

3 Likes
30

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
31

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

32

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

33

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.

34

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
35

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

Just want to wait for the feedback on the Frontend.

3 Likes
36

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