2022.12 Color states are broken/unusable

Found my own solution :slight_smile:
Last question, is there a way to change the colors back before this release?

You could restore a backup from before the update (like I did) or use a theme like for example @robertwigley suggested here.

I can’t see that this theme approach helps with the colouration of zones, or am I missing something? I’m a bit fed up with Green for home, grey for not_home or blue for everywhere else.

Sorry, can’t help you with that. I did not use the theme until now, first I want to set up a test system where I can test new releases to protect my daily use system.

I’m chiming in here with the dislike.

My biggest issue is the history graphs. Off is the same colour as Unavailable. On is both orange and blue depending on if it’s a sensor or a switch(?) – On should be always the same colour. Thin bars of orange are much harder to see than the previous thin bars of green.

Can I change these in a relatively straight forward manner, or should I wait for customisation options?

1 Like

That’s actually not only a color problem, but a rendering problem. The way they render the timeline bars is incorrect. Antialiasing will blur the colors together at the edge of each bar transition from one color to the next. If a bar is very thin, this reduces contrast a lot more than it would simply with the colors. You can see this by yourself by taking a screenshot of a history timeline and zooming into it. In my history explorer card, I specifically managed the timeline rendering in a way to keep high contrast at the color edges, even for thin bars. The HA devs didn’t do that.

You could use the custom card I linked to above to replace the native history, it’s has fully configurable colors and lots of nice other stuff too, I promise :grin: (shameless plug, sorry).

3 Likes

I too am struggling to see state changes on some cards.
My custom cards are fine, but the core cards, notsomuch.

I appreciate the steps towards making the colour selections easier to customise for theme developers, however I think it would have made sense to retain the previous colour selections in the core pallette so users can deviate away if they wanted.

Idea:
It would be great if there was a page in settings which had all the domains and state options with their default colour selections and from there allow users to select alternate colour for each as desired or necessary.

And any outliers being defined manually as before with css/card-mod or custom cards.

The dev already said a documents page on themes and supported options this was coming soon.

3 Likes

Ah … that is awesome.
Thanks for the reply :heart:

OK, I should clarify, I was saying that the dev said a documents page was coming soon to themes. Sorry, I don’t think there will be a UI page in the near future. My brains not firing yet and I missread your message.

Still, it’s a step in the right direction so we can get in there and get tinkering :ok_hand:

Thanks again. Looks like you guys have had a rough couple of days.
Some… “passionate” people out there :eyes: :grinning_face_with_smiling_eyes:
I’ve been admin on a couple forums. I bet the private mod chat area’s been busy.

With that, I appreciate all you guys do to try and steer the threads back on point.
Normally it’s a thankless task, but thank you guys :heart:

7 Likes

Nothing that hasn’t already been said, but given the situation felt it important to stand up and be counted.

I don’t care for the color choices, but as I roll my own I don’t really care what you choose as long as I am able to achieve my own design objectives. A very big thank you to the Dev that offered to provide some documentation on the new direction.

That said, how they chose to do it is puzzling at best. Gaining more control over the colors et.al. is great, but I have a feeling it won’t be long until this needs to be re-factored. And, I am now wishing I didn’t accidentally stumble on WHY they made this change, because it is just stunning.

In the interest of keeping things constructive, I would like to suggest that from time to time it might be helpful to get outside guidance on big application architecture decisions.

Lastly, while it may “technically” not be a breaking change, anything that has this big of an impact on such a large part of your user base warrants far more communication than was given ahead of the change.

This is just a hobby for me, but I really do greatly appreciate the project and all the people that spend so much time and energy keeping it great

8 Likes

@ HeyImAlex Thanks for your work! And I did take notice of your earlier post about your add-on. I might have the time to tinker with these coming holidays.

1 Like

For me, I agree with this approach . Did you expand on @prof7bit example? Could you add your configuration to this thread? thanks

hi Paul,

since Ive posted a couple of compound posts, and didnt get a conformation, please let me ask here separately:

using the tile card:


with a seemingly ‘unavailable’ cover

and its more-info, which does use the correct color:

it’s not related to the entity/domain, my other posts show the same behavior for different domains.

In other words: Tile card does not use the color scheme the entity should get (and does get in the more-info)

could you please confirm this is acknowledged?

I suggest making this an issue in the frontend

I’ve tried to read through this thread but something I’m not clear on is future plans- I see this noted as the first step towards something, but has it been explained what that is exactly? I’m among others that don’t love the new changes (things like some items on/off states are not different enough to see at glance, along with lock default being red which catches my attention at a glance but is the state I’d like rather than a ‘concern’). I’m glad others have found workarounds and suggestions to mostly revert via theming, but I don’t want to be too reactionary. I don’t want to create a themes file, modify my configuration yaml, and apply the theme to my users if this is all something that will continue to change or get better over time. I’d mostly just like reassurance that these concerns are heard and the current marked solution in this thread is not a long-term recommendation.

4 Likes

tbh, I am not even sure the marked solution is The solution. It is what?
Its a list of most new color variables probably set to the colors they were before?

That might not even be close to a solution, because before, we couldn’t set many of these at all.
What I fear a bit, is that with this ‘solution’ people who didnt use themes before, dont really understand what’s changing, either with the new 2022.12 frontend, or with that Classic theme.

I am all for educating users, so they can create their frontend as much as possible to their liking, understanding the structures on which that frontend is built.

My post #3 was a fix of my already existing themes. Themes which were meticulously curated, and using the former color variables.

the snippet I posted fixed what had to be fixed, in those themes.

with these new color variables things are way more complex though than only setting those themes. Any card_mod working with the former color variables has to be scrutinized, because they most likely will no longer work correctly.

HA devs dont care about that, and state that time and time again. “We dont support that, so we dont need to document that either, and its no breaking changes because we didnt support that in the first place” …

example:

I had a footer mod on a script button:

  - type: entities
    state_color: true
    title: Camera detection
    show_header_toggle: false
    card_mod:
      style:
        hui-buttons-header-footer $ hui-buttons-base $: |
          .ha-scrollbar {
            justify-content: space-evenly;
            height: 50px;
            align-content: center;
            margin: -8px 0px 0px 0px;
            --ha-chip-background-color: var(--primary-color);
            --ha-chip-text-color: var(--card-background-color);
            /*--paper-item-icon-active-color: red;*/
            --secondary-text-color: var(--card-background-color);
          }

and that used the up to then used --paper-item-icon-active-color. turning the button to a red button when the script ran.

I had to take that out, and add the color variable for scripts to my theme:

  state-icon-color: '#636B75'
#   rgb-state-switch-color: 255, 215, 0 #(paper-item-icon-active-color: gold)
  main-on-color: '#ffd700' #255, 215, 0
  state-script-color: '#f00000' # red
  state-switch-color: '#ffd700' # gold
  state-automation-color: '#ffd700'
  state-cover-color: '#ffd700'
  state-fan-color: '#ffd700'
  state-light-color: '#ffd700'
#   state-binary-sensor-color: '#ffd700'
  state-input-boolean-color: '#ffd700'
  state-group-color: '#ffd700'
  state-update-color: '#f44336' #red
  state-person-home-color: '#008000'
  badge-person-not-home-color: '#636B75'
  state-person-zone-color: '#7b68ee' #mediumslateblue
#   state-climate-heat-color: '#800080'
#   state-climate-idle-color: '#000000'

fixed that particular button.

So you see, there’s more to it than a single theme substitute, and we need to understand why/what…

4 Likes

I am using HA 2022.12.1.
HA in Docker.
My colors for binary sensors are these:


Today on Github one person posted a screenshot where colors for binary_sensors are orange (not red).
He said that this is the latest HA, so I wonder - if anyone else have these icons/graphs of orange?

Can you please explain this WHY, thanks!

1 Like