HI Philip,
Any chance this could be defaulted: have the state_color set to true?
we now have huge amounts of this line in our Yaml config, and probably none would have been set to false if default was set to true…
That would be hard a logic change/break to most existing dashboards, so I’d say even more impactful than the color topic here. At least with the colors only people that had their cards set to use the state colors were impacted (plus the history timelines).
Given the reactions (and tone) here in this thread, I am more than reluctant to vote for such a change (or honestly do any changes/fixes to HA in general from my side, since the reactions/tone here was quite discouraging, but that is a known issue that maintainers in many open source projects have to deal with, but I am getting off track…).
So in the end not my decision to change the state_color behavior, but I’d lean towards not touching that.
2 Likes
Wait before you do the change of amounts of lines as a change/improvement of this line is planned to use either nothing or only on/off colors or class colors).So in future you will heave hear at least three choices.
And how about a global setting that can be turned on / off ?
If you haven’t used colors for many areas in your (huge) dashboard - but want to do it now since the new color-features came out - you need to go through each single entities card, glance card, etc. to switch that on…
I would prefer one global setting - and then, be able to switch it off, where I don’t want to have colors…?
2 Likes
ofc, one global setting would practically be identical to default state_color: true, and be able to override that with a local state_color: false. For which I yet have to find a usecase, but that might be me.
please like the PR, so we can have a look?
@petro, @tom_l
c/would it at all be possible to unsolve this topic? upon each and every post we get this:
and I dont think the community would be well served if we did open a new topic instead…
3 Likes
Don’t know anymore, where I read this these days. Was not yet a PR, but a comment in one thread here or github. Will search, if I can find it.
Such a change will be a breaking change for many and then we end suggesting making the kind of breaking change that we have been upset about the past days.
I would probably be OK with it but we cannot assume most will
1 Like
ofc, this Would be announced in the release notes 
although, Breaking change… I truly wonder. It would only be breaking for those that dont want state_color to be true. So no one in this topic. And the users that didnt join here would not have any interest.
but thats being presumptuous.
#justkidding
right. now thats interesting. all the more reason to think of a global setting… cant comment on that closed/merged PR anymore, so hope Paul is seeing this and can comment on that.
Ive been trying to downplay Custom-ui for some time now, and have been deleting my own customizations as much as possible in favor of the new core colorizations where I could. Started out well with some of the binaries (though not all binaries got the correct class imo)
for some reason though I can not help but feeling custom-ui will keep its value for a longer time to come. The flexibility this offers to users should really be built in core HA. This topic is the perfect illustration of that.
the issues we are seeing would all have been prevented, for years, and our UI’s would be as flexible as can be. customize per glob, per instance, per domain you name it. Want a state colored based on another entity, no issue at all.
Frontend code has become so complex, with all compute states and exceptions in trying to create some system default that pleases some but never all, and fixes some, but never all. And not even speaking about granularity some want, and others dont care about.
Trying to be flexible, but will never be. It’s a shame really. so much work done, all the best efforts. And still all is an arbitrary choice of colors. Not even talking accessibility aspects, which are ofc hugely important.
In the end, the only true solution will probably be freedom of choice for all.
homeassitant:
customize_glob:
switch.switch_*_poe_port_*_poe:
templates:
icon: >
return (state === 'on') ? 'mdi:ethernet' : 'cli:ethernet-off';
binary_sensor.*_door:
templates:
<<: &alert_color
icon_color: >
return (state === 'off') ? 'var(--primary-color)' : 'var(--alert-color)';
to illustrate just how easy it can be.
If only.
1 Like
it shouldn’t be too hard to solve:
create a parameter that can be set in the settings.
default: use card-state => if the card has been individually set to state_color: true, keep it.
if the card has been set to state_color: false => keep it.
Sure… if you want to use the parameter then, you need to edit your cards the first time manually.
But I think, that would be OK for those who want to use that feature…?
I am working in a company where we are providing software with a lot of “parameters”… as soon as we implement a parameter in the configuration that was until then somehow “hardcoded”, the default state needs to be the same as it was before.
I would call that somehow common sense in Software-Design…
in all honesty, not trying to re-iterate things that have been said. but that wider community response was caused by breaking peoples frontends without a warning.
I am trying to do the opposite here: first ask what people might think, then ask a dev for the coding implications, and next I’ll probably open a discussion, so others might chime in. Yet, most of these discussions are ignored mostly, so not very hopeful there. Hence the post here. How else are we supposed to partake in the development of Frontend?
In the end, I (we) am/are all trying to make this project better, by having all the work that has been done by the frontend team default to true.
4 Likes
If the desire is to have state_color on by default - which it is not today. Then a backward compatible way would be to make it default on when you create a new card and leave existing cards alone.
The only downside to that approach is that existing users that want it on will have to walk through all cards and turn them on. Like it is today. So they probably already did. And if they did not - it is probably not so important for them in the first place.
Making state_color (or similar newer feature - I see Paul is working on something) default for new cards is not a real breaking change IMHO.
1 Like
Sorry, you’re going to have to deals with it. It’s not for you. It’s for others looking for a temporary fix.
1 Like
for state_color as global option and set it to true by default, please see:
1 Like
I had thought about that, but that feels weird / inconsistent between YAML and UI editor then. We should not change the default behaviour that undefined = “off”, so that means we still need to state that default is “off”, but then when you create a card in the UI editor the default is suddenly “on”.
The alarm icon changes with the state. 
I think the discussion here shows
- that there is no way satisfing everybody.
- how important colours are for people
Before Home Assistant I have used Loxone, where coulor definition was also possible on entity level.
Why don’t you allow setting state colour on entity level?
I have some doors which are safety critical: I would prefer Red as active state as caution
I have other doors not safety critical: I would prefer a simple yellow as information!
Yes, the colour can be changed in the new tile card, however as soon as I click more info the original colour is again there. And yes, I know that I can make a custom template but I don’t want to do this.
5 Likes