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:
-
Is there a theme variable for āunknown stateā - icon, history? Cannot find it here.
-
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. -
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).
-
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?
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 
Yes, lights are the hardcoded exception (has been that way since ā¦ like forever ).
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 
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
If we are trying to use color blindness to justify what colors (or not) to use then it isnāt just about red/green.
yellow/blue color blindness is also a thing and according to the National Eye Institute it also affects purple and red, and yellow and pink.
The list of acceptable colors keeps getting smaller and smaller. 
maybe we should completely forgo icons and colors and just use words ( I know of a certain button row set that does both - shameless plug 
).
Problem solved.
unless you are dyslexic. Or blind. Well, darn.
/sarcasm
But isnāt armed in a āsafeā state? So it should be green when armed to let you know itās in a āsafeā condition. Just like the example of your locked lock or closed door.
I personally think green is armed (safe), yellow is unarmed (warning) and red is triggered (unsafe).
Itās true. Red green is the most common kind of colorblindness but hardly the only one. Itās why comments like this one suggest a more serious problem to me:
Color should not be the only way to differentiate this information, thatās not very accessible.
I mean I donāt disagree. I use your UI components all over. I am a huge fan of the button rows. Definitely prefer them to sliders and tiles.
Anyway Iāll back out now. I donāt really care about my UI all that much so Iāll leave this to those that do. It just always bothered me that HA seems to use red green everywhere when thatās basically accessibility issues 101.
1 Like
Color and theme are very dependant on personal preference and use. One default solution is unlikely to fit everyoneās preference or use case.
I do think it would be nice to be able to select a few default color preferences in general settings (a selector with "original colors, accessable colors, phone theme colors, custom colors). Custom colors could point to documentation on how to configure your own preferences.