2022.12 Color states are broken/unusable

Configuration
250

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
251

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

image
image934×330 20.1 KB

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?

252

Can you please explain this WHY, thanks!

1 Like
253

Hi

You may be surprised.

document.documentElement.style.setProperty('--rgb-state-cover-color', 'var(--rgb-orange-color)');
document.documentElement.style.setProperty('--rgb-state-binary-sensor-color', 'var(--rgb-state-switch-color)');

That is what I needed. 99% of my daily use of HA front end are two picture-element cards (floor plan based) and in those I have defined on off colours for quite many entities.

That was hard work to get then as they were before.

1 Like
254

he probably refers to some information how the UI of HomeAssistant MIGHT look in the future.
There are some previews / studies that the UI will be somehow look like the mushroom dashboard (nowadays) - but unfortunately, I don’t find the link to the study at the moment :frowning:

1 Like
255

That thing here ?

256

yes, that was it… during the Event “State of OpenHouse” (?) Paulus has showed some sketches, too…

257

Can someone tell me how to fix this on the Picture Elements Card with state-icon
I want the icon to be red when the binary_sensor is off, yellow when on

    - type: state-icon
      entity: binary_sensor.clock_br2
      icon: mdi:clock-digital
      tap_action:
        action: none
      hold_action:
        action: none
      style:
        top: *row_03_1
        left: *column_5
        "--paper-item-icon-color": red

I tried this, but didn’t work
‘–rgb-state-binary-sensor-alerting-color’: 255,0,0

258

Use ‘–rgb-state-binary-sensor-color’: 255,0,0

For binary sensors

259

Thank you, I think I’ve been looking at this too much today. Time to quit

260

Zones in History

1 Like
261

@prof7bit

2022.12.5:


// HISTORY CHART BAR: OFF & TILE CARD ICON
document.documentElement.style.setProperty('--rgb-state-inactive-color', '255, 0, 255');

It’s

```

document.documentElement.style.setProperty(’–rgb-disabled-color’, ‘255, 0, 0’);

![Bild|535x500](upload://fXDKUCLPp5hpPkOdz9NmKJjESB1.jpeg)

Note, that this will also impact the Tile card:

![Bild|690x96](upload://frBCTmWIfoKYon6mv63pDAIGRVj.jpeg)
263

hmm, for me --rgb-disabled-color does not have any effect, neither on switches nor on binary sensors, neither in the history nor in the tile card.

(I have updated to 2022.12.3 this morning, hoping for any improvements or removal of these unusable new default colors, but nothing changed at all)

264

Here is my constructive(!) suggestion to the devs how to get out of this mess in an elegant way and without losing face:

  • leave the ability to configure all these colors in place (it is generally a good idea)
  • remove all the default colors for these new settings and let it (in the absence of these settings) fall back to the old theme coloring mechanism, that way only those who actively decide to change one or two colors for a specific reason can use the new feature and for all others it continues to work as before. Or to say it with fewer words: please make the feature optional, don’t force its use on everybody.
13 Likes
265

Bookmark this link to see Core updates and changes.

266

struggling to understand what you’d want here?

we now have a state-person-zone variable, and that would be/is used for all zones indeed. So, unless you would travel from zone to zone, without traveling to Home/Not Home in between, you might be seeing several concatenated zone blocks in the graph.

What would you be proposing? To have Zones return to random colors? Tbh, this is the one change I am happy about in the new color schemes :wink:

Finally a calmed down history-graph on person trackers. And one we can (almost) fully customize to our liking/theme preferences. (not_home still hard_coded?)
we have distinct colors for home/not_home/zone. What more do we need?

well, have this work really, that would be nice…

  state-person-home-color: '#008000'
  state-person-not-home-color: '#636B75'
  state-person-zone-color: '#7b68ee' #mediumslateblue
  badge-person-home-color: '#008000'
  badge-person-not-home-color: var(--state-person-not-home-color) # '#636B75'
  badge-person-zone-color: '#7b68ee'

now we still have to state the hex or rgb value on the badge and can not reference another var with the same value.

Also, it would be nice if the not_home color in the graph would be theme able and not hard coded. Or at least follow frontend/person_color.ts at 348c3c9787e86df4a655a9e59498eaf1ba05ea2d · home-assistant/frontend · GitHub

and no reason to have the badges do anything different…

1 Like
267

I have a better idea.
Create new official, default theme, but provide the old theme to be optionally selected. Actually, themes are for what HA devs are doing. They should use them too.

I know that with the actual way of setting a theme (per end-device) it might feel annoying to change the theme on all devices, but there is a way to set up a backend-selected theme using automation.

268

maybe something like --state-person-zone-$(zone_name)-color

so one could (if he wants) do things like this:

state-person-zone-color: 'blue'  # default, unless overridden for specific zones

state-person-zone-work-color: 'yellow'
state-person-zone-golf-club-color: 'lightgreen'

state-person-zone-home-color: 'darkgreen'

The frontend JS code is already dynamically constructing variable names and then looking up whether they exist, so this proposal would not be very far-fetched.

By the same principle we could then also color only one specific sensor:

state-binary-sensor-garage-door-open: 'red'
state-binary-sensor-garage-door-closed: 'darkblue'

And if the user does not specify any of these colors it should fall back to looking up the next higher more generic color in the hierarchy (default zone color, default color for all binary sensors, etc), so eventually, if none of these are specified, it will fall back to the pre 2022.12 theme color for everything that is active or inactive.

2 Likes
269

yes, that would work, and, on the other domains, is what we indeed should be having already. Being able to define dedicated on/off colors on the binary for example is so desired.

for me, zones was a bit of a surprise,( I have a lot of zones, and it would require some rethinking to see the need for separate colors there), but I guess that would indeed be a nice option. As long as you could set them (please no more randomized colors…)

1 Like
270

You have to empty the browser cache.