How to customize device_class in Hass 2021.12?

Now that Hass 2021.12 removed the customization panel (why??? This UI update is really crappy IMHO), how can it be done to change a binary_sensor device_class ?

I’ve used the customization panel to change e.g for windows and doors.
Now, if you don’t want to touch yaml, you’re stuck with the white square icons.

Maybe the customization panel wasn’t the best tool possible, but now there’s nothing left but yaml.

Could the devs bring back this panel until a better UI is found ? Or maybe there’s something new I didn’t see ?

That’d be great to have a button/tab in the entity pop-up that brings back this customization/advanced settings for the entity.

The reasons were given in the release notes. It’s not coming back.

A small explanation why it has been removed:

With customize, one is changing the state machine directly, without any checks. This comes at a risk. Additionally, for many use cases (like: name, icon, device class) one should edit the entity via the UI instead, which is possible for the greater part of the entities nowadays.

The old customize UI is confusing in many ways and has a level of power that, if wielded incorrectly, can have unforeseen consequences. Someone found and used the customize UI first, and then things are out of sync throughout the UI, as the internal entity registry would show the old values.

The customize UI also relied on setting up an include and YAML configuration to begin with; which already made it an advanced feature.

Therefore, the customize UI was removed and remains available as an advanced YAML feature, additionally we have added the capability, to adjust the common device_class changes using the “Show as” feature while editing the entity from UI.

However I can’t find this “Show as” feature anywhere.

2 Likes

The “Show As” feature was added to the entity dialog so it’s available for every device without having to go to a special menu. Much more convenient, in my opinion.

Ok I cleared my cache but I only see that for binary sensors. What about sensor device classes?

https://www.home-assistant.io/integrations/sensor/

And switch device classes?

And cover device classes?

1 Like

I do see that there’s some inconsistency on where these are implemented. I only override device classes for binaries. It’s unfortunate that it isn’t for every entity… The omission makes it feel like the decision was not well thought out.

That said, if you’re using templates to define covers, the device class can be specified, same goes for template sensors. Unfortunately that doesn’t help for non-templated devices.

yea I do not have this option on my zwave ring contact sensors. I do have it for my aquara door sensors. very inconsistent and a little annoying that they took something away while only half baking in a replacement.

Hah. After multiple reloads, I finally had this option. Thanks. That’s indeed better than the customization UI.
Would it be possible to have the same option for the entities that don’t have a unique id then ?

1 Like

How did you get this to show up? What did you reload? Did you unpair the device from HA and try again? I have three contact sensors. One is a more recent smartthings zigbee sensor. Two of them are a little older smartthings sensor. The newer one has the Show as option, the older ones do not have the show as option. How do I get the show as option to show up for them? Help would be appreciated!

I haven’t seen this option anywhere yet, not in browser, not on mobile. I reloaded, restarted, crtl+F5, shift-F5, what cache are you referring to and how do you clear it?

Yeah, same here.
I have curtains that show up as cover entities (so with up and down arrows, which is very confusing). Would like to change them to awning (which is what I found as the solution) but can’t seem to find this “show as”-option either (running 2021.12.6)

I have a bunch of binary sensors via MQTT (Paradox PAI) and I don’t see the “Show as” option for these sensors either. Anyone got any insight as to how to get this dialog option to show up?

well, Ive checked all of my binaries (at least the interesting ones that could use a device_class), and only see the Show as on my Door binaries. Which ofc already have a correct device_class :wink: Not on shutters, covers, nowhere else tbh have I encountered the Show as… Not even on Alert (Problem) or Motion sensors, or even the core update sensors (from Supervisor integration)

Have been settings customizations in yaml ever since I started with Ha, so no real issue for me, but starting to move over to a UI way of working, this doesnt really help the transition.

Could people seeing the Show as please post a few examples of where to look? Maybe we just didnt find them yet. Id love to play around with it a bit .

It’s broken in it’s current state. 2021.12 removed the Customize UI, but didn’t give the options back to change in the entity UI for all entities. You can only change to door, window or garage sensor.

For example, this is one of my curtain covers:

I can show it as ‘Window, Door or Garage’ :face_with_monocle: instead of ‘Blind, Curtain, Shade’ or any other cover device class.

In this case you are forced to use customize.yaml if you have covers that you need to change the device_class on. I use YAML most of the time anyway and won’t mind editing it through there. But removing the entire UI without having an alternative in place is just bad design. This makes no sense and they just pulled the plug too soon, since it’s clearly not finished yet.

right, I do see Show as on a few covers. My garage door (Somfy Tahoma) and the Tradfri FYRTUR block-out roller blind. Any other of my Tahoma covers doesnt have the option.
Nor do my group covers ofc, because I didnt set a unique_id set, while I now see thats possible (something good comes from this after all :wink: ). call that a user error, will test right away if that makes a difference.
update

yes, that makes the Show as appear on cover groups. Still, nothing on the integration covers directly except for the garage door

None of my covers (Somfy TaHoma) have the show as. Also none of my doors/binary sensors have it (seeing the screenshot above shows that that should work as well).
Agreed that this is bad. It just pushes people towards the customize.yaml, while apparently that “can have unforeseen consequences”.

I’m confused how this is bad. It’s still in the same space. The unforeseen consequences that you’re referencing existed when customize was in the UI, but the UI for customizations had a whole slew of other issues associated with it. Now those other issues are gone and it needs to be managed in 1 place, customize.yaml. The new implementation of ‘display as’ will slowly work it’s way into every integration. Until then, use customize.yaml.

Just so everyone understands: All the UI did was modify customize.yaml. So if you used the UI, it adjusted that file. If you need examples of how to make the adjustments you made in the UI… Just look in your own customize.yaml file.

Alright, that’s a clear statement. Glad to hear that the customize.yaml has less issues. I think I’ll prefer the “display as” for most purposes, so I’m looking forward to that.

The issue I had with this was that the few integrations with ‘display as’ were set to a value that incorrectly overrode my existing yaml customizations.

Maybe visible again when Advanced Mode for a user is on. What’s the point of having advanced mode, when advanced features get removed without a substitute?
You are right, the function is still there in form of YAML - which is not the same, because the advantage was that the UI gave options, so way easier to do when on the go with a mobile. Changing YAML and restarting the customizations is just taking also more time.

I am very confused now how this is good, or more precisely: the YAML could be better over the UI
UI:

  • easy to choose from entity IDs
  • easy options to choose from
  • less errors when choosing attributes instead of manually writing them

YAML:

  • you need to know the entity ID and add it correctly
  • you need to know all the attributes and add them correctly
  • you need to keep the freaking YAML intends