It may be corrected in the .1 or .2 …
It is possible to customize in the theme but I did not succeed for the zones…
1 Like
Let’s hope so. I find the approach weird. Why not leave it as is but give the options to change or adapt the colours to your liking. Preferably via the cards. Set icon and set state colours. That would have been neat.
To start digging in the themes yaml I’d rather not.
9 Likes
Hmm, now people will have to define colors as “255,0,255” instead of using rgb variable.
Means - if earlier a user was able to use “red”, “green” and other colors:
--paper-item-icon-color: gold;
now he CANNOT do it, he has to:
--rgb-state-binary-sensor-alerting-color: 212,175,55;
Are you serious?
Seems to be a too wise decision.
Not too mention bad choice of colors for cases like:
device_class=battery_charging:
and same similar colors for fan, device classes “cold”, “connectivity”, “door”, “garage_door”, “light”, “lock”, “motion”, “moving”, “occupancy”, “opening”, “plug”, “power”, “presence”, “running”, … almost all of them, except tamper, smoke, safety,problem moisture,heat, gas,carbon_monoxide,battery;
So, this was “discussed a lot”?
There are more important issues added on 2022.11 - like picture-elements stopped working, graphs in more-info became useless; but we got this coloring. Now many users will have to rebuild their dashboards again.
12 Likes
Try these formats:
--rgb-state-binary-sensor-alerting-color: rgb(212,175,55);
Or
--rgb-state-binary-sensor-alerting-color: rgba(212,175,55,1);
Or
--rgb-state-binary-sensor-alerting-color: '##d4af37';
No, does not work; do not think it is really supported by css to use rgb(x,y,z) values INSIDE another rgb().
Btw, the " --rgb-state-binary-sensor-alerting-color" var is used only for SOME binary_sensor device_classes (listed in my post above - tamper, smoke, safety,problem moisture,heat, gas,carbon_monoxide,battery).
Its what I’m planning on. Using as few custom cards and theming options as possible, after the recent changes and after reading this:
https://developers.home-assistant.io/blog/2022/12/07/entity-color-changes/
It is going to be a much poorer user experience, but hopefully much easier to maintain.
3 Likes
As with the other colors in my earlier post try the color name without the leading rgb- ?
You can use the hex colors, they will be translated to rgb.
Colornames can not be used because the colors are stored for the graphs, and the can not be auto-translated by the system.
Well yes, and the response was like in this thread. Not all 100% positive….
Would have been better if more people had been partaking the beta though and had joined me in expressing that.
Yet I was told the majority of people never touch colors, so wouldn’t mind and users like us, customizing colors, we are left to find out ourselves.
We’re even told so now in the themes documentation.
Which is what we’ve been doing for years of course now with custom-ui. Set our own colors based on state
If only Core would introduce that: user configurability. That’s the main thing now ofc. Silly, random state colors. All very subjectively ‘much nicer’
6 Likes
Yeah - looks like I have to deal with this contrast issue - which rooms are occupied? Anyone? Anyone …?
7 Likes
reading that now, this is so not what we expected from the dev blog… its basically the same as in the release notes and certainly not what was promised here. Or, what I was expecting from it (go as technical as needed):
There are many different types of users of Home Assistant (Home Assistant Design). Only the people that create their own themes are interested in seeing the variable changes. The other people are not interested in this. By adding it to the dev blog we can go as technical as needed without creating noise in the release notes for majority of users that do not create themes.
And noteworthy dev blogs are always linked in the release notes too
1 Like
Same in my HA dashboards. All my motion sensors and door/window sensors use only dark blue (no move; closed state) and blue color (motion detected and door/window open). Why you make this kind of “improvement”? Can we go back in some way to previous view?
Regards to All of You Guys!
1 Like
Thank you for ruining my HA appearance on DEFAULT THEME DARK
Who came with idea to force change colors from the ones we were able to set in theme in settings to this madness?
Where is tutorial to change it, where is information in breaking changes about it?
Why not pink, magenta, dirt color like your bright ideas of forcing changes not enabling them after switch ?
Edit:
I have no F idea where to change it because nowhere there is setting to change it. Accent color is not this one.
Nothing in configuration.yaml nothing in ui-lovelace.yaml nothing created in themes.
Really how I have to open deep files using File Editor if deepest path is /configuration?!
12 Likes
Right?
The contrast between on and off is absolutely terrible, and quite surprising after the State of Open Home had that talk on the importance of accessibility. Those of us with good eye sight are struggling to see the difference between on and off right now - people with poor eye sight, will be finding this change near impossible to use.
7 Likes
I don’t understand this toxic behavior. People have been asking for years for the ability to set colors for states on entities and in themes. The very first iteration of this ability is added and the initial response is to go from 0 to 100 on the anger scale? It’s the first step, relax. Change your theme for the time being. Calmly post things things that should be updated.
There is no reason to get bent out of shape with the level of anger in this thread so far, this is a work in progress.
EDIT: This is a general response to everyone that posts about the colors, I’m not trying to single you out Andrew.
17 Likes
Then please tell where to change them ?
Which file is having them and why it’s not in themes, configuration.yaml or somewhere else where people are keeping configuration?
I have ugly UI would fix it in no time if I had this information. Instead there is a note that logs and history have new colors, you install new Update and boom something is different.
Best regards
2 Likes
There are posts above that describe what values to change in your themes.
All those colors can be themed. There were multiple posts already here in the thread about it. You just need to scroll up a bit.
Here you can see the current list in the coding: frontend/ha-style.ts at b581b95d9d2a90134f9680a6230c51d664375c7e · home-assistant/frontend · GitHub
2 Likes
I can not find the colors for “off” and “unavailable” (switches, binary sensors) in that file, or also the “not_home” in the history graph bar chart. “Off” appears like “unavailable” now and this is completely counterintuitive. I tried to change it with overrides like this (using the extra_module_url trick):
(This does NOT work)
document.documentElement.style.setProperty('--state-off-color', '#ff0000');
document.documentElement.style.setProperty('--rgb-state-off-color', '255, 0, 0');
or even
document.documentElement.style.setProperty('--rgb-state-switch-off-color', '255, 0, 0');
And also a lot of variations thereof, even tried to dig through the changed typescript code in the frontend that introduced this new behavior to see how the variable name is constructed, but I cannot find it, it is too convoluted for me with too many indirections.
I cannot change the color of “off”, nor can I change the color of “unavailable”.
Can you help?
3 Likes
Have you tried it by yourself since it does NOT work - probably because these vars w/o “rgb-” do not exist here.
type: entities
state_color: true
entities:
- entity: binary_sensor.test_device_class_heat
name: heat
- entity: binary_sensor.test_device_class_heat
name: heat
card_mod:
style: |
:host {
--rgb-state-binary-sensor-alerting-color: 0,255,0;
}
- entity: binary_sensor.test_device_class_heat
name: heat
card_mod:
style: |
:host {
--state-binary-sensor-alerting-color: rgb(0,255,0);
}
- entity: binary_sensor.test_device_class_heat
name: heat
card_mod:
style: |
:host {
--state-binary-sensor-alerting-color: green;
}
- entity: binary_sensor.test_device_class_heat
name: heat
card_mod:
style: |
:host {
--state-binary-sensor-alerting-color: '#00ff00';
}
Again - NOT.
Now I have to use only “255,0,0”, not “red”, not “#ff0000”.
BUT - there is a glitch here with HEX values.
This code does NOT work:
- entity: binary_sensor.test_device_class_heat
name: heat
card_mod:
style: |
:host {
--state-binary-sensor-alerting-color: '#00ff00';
}
but this THEME works:
test_new_colors_theme:
# rgb-state-binary-sensor-alerting-color: 0,255,0 # OK
# rgb-state-binary-sensor-alerting-color: rgb(0,255,0) # failed
# state-binary-sensor-alerting-color: rgb(0,255,0) # failed
# state-binary-sensor-alerting-color: 'rgb(0,255,0)' # failed
state-binary-sensor-alerting-color: '#00ff00' # OK
# state-binary-sensor-alerting-color: green # failed
# state-binary-sensor-alerting-color: 'green' # failed
i.e. HEX color is not accepted via card-mod but is accepted in a theme.
Seems that vars w/o “rgb-” like “state-binary-sensor-alerting-color” work ONLY in themes, they cannot be used in card-mod, cannot be edited in Code Inspector.
Sorry, I do not see a logic here. It was possible earlier, not possible now.
And the only possible reason - using “255,0,0” values as input.
Like majority seems do not need precise graphs in more-info.
Please revert this entire breaking color update, wait until it is debugged and tested before you release. And also please:
- document all the new variables
- announce the breaking change before it happens
- use the old colors we were used to for the defaults
- don’t hardcode any colors (off, unavailable)
- test, test, test, and then test it again.
- then release.
Not the other way around.
Please!
Thank you.
28 Likes
Sorry, but not everyone is posting in toxic way. Just giving some examples of poor accessibility colors and kindly asking to re-consider/fix them in nice way is not toxic in any way. Please also let us know if you’d rather have it registered as an issue in github.
2 Likes