When this thread was created it was moved to “social” first, then moved to “configuration”, but currently it does look like a “social” since users are communicating here w/o any meaningful affect to HA design.
I think we are back in the way rgb is now defined to have perhaps a solution, which will work for all tasts.
Why not going back to declaration with declaration type (and solve the parsing topic with a backend or whatever parser for the single card, where it is used)
Then everyone can
- define the colors as they are used to with rgba()
- The standard can set transparency to 100%
- The theme users can set color and transparency for whatever they want
2 Likes
yes, and I forgot to add to my post, we should bring this back into the release topic. And suggest a title change.
It’s not about I dislike the 2022.12 color changes. it should read something like Colors are broken in 2022.12
1 Like
exactly ((
with my all due respect to Dev team, and this are not just diplomatic & polite words
1 Like
Fixed.
5 Likes
It is getting worse. The alarm entity in my UI is now grey for disarmed and green for armed.
GREEN for armed!
How do I fix that make? I cannot live with that
3 Likes
There’s a fix in for the binary sensor off colour. Fix binary sensor color when off by piitaya · Pull Request #14735 · home-assistant/frontend · GitHub
Is there a way to add different colors for a different device class? It is listed in the first link but not available in the theme you’ve created. What would be the naming convention?
are you now advocating same colors for unavailable and unknown? thats a bit unexpected tbh, since you earlier mentioned 2022.12 Color states are broken/unusable - #301 by Ildar_Gabdullin
Tbh, I do like the unavailable color there. That greyed out should be system default for unavailable.
Not sure about the unknown, which seems to be the same as Off? That would still be an issue imo.
1 Like
Wasn’t that a requested change here from the community to make sure that good/safe states are green (which obliviously having the alarm set would be such a state)?
I am not sure about the gray though, considering that here we have it as default blue.
Yes.
But an alarm being triggered is a thing that triggered like a bomb set to go off. For an alarm system, the daily use is “be careful, the alarm system is on, don’t open the door without turning it off”
I now had to add this to my addition js file which is getting longer and longer
document.documentElement.style.setProperty('--rgb-state-alarm-disarmed-color', 'var(--rgb-green-color)');
document.documentElement.style.setProperty('--rgb-state-alarm-armed-color', 'var(--rgb-red-color)');
2 Likes
No no no, my issue was about a battery ICON only. I may accept the way “same color for unavailable & unknown”, but for history the must be different.
Well, it is worth to add a remark in that issue.
Update: yes, colors for unavailable & unknown should be different for icons too.
right. And this has been working like that for years, to each and everyones satisfaction.
and yet this these colors are changed out of the box, because … ?
O I misunderstood that obviously, but please let me repeat my suggestion for colors then:
unavailable: that same light grey (ed out)
unknown: some theme default for grey (is what it says, not off/not on, we dont know so…)
on: active color depending on device_class, or fallback to classless system default for on
off: inactive color depending on device_class, or fallback to classless system default for off
didnt want to run through your Issue, but if you’d agree in this, please pick this up?
I do get that point (I personally do not use anything like that in HA). It looks weird/inconsistent then when e.g. comparing it to locks which are red when open/unsafe.
I’ve programmed the LED ring in my custom doorbell to be green when the alarm is disarmed and blue when armed, it seems logical to me. I cant program grey though 
1 Like