2022.12 Color states are broken/unusable

I have used this way to control the colours of state on and off in my picture element cards

  - entity: cover.kitchen_curtain
      '--paper-item-icon-active-color': orange
      '--paper-item-icon-color': green
      left: 44%
      top: 4%
      action: toggle
    type: state-icon

The paper-item-icon css is a breaking change. Unfortunately there is no description of how do define these colours anymore.

I am sure there is a way.

This is a really annoying breaking change. The using red/orange and green seems to be pretty standard requirement in a UI. Red off and green on. Unless it is a light where I use default.

There must be a way to do this. I cannot for the world understand how anyone would want these colours as green and purple. Purple! Yuk!

The motion sensors are now grey and blue and the blue is very close to the grey. Very difficult to see the difference. I want my control back of the colours in my dash boards


Take this as a starting point.


We’ve discussed those new colors extensively in #beta. You can set the binary alert colors with the device_class, and I believe all are now settled to be the correct colors (for default)

the state colors are listed here: frontend/src/resources/ha-style.ts at f1393e5f00690287a78665faf88ca6145d4aaf48 · home-assistant/frontend · GitHub

you can override the default colors in your themes with:

  state-switch-color: '#ffd700'
  state-automation-color: '#ffd700'
  state-cover-color: '#ffd700'
  state-fan-color: '#ffd700'
  state-light-color: '#ffd700'
  state-person-home-color: '#008000'
  badge-person-not-home-color: '#636B75'
  state-person-zone-color: '#800080'

my one hope is that there soon will be a state-person-not-home-color too, so we can set that, and not only use the badge variant of it…

those were my words… but, as stated by Paulus, only 2 variables are in fact officially supported by core Frontend, the others are prone to change (as they do…) and used on ones own risk… There is supposed to be a Dev blog on the matter (soon), linked in the release notes?


Based on the entity’s state, the card will get different colors. This color provides an additional visual indication of the entity’s state.

Didnt see this in the notes until now. wow. I think I will print this and keep it as a memento… It’s what I have been advocating for years now, and many others have asked for it. So glad it has finally returned to Core Frontend. almost can not believe the struggle we had convincing, and failing at it, the dev team of using a more colorful frontend.

Of course I am not unbiased, but hey, I count my blessings. yeah. Ditched all of my domain glob customizations on the binaries, and only have a few coloring battery and energy sensors templates left. Nice.

I followed the documentation on Picture Elements Card - Home Assistant

And it still states the old --paper-item CSS used in side the individual elements.

Can I still control the colour of the icon?


  - entity: binary_sensor.front_door_lock
    icon: mdi:lock
      '--paper-item-icon-active-color': red
      '--paper-item-icon-color': green
      left: 48%
      top: 79%
    type: state-icon

What do I put instead? I do not see two different CSS names for on and off in what you listed

1 Like

not sure tbh, I never used that. But I suppose you could try :wink: doesnt this work anymore? (dont think you stated that?)

No. It is all broken.

I am in the middle of experiments.

This changes my door lock (binary sensor) to being red again

  - entity: binary_sensor.front_door_lock
    icon: mdi:lock
      '--rgb-state-binary-sensor-color': 255,0,0
      '--paper-item-icon-color': green
      left: 48%
      top: 79%
    type: state-icon

I am still trying to figure out the name of the same thing when it is off to have control of the off colour also.

I think I will also try to look at theming this as the same colour look horrible also in the rest of the UI. The colour bar of motion that changes between grey and light blue is basically grey and grey. Really a bad choice. This is not just taste. There is objectively no contrast between the two states.

Just look at this image


When the On state was red, it was easy to see the other state. The light blue and grey have zero contrast.


on door and window device_class: Ive stated I would think those to be alertive colors too, but the team was not decided, so they are not set in that binary class. They do get their own colors by default though, but tbh, I cant find that right now.

On the Picture elements card, the would seem a bug, if the documentation is no longer doing what it says…

its all new, so we need to give as much feedback as possible to color dev piitaya (didnt want to tag here)

1 Like

I am completely lost on the colors. They all changed sort of randomly. I don’t now how to correct it back and I can’t find any documentation on it. Why was this done???


I have to complain about the icon color changes as well, lock state being red for locked is backwards in my opinion but the blue vs dark blue for other stuff is terrible. Motion, windows, and doors are security devices to me and not being able to quickly and obviously notice a state change is unacceptable.


Same problem for the zones…

Yes what a mess suddenly. Previously you couldn’t set the colours either but they made sense somehow. Now I am completely lost on the logic of the color selection.

Somebody know how to set the colours?


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.


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:
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.


Try these formats:

--rgb-state-binary-sensor-alerting-color: rgb(212,175,55);


--rgb-state-binary-sensor-alerting-color: rgba(212,175,55,1);


--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:


It is going to be a much poorer user experience, but hopefully much easier to maintain.


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’


Yeah - looks like I have to deal with this contrast issue - which rooms are occupied? Anyone? Anyone …?