If you post the lovelace card, someone will be able to show you the simplest way to get what you want.
Agree.
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.
It is impossible.
However, it’s reasonable to keep in mind that only an active minority (in terms of quantity) of users make FRs or ask for changes using various channels. The majority is happy and doesn’t want any dramatic changes.
If you ask them to vote before rolling out something major (and many of them woudn’t vote as they don’t care) then you can carry on with the active minorities’ ideas (provided you received enough support) and in case of riots say ‘look, we asked you’. But without such a voting/consultation it’s catering for minorities only I’m afraid. Well, that’s my personal view on it.
And thanks for keeping us informed, that’s very important.
Hope based on discussions on this forum there will be more ways how developers gather users’ feedback and weigh they decisions before implementing changes.
1 Like
Cut from within a vertical and horizontal stack, but this is the syntax for all the problem cards.
As an alarm_control_panel it is highlighted in yellow (I’m using the default theme) when disarmed.
- card:
entity: alarm_control_panel.blink_sync
hold_action:
action: call-service
service: alarm_control_panel.alarm_disarm
service_data:
entity_id: alarm_control_panel.blink_sync
icon: 'mdi:video'
name: Indoor
theme: Backend-selected
type: entity-button
conditions:
- entity: alarm_control_panel.blink_sync
state: armed_away
type: conditional
At first thank you for the contribution to this thread.
I need however comment on what you wrote. Quoted fragment seems to be inconsistent to me. But it might be due to my different point of view.
You mentioned 2 facts:
- Content Accessibility Guidelines
- newcomers (I’m one of them)
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.
You also mention that the new HA version adds other domains to behave like bulbs icon-wise. It means even more yellow color.
I know it already happened and will likely be not turned back. But if I go this way, I would provide some global switch (on root level) to maintain old behavior.
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.
with regards
well, I found it hard to see what icon it is when highlighted, maybe that’s what he meant?
the issue I see now is if there is no highlighting, some of my icons should reflect entity’s state but sometimes there are no crossed icons OR I don’t know how to change icon according to state (or maybe I just cannot justify creating a template wrapper just to get that changing icon).
But is it important? To the extent that it’s better to remove the coloring at all from icons of some domain (while adding it to other domains)?
Was changing active color under consideration? Maybe adding ability to change it on global level would help? Maybe making the yellow a bit darker? Maybe adding thing border or shadow…
IMO removing the functionality of providing visual cue was the worst choice considering HA UI’s main task is to signal states.
2 Likes
I have no answers and suspect they depend on who you ask.
All I know there was a long discussion that included a limited number of HA developers and contributors and there was no public survey carried out before implementing the change to find out what’s important to the community.
Here we are.
Now we need to file feature request “state_color: true” as default.
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.
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.
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.
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.
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.
No functionality was removed though, in fact more was added. The only thing that changed here is the default setting.
4 Likes
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. 
4 Likes
Over 55K users have registered to this community forum. Would it not make sense to discuss some of the pre-release ideas here?
2 Likes
and also avoid things like
which in turn supports this
and I understand and agree
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.
2 Likes
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”
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
11 Likes
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!
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!
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.
1 Like
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.
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.