Customizing components is done completely outside component configuration. It should be possible to do it directly in the component’s configuration to have together what belongs together. So we should add a "customizing: " property that is allowed on all components.
I digged a bit into the code. Some sensors already have the option to set an icon. The base class “Entity” has options to return icon, hidden, device_class, unit_of_measurement …
So I suggest to refactor the code and move the default implementation to Entity, removing all the redundant, incomplete and non-consistent implementations:
- Add a “customize” function or similar to Entity that gets a “config” object passed and reads properties like “hidden”, “icon”, … from config to local variables. Change the default property methods to use these variables. This change would not break anything.
- Modify all sensors, binary sensors and maybe other components to call this new function. Should not break anything, our tests will show.
- Also make entity_id customizable. This allows users to decouple “name” and “entity_id”, making the friendly_name customization unnecessarry in many cases. This change would not break anything.
Result: Any component can be directly customized with it’s configuration. Redundant code will be removed.
If you agree with this, I’d start a PR 
In general I agree that it makes sense to do the customization at the same place where an entity is configured. That however is not always possible. Take the Philips Hue lights for example. There you only configure the hub, and all of the paired lights are detected and configured automatically. Hence there is no other way of customizing besides doing it in the separate section with the references to the entity IDs like it’s done now.
If your implementation doesn’t break the current way it’s done, some could still argue, that there then would be two places to do the same thing. So if I were to modify an existing configuration that would be a mix of the classic and your way, I’d have to look at two places to find out where I have to make the modifications.
Another way of thinking about it: the way it is now we’re explicitly configuring the things that are unique to devices within the needed sections, whereas the customization takes care about attributes that resulting entities have in common with each other. So customization would actually be something where it wouldn’t be too hard to make a configuration GUI for.
Customization is part of the core. You can reload it without a restart of HA.
Separate customization files allow for localization (in different languages).
It’s a tough call whether or not to change this, since merging them into the components also has its advantages.
Thank you for feedback. I see the point in having the central customization in some use cases. So I would not drop it, rather extend it. There are already components that allows to set some of the values directly on the component. Each implements it in it’s own way.
The change I propose could also be optional (I use a super init but we could also just provide a function in the “Entity” base class so it’s call is optional). With this each developer can decide if direct customization makes sense for this component. For me this is at least true for any manually configured Entity (e.g. all mqtt components, command line components, template components).
The current customization happens outside on purpose - it is something the code of each component/platform is unaware of. Also this allows you to customize every attribute. For example you could say that power_consumption attribute of a light is 1.
Allowing to pick entity_id would be nice. However it wouldn’t always be possible when entities are auto-discovered and not manually added. (Unless there were aliases that mapped discovered entity_id to another id.
As for conveniently having everything related to some platform in a single place in a yaml file - there are packages: https://home-assistant.io/docs/configuration/packages/
@andrey, Thank you for your feedback. I’d keep the external customizing for this reason. But the basic attributes like icon, hidden, … usually belong to the component. So IMO it’s a good idea to make it configurable there as well. It’s makes config much clearer if you e.g. define an mqtt sensor for your swiming pool temperature and put “icon: water-temperature” directly to the sensor config.
Especially a custom icon is already implemented in several components, the code base would be better with a central implementation.
What do you think about having this feature on most items in the same way instead of having it on some items in different ways?
In my proof-of-concept I use the parameter “id” to set an entity id. It works and I do not see any side effect. It would allow us to use arbitrary component names and change these without changing the entity_id.
I saw the packages feature but I’m not sure if I can have customizings there.
Regarding icon, name etc. in-entity - good luck convincing @balloob 
I would be ok with an id too, but it won’t really allow you to use arbitrary components. There are places in the code that deduce component/domain from entity_id.
Just noting that providing an id won’t work for auto-discovered entities (as there is no “entry” for them in yaml)
I’ll try to convince.
Maybe a good way is to provide a function like: configure(config,id=true,icon=true,…) where a component passes it’s config plus a list of properties that should be read from config. This allows a per-component decision which configs makes sense but allows to have one central implementation.
After discussion with @balloob I’m going to split this discussion in 2 parts:
- Setting entity_id
- Setting icon, …
Both are different features do be discussed separately.
- Our config UI requires all
customizeto be in 1 file. This is only possible in the current format where it is all under thehomeassistantentry in the config. The config UI is the future of our config. We should no longer introduce anything that will hinder further extension of the UI panel. - You can use packages to keep your customize definition close with the config of your platform. Package customize will all be merged together when the config is loaded.
- Every integration has different information available. So some platforms will allow configuration of certain properties by a user because the integration is more low level, like any MQTT platform.
- The current POC requires changes to every platform out there. This is unacceptable. Generic functionality should be generic so that any platform can benefit without any changes.
@balloob Thank you for your feedback. So would you agree that it makes sense to allow the configuration like icons for low level platforms like mqtt? If so, we probably should have kind of naming guidelines and standards to ensure that same things are configured the same way on any device.