@stickpin Thx for this…
Is there a way to not make a new theme and just overwrite the default? now i have a new theme with the name state-colors… its not biggy
@stickpin Thx for this…
Is there a way to not make a new theme and just overwrite the default? now i have a new theme with the name state-colors… its not biggy
A parser definitely could be a proper tool without breaking users’ UIs.
That did the trick… thx again m8
In configuration.yaml
frontend:
extra_module_url:
- /local/theme-override.js
and in the www folder (which is always automatically mapped to the URL /local/) I created a file
/config/www/theme-override.js
with content like schown below, one line per variable (still incomplete because I only needed to override the binary-sensors at the moment):
document.documentElement.style.setProperty('--rgb-state-binary-sensor-color', 'var(--rgb-state-switch-color)');
This makes the binary sensor icon color the same as the switch color. It is injected into whatever theme you are using (in my case the default dark theme) without creating a new theme.
It also does not need a theme reload, only once to establish the extra_module_url, after this just hit shift + reload in the browser whenever you edited the .js file.
Do not think they will agree with it - that was announced (imho) as a main idea “define standard colors for each domain, each state for icons & graphs”.
I myself have nothing against this way. I even agree with it.
It could be really great (imho) when an icon & graph are of same color for same cases.
But:
– choice of colors should be very accurate & may not be perfected after just 1 iteration;
– themes should contain “rgb(255,255,255)”, “#ffffff” or “red” values (issue);
– the “paper-item-icon-active-color” should be kept as long as possible.
It should fall back to the old way of defining the colors if the new color variables are not set and by default they should not be set. Then they should document which variable to set SHOULD one wish to override the color for a certain class. That way nobody would even notice any change.
Mmmm, so far no docs for themeing. And it was said that officially only 2 vars are supported.
For me it seems like hiding internals from users.
A trend which includes “integrations moved to UI”, “more-info shows statistics instead of precise data”.
not to down your effort or solution, but this seems way more complicated than adding 1 variable in a theme (and have that loaded for all other themes if you use more of those, simply copy it in an anchor). see here
the latter has the advantage you can easily test and reload, see the result in the frontend immediately. And, it’s the ‘official’ way of dealing with color vars in themes as designed in HA Frontend.
I know. But my solution was a reply to the question how to do it without creating a new named theme to which I have to switch all clients, just inject it into the existing default theme.
yes, I see, and as said, it’s not meant as criticism.
as a tester I need the default theme alive… If something is borked in HA, and I need to create an issue, I always do so in default theme. To be sure no customization could be causing trouble. For that reason, I couldn’t follow your approach.
If you dont care about that, I guess it would be simpler. yet, you still need to be sure of the actual vars, and their correctness before injecting them into default.
I don’t get it. Using
## Variables
gruen-hell: 139, 195, 74
test-1: rgba(236, 201, 205, .5)
test-2: '#af6a71'
## Colors
rgb-state-input-boolean-color: var(--gruen-hell)
colors my activated input booleans light green.
state-input-boolean-color: var(--test-1)
or
state-input-boolean-color: var(--test-2)
does nothing. Only
state-input-boolean-color: '#af6a71'
works. Why?
It is a great solution.
I hate using themes. I have to walk around all computers, all portable devices, all wall displays, also the ones that belong to my wife. My computer at work. Everywhere just to adjust 3 colours.
I miss being able to change colours of a few critical elements. I do not want to be a theme designer. I just want my curtains to be orange when open instead of purple. PURPLE!! Oh my God. And my motion sensors red instead of a blue.
I think I will go for prof7bits solution unless this unfortunate situation 2022.11.0 has created gets improved.
Thanks a lot, this helped me out of this mess.
I was not able to make it work as well. Only with “#color”.
I haven’t read every post here as there are way to many. However I would like to suggest that all internal cards should now be like the new “Tile” card and have the option to be able to change the icon colour/color in the actual YAML config. All my buttons on my carefully sculpted and themed dashboards now all have yellow(ish) as the colour/color.
@petro your observation of everyone going from 0-100 anger is probably because it takes time to get this “just right”. I myself spent about an hour today getting a tab-based card to work (in YAML as no visual editor for it) with the grid card and all the themed colours/colors right. I then update HA and see all that hard work getting it right is half wiped out.
If the Button card I am using (and any other cards icon colour/color is relevant to) in the Grid had the ability to change the colour/color like the new Tile card, this would be a very simple thing to update. As it stands now I have to read through a thread of 137 posts, navigate the understandably frustrated people, and see if I can find something that will help add back in the ability to have my own colour/color for a given item.
There is an unwritten rule in software engineering:
“If you add a new configuration setting, then make its default setting behave like it was before that new setting existed.”
This golden rule has been violated.
To fix it all new color settings should by default be “undefined” and then make all undefined colors fall back to the existing theme color. Problem solved.
A month ago I said in a similar blog thread “do not turn Lovelace into Mushroom”. This is what happening now. And this way got its adepts.
Given the changes in this release, maybe the devs will consider officially supporting more than two theming colours going forward. It would solve a lot of problems.
I rolled back to 2022.11.5 too. So nice to have your original colours back. I will wait and see. The new update 2022.12.1 didn’t say much about colours so I wait and see a bit longer.