Yes they all do
If we have the functionality in the UI to set the colour on entity.state level we are set I am sure.
I have a relative simple colour configuration based on the original defaults settings:
Entities on off unavailable unknown:yellow, white, transparent.
History graphs, gauges: green, red. Where possible yellow in between. Unavailable and unknown Transparent.
Heating and cooling: orange and blue
A very limited set of colours with a clear meaning to avoid any confusion.
it requires unique_id set for all entities. Do all integrations support it already?
Anyway I would prefer setting it in a theme (for each class). It would be more efficient than setting each entity separately. But yes, there might be cases requiring special color, which overrides default.
As far as I know every entity can have an unique id.
Perhaps per entity it’s very granular but it gives maximum flexibility.
Not yet the case.
I’ve been scrolling and searching but I couldn’t find a solution for the colors of the zones? Now they all have the same color besides home. is there a way to set up their own color at this point? maybe in config.yaml since I don’t see an option in the UI for zones
Find my issue regarding zones in History.
So far no neither a solution nor a feedback from Dev.
Paul, could you answer these questions:
Is there a theme variable for “unknown state” - icon, history? Cannot find it here.
Update: is it
"--state-unknown-color: #606060"? Is it used for icons & history?
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.
- Some actions take place regarding colors for a Tile card - I hope that this is a part of “using traditional approaches to define colors” way.
- As it was already stated many times - as long as a color for a particular domain/device_class/state may be defined by a dedicated unique theme variable, default colors & issues like “why red stands for heating?”, “why using this color for color-blinded people” etc are NOT a big problem since everything may be customized.
But pretty close I assume !
Actually, quite the opposite.
@Ih8rain2 I wishm but unfortunately there are many that don’t. Just look at the Envisalink integration for instance. It doesn’t support UniqueID and you cannot add it. I answer a question about it at least once a month.
Guys I was not aware. Because for the majority of entities I have an unique id. And for changing names, areas and icons and some other options it works beautifully. My bad !
Just discovered this yesterday after an update. Green icon for a “armed” security system??? Without UniqueID, what are our options? Really wish I had the skills to modify the Envisalink Integration…
Oh you’re not wrong - It NEEDS to be added… but that’s a completely different discussion.
it’s just a typo, not marked that way in github Release 2022.12.6 · home-assistant/core · GitHub
Just follow the marked solution in this post and create a theme to set the color to whatever you want
Will do. Thanks!!
Just a quick comment to say thank you to the Devs for listening to the community and coming up with a fix for the colour problems.
My default non-themed system is now back looking right again.
// HISTORY CHART BAR: OFF & TILE CARD ICON document.documentElement.style.setProperty('--rgb-state-inactive-color', '255, 0, 255');
is now working for me (2022.12.5)
this will probably be the thread where color caring people join these days, so please let me put forward a question in the color scales.
After some serious readup on dB/dBm, I am trying to color my sensors for signal_strength in their various HA incarnations. They are a varied bunch, but most seem to use the dBm scale where this is the buildup:
-30 dBm: maximum signal strength. If you have this measurement, you are likely standing right next to the access point.
-50 dBm: excellent signal strength.
-60 dBm: good signal strength.
-67 dBm: reliable signal strength. This is the minimum for any online services that require a reliable connection and Wi-Fi signal strength.
-70 dBm: not a strong signal strength. You may be able to check your email.
-80 dBm: unreliable signal strength. You may be able to connect to your network, but you will not support most online activity.
-90 dBm: bad signal strength. You are not likely to connect to internet at this level.
since we dont have a coloring of those (yet) in Ha, like we do have now for eg battery %, I am faking that currently in custom-ui, with the following colors:
sensor.*_signal_strength: <<: *hide templates: <<: &rssi_color icon_color: > if (state >= -50) return 'green'; if (state >= -60) return 'gold'; if (state >= -67) return 'orange'; if (state >= -70) return 'darkorange'; if (state >= -80) return 'maroon'; return 'red';
but, and here’s the real question, I am not very happy with the last 2/3 colors. Just doesnt seem to build up correctly for my eyes.
Would there be some universal scaling in UX for this? what would be the most appropriate ‘default’ color schema for scaling those rssi levels.
please let me know if you have some docs on that (or ideas ofc )
ps nevermind the overkiz covers, they use the dB scale, which also uses different numbers/scale.