You only have to use customize.yaml to customize entities that can only be configured in yaml that do not extend device_class to that integrations yaml configuration. So your argument is a moot point because you still have to set up that configuration via yaml. Now instead of configuring it via yaml and then the UI, it’s now yaml and then more yaml.
A good rule of thumb:
Did you configure it through the UI? Then you should be able to customize it through the UI.
Did you configure it through yaml? Then you should be able to customize it through yaml.
Any “Custom” attributes have to be configured through yaml.
Anything outside of that should be written up as an issue and fixed.
E.g.
An integration created through the UI creates entities that are not customizable through the UI? → issue.
An integration though the UI doesn’t assign device_class or state_class when it’s a sensor that clearly needs it? → Issue
Anything configured through yaml will need yaml customizations, although one could argue that they should also set the device_class and state_class properly.
false.
Home Connect for example. Config works over the UI, and brings some 25 programs of a dishwasher (DW), that A) do not even exist on the DW and B) have just plain wrong names. Also the dishwasher name is so messed up that neither Google Assistant nor Genie/Edge/Almond was able to understand it.
So not only changing icons, device classes or names, it’s also unit_of_measurement (when you have a custom device) or a device where the developers did not fully finish engineering.
Ok, when I understand you correctly, anything that has been customized in the UI and was customizable in the UI but is now not customizable in the UI anymore, is considered to be a bug?
In my case I configured it through the UI, and now I cannot revert or change the config in the UI anymore because the feature to customize it disappear.
Read my last post. Write up an issue if it doesn’t create these entities with a unique_id.
it appears you might have
I have the impression this goes completely in the wrong direction. Please allow me to start over:
I was very used to a function called Customize Entities. I used it heavily to alter existing entities to make my life easier. The function disappeared for numerous reasons.
What can we community do to get a feature that does that, preferably packed in a nice UI?
Can you help on that please?
I just looked at the home connect code, you can change the names of everything through the device configuration and entity configuration in the device list or entity list.
How do I change unit_of_measurement?
if the unit_of_measurement is wrong, that’s a bug.
if the unit of measurement is not the units you want (i.e. the unit_of_measurement matches the output value), you have to create a template sensor and convert the value yourself and supply all that information.
And this is exactly what I am talking about! IoT world is far away from the world with pink sensor and colorful switches. There was a nice feature that worked but it get’s removed by a feature that’s not even close to a replacement.
We users use HA to make things talk to each other that usually would not. Some cool people gave us a great tool with features to do that. A nicely grey world on the way to turn pink.
And then we go a black and white way with (just to name a few):
DNS
Portainer
remove Supervisor from sidebar
Customize Entities
The end is people again have to do console, command line, community addons or baloobs tricks for features that existed. But between this black white is lot’s of grey called options: Leave it up to the user to see it and use it. The feature is dangerous, place a warning. And all of us will remember clearly: Removing toys that we enjoyed will not keep us from playing with them.
So again, what is your suggestion to help getting this feature back as an optional setting somewhere deeply hidden in the config? It can be flag in configuration.yaml that enables the UI? Then we have our YAML team happy and the UI guys too?
2 Likes
If the unit_of_measurement isn’t what you liked even with customize.yaml in the UI, you’d still have to make a template sensor. I’m pretty sure you don’t understand what I’m saying.
If your unit of measurement is Wh, and the output value of your sensor is kWh, then that’s a bug.
If your unit of measurement is Wh, and the output value of your sensor is Wh and you want kWh, then you have to create a template sensor to convert the value. This hasn’t changed. It’s the exact same as it used to be.
If you thought that changing the unit_of_measurement automatically did the conversion, then you thought wrong.
I’m not suggesting anything. The customize UI is not coming back, arguing with me about it coming back will be fruitless because I didn’t remove it. You’re arguing with the messenger.
Another thing where this UI would be great. Entities without a unique_id
proximity is one of them, that comes up w/o unique_id when setup as per documentation.
But another question, when I change device_class or icon in the UI it is not updated in customize.yaml. Where does it go? Which information has higher priority, customize.yaml or the directly changed value?
I get the unit_of_measurement (UOM) obstacle, in my case I use it with low cost step trackers that report just a number. Sure, I can change it in customization.yaml, but as said this is from a user perspective rather uncomfortable. No conversion needed, we just need the UOM changed.
And I do not want to argue with you, I seek your help on how to create a feature similar to the Customize Entities. I don’t care if it is called that way, needs 2FA to open the feature or whatever. I am seeking help to get a feature into Home Assistant, or smart workarounds that do not imply the use of config.
I get the point, this exact feature in that form will not come back. Understood. Please allow me to rephrase my question:
I am looking for a feature.
As an administrator of Home Assistant I am looking for a feature to change any attribute of an entity.
As a not so skilled administrator I expect the feature to offer me a list of options for each attribute.
Also for that reason I want to see a warning message that this feature can possibly destroy my HA instance and that using it does not grant me support anymore.
The lists cold have some thumbnail or image next to an option to make it easier to find things, eg. device_class: door has a small door icon.
As a good googler, backup maker and forum reader I still want to be able to change the attribute to whatever I want despite it not being part of the offered list.
To make things easy this plugin could read and write the existing customize.yaml
Petro, what would be your suggestion to place this request? Can you help with that in this thread or is that already worth a new thread?
1 Like
You can make a #feature-requests for that but I personally don’t think it would get added without overwhelming support from the community. All work is moving towards config flow and adjusting entities on an individual basis with a set number of adjustable attributes. Adding fake attributes is something that would be considered ‘very advanced’ and the expectation would be that the user does this through yaml.
I inadvertently clicked on the “Show as” entry in the entity settings, and changed a connectivity entity to show as a plug. Well, I cannot change it back - “Connectivity” is not in the list of “Show As” items… but this is surely a valid binary sensor device class.
I ended up having to go into Developer Tools → States to change it back, and the entity settings still shows it as a plug - is this the intended behavior?