Colors signaling a state of an electrical device are. Sometimes just to have a quick view on a situation. But sometimes they are the only barrier between life and death.
With HA mostly the second is not present. But still, they can be very important.
Just please, do not make this kind of resolutions, just because they are not important for you. As we can see clearly in the last 7 days, there are many people with a different view.
I’m not affected very much by this issue, so I’m not choosing side’s on the topic. Just it bothers me seeing people not being taken seriously, if they have problem with some changes.
So, in my opinion, they are sometimes very important colors.
Marius, I was simply pointing out to Bill that the colors were shown in the beta and it wasn’t conflagrated to the level that it currently is. I did not say “No one found issues and everyone was happy”, so please don’t act like I said that.
If we were talking about colours of the general user interface then yes.
But this is not about font colours, or colours of headers or dialogue boxes.
The issue is FUNCTIONAL colours. It is colours that reflects the state of entities in the UI. And not only the standard UI but also the UI that I have spent hours defining the way I want them.
We have every reason to be a grumpy bunch because our dashboards that our families use in their daily life are totally functionally broken unless we constantly spend hours trying to fix it back.
And the answer doesn’t help anyone. You said the exact same thing basically in the release thread replying to no-one. At this point it seems like you’re trying to start a witch hunt. Stop. As you can see, your comment already started another argument for what good? None.
Stick to the topic at hand: Getting the colors and issues fixed.
?
I didnt want to at all.
I was merely trying to illustrate the fact the issues have increased after the beta, so that would explain to some extent the intensity increase in issues.
Dont read anything personal in my post please, as I said, not my intention at all
Here’s the updated themes.yaml for 2012.12.4 from my earlier solution, which takes into account the new variables in 2012.12.4 and ‘partially’ restores the green state to the alarm when disarmed (the icon doesn’t show green, but the Alarm Control Panel does) and sets armed to red.
Given a few more things have ‘broken’ in this release (e.g. the locked state of a lock no longer respects the green colour set in the variable), I suspect there may be a chance that this needs to be updated again when the next patch is released. I’ll update the original post/solution with a link to here for now, as it seems to be a bit of a moving target at the moment. Hopefully I will be able to update the original post fully once things settle down a bit.
You should be able to update your post indefinitely. I update some of my old bookmarked posts ~3 or ~4 years after the fact on a regular basis when things are updated or changed.
I’m intentionally trying to keep it partially separate for now, with links in both directions, as not everyone will necessarily have updated to 2022.12.4. Once things settle down and we have a more ‘final’ solution, I will fully update the original post with the latest yaml.
So let’s sumarize.
Devs introduced rgbprefixed color variables, where rgb indicates the need of using list of values instead of CSS color methods (#/rgb/rgba/hls/etc)
So, not only they cannibalized CSS, they did it in an inconsistent way (there are still lot of color variables that allow using CSS methods, see link above) and on top of this they introduced names that are dependent on a current framework limitations. Arent’ there any reviewer who can stop doing such antipatterns?
I guess we can expect another clusterf* in a year or two because names of those variables will likely change again (if they decide to improve the approach, for example allowing again use of CSS methods for those colors)
Color variable names have to remain technology agnostic. Shouldn’t contain information about the way how colors are being set, or what color model is used for that. --rgb-state-climate-heat-color should be --state-climate-heat-color instead
Thanks for keeping it updated. Do you know if we can specify in theme colors for various device classes? E.g. binary_sensors now have different colors depending on class (as per the page you’ve shared earlier) e.g. connectivity, problem etc. Is there a particular naming convention for that?
I believe the only variables that exist are what you see in the state entity colour variables, which are all duplicated and modified to some extent in my themes.yaml. You can change any of them to whatever you want though, just not ones that don’t exist (yet).
Hmm. You are right. After looking into changes history, there were several rgb variables year ago already.
Not sure how important and how widely were used.
But now they introduced a lot of them for specific devices/entities and their states. So the impact will be huge once they change the approach.
If you’ve been paying attention to the thread, you would have found out that the goal is to have supported variables so this doesn’t happen again. That was mentioned posts ago.
I just proposed in one of the issues about zone colors to make the frontend code also look for variables that contain the entity-id, optional but with higher precedence than the domain specific variables.
This would allow for
state-person-zone-work-color: 'red'
state-person-zone-church-color: 'yellow'
state-person-zone-golf-color: 'lightGreen'
state-person-zone-color: 'blue' # all other zones
When it does not find a matching variable for a certain entity it would fall back to the more generic domain color. This could be done for all domains, not only zones, it would create a zillion possible variable names and allow every entity to have its own set of colors (and by the same mechanism maybe even different colors for history and entity card), but none of them needed to be defined, it would be completely optional, it would always fall back to the next more generic variable in the hierarchy (ideally all the way back until it arrives at the theme accent color).
I would love something like this implemented. Then also a lot of the new default colors could be removed again and it would simply fall back to the old default colors. This would end all discussions, be 100% backwards compatible and would still allow complete theming of everything.
Great!
But unfortunately history graph for binary_sensors (and as I see, for binary_sensors only but not for switches, lights etc.) uses the same color for both “on” and “off” states. This color may be amber or red depending of device_class, but it does not change depending of state.
