2022.12 Color states are broken/unusable

Just to explain the color choice about alarm :
Safe state is green so armed alarm and locked lock are green.
If you don’t like it, you can change it with themes.

3 Likes

I am seeing colour changes to the icons for my binary sensors on the Glance Card but not the Entities Card. Anyone else confirm? Edit: looks like the same issue with switches and automations (maybe automations never had an on colour?) Light works. this is with 2022.12.5

all right, thanks for the explanation :slight_smile:
In this case, I have mis-interpreted the previous PR where the red/green color state has been mentioned as such, that this has was already possible :slight_smile: :+1:

Yep

Green is safe. Safe to open the door without setting off the alarm. :stuck_out_tongue:

It is a change from before 2022.12. Whoever designed the original alarm related UI felt the same about it as some of us have stated. But yes, we can theme it right or do the permanent js hack so it applies to also my families devices without having to check their themes.

2 Likes

Thank you for reverting to old colour scheme (to some extent). At least standard GUI binary sensors are now perceivable.
Could I politely ask, than any new funky colour schemes would be introduces as an additional theme. This should not mess people up and limit the backlash.

1 Like

Paul, could you answer these questions:

  1. Is there a theme variable for “unknown state” - icon, history? Cannot find it here.

  2. What is a current progress for transparent history for “unavailable” - are there any plans to rectify observations from “History-graph: do not make a graph for “unavailable” sensor transparent” issue?
    It was mentioned in the issue:
    – absence of a graph treated by many people as a bug;
    – even if a label “unavailable” will be added on the transparent graph - it will not be noticeable;
    – will not be possible to distinguish “unavailable” case & “does not exist” case;
    – since icon color = history color for all states, it is inconsistent to use different colors for “unavailable” - it is better to use a themeable variable for “unavailable” for icon & history.

  3. Are there any plans to refactor the freshly added variables from “255,255,255” format to conventional CSS formats like “rgba(255,255,255,0.9)”, “#ffffff”, “red”? (the “Inconsistency with defining colors in a default theme” issue was closed by you).

  4. Are there any plans to restore different colors for zones in history? Check the “Different zones in History have same color” issue.

@piitaya , sorry for tagging you in the post to get your attention.

the problem is of course the following:

green => unarmed
red => armed
and what’s with “alarming” ?

If your Alarm panel would be Armed (red) and then an alarm will be active, it is hardly to recognize.
Btw… that would also be the case, if we have multiple states with the same color (as it is right now)

Probably OK:

  state-lock-jammed-color: '#F44336' # Red
  state-lock-locked-color: '#4CAF50' # Green
  state-lock-pending-color: '#FF9800' # Orange
  state-lock-unlocked-color: '#F44336' # Red

Arming and Unarming would be OK…
Armed / triggered - in combination with the other alarm devices (red => triggered) is probably a bad choice.

  state-alarm-armed-color: '#F44336' # Red
  state-alarm-arming-color: '#FF9800' # Orange
  state-alarm-disarmed-color: '#4CAF50' # Green
  state-alarm-pending-color: '#FF9800' # Orange
  state-alarm-triggered-color: '#F44336' # Red

I would consider an darker orange color tone for “armed”…
This would indicate, that it is not “green” => safe to open - but also no alarm has been triggered

But this would collide then again with “arming” / “pending”

There is a pulsing animation for triggered. We should add that to jammed for lock too.

3 Likes

I am actually considering orange for armed but I need to be alone in the house before I test the alarm triggered mode.

I believe it flashes when triggered

Yes, triggered alarm flashes the red icon (what Paul meant with “pulsing” in his comment). You can see all of that in action here: Home Assistant Design

3 Likes

Based on that, automations which are on should also have a different icon colour. (As well as the other domains I mentioned in my previous post) So unless someone can say their entities card is working fine I will open an issue on GitHub…

My automations in “on” and “off” state are correctly colored in yellow as per the design page. Cannot spot anything wrong here.

1 Like

have you enabled the option to show the state color?
grafik

For me, everything is working as expected (I’ve changed the colors)


1 Like

Quite right guys. I use yaml and I did not have the state_color set to true . However, this may mean that the light domain is not following that setting as my light entities do have the icon change colour. Is that by design?

probably depends on the card type you are using for these.
Or - how the entities-card has been setup once :slight_smile:

Yes, lights are the hardcoded exception (has been that way since … like forever :slight_smile: ).

We just had a discussion about that today in PR because I had also forgotten about that: Ensure consistent light state icon brightness by spacegaier · Pull Request #14740 · home-assistant/frontend · GitHub

3 Likes

Thanks for the info! Back to the sidelines for me :grin:

According to data published by NEI in 2015, only about 4% of population are actually affected by red-green blindness when accounting for a combined male and female population. I believe a majority of the other 96% of users would prefer a standard red/green binary in HA (colors which have proven successful for vehicular traffic needs). The ability to independently theme and add additional state indicators is available for those who differ.

It’s acceptable for traffic lights because which light is on can also be differentiated by position. If you can’t see the colors you can still know that the top light being on means stop and the bottom light means go. Hence my comment:

(Added emphasis)

I’m seeing 8% of men and 0.5% of women more now (I may have accidently read that as 8 and 5 the first time). Hard to know for sure since not all statistics come from good data. Even if it’s only 4 or 5% that’s still 1 in 20 or 1 in 25 which is a lot of people to alienate. In general the preference is either don’t use red and green or ensure there is some other way to visually differentiate for those that can’t differentiate those colors.

Or let people easily customize. Then everyone can be happy.

4 Likes

First thanks for all the changes that have been made this release as a result of the feedback here.

Second - that’s not really how people use red and green (or whatever other combination of colours people use).

Generally it’s about state, what is dangerous and what is not.

Lock: Locked = Green, it’s safe. Red is unlocked.
Door: Closed = Green, it’s safe. Red is open.

Alarm is tricky - it’s generally accepted though, that Red means armed. Whether that is an alarm, or a bomb. I guess it makes sense - because it’s telling you that YOU might set the alarm off if you open a door or trigger a motion sensor. Green means it’s safe to move around.

It’s basically the same as a traffic light - Red is Stop, Green is Go. Or the system they use on the Running Man to stop the prisoners from trying to escape. Green = your head won’t blow up if you pass this point.

3 Likes