wait, I never read that beforeā¦ are you serious? what is not robust in your experience? I must have a look if that could speedup my config maybe.
tbh, Ive never met a case where this does not work, but, given the core support for those state colors, it does sound very interesting, even more āsupported in coreā for that matter.
thing is, there are quite a few domains Not supported in state color theming, sensor being one of the main domains ofc, so we can only use --card-mod-icon(-color).
# pm25_color:
style: |
:host {
{% set air = states(config.entity)|float(-5) %}
--card-mod-icon-color:
{% if air < 35 %} var(--ok-color)
{% elif air < 85 %} orange
{% elif air >= 85 %} var(--alert-color)
{% else %} var(--no-power-color)
{% endif %};
}
is my main way of modding the icon-color and this works domain independent., even overrules device_class nicely without !important
# active_icon:
# replacing the mdi:play/stop now set by the device_class: running
style: |
:host {
--card-mod-icon:
mdi:{{'checkbox-marked-circle' if is_state(config.entity,'on') else
'radiobox-blank'}};
}
what I am trying to say: looking for a spot this is not robust, so I can test that seriously
and suppose we should not pursue to use the --paper-item-icon-color variable anymore, so this would be the ādefaultā replacement for what I have above:
card_mod:
style:
hui-generic-entity-row:
$: |
state-badge {
color: {{'red' if is_state(config.entity,'below_horizon') else 'green'}};
}
which to me seems more fragile and complex, and most of all, loses the elegance of using both --card-mod-icon
and --card-mod-icon-color
on the same element in the dom path
(ofc except the case I posted about yesterdayā¦)