How to make state_color: true global?

[SeanM]

@TazUk

I understand the driving reasons behind the state_color change, however not all cards offer this ability.

I use a large number of entity-button cards conditionally to enable toggling on and off of certain items (switches, input_booleans, and alarm_control_panels). Different icons represent different states, and this is something my family are now used to.

That was an intentional decision because Button card does not display the state as text. The icon coloring is therefore necessary to determine the current state. You’re correct though that button card currently doesn’t support state_color: false . That’s good feedback and would be a perfectly reasonable feature request to make.

Alternatively there’s also the Custom Button Card which is fantastic and allows full customization of everything. That will always have more features than the default core cards which are meant to be more simple and straightforward.

@AhmadK

That’s a bit disputable. I believe a lot of HA users only use this forum (namely - Fearure Request section that doesn’t seem to be visited by the developers so often it looks like another chat room without any tangible result - but yes, I know it’s important as well) and sometimes don’t even know about all options Github provides (like Issues etc). Discord is also not for everyone and nobody apart form interested parties can see the discussion after it happened.

Well I’m not sure what else to say, the GitHub and Discord are where all development-related things occur, and so naturally that is where one should expect the pre-release discussion to take place as well. These are public and super easy to access, just click the “Need Help?” link at the very top of the main website and forum or the Developer Tools > Info page in Home Assistant itself.

It’s far better and more organized to have all the discussion occur in one central location where you can be 100% sure the developers are reading the feedback, and so that information doesn’t have to be unnecessarily repeated in multiple different places. That would just slow down development.

The GitHub PR’s are linked to from the release notes, so it’s helpful for users to click on them to learn more about why a change was made (again, here is the PR for this specific change). If the discussion about a change was fragmented across various forum posts or social media networks the links in these release notes would be far less useful.

@maxym

Since newcomers start mostly from implementing lights, how can you achieve CAG if they get GUI full of yellow bulbs as they would have had without HA change? And in addition the same beginners will get confused with switches, which drive lights but not change the color.

If you want switches that drive lights to also behave like lights, you can use the Light Switch platform. This way you can also add them to light groups and they’ll show up in Google/HomeKit etc as lights.

@maxym

You also mention that the new HA version adds other domains to behave like bulbs icon-wise. It means even more yellow color.

Yes, and giving all those other domains coloring is precisely why it was made opt-in. To avoid all that yellow unless the user specifically wants it. It’s set to state_color: false by default for the Entities card.

@maxym

As I mentioned I’m beginner. I’m using default light theme. And I didn’t found yellow icons on default bright background cumbersome (working on different monitors and iPhone). Hope trying to be compliant with CAG at any cost wouldn’t the main goal of the change.

Accessibility was not the main goal of the change, but just one of several reasons why it makes sense. You can visit this contrast ratio checker website to see the results of yellow on white (a huge fail).

Ultimately it’s simply not necessary in the Entities card, because the state is always displayed either as text (for binary_sensor) or as a colorful toggle switch for most other domains (switch, fan, input_boolean, automation, etc etc).

Here is an example of the Home Assistant default theme (left) and some various community themes, both light and dark. You can easily determine the on and off states just by glancing at these toggles, without even seeing the rest of the entity.

And this is exactly how all other platforms work too, here is the equivalent of an entity row on both iOS and Android for example:

Notice how the icons don’t change here on iOS or Android? Because the toggle makes it perfectly clear already. Coloring the icon on top of this is unnecessary duplicated functionality. It’s still easily possible to add back if you want, but it’s certainly not essential.

@maxym

IMO removing the functionality of providing visual cue was the worst choice considering HA UI’s main task is to signal states.

No functionality was removed though, in fact more was added. The only thing that changed here is the default setting.

[finity]

I believe the issue here is that the implementation of this change was, first, a complete surprise to the vast majority of users because there aren’t that many people who have the time to try to keep up with this forum and updates to HA and then to also visit the other various and sundry places that these development discussions happen. I know I don’t have that kind of time. HA already takes up way too much of my time already.

It’s kind of funny that you say that the developers need to have a place that they can discuss all of these changes without having to be spread all over social media. So what did they do? Instead of using this forum they created a separate discord channel for HA, a reddit channel (or whatever it’s called), the github issues section and a feature request section here.

The “need help?” link goes to a page that has no less than 10 places that users might need to go to get help. That doesn’t sound very consolidated to me.

I would bet good money that if the developers used this forum and made more forum posts about “hey, this is coming down the pipe. What do you (the experienced current users) think?” you would get a lot more positive feedback. And when those changes got implemented you would likely have a lot less push back from those very same experienced users because those decisions would have been aired in the place where the vast majority of users actually spend most of our social media HA time.

Second, the stated goal was to improve understandability to newcomers by making everything consistent. Then turning immediately around and making things inconsistent by making the “light” domain the only domain to get a colored icon by default.

third, the recommended “salve” to sooth the irritation of having to go through your entire config and opting back in to a functionality that had previously existed is to claim that “you can make the changes on a card level basis”. Then when people in this thread tell you that doesn’t work for all cards is to basically ignore that statement and keep repeating the same thing isn’t at all helpful.

So, can we do the card level option on, at least, all of the core cards? If not then the change was rushed out before it was fully implemented. Which causes more frustration from existing users.

Last, to offer the suggestion to change all of your light switches to the “Light Switch” integration isn’t much of a solution either. You still have to go thru your entire config and re-create all of the existing switches into “light switches” and then you end up with two entities that represent the state of one device.

For me I had already customized my switches that control lights to have the light bulb icon to indicate they were light switches. Now, unless I go to each entity and either convert them all to “light switch” or turn on the state_color option in each card for each entity I will have some “bulbs” that show the state color when switched on (because they are in the light domain) and other “bulbs” that don’t show the state color when turned on (because they are in the switch domain). Nope, that’s not confusing at all.

[123 (Taras)]

Over 55K users have registered to this community forum. Would it not make sense to discuss some of the pre-release ideas here?

[TazUk]

@SeanM

That was an intentional decision because Button card does not display the state as text. The icon coloring is therefore necessary to determine the current state. You’re correct though that button card currently doesn’t support state_color: false . That’s good feedback and would be a perfectly reasonable feature request to make.

Thank you - Raised

[AhmadK (akasma74)]

@finity

I would bet good money that if the developers used this forum and made more forum posts about “hey, this is coming down the pipe. What do you (the experienced current users) think?” you would get a lot more positive feedback.

and also avoid things like

@SeanM

You’re correct though that button card currently doesn’t support state_color: false . That’s good feedback and would be a perfectly reasonable feature request to make.

which in turn supports this

@finity

So, can we do the card level option on, at least, all of the core cards? If not then the change was rushed out before it was fully implemented.

and I understand and agree

@finity

Which causes more frustration from existing users.

especially if they spent plenty of time making their UI useable and consistent and now it looks weird again because someone did something ‘logical’ from their point of view (as it was decision of 3-5 people as far as I understand). so we’re all reaping the results.

Well… as previously said the very same changes could be done better, much better using different approach.

[Torgrim]

Can we get a solution to set all state color to true?
I used it on all my devices before and it helped a lot to just get a visual confirmation.

I loved the update for the thermostat, when it activates the heater now it turns orange:)
Now it just need a color when it miss behaive

• The temperature is out of range lower or higher then set temp.
• heater/fan is “unavailable” or if it is not turned on, when it supposed to.
• temperature sensor is “unavailable”

[iantrich (Ian)]

Hello all,

First off, just want to highlight that changes to the project are not done in the shadows and feedback is always welcome. There was a lot of discussion on this PR that led to the final decisions: https://github.com/home-assistant/home-assistant-polymer/pull/4510.

I see quite a few people asking for things to be cross-posted here in the forums for more feedback/visibility and frankly, I just don’t see that being viable. Lots of PRs are from one-off contributors. We’re already hurting for contributors as it is and to make them post over here as well before we merge something is an obstacle that most won’t want to go through.

I’m a fairly regular contributor, but even that is a big ask for me. I do this in my free time; I’ve got 3 kids, a wife and trying to work on my own HA setup. And like I said before, all our PRs are open to the public, our Discord channel as well.

That all being said, I can feel your pain. I too had to go through my large configuration and added state_color to my cards as that is my preference for entities card. If you have a large config that you need to update, my best suggestion right now would be to copy your config to an IDE like Visual Studio Code (release 1.38 or higher), and do a find replace on

type: entities

and replace with

type: entities
state_color: true

Watch for indentation issues.

I really hope you don’t truly think contributors, myself and core devs included, are out to hurt you. I honestly thought this would be a great improvement to the UI and still do. Like I said, I too use this on a daily basis.

Lastly, I do plan to add the state_color option to button and glance cards as well as the state-icon element for those of you that want to turn off such indications. Feel free to provide feedback on the PRs when I submit them. You can subscribe to the frontend repo to get notifications if you wish. I’d recommend turning off email notifications though and just check them periodically if you want to keep your inbox at a sane level

~Ian

[AhmadK (akasma74)]

Thanks Ian for your hard work and for the answer.
I think many of us understand you very well.
However, as it was your PR and after its merge there were many omissions showing that the merge was a bit rushed and it could benefit from a brief consultation with the community I just want to ask to think about the situation calmly and maybe try gathering more feedback before implementing such dramatic changes next time.
Of course, ideally it should apply to all of us.
And I’m not teaching, just voicing my opinion as a member of the community and a user of this great system.
Thanks again!

[skynet01 (Alex)]

Thank you for such a detailed response. And thank you for continuing to work and improve HA! I think this change makes HA much better, people are just complaining that they want more control over it.

Any plans to add an option so you can globally set this variable or even change color in a config? Similar to how custom UI does it? There was a feature request about this, but I didn’t think it was actively being worked on.

Again thank you so much for your contribution!

[iantrich (Ian)]

No, I don’t think so. At the very least it is not something I will not work on as it is really just a stop-gap to avoid adding this to your cards. Which I can understand can be tedious for updating an existing large config, but should really not be a big issue going forward, in my opinion.

[iantrich (Ian)]

It was in the beta for a week and no complaints were raised during that time. A PR open for a week and a week in beta is, in my opinion, far from being rushed I also can’t keep my ear to all the feedback on the forums. There is a LOT going on here I focus mostly on what is happening on GitHub.

[skynet01 (Alex)]

Gotcha, so no plans for color state options? It would make it sooo easy to set up how state colors behaves for different entities. For example, using Custom UI (which is buggy as hell but somehow still works) my global config looks like this:

"switch.*":
 templates:
    icon_color: if (state === 'on') return '#fdd22f';

"binary_sensor.*occupancy*":
  icon: mdi:home
  templates:
    icon_color: if (state === 'on') return '#FF1C8C';

"binary_sensor.*window":  
  device_class: window
  templates:
    icon_color: if (state === 'on') return '#5a5a5a';

This is easy as I can just name my entities a certain way and they will be colored accordingly.

[iantrich (Ian)]

Not by me I’m just one dev though and a selfish one who usually makes thing that I want

I could see an icon_color option being added to cards, but I doubt it would be done the custom UI way, i.e. globally. But if icon_color becomes a thing, a custom solution to set those by templates becomes much easier.

I actually proposed icon_color previously, but don’t recall why I closed it…https://github.com/home-assistant/home-assistant-polymer/pull/3956

[AhmadK (akasma74)]

@iantrich

It was in the beta for a week and no complaints were raised during that time.

Ian, (I presume) that’s because most of the beta users are the very same people who propose changes or make PRs. I personally only update when .2 comes out as I cannot afford disrupting my setup. (I also open issues and sometimes make PRs, but not as great as yours )

@iantrich

A PR open for a week and a week in beta is, in my opinion, far from being rushed

And still, I think now you have at least 2 FRs on your hands related to the lack of functionality in various types of cards making them difficult to use after the change. We can call it whatever we want but it could have been less stressful, and it’s not only about time - more importantly, it’s taking into account users’ opinion.
If you meant that 2 weeks was enough for everyone to get familiar with that PR… I don’t know who reads all these PRs before they become part of HA. I got a link to it from the release blog when we discusses “why could it happen at all?”

@iantrich

I also can’t keep my ear to all the feedback on the forums.

but did you try to gather it? like a poll or something? if no, then yes, you can’t

@iantrich

There is a LOT going on here

I believe you and that’s great, really!

However,

@iantrich

I focus mostly on what is happening on GitHub.

it’s ok but do you really think that your discussion with @SeanM and @balloob could for sure take into account needs and use cases of say, 50% of HA users registered on this forum alone (50% of roughly 50k If I remember it right). Or 10%?

I’m happy either way as I can see HA progressing. But its progress ultimately relies upon its user base, which in turn is directly influenced by relationship between users and developers, by the way developers respond to their needs and issues - just because users are here if the product satisfies their needs.
Beta users will stay for sure as that’s their hobby, what about the majority? Everyone (both developers and users) should understand that.

[iantrich (Ian)]

I can understand frustrations on all of that, but at the end of the day, I’m just a guy who likes poking around in a project in his free time. I don’t really want to be more than that.

I mean, we try not to break things, we try to make informed choices, we try to make things better. But asking me or anyone really to talk to 50k users, to do case studies and user polls and filter through all that to make a change to icon coloring…that’s not something I’m going to do. But I’m not a core dev, I’m just a guy, trying to have some fun and make cool things

[AhmadK (akasma74)]

Got it, thanks
2 All: is everything clear now?

[123 (Taras)]

@iantrich

It was in the beta for a week and no complaints were raised during that time. A PR open for a week and a week in beta is, in my opinion, far from being rushed

I’m not entirely convinced that “no news is good news” during testing. No complaints may also be a result of:

• superficial testing
• exclusively focusing on pass/fail

In contrast, within a day of the feature’s release, members of this (large) community forum were reporting on its impact (reported in this thread and others and in GitHub).

I feel the community is a resource that ought to be leveraged earlier in the development process.

[AhmadK (akasma74)]

@123

I feel the community is a resource that ought to be leveraged earlier in the development process.

100%. However, we need to get this information to the decision makers.
Ian is just one of us

[Molodax (Alex)]

@AhmadK

Ian is just one of us

Except that he is creating code, not just consuming it and, therefore, his point is also very important.

[SeanM]

@123

Over 55K users have registered to this community forum. Would it not make sense to discuss some of the pre-release ideas here?

This sounds reasonable at first, but it ends up just opening a can of worms. All communities would (rightfully) want equal treatment. This forum has 55k users but the Home Assistant Reddit community is even larger. So it’d make sense to discuss it there as well, right?

Now you’re already up to 3 different locations, why not make it 4 or 5 and poll Facebook and Twitter too? Where do you make a cutoff that doesn’t make certain sub-communities feel left out? And now if you only participate in the forums (as several people here have indicated), you’d only be seeing a small fraction of the entire discussion. It quickly spirals out of hand, and places a very large burden on the contributor too.

GitHub is specialized for this exact purpose, the frontend repo has a feature request template and a bug report template. Things can be labeled and organized into roadmaps, easily cross-referenced and searched, etc. It’s far more efficient for all involved if the pre-release discussion happened there.

And this thread already has a good example of the current system working fine, @TazUk raised a valid issue using the proper avenue and @iantrich is adding support for it. Ian also improved the icon coloring for alarm control panel yesterday as well (here) based on feedback. Feedback is always welcome, just try to raise these issues in the proper spot for them.