2022.12 Color states are broken/unusable

KennethLavrsen · December 8, 2022, 9:03pm

Note that when you have modified colours of icons in Picture Elements cards the situation needs a little more explaining

An example is

  - entity: binary_sensor.front_door
    icon: mdi:door
    style:
      '--rgb-state-binary-sensor-color': 255,0,0
      '--paper-item-icon-color': green
      left: 44%
      top: 81%
    type: state-icon

and for a cover

  - entity: cover.kitchen_curtain
    style:
      '--rgb-state-cover-color': 255, 152, 0
      '--paper-item-icon-color': green
      left: 44%
      top: 4%
    tap_action:
      action: toggle
    type: state-icon

So you still need to use the old --paper-item-icon-color for the off colour.

For the on colour things have become much more difficult. Before it was the same css variable no matter what type of entity. Now you have to know which type of entity you deal with and then find which new variable to put in the card code. It was not really friendly before. And now it got worse.

I would really hope we instead eventually can make this easier for the user by having a simple documented set of color_on and color_off variable that you can define for each entity

Any solution using themes changes colours everywhere. That may be good for many. But as I explained earlier, I have several binary things where I use different on and off colours. I cannot even see how I change the off colour uniquely for covers in the new CSS.

Ih8rain2 · December 8, 2022, 9:08pm

Agree. On setting the colours I made a similar remark earlier. Put an UI somewhere in the settings and done. I would be happy with that!

Eoin · December 8, 2022, 9:12pm

Great comment and 100% agree!

mirekmal · December 8, 2022, 9:00pm

This is the very first time when I get seriously upset with the release…
While it works for me in 100% wihout any (functional) breaking changes, my theme got screewed up with new color schemes and some undocumented variables being added without notyfying users. Again. Enough is enough… We were asking for more reliable, predictable and consistent color schemes for years. Finally we got exciting news that now we have ’ Shiny new state colors!’… that quite some number of users do not like (just count the posts that are against these colors!). And to be well understood - I’m not questioning the palette as such. For some it might work and some might really like it! I recognize this. But once again developers made the decision to change color variables in themes, so work of hundreds of people using custom themes was destroyed. And again for years we were asing for good documentation of themes and and variables used, all we got was referencing to source files with no comments. Just count the number of posts across the forum, comments where people are sharing their discoveries of what variable is responsible for what UI color! Some of them takes literaly weeks to be discovered! Yet you ignore us, not even considering to mention that you made such breaking change (yes it is breaking UI in many, many cases, making it unreadable). All we get for our complains is that we are welcome to participate in beta… not everyone can/is willing/is capable to participate with their production systems. Basic respect to users would require to document and clearly explain to community that such changes are made in release notes, as you do for any other functional change. This would at least give users possibility to counteract and update their themes to revert unwelcome changes and make UI again as it was intended by them.
Do we deserve such minimal effort to give us this info in clear text?

petro · December 8, 2022, 9:24pm

Not really. Ever heard of the boy who cried wolf?

Ih8rain2 · December 8, 2022, 10:19pm

Yep. It send a message

drawbars · December 8, 2022, 11:04pm

I agree with the OP. I spent days (weeks?) tweaking my themes, because I use a slightly different one for the buttons that control each room/function in my setup. I used to be able to look at the console and quickly see that I left my laptop on, or the shop lights, etc. Now, they are all yellow when lit. In my particular case, reverting back to the ‘standard’ colors is pointless – I rarely use them.

Strangely enough, a few of my themes did not break after the upgrade, even though I tend to use the same minimal theme structure for each button theme. I’m going to have to compare them to see if I can spot the differences. What I really need is a list of syntax for the supported elements, and maybe more importantly, the ones that no longer work, since there has never been a full set of documentation for creating themes. (Probably not going to happen, right?)

Regards,
-BW

petro · December 8, 2022, 11:15pm

I don’t know why there’s no documentation. That’s always baffled me. Seems like something that should be in the regular documentation, not just the development documentation.

jerrm · December 8, 2022, 11:20pm

Should this thread really be flagged as “solved?”

The OP of the this spinoff just happened to be the first message moved. If it were just about his specific issues problem, it would not have been broken out to begin with.

petro · December 8, 2022, 11:27pm

I flagged the post that has the solution to fix themes, don’t read too much into it…

kerbal · December 9, 2022, 12:19am

hi there, can u also show the left side/whole part of the card config code? just want to see what’s the syntax. thanks!

tom_l · December 9, 2022, 12:54am

As I keep pointing out, we have been told there are only two supported elements for themeing.

primary-color and accent-color

Everything else is done at our own risk and won’t be documented.

STATERA · December 9, 2022, 1:22am

I just updated and it has changed the colors for some items on all the themes I made. How do I remove the new colors? Is there a way to downgrade just the front-end portion?

Ildar_Gabdullin · December 9, 2022, 1:59am

I am still interested in an official explanation why new variables now defined as “255,255,255” instead of “rgb(255,255,255)” or “0xffffff” or “red”.

github.com/home-assistant/frontend

Inconsistency with defining colors in a default theme

opened 02:02AM - 09 Dec 22 UTC

ildar170975

### Checklist - [X] I have updated to the latest available Home Assistant ver…sion. - [X] I have cleared the cache of my browser. - [X] I have tried a different browser to see if it is related to my browser. ### Describe the issue you are experiencing Since 2022.12.0, colors in a default theme are defined like "255,255,255" - instead of "rgb(255,255,255)" (or "#ffffff") as it was before. And this happened to SOME colors (probably to the newly added vars) - check this file: https://github.com/home-assistant/frontend/blob/f1393e5f00690287a78665faf88ca6145d4aaf48/src/resources/ha-style.ts example 1: ![изображение](https://user-images.githubusercontent.com/71872483/206602684-62f1c237-0426-4b18-b319-8620fde108f4.png) example 2: ![изображение](https://user-images.githubusercontent.com/71872483/206602821-4924fab9-cce8-43bd-b096-32dca84b31a4.png) **Why colors are defined in different ways?** Also, with these "255,255,255" variables it is NOT possible to use alternative definitions like: ``` var(--accent-color,red) var(--accent-color,#00ff00) var(--accent-color,rgb(0,0,255)) ``` W/o using alternatives we should use: ``` rgb(var(--rgb-state-sensor-battery-medium-color)) ``` and this possible way does NOT work: ``` rgb(var(--rgb-state-sensor-battery-medium-color,'255,0,0')) ``` Users HAVE TO use alternative definitions since some variables may just disappear - as it happened with `paper-item-icon-active-color`. **All variables must have "traditional" versions (i.e. defined as "rgb(255,255,255)" or "#ffffff") which are EXPOSED for external use - for instance, in custom plugins.** ### Describe the behavior you expected as above ### Steps to reproduce the issue as above ### What version of Home Assistant Core has the issue? 2022.12.0 ### What was the last working version of Home Assistant Core? _No response_ ### In which browser are you experiencing the issue with? Chrome 108.0.5359.95 ### Which operating system are you using to run this browser? Win10x64 ### State of relevant entities _No response_ ### Problem-relevant frontend configuration _No response_ ### Javascript errors shown in your browser console/inspector _No response_ ### Additional information _No response_

balloob · December 9, 2022, 3:52am

The community guides category would be a good place to document such things, as it comes with the necessary disclaimers.

gbfromhb · December 9, 2022, 4:09am

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.

FrankL1966 · December 9, 2022, 7:47am

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.

BlueChris · December 9, 2022, 7:53am

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…

prof7bit · December 9, 2022, 8:09am

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:

they chose default colors that were different from the previously used default colors
they chose default colors that for some classes absolutely did not work with the default theme
they fixed the history chart colors to the icon colors.
they hardcoded “off” and “unavailable” colors for the history chart.

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:

revert all the changes for now to have more time to redo some of the architectural decisions in a different way, without any hurry
completely decouple the entity card icon colors from the history card colors, make them configurable separately
make the defaults for the icon colors all the same as they used to be
make the defaults for the history chart colors the same as they used to be
make it so that the old theme color variables continue to work for all device classes except the ones that have been deliberately changed by the user
get rid of the r,g,b syntax and allow normal CSS color syntax

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.

stickpin · December 9, 2022, 8:12am

See this post . This is exactly what I’ve done.