It would not work for me as a yaml drop in for the automation; I just had to use the UI to duplicate the contents for the automation and it worked.
This is my generated yaml for the automation:
alias: Set_Theme
description: Set default theme to Classic
trigger:
- platform: homeassistant
event: start
condition: []
action:
- service: frontend.set_theme
data:
name: Classic
mode: single
Fully agreed with that.
I also just canceled my subscription for the same reasons.
Yes I agree, we should fix that 
So how do those of us that manage our HA via the gui, which is being increasingly favoured, correct this problem?
I see mentions above about âchange your themeâ, Iâve never set a theme so how do I change it?
I think if you look at your own post, you said that folks have been asking for this ability and for the more advanced Iâm sure theyâll love it, but why force it on all and make such poor choices of colours? Blue for off and yellow for on has gone to an imperceptible change in shade of blue for some items not all!
The result being my 80 year old in-laws havenât had any heating all day cause they couldnât understand if it was on or off.
Check the marked solution 
How cold did it get?
Too cold to be acceptable.
Which is where? Donât see anything on this thread. And itâs not really a situation for people are pissed.
What was the acceptable value and is it perceivable to occupants?
So there isnât a GUI solution then or am I missing something?
Iâm fully upset with the changes as most of the people mentioned here. Iâm a developer and I understand that the things have to move forward, but never in a not mature way and not under A/B test without getting massive user feedback.
On the other hand, as an engineer I try to solve problems with the tools I have and I came here with a modification of my theme to bring back the style I had. This change was mentioned above by stickpin
modes:
light:
state-default-color: "#44739E"
state-alarm-armed-color: "#F44336"
state-alarm-arming-color: "#FF9800"
state-alarm-pending-color: "#FF9800"
state-alarm-triggered-color: "#F44336"
state-alert-color: "#F44336"
state-automation-color: "#FFC107"
state-binary-sensor-alerting-color: "#F44336"
state-binary-sensor-color: "#ff8000"
state-calendar-color: "#ff8000"
state-camera-color: "#ff8000"
state-climate-auto-color: "#ff8000"
state-climate-cool-color: "#ff8000"
state-climate-dry-color: "#ff8000"
state-climate-fan-only-color: "#ff8000"
state-climate-heat-color: "#ff8000"
state-climate-heat-cool-color: "#ff8000"
state-climate-idle-color: "#BDBDBD"
state-cover-color: "#ff8000"
state-fan-color: "#ff8000"
state-group-color: "#ff8000"
state-humidifier-color: "#ff8000"
state-input-boolean-color: "#ff8000"
state-light-color: "#ff8000"
state-lock-jammed-color: "#F44336"
state-lock-locked-color: "#F44336"
state-lock-pending-color: "#FF9800"
state-media-player-color: "#ff8000"
state-person-home-color: "#ff8000"
state-person-zone-color: "#ff8000"
state-remote-color: "#2196F3"
state-script-color: "#FFC107"
state-sensor-battery-high-color: "#4CAF50"
state-sensor-battery-low-color: "#F44336"
state-sensor-battery-medium-color: "#FF9800"
state-sensor-battery-unknown-color: "#BDBDBD"
state-siren-color: "#F44336"
state-sun-day-color: "#FFC107"
state-sun-night-color: "#673AB7"
state-switch-color: "#ff8000"
state-timer-color: "#FFC107"
state-update-color: "#4CAF50"
state-update-installing-color: "#FF9800"
state-vacuum-color: "#ff8000"
dark:
state-default-color: "#44739E"
state-alarm-armed-color: "#F44336"
state-alarm-arming-color: "#FF9800"
state-alarm-pending-color: "#FF9800"
state-alarm-triggered-color: "#F44336"
state-alert-color: "#F44336"
state-automation-color: "#FFC107"
state-binary-sensor-alerting-color: "#F44336"
state-binary-sensor-color: "#ff8000"
state-calendar-color: "#ff8000"
state-camera-color: "#ff8000"
state-climate-auto-color: "#ff8000"
state-climate-cool-color: "#ff8000"
state-climate-dry-color: "#ff8000"
state-climate-fan-only-color: "#ff8000"
state-climate-heat-color: "#ff8000"
state-climate-heat-cool-color: "#ff8000"
state-climate-idle-color: "#BDBDBD"
state-cover-color: "#ff8000"
state-fan-color: "#ff8000"
state-group-color: "#ff8000"
state-humidifier-color: "#ff8000"
state-input-boolean-color: "#ff8000"
state-light-color: "#ff8000"
state-lock-jammed-color: "#F44336"
state-lock-locked-color: "#F44336"
state-lock-pending-color: "#FF9800"
state-media-player-color: "#ff8000"
state-person-home-color: "#ff8000"
state-person-zone-color: "#ff8000"
state-remote-color: "#2196F3"
state-script-color: "#FFC107"
state-sensor-battery-high-color: "#4CAF50"
state-sensor-battery-low-color: "#F44336"
state-sensor-battery-medium-color: "#FF9800"
state-sensor-battery-unknown-color: "#BDBDBD"
state-siren-color: "#F44336"
state-sun-day-color: "#FFC107"
state-sun-night-color: "#673AB7"
state-switch-color: "#ff8000"
state-timer-color: "#FFC107"
state-update-color: "#4CAF50"
state-update-installing-color: "#FF9800"
state-vacuum-color: "#ff8000"
Hope it helps someone
Dear Robert
I followed your solution and in the dark theme i have the sensors to be orange again but i have a binary sensor that i had created that doesnt change to orange.
In the Screenshot its the marked with the Red sign.
The binary sensor is On when the temperature is above 42c so in lovelace there is a ThumbUp that is yellow⌠If the temp is below 42 the icon became thumb Down, this helps the wife to see fast if the water temp is ok to shower.
I think i need something extra to declare in your classic theme but i dont know what.
Edit: nevermind⌠i had in lovelace for this the state_color to false⌠i change it to true and all is fine now.
Sorry.
Unhappy with the new colors. Ugly, confusing, and poor contrast. Please add a kill switch.
This actually makes me a bit concerned about this open source project. Itâs been so successful. Incredible, really. But many projects with lots of developer support, sometimes they turn a corner into making changes for changes sake. Philosophically speaking⌠just because you can, doesnât mean you should.
It is when I get the same question to that post over and over again. My patience has dwindled. Sorry you didnât like the colors.
Nothing to do with not liking the colours, itâs a bad decision poorly executed. Your just showing that you donât âgetâ the problem.
No wonder you have comments about lack of respect for users and people cancelling subscriptions.
I have to repeat because not getting an understanding.
Colors - black or red - are NOT a problem.
Surely, some colors like âdifferent shades of blue for different statesâ are not good for old people, myopic people, colorblind people, low-quality tablets, outdoor displays when sunny, âŚ
Anyway, do not like a color - change it in a theme.
And some advises are already given by people on Github - hope they will be heard, accepted & implemented.
The problem is in a SUDDEN change - without any warnings like âthis feature is going to be unsupported in 2022.12â:
â removed varaible ââpaper-item-icon-active-colorâ;
â new variables are now â255,255,255â instead of ârgb(255,255,255)â or â#ffffffâ or âredâ.
1.Regarding the removed variable.
We were told that HA officially supports only a couple of vars - but still using a ânot officially supported variableâ in Docs - as it was already mentioned here.
Anyway, even this removed variable was NOT officially supported - donât Dev people know that it is used by plenty of users? Even w/o custom themes, even w/o card-mod.
A simple example - with official Picture elements:
style:
...
'--paper-item-icon-active-color': red
Now it does not work due to the removed variable.
Not to mention plenty of people using card-mod - which is 3rd-party plugin but it is used by many people.
2.Regarding the â255,255,255â format.
Assume I want to override colors for a binary sensor in the same official Picture Elements:
style:
...
'--rgb-state-binary-sensor-alerting-color': green
Does not work, as well as:
'--rgb-state-binary-sensor-alerting-color': rgb(0,255,0)
'--rgb-state-binary-sensor-alerting-color': '#00ff00'
'--state-binary-sensor-alerting-color': rgb(0,255,0)
'--state-binary-sensor-alerting-color': '#00ff00'
'--state-binary-sensor-alerting-color': green
We need to use:
'--rgb-state-binary-sensor-alerting-color': 0,255,0
If people have some logic to define those colors like by template sensors, custom cards like config-template-card, card-mod - then they have to change their code to this â255,255,255â format.
I asked the Dev person here about a reason of this â255,255,255â change - he answered like âneeded for a Tile card to add opacityâ.
Guys, since when one particular card (even a great one) becomes a reason to break many peopleâs solutions for other cards? And why a different logic cannot be used to extract an opacity from rgba() or HEX value?
Also I was told that non-rgb âproxiesâ like âââstate-binary-sensor-alerting-colorâ are exposed only if a user defined a custom theme and this âââstate-binary-sensor-alerting-colorâ variable is defined there as a HEX value.
What is this such a limitation for?
All these color chages are NOT a huge problem for me, just a matter of time I spent to fix it.
I am a rather experienced user, may use themes, card-mod etc, also living in a russo-fashist Russia adapted me to more serious troubles.
These changes mainly affected less experienced users who has already spent their time to build a perfect UI, now have to rebuild it.
Even waste of time may not be a problem.
The problem is that these changes are SUDDEN, are not defined as BREAKING, and was not DISCUSSED with users before.
There are solutions like MiHome, Apple Homekit etc - but they are proprietary & commercial.
HA is a solution of many people involved - developers & users. And both sides must RESPECT each other. In this particular case - these changes must be discussed first.
there is css function for such usecase: rgba(). Using rgb() instead of rgba is valid case and means no opacity.
Wonder if the dev doesnât know that.
I am sure they do know it.
I guess (can only guess) that it is easier to extract an opacity from â255,255,255,0.9â value than from a ârgba(255,255,255,0.9)â or some corresponding HEX value (#efffffff).
Note that I have never been a web developer or a web-designer, cruise missiles were my specialization.
Also it may not be a problem to use a ârgb(255,255,255)â value and add an opacity AFTER.
I understand problem, I really do. But you chastised me for asking for everyone to remain calm⌠Iâm a moderator, I have nothing to do with this change. Iâm not closely tied with the dev team. I did not make the decision. Iâm just asking everyone to remain calm When reporting issues. If you canât remain calm when replying to me, then youâre going to get a sarcastic response. Sorry, actions have consequences.
retrieving opacity from this expression is the same common task as extracting colors. which wasnât the case till now. So⌠no, I donât buy it. The answer you mentioned sounds to me evasive (at least)