Great work everybody, and thanks for all the hard work.
However, I am having some issues with the new state colors. Fixing the concern I have is not about being able to theme the solution. I want to do as little with themes as possible. The problem I am having is the contrast between on and off states. Depending on the monitor I am using, or how the icon is shaped, I can barely tell the difference between the state of On and the state of Off color.
I have decided for myself not to get upset anymore or to keep hoping that my opinion will be heard. I restored my last backup and everything works as it should again. I’m skipping the current update and I’ll probably wait and read the posts for the next update and then decide what to do with it. Shame for the good changes in this update. I guess I lost my confidence with the way the complaints were handled.
Have a nice day everyone I’m out.
Guys sorry for asking if this is stupid.
I use dark the default dark theme and i just need everywhere in the default them the accent color to be yellow…nothing more nothing less. Exactly as it was before. In my settings i have the default and it shows yellow correctly but now when a motion sensor or anything (except switches) goes ON its Blue.
I just want the old behavior…
I think, if I understood it correctly, it is because they are also using these values in JavaScript directly where they are using functions that accept only RGB values and not CSS color syntax or CSS color names.
And because they needed to rush the release as fast as possible before the xmas holidays they did not have time to write a little parser or lookup table in JS that would translate color names like “red” into an RGB color. Writing that parser would have been the clean way to do it, or even trick the browser into doing the work like described here: Javascript function to convert color names to hex codes - Stack Overflow
But the main problem with this set of changes as I see it is this:
Before the change we had separate colors for the icons on entity cards and the colors in history graphs. The colors for icons on entity cards were all the same for all classes of switches and sensors and had been carefully chosen to match the theme and make it easy to distinguish between inactive (off) and active (on). The colors on the history graph card were completely different, used the full range of available colors to achieve maximum contrast between all possible state and were not limited by theme colors.
Now after the change, in an attempt to make the icon colors for different device classes configurable, they overshot the target and made these capital mistakes:
The result of this is now after adjusting all the entity icon colors back to their previous defaults “yellow”, the history charts also lost all their nice colorful contrasting colors and are yellow/grey only. And because they hardcoded off and unavailable to the same type of grey they also lost the ability to quickly see on the history when a sensor went offline.
Therefore my suggestion is this:
I know this is a lot of work and will not be completed before the end of the year, but IMHO it is worth the effort to do this properly, therefore I suggest to revert the entire change now immediately to not let one single rushed design error solidify itself and block the road for the future indefinitely, rethink, redesign and redo it slowly and carefully without hurry.
See this post 
. This is exactly what I’ve done.
@stickpin Thx for this…
Is there a way to not make a new theme and just overwrite the default? now i have a new theme with the name state-colors… its not biggy 
A parser definitely could be a proper tool without breaking users’ UIs.
That did the trick… thx again m8
In configuration.yaml
frontend:
extra_module_url:
- /local/theme-override.js
and in the www folder (which is always automatically mapped to the URL /local/) I created a file
/config/www/theme-override.js
with content like schown below, one line per variable (still incomplete because I only needed to override the binary-sensors at the moment):
document.documentElement.style.setProperty('--rgb-state-binary-sensor-color', 'var(--rgb-state-switch-color)');
This makes the binary sensor icon color the same as the switch color. It is injected into whatever theme you are using (in my case the default dark theme) without creating a new theme.
It also does not need a theme reload, only once to establish the extra_module_url, after this just hit shift + reload in the browser whenever you edited the .js file.
Do not think they will agree with it - that was announced (imho) as a main idea “define standard colors for each domain, each state for icons & graphs”.
I myself have nothing against this way. I even agree with it.
It could be really great (imho) when an icon & graph are of same color for same cases.
But:
– choice of colors should be very accurate & may not be perfected after just 1 iteration;
– themes should contain “rgb(255,255,255)”, “#ffffff” or “red” values (issue);
– the “paper-item-icon-active-color” should be kept as long as possible.
It should fall back to the old way of defining the colors if the new color variables are not set and by default they should not be set. Then they should document which variable to set SHOULD one wish to override the color for a certain class. That way nobody would even notice any change.
Mmmm, so far no docs for themeing. And it was said that officially only 2 vars are supported.
For me it seems like hiding internals from users.
A trend which includes “integrations moved to UI”, “more-info shows statistics instead of precise data”.
not to down your effort or solution, but this seems way more complicated than adding 1 variable in a theme (and have that loaded for all other themes if you use more of those, simply copy it in an anchor). see here
the latter has the advantage you can easily test and reload, see the result in the frontend immediately. And, it’s the ‘official’ way of dealing with color vars in themes as designed in HA Frontend.
I know. But my solution was a reply to the question how to do it without creating a new named theme to which I have to switch all clients, just inject it into the existing default theme.
yes, I see, and as said, it’s not meant as criticism.
as a tester I need the default theme alive… If something is borked in HA, and I need to create an issue, I always do so in default theme. To be sure no customization could be causing trouble. For that reason, I couldn’t follow your approach.
If you dont care about that, I guess it would be simpler. yet, you still need to be sure of the actual vars, and their correctness before injecting them into default.
I don’t get it. Using
## Variables
gruen-hell: 139, 195, 74
test-1: rgba(236, 201, 205, .5)
test-2: '#af6a71'
## Colors
rgb-state-input-boolean-color: var(--gruen-hell)
colors my activated input booleans light green.
state-input-boolean-color: var(--test-1)
or
state-input-boolean-color: var(--test-2)
does nothing. Only
state-input-boolean-color: '#af6a71'
works. Why?
It is a great solution.
I hate using themes. I have to walk around all computers, all portable devices, all wall displays, also the ones that belong to my wife. My computer at work. Everywhere just to adjust 3 colours.
I miss being able to change colours of a few critical elements. I do not want to be a theme designer. I just want my curtains to be orange when open instead of purple. PURPLE!! Oh my God. And my motion sensors red instead of a blue.
I think I will go for prof7bits solution unless this unfortunate situation 2022.11.0 has created gets improved.
Thanks a lot, this helped me out of this mess.
I was not able to make it work as well. Only with “#color”.