Now input booleans and many more that never had this hand had to have custom coding written for them in each card/entity do not need it. It’s positives far outweigh its negatives.
Yeap… I had this feeling when I read about their decision about state_color and thought to myself… that seems like a major decision that wasn’t made right. I didnt see what was so out of control with the example shown (all yellow icons), and I did see lots of WTF’s coming when colors stop working for ppl.
I hope they made the right choice and it ends up being less painful the way they did it. However so far it seems a shot in the foot.
I am enjoying serendipity at the moment… I have mostly entity button cards and my only entity cards have stuff that doesnt need changing. Still… feel bad for all the loss of WAF the will need fixing across the globe this weekend.
3 Likes
It wouldn’t be so bad if I could change the behavior globally or at least at a card level. But the card level doesn’t work when I have stuff nested and/or custom cards (not sure which one). Which means I have to touch each and every entity individually. I’ll be surprised if I’m done come Monday actually…
It’s even worse because I STILL don’t understand why this change was even made. The release notes make no sense…
Oh and now I found a fun one, I actually CANNOT override this behavior with my fold entity row card. The head entity cannot be overridden which means it doesn’t change color. What a cluster…
I finally had everything pretty much perfect and how I wanted it and now it’s all jacked up and not possible to fix it even if I spend all weekend making changes. 
I want the old state color too, but it not work with state_color: true for entity-filter
I would try the custom-ui. This will probably cost you around 10 min to be back were you were. This way at least your wife is happy again and you gave yourself more time to do the adjustments/rethink your setup/find out if custom-ui is going to be deprecated.
It’s still working on the custom button_card without any changes makked.
- entity: group.backlight_tv
icon: 'mdi:television-classic'
name: Tv
type: 'custom:button-card'
title: Lights
type: horizontal-stack
1 Like
I think the change only affected the entities card, maybe entity-filter
1 Like
I don’t mind spending hours on my config files to gain a major feature , but to have to spend hours just to restore a rather mundane but useful feature is a bit ridiculous. Thousands of man hours across the planet wasted just to restore the status quo. I’m holding off making any changes and hoping they will come to their senses and introduce a global switch to undo this change in next update.
1 Like
I really wouldn’t be so grumpy if I actually understood WHY this change was made in the first place. The logic in the release notes doesn’t make any sense. I thought the idea always was to have the icons change color based on state. That’s how it was even in the states UI. Seems like the proper way to do this would have been to leave everything as-is then make state_color: false what you would add to disable this behavior.
Anyway, I’m probably 90% done fixing this mess. I’ve added roughly 150 lines to my lovelace config meaning I’ve manually touched 150 entities. Still trying to figure out a fix for the fold entity row card and trying to track down all the stragglers. This has been a nightmare and not how I wanted to spend a weekend…
1 Like
i agree! this is a bad decision, with no (so far) a easy way to turn it on globaly.
My guess is that this is either gonna be reversed or solved by adding a setting that works for all cards.
1 Like
Actually it does make perfect sense.
Previously it only worked with lights and switches but input_booleans etc didn’t change colour with the state change. So they enabled a bunch of other entities and then it really doesn’t make sense to have them all on by default so you instead need to configure them on lovelace cards. But you can define it once for the card or for each entity… Yes, like a lot of things it’s a pain but it’s temporary.
That’s going to get you nowhere.
Don’t really see this happening.
My guess is you’ll continue to be disappointed
1 Like
But why disable this behavior? I had input booleans, binary sensors, switches, etc that were working great and showing the icon color. Why didn’t it make sense to have them all enabled by default? It did exactly what I wanted. And as I pointed out this is ALSO how it worked on the old states UI. Why not just allow it to be disabled? And why didn’t it make sense to leave it as-is?
As for how to revert this behavior, the card level didn’t work anywhere I tried it. I don’t know if this was because of the nesting of cards or custom cards or both. I literally had to touch EVERY SINGLE ENTITY - all 150+ of them. There are still more I’m trying to track down too. And my fold card still doesn’t show the color on the main entity.
I still don’t understand the need to make this change. And would love to have a global way to revert this.
That’s never how it worked in the Entities card. Prior to this change, only a handful of domains had state coloring (binary_sensor, switch, sun, light, fan). It was confusing for users that switch would get coloring and input_boolean would not considering they looked exactly the same.
And it was a major problem for cards like Glance and Button which rely on the coloring in order to determine their state. If you had an input boolean in a Button card you could never see whether it was on or off. So this change made everything consistent and brought state coloring to a lot more domains including cover, input_boolean, automation, etc.
One downside of that, as the image in the release notes demonstrated, is there would be a lot more yellow in certain cases. Too much yellow. So it’s disabled by default on the Entities card only, which is fine, because the Entities card typically has a colorful toggle switch that shows whether something is on or off.
And that’s how it works on other platforms too - if you go inside the Settings app in iOS or Android the icons there don’t change colors when you toggle things on.
You can read the discussion about this change here if you’re interested. It’s unlikely to ever have a global option, because this is a sensible default. Setting it at the card level is much more flexible.
Which I worked around, I always thought input_boolean should have had this behavior.
Never used those so I didn’t notice.
It was disabled on EVERYTHING. I lost the color change across the board.
Right but this doesn’t work. If you look back through this thread I was unable to set it at a card level and had to touch every entity. And even THAT still doesn’t work for some cards.
I really, REALLY just want to globally revert this…
I don’t mean to get grumpy, but this caused an enormous amount of effort touching 150+ INDIVIDUAL ENTITIES to revert this “enhancement.” And it’s still not fixed…
Did you post your not working code?
It’s unlikely to happen IMO
Yes: post 40 I think. Not sure how to reference it.
I had that issue all over the place though since I have fold cards, conditional cards, etc. Straight entity cards were fine, but I don’t have any of those with switches and such.
If I could have done this at a card level it would have been FAR easier.
Really though it doesn’t matter at this point since I’ve touched all 150+ entities. I just need to finish tracking down the stragglers and find a fix for my fold card.
Also, why can we not get a global override to revert this? It worked, and worked great, why change it?
Actually this whole thread is just wasting my time. Not sure why I keep replying. Clearly this change is here and I just get f’ed. The WAF has tanked and I get to waste numerous hours trying to fixing it.
I’ll just deal with it even though I still don’t understand. Sorry to have wasted everyone’s time… Hope everyone has a better weekend than me.
1 Like
somewhat agree
that’s the very first time I hear something that explains the change. yes, at least it makes more sense now (and it probably could have made a different impression on people if we could have seen it in release notes).
how it was implemented (off by default) is another question, not sure it was absolutely impossible to make it the other way round (but we just don’t know)
Actually I thought the release notes said pretty much exactly that but English is an imprecise language I guess…