If you’ve been paying attention to the thread, you would have found out that the goal is to have supported variables so this doesn’t happen again. That was mentioned posts ago.
1 Like
Does it mean that those just introduced variables’ names are about to be sanitized yet?
Yeah, I read the whole thread but have no impression it’s going to change the way you say. But maybe I missed something.
I have no idea, the supported variables haven’t been released yet.
1 Like
I just proposed in one of the issues about zone colors to make the frontend code also look for variables that contain the entity-id, optional but with higher precedence than the domain specific variables.
This would allow for
state-person-zone-work-color: 'red'
state-person-zone-church-color: 'yellow'
state-person-zone-golf-color: 'lightGreen'
state-person-zone-color: 'blue' # all other zones
When it does not find a matching variable for a certain entity it would fall back to the more generic domain color. This could be done for all domains, not only zones, it would create a zillion possible variable names and allow every entity to have its own set of colors (and by the same mechanism maybe even different colors for history and entity card), but none of them needed to be defined, it would be completely optional, it would always fall back to the next more generic variable in the hierarchy (ideally all the way back until it arrives at the theme accent color).
I would love something like this implemented. Then also a lot of the new default colors could be removed again and it would simply fall back to the old default colors. This would end all discussions, be 100% backwards compatible and would still allow complete theming of everything.
2 Likes
Great!
But unfortunately history graph for binary_sensors (and as I see, for binary_sensors only but not for switches, lights etc.) uses the same color for both “on” and “off” states. This color may be amber or red depending of device_class, but it does not change depending of state.
1 Like
It’s a bug, already fixed, will probably be in the next release.
4 Likes
I ran across this thread when I updated yesterday (first time in a few weeks) and many of my icons changed colors. Not that they are unpleasant, but it was unexpected - some are improvements. What I really came here to find out is how to change them because they don’t all make sense, and it seems like the only current fix is to hack through it. I hope that HA puts in a system to change these colors easily via the UI rather than forcing us to do a lot of YAML hacks to get the job done.
Forced color changes aren’t friendly to custom UI’s, I don’t feel they should be just set for me and then done, I would rather there be an option “hey, now you can easily set icon colors via the entity setup”. RGB bulbs that are bright white that a few updates ago started being reflected in the icon was a bad decision, it should be configurable, since a white icon on a white background is impossible and I don’t like using night themes just because the software forces me to via it’s color scheme.
HA is growing by leaps and bounds daily, I think more thought needs to be put into these types of forced changes in order to consider how users would react to a forced change (and there have been quite a few of those lately) versus giving them a simple method to implement a new shiny feature themselves if they choose to.
5 Likes
AFAIK, this is a bug in 2022.12.4 that is being addressed. See further back in the thread for links to GitHub. Also, this is not a perfect solution, it’s doing it’s best to address people’s concerns with the new colouring until the devs hopefully implement a more fully baked solution.
Check the solution of this post, outlines a clean and step by step way to change the colors that you’d like to. Took me 5 minutes to update my theme and get it right 
dont say I didnt try:
but I have no more time for this. Maybe someone else can pick up from where I lost motivation?
that’s applying a patch though, not what I would call a “solution”. It’s like hiding the dust under the rug. Thank goodness the problem seems to be fixed now with 2022.12.4
edit: history is still messed up so yeah it’s not fixed yet.
1 Like
Upadated to 2022.12.4 and didn’t realise what was behind the scenes
I literally did a scooby-doo double take walking out of the room when I realised my state sensors were back to their old contrasting colours 
Thanks to the devs for the speedy fix and to the mods for putting up with us 
I’m guessing you have not had a look at the state history of any of your binary devices.
3 Likes
Patch/Solution. Call it what you want. However, it’s the closest thing we have to being able to tidy this up until the devs come up with a more fully baked solution to what is essentially a rushed release of a half complete new feature.
For those wondering about the climate entity icon colors Fix climate hvac action color by piitaya · Pull Request #14747 · home-assistant/frontend · GitHub 
1 Like
Yea, I saw that earlier today while fine tuning some automation thresholds for our heating switch.
It did make me chuckle a bit 
Unordered/multiple states still look fine - though I don’t think they were included in the 2022.12 release.
This is probably the only one I look at occassionally.
You can just add a unit of measurement to that to see a graph instead of that rainbow
3 Likes
please people have a look. Ive been talking with Martin cs on a dedicated binary_sensor for heater, mainly because this was the outcome of a short PR discussion on an icon PR I did. was the wrong class, so (we) figured a new class for heater would be best/appropriate.
Using Plugwise myself, they’re already 3 binary_sensors that would benefit the new class.
binary_sensor.opentherm_dhw_state , binary_sensor.opentherm_flame_state and binary_sensor.opentherm_heating
An additional device_class is only considered if more integrations would use that.
So if you could, please chime in here Add device_class: heater · Discussion #841 · home-assistant/architecture · GitHub with an integration you use creating a binary_sensor for a heater like above.
As they are binary sensors that would fit under my custom device class FR nicely.
Not really on topic.
1 Like