I can imagine the complexity (not most complex thing over the world though). I’m a sw developer/architect for 25 years. I appreciate devs work (regardless it’s paid or for free). But I don’t buy the “beta” argument. How long it’s stucked in this phase? Is there a roadmap available? What is the final plan for entities behavior (considering we are experiencing a transition). It’s incrementally ongoing development for sure. But version number itself is meaningless.
well, the problem is they plans must take into account users’ feedback. I very well know what happens when people start doing something “for the best for others” and don’t get in touch with reality and are carried away by their fabulous ideas… to nowhere.
There is even an english proverb about good intentions but I’m not that proficient
My point here is that it doesn’t seem like a good mechanism of getting such a feedback does exist for HA (or maybe I’m not aware of it). FRs have no dev’s attention. PRs/issues being put down just because one person says no (and there were situations when it happened just because that person didn’t take time to read a proposal properly) or there is just no response to it at all (sounds very encouraging to anyone willing to contribute, and don’t forget - we are talking about the project that declares itself being hugely based on volunteers’ help).
So it’s very unclear how devs set their goals and what influences their decisions. If it does not include user’s feedback… it can be fatal in the long run as essentially it’s not users for HA, it’s the other way round. If users say “screw it if it screws us” who would be bothered about state_color or whatever?
I personally am trying to take it realistically and hope the devs-users interaction in terms of goals and decisions will improve in the long term as it’s definitely not at its best right now. It’s just a fact and I hope it won’t offend anyone, that’s definitely not my goal. I like this project and wish it only the best… but if it stops being suitable for my needs, I’ll have to go elsewhere if I have no way to influence.
I meant how complicated sometimes is for them to make a decision
Perhaps it’s a result of
I have enjoyed being on the sidelines of this discussion, since my UI is setup with mostly glances, entity buttons, and some conditionals.
However, I am still not sold on the reasoning for only lights being colored by default. Was it like, “What class entities do you guys thing should be colored by default?”, and the decision is made, “Just lights. I think colors on switches, binaries, and booleans are a rare use case. So we’ll default those to false.”
Seriously? I mean, OK it makes sense for most sensors, and stuff like zwave entities etc, but it seems common sense to default color on things that return only on/off, 0/1. Call me lost in translation, but I’m failing to see the logic there honestly. Again, I don’t even have a dog in this fight… just a casual observer offering $0.02.
This is actually one of the main reasons it was changed, to make things easier for newcomers. It was very tough to explain the previous setup - certain things got coloring and other things did not, and there was no clear reasoning why things worked the way they did. There wasn’t a consistent ruleset that you could easily explain.
The old behavior was far from perfect, it’s just that we got used to the quirks over time.
Aesthetically, having potentially dozens or even hundreds of small yellow icons on a white background would look awful and be very hard to see. That has a contrast ratio of 1.39:1 which fails Web Content Accessibility Guidelines.
It might look perfectly fine on your particular setup and theme, but everyone’s setup is different. Some people have really minimal setups but others – especially newcomers who haven’t yet learned about conditional cards and seperate views – have densely packed interfaces. We have to take into account things like the default auto-generated user interface which places ALL entities in one single view.
The default auto-generated user interface is one of the reasons why there must be a sensible default, because the auto-generated layout cannot be customized at all unless the user takes control. They would have no way of opting-in or opting-out and need to have something that looks and works good by default. This default UI is something that most existing / advanced users take for granted because we’re so used to customizing our layouts.
I realize it’s an inconvenience to update your setup to how it was before. But the fact that you can still do that means it’s not the end of the world. More domains have coloring now, and the user has more control than ever before - you can enable or disable coloring on a per-card basis, or even a per-entity basis. The current system is super flexible.
This very much incorporated user feedback, there were tons of requests to get coloring on input booleans and other domains/cards. Here’s one from Sept 2018 and another from Jan 2019 just to give two examples. It was put on the backburner for a long time because it’s a very difficult thing to figure out - there’s dozens of domains and two dozen Lovelace cards with very different styles and needs. It’s challenging to figure out something that works best for all of these.
Majority of the discussion about this change happened in public places - the GitHub link I shared earlier, the Discord chat, there was a public beta where everyone had a chance to provide feedback.
It’s impossible to please everyone, but I hope this post at least explains some of the reasoning as to why these choices were made.
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.
With this change my buttons are now coloured in line with the stipulated domain states (e.g. alarm_control_panel icons are coloured yellow when disarmed), and I have no way of changing that AFAIK as I cannot use ‘state_color: false’ within the entity-button card.
I spent over an hour trying to adjust this yesterday after upgrading before giving up. I’m now having to consider how to completely redesign this section of my UI to take it back to the state it was before the upgrade.
Irrespective of the reasoning behind altering this behaviour, it would seem logical to consistently offer the same control capabilities of this feature throughout all aspects of the user interface. I would assume that consistent entity / card features in the UI would be more friendly to new users?
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.
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.
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.
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.
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.
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.
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.
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.
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.
