2022.12 Color states are broken/unusable

[CentralCommand (Mike)]

@KennethLavrsen

where I have used the oficially documented recommended method to control colours of individual entities with --paper-item-icon-color.

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.

[maxym]

@drawbars

Understood. I’m in the process of moving everything to custom button-card. I should have done so a while ago, but my philosophy has always been to use as much of the native functionality of a system as possible.

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.

[Ildar_Gabdullin]

@CentralCommand

It’s usually pretty bad practice to use implementation details in names of things that are officially supported since implementation stacks can change.

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)))

[Ildar_Gabdullin]

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 %}

[Ih8rain2 (Ed)]

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…

[robertwigley]

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.

[petro]

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.

[robertwigley]

Sounds like a plan. I’ll try to keep it updated if anything further comes up. I’m following the thread closely.

[adorobis]

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!

[piitaya (Paul)]

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.

[robertwigley]

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.

[Ih8rain2 (Ed)]

And is this sustainable with custom themes and when new updates are released ?

[piitaya (Paul)]

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).

[piitaya (Paul)]

If it’s documented, it will be sustainable.

[iDevice]

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…

[schleeh]

It worked! Just have to adapt the right color and it looks like before! Thanks a lot!

[arganto]

@arganto

I don’t get the change of declaration either but am very interested in this from a technical perspective.

Why is it defined as a plain number tuple without rgb() in the new variables (and than most probably used hard-coded within one other rgb() placeholder in the code) instead of having the common rgb() in the variables and use this than in the code afterwards 1:1? All the other rgba, hex, etc. are containing the declaring-type within the definition even in the related ts file. Only the new don’t do it.

Perhaps Paul can explain it in more detail?

BTW Will the announced dev blog for this topic be published (or is it already, but I have overseen it)?

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.

[robertwigley]

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.

[crzynik (Nicolas Mowen)]

Yes, so just change the cover color to whatever you want

state-cover-color: '#9C27B0' # Purple

[crzynik (Nicolas Mowen)]

You can see the answer directly from paul here: I dislike the 2022.12 Color changes - #46 by Mariusthvdb