I have a better idea.
Create new official, default theme, but provide the old theme to be optionally selected. Actually, themes are for what HA devs are doing. They should use them too.
I know that with the actual way of setting a theme (per end-device) it might feel annoying to change the theme on all devices, but there is a way to set up a backend-selected theme using automation.
maybe something like --state-person-zone-$(zone_name)-color
so one could (if he wants) do things like this:
state-person-zone-color: 'blue' # default, unless overridden for specific zones
state-person-zone-work-color: 'yellow'
state-person-zone-golf-club-color: 'lightgreen'
state-person-zone-home-color: 'darkgreen'
The frontend JS code is already dynamically constructing variable names and then looking up whether they exist, so this proposal would not be very far-fetched.
By the same principle we could then also color only one specific sensor:
And if the user does not specify any of these colors it should fall back to looking up the next higher more generic color in the hierarchy (default zone color, default color for all binary sensors, etc), so eventually, if none of these are specified, it will fall back to the pre 2022.12 theme color for everything that is active or inactive.
yes, that would work, and, on the other domains, is what we indeed should be having already. Being able to define dedicated on/off colors on the binary for example is so desired.
for me, zones was a bit of a surprise,( I have a lot of zones, and it would require some rethinking to see the need for separate colors there), but I guess that would indeed be a nice option. As long as you could set them (please no more randomized colorsâŚ)
You cannot directly edit that file, but you can override these colors with your own theme.
Alternatively (if you feel super nerdy) you can also inject your own JavaScript module into the default theme to override the values from there. This approach is usually not the recommended way, but it would allow you to test quick changes without reloading the theme or even without creating a theme at all.
use the ha-styles file only as a reference for which variable names are existing and what their default values are.
itâs here and you should bookmark it, since I practically can not remember a single release that didnt need some re-styling after changes in this file
As far as I have seen on github they have already begun changing it so that these are configurable. In the current latest release it is still hardcoded.
and again, thatâs the thing - people often donât use themes.
So, they basically have to create a theme that just âexposesâ the colors to be editable.
BUT:
Still⌠some might like the actual HA default theme - and just want to get rid of the color choicesâŚ
This should be addressed in the endâŚ
The goal would be:
Add official support for themes.
Which means:
Expose the Color for entities / entity states to the Card Configurator (UI).
anyone can choose the preferred colors, and colors per state
Add themable elements and document these:
Themable Elements are:
borders
border radius
shadows
headers (Card-Headers)
background colors / background images
etc.
These options should be:
Documented
strict â further UI development will also stick to these options.
That would allow:
1 - official Themes would not use undocumented features that might brake at some point
2 - allow better support, since everything is documented
3 - development of official âbuilt in themesâ that can be improved
4 - acceptance from the community, since they can still use custom themeing
5 - it woudl (probably) remove the need for card mod for many users
Its also incomplete, probably because this list is compiled manually. For example between 12.0 and 12.3 there was a fix that fixed the wrong home colors in the history (blue instead of green sometimes for some persons). It is not mentioned in the changelog.
(because of iPad)
