So, the motivation for this is similar to this one, but the WTH is more fundamental based on frustrations I had on reading this and other threads.
A recurring topic seems to be, excessive customization is bad, YAML-based customization is bad, customization should happen through the UI (applying a bit of hyperbole, of course). But UI-based customization doesn’t allow me to set dynamic icons and doesn’t allow me to set dynamic icon colors. If I look at the entities I care about on my dashboard… all the integrations provide dynamic icons, or at least dynamic icon colors (and frankly, if the icon isn’t dynamic, I don’t know if I even care about it at all). So the only thing the UI-based customization is allowing me to do is to… break icons. By that I mean: it replaces the “(dynamic) icon” concept that I know, which shows me some information about an entity’s state, with a “static icon” concept that I rarely come across in real-life integrations - and that I also don’t want.
Obviously, this is an often-requested feature, I have used search extensively, probably there still are so many threads I haven’t read, but mostly the answers are always along the lines of “use custom-ui” and/or why more powerful customization isn’t coming and why UI form-based customization is the intended way to customize icons. I find this surprising, to say the least, because of this statement by frenck:
For example, I have a some kind Window sensor from China. Now lets say, I have one, and I ship one to Paulus in the USA. We both pair it with ZHA… what should it show?
IMHO, this is a really good point, and points directly to a flaw in the current design of HA. The issue is not even about localization US vs. EU vs. whatever. The sensor probably isn’t a “window sensor”, even though it may be marketed as such. It’s a contact sensor. You can use it on windows, but also on doors, drawers, what have you. The fact that it should be the integration determining the icon to be shown seems just… wrong. It’s a design flaw. If anything, the integration can provide a default icon. But if the integration should no longer be the preferred source of truth for icons, that now really means that (icon) customization needs to be a first-class citizen - but a UI form-based customization feature that, when used, makes the icons for the vast majority of integrations less useful, certainly isn’t that.
Maybe there’s the plan to add state-based icons to the UI-based customization, and nobody ever got around to doing that, who knows. But the fact that I’ve seen the recommendation to use the icon customization in the entity settings gives out the impression that the “how” (UI components should be used for customization, not YAML) takes precedence over the “what” (change icon - without breaking the icon concept I know), which isn’t very user-oriented.
