I was told today that using “r,g,b,a” is done due to a need to achieve opacity.
Although the same may be achieved by using rgba(r,g,b,a) and HEX with a proper parsing (as it was noticed earlier by other user).
Can you point me to where this was officially documented? This isn’t sarcasm I genuinely want to know. My understanding was that there were only two things officially supported that themes could change - primary color and accent color. Everything else was undocumented and therefore use at your own risk.
I would also be rather surprised that something with paper in the name was officially supported and documented given paper is an old polymer component set (i.e. a specific implementation detail) and now no longer in use. It’s usually pretty bad practice to use implementation details in names of things that are officially supported since implementation stacks can change.
3 Likes
Good decision.
While I leave my development/experiment dashboards using native GUI (since I don’t use them often) my production dashboards are based 100% on custom button cards.
I call it a GOD CARD.
Here comes a good advise for card-modders: do not use variables, dig into DOM and change CSS properties directly.
Hmm, as for theme-developers - oh, these poor people)))
For those who wants to play with binary sensors of different device_classes - check this test card (use it in Panel mode):
It allows to see icons & graphs.
These device_classes are supported.
Code for the card (auto-entities are required + card-mod to make it compact)
type: horizontal-stack
cards:
- type: custom:auto-entities
card:
type: vertical-stack
title: input_boolean
card_param: cards
unique: entity
show_empty: true
filter:
template: |-
{% for state in states.input_boolean -%}
{%- if state.entity_id | regex_match("input_boolean.testing_device_class_", ignorecase=False) -%}
{{
{
'type': 'entities',
'state_color': true,
'entities':
[
{
'entity': state.entity_id,
'name': state.entity_id.split('testing_device_class_')[1]
}
]
}
}},
{%- endif -%}
{%- endfor %}
sort:
method: name
- type: custom:auto-entities
card:
type: vertical-stack
title: binary_sensor
card_param: cards
unique: entity
show_empty: true
filter:
template: |-
{% for state in states.binary_sensor -%}
{%- if state.entity_id | regex_match("binary_sensor.testing_device_class_", ignorecase=False) -%}
{{
{
'type': 'horizontal-stack',
'cards':
[
{
'type': 'entities',
'state_color': true,
'entities':
[
{
'entity': state.entity_id,
'name': state.entity_id.split('testing_device_class_')[1]
}
]
},
{
'type': 'history-graph',
'show_names': false,
'card_mod':
{
'style': '.content {padding: 0px !important}'
},
'entities':
[
{
'entity': state.entity_id
}
]
}
]
}
}},
{%- endif -%}
{%- endfor %}
sort:
method: name
Meta-Code for sensors (place it into Dev tools -> Templates, then use the generated code):
{% set CLASSES_BINARY_SENSOR = [
"battery",
"battery_charging",
"carbon_monoxide",
"cold",
"connectivity",
"door",
"garage_door",
"gas",
"heat",
"light",
"lock",
"moisture",
"motion",
"moving",
"occupancy",
"opening",
"plug",
"power",
"presence",
"problem",
"running",
"safety",
"smoke",
"sound",
"tamper",
"update",
"vibration",
"window"
] %}
{% set code_input_boolean = '
testing_device_class_{0}:' %}
{% set code_binary_sensor = '
- name: testing_device_class_{0}
device_class: {0}
state: >-
{{% set INPUT_NAME = "input_boolean.testing_device_class_{0}" -%}}
{{{{ states(INPUT_NAME) }}}}
attributes:
package_type_1: test
' %}
input_boolean:
{% for class in CLASSES_BINARY_SENSOR -%}
{{ code_input_boolean.format(class) }}
{%- endfor %}
############################################################################
template:
- binary_sensor:
{%- for class in CLASSES_BINARY_SENSOR -%}
{{ code_binary_sensor.format(class) }}
{%- endfor %}
2 Likes
And one more thing. I have never seen that the devs have done a roll-back on the comments of the community. Never. So let’s stay present until this has lead to something good and workable. For sure they can make that happen…
5 Likes
Thanks to others for doing the hard work. I’ve done a bit of tweaking to include descriptive colours and also remove the duplication for light and dark modes. Also for those who are not familiar with using themes and to try and summarise everything into one place, here are some hopefully simple instructions that everyone should be able to follow fairly easily and save having to read the entire thread if just looking for as close as I feel we can currently get to a solution. Note, as far as I can tell, certain things can’t be reversed currently e.g. locks are only coloured when locked and not when unlocked as there is no state-lock-unlocked-color to set it to amber and there is no state-alarm-disarmed-color to set it to green.
Place the following in configuration.yaml:
frontend:
themes: !include themes.yaml
For 2022.12.0 to 2022.12.3, create a themes.yaml file in your config directory and copy the following into it. For 2022.12.4, see the updated themes.yaml contents here.
Classic:
state-default-color: '#44739E' # Blue-Grey
state-alarm-armed-color: '#F44336' # Red
state-alarm-arming-color: '#FF9800' # Orange
state-alarm-pending-color: '#FF9800' # Orange
state-alarm-triggered-color: '#F44336' # Red
state-alert-color: '#F44336' # Red
state-automation-color: '#FFC107' # Amber
state-binary-sensor-color: '#FFC107' # Amber
state-binary-sensor-alerting-color: '#F44336' # Red
state-calendar-color: '#2196F3' # Blue
state-camera-color: '#2196F3' # Blue
state-climate-auto-color: '#4CAF50' # Green
state-climate-cool-color: '#2196F3' # Blue
state-climate-dry-color: '#FF9800' # Orange
state-climate-fan-only-color: '#00BCD4' # Cyan
state-climate-heat-color: '#FF5722' # Deep Orange
state-climate-heat-cool-color: '#FFC107' # Amber
state-climate-idle-color: '#BDBDBD' # Disabled (Light Grey)
state-cover-color: '#9C27B0' # Purple
state-fan-color: '#00BCD4' # Cyan
state-group-color: '#FFC107' # Amber
state-humidifier-color: '#2196F3' # Blue
state-input-boolean-color: '#FFC107' # Amber
state-light-color: '#FFC107' # Amber
state-lock-jammed-color: '#F44336' # Red
state-lock-locked-color: '#4CAF50' # Green
state-lock-pending-color: '#FF9800' # Orange
state-media-player-color: '#3F51B5' # Indigo
state-person-home-color: '#4CAF50' # Green
state-person-zone-color: '#2196F3' # Blue
state-remote-color: '#2196F3' # Blue
state-script-color: '#FFC107' # Amber
state-sensor-battery-high-color: '#4CAF50' # Green
state-sensor-battery-low-color: '#F44336' # Red
state-sensor-battery-medium-color: '#FF9800' # Orange
state-sensor-battery-unknown-color: '#BDBDBD' # Disabled (Light Grey)
state-siren-color: '#F44336' # Red
state-sun-day-color: '#FFC107' # Amber
state-sun-night-color: '#673AB7' # Deep Purple
state-switch-color: '#FFC107' # Amber
state-timer-color: '#FFC107' # Amber
state-update-color: '#4CAF50' # Green
state-update-installing-color: '#FF9800' # Orange
state-vacuum-color: '#009688' # Teal
modes:
light:
state-default-color: '#44739E' # Blue-Grey
dark:
state-default-color: '#44739E' # Blue-Grey
I have changed the colour of state-lock-locked-color from red to green on my latest edit, as, for me at least, it makes more sense to be green than red, indicating all is OK and it’s locked.
As with all the colours you can copy and paste them to each variable to suit your needs. e.g. if you want covers to no longer be the new Purple colour and the default Blue-Grey, change state-cover-color: '#9C27B0' # Purple to state-cover-color: '#44739E' # Blue-Grey. As mentioned previously, we can’t quite revert everything to exactly how it was before, but this does allow us to get pretty close and certainly to a more useable state, in my eyes at least.
Next, create a new automation to load the Classic theme on startup for all users:
# Set the default theme to Classic
- id: A550734A-8AAC-4436-AF15-8193FAF984D5
alias: "System: Set default theme to Classic"
trigger:
- event: start
platform: homeassistant
action:
- service: frontend.set_theme
data:
name: Classic
mode: light
Subsitute dark into the automation in place of light if you would rather have dark mode set. Note you may also need to set your theme to Backend-selected in your profile if you have changed this previously.
Lastly, restart Home Assistant.
Also, for easy reference, I’m duplicating here a couple of useful links to the state entity colours and state entity colour variables.
51 Likes
If you don’t mind keeping that post updated, I’ll mark it as a solution for people who don’t want to read the whole thread.
7 Likes
Sounds like a plan. I’ll try to keep it updated if anything further comes up. I’m following the thread closely. 
1 Like
I have also came to conclusion that the best will be to use some custom themes. Many thanks for this one as it is not that obvious how to get the yaml file for the standard theme We’re back in the good accessibility of the frontend!
Hello.
In the coming days, I will propose a guide to upgrade your theme to the new variables and I will list all the new supported variables so you can use them without any worry. I just don’t want to write it too quickly because there are a few variables to adjust using your feedbacks.
We’ve been stuck for years with unofficial theme variables using --paper-item things. We want to propose a better way to theme things, officially supported.
I try to read feedbacks, ignore non-constructive complaints and do PRs to fix things as much a possible. 
32 Likes
That would be appreciated. Could we also have variables for e.g. state-lock-unlocked-color and state-alarm-disarmed-color at some point in the future, as it seems a bit strange that we can’t set a highlight/alert colour when the lock is unlocked, unless I have missed something.
2 Likes
And is this sustainable with custom themes and when new updates are released ?
There are discussions about alarm/lock on Github 
It’s not an easy subject as a lock can be viewed a secure device (lock is the active state) or an alerting device (unlocked is the active state in this case).
2 Likes
If it’s documented, it will be sustainable.
2 Likes
This is awesome, thanks for this work ! 
But the covers are still purple, is it intentional ?, because there weren’t before 2022.12.
So although it’s now close, I wouldn’t call this a total workaround (yet).
No big deal, I’m just nit-picking , I’ve already modified it, and I’m happy now…
It worked! Just have to adapt the right color and it looks like before! Thanks a lot!
1 Like
Can you give some explanations and details, Paul? Would really appreciate it.
Until now I heard only here and there that is might be because … or that it is said (where, from whom) that some things … But not really the technical background.
Just subsititute whatever colours you want for each device type. It’s still a bit of a work in progress as I spot devices that are the wrong colours. You can put the Default colour for each device type if you want. I will update the post with this information.
1 Like
Yes, so just change the cover color to whatever you want
state-cover-color: '#9C27B0' # Purple