I am trying to set conditional icons using customization
Friendly name part works, so I know this customization file loaded
Icons not work.
Neither conditional nor simple customization for counter.errors_counter
Does anyone see any problem?
(I use Lovelace UI in yaml mode)
No errors or warnings in the log file.
binary_sensor.router_tanda_floor_1:
friendly_name: "WiFi router FL1"
binary_sensor.color_printer:
friendly_name: "Color printer"
counter.warnings_counter:
templates:
icon: >
if (state == 0) return 'mdi:lightbulb-outline';
return 'mdi:lightbulb';
counter.errors_counter:
templates:
icon: 'mdi:lightbulb-outline'
climate.living_room:
templates:
icon: >
if (state === 'heat') return 'mdi:fire';
if (state === 'cool') return 'mdi:snowflake';
if (state === 'idle') return 'mdi:sleep';
return 'mdi:power-off';
icon_color: >
if (state === 'heat') return 'red';
if (state === 'cool') return 'blue';
if (state === 'idle') return 'black';
Ok ok. I am new to this and donāt fully understand the ways each thing works yet. The documentation is incomplete, not very clear and full of typos and wrong examples. And I know how to use documentation, I am engineer Anyway. Thank you for pointing out that it is Custom-UI functions. I will install it now.
just to be a bit more specific:
you can customize icons in regular HA, without custom-ui, on several components that support this. Template sensors, and template binary sensors, and a few more can use these Jinja templates, see https://www.home-assistant.io/components/#search/template
General advice would be to use HA templates whenever you can, and use the custom-ui templates if you must.
Both have impact on performance, especially when evaluating states of other entitiesā¦
the climate.living_room isnāt a components listed to use icon_templates (as far as I could check) so a custom-ui JS templates would be necessary. The one posted is perfect, and would do the trick. Id give icon_color and extra line for the āelseā (which you need not state), simply enter return 'grey';
icon_color is a custom-ui template always, since it isnāt available in the HA templates defaults.
an example for Jinja would be:
icon_template: >
{% set state = states('sensor.number_of_days_next_alarm') %}
{% if state == 'Not set' %} mdi:alarm-off
{% elif state == 1 %} mdi:numeric-{{state}}-box-outline
{% else %} mdi:numeric-{{state}}-box-multiple-outline
{% endif %}
Note that these donāt need quoted values for the icons, while JS always uses quotes.
You are right. Becouse number of examples in documentation are very limited and amost all relevant examples I take from this site. But it is not always clear is discussed functionality from core or from custom components.
So exactly becouse of perfomance I would say that client side evaluation preferable in most cases. Especially if HA runs on PI and you are working with UI usually from PC with x10 processor power.
well, ymmv, as always. And I think I must say youāre right.
One extra advantage of using native templating is you wonāt need external or custom components.
I have a lot of customizations. Not one entity isnāt customizedā¦ and yet, the only ālagā or performance issues I see are templates using other templates, in regular Jinja that isā¦
Iāve solved most of these by finding the correct entity_id;s to mention in the templates.
Custom-ui is always spot on. Still, it was advice the autor of custom-ui gave me.
The migration to Lovelace might be another reason for folks to use HA native as much as possible.
to get back to this topic: are your icons working now?
Yes. Working now after i installed custom-ui. Thanks. I would also prefer to use only native functions. But i need this for counter and I donāt want to create additional sensor etc. Things are pretty complicated as is. And anyway native template doesnāt allow color change and this is really nice. I hope they will add this functionality one day.
as an example, maybe a bit extreme , this template changes the icon only after a while, and sensor.time kicks in:
number_of_days_next_alarm:
friendly_name: Days to next alarm
entity_id:
- sensor.time
- input_boolean.alarmclock_wd_enabled
- input_boolean.alarmclock_we_enabled
- input_number.alarmclock_wd_hour
- input_number.alarmclock_wd_minute
- input_number.alarmclock_we_hour
- input_number.alarmclock_we_minute
icon_template: >
{% set state = states('sensor.number_of_days_next_alarm') %}
{% if state == 'Not set' %} mdi:alarm-off
{% elif state == 1 %} mdi:numeric-{{state}}-box-outline
{% else %} mdi:numeric-{{state}}-box-multiple-outline
{% endif %}
value_template: >
{% if is_state('input_boolean.alarmclock_wd_enabled','on') %}
{% if now().weekday() in [0,1,2,3] %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_wd_time') %} 0
{% else %} 1
{% endif %}
{% elif now().weekday() == 4 %}
{% if is_state('input_boolean.alarmclock_we_enabled','on') %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_wd_time') %} 0
{% else %} 1
{% endif %}
{% else %} 3
{% endif %}
{% elif now().weekday() == 5 %}
{% if is_state('input_boolean.alarmclock_we_enabled','on') %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_we_time') %} 0
{% else %} 1
{% endif %}
{% else %} 2
{% endif %}
{% elif now().weekday() == 6 %}
{% if is_state('input_boolean.alarmclock_we_enabled','on') %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_we_time') %} 0
{% else %} 1
{% endif %}
{% else %} 1
{% endif %}
{% endif %}
{% elif is_state('input_boolean.alarmclock_we_enabled','on') %}
{% if now().weekday() in [0,1,2,3] %} {{5 - now().weekday()}}
{% elif now().weekday() in [4] %} 1
{% elif now().weekday() in [5] %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_we_time') %} 0
{% else %} 1
{% endif %}
{% elif now().weekday() == 6 %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_we_time') %} 0
{% else %} 6
{% endif %}
{% endif %}
{% else %} Not set
{% endif %}
while using custom-ui:
sensor.number_of_days_next_alarm:
templates:
icon: >
if (state == 'Not set') return 'mdi:alarm-off';
if (state == 1) return 'mdi:numeric-' + state + '-box-outline';
return 'mdi:numeric-' + state + '-box-multiple-outline';
icon_color: >
if (state == 'Not set') return 'grey';
return 'red';
makes it instantaneous.
Got to keep in mind that when using templates based on the value of another entity (or maybe an icon ā¦) it can propagate that lag throughout the HA, and even though the custom-ui has already changed the icon, HA state machine hasnāt yetā¦
Iām new to this as well (first post ), sorry if this seems like a dump question.
value_template: >
{% if is_state('input_boolean.alarmclock_wd_enabled','on') %}
{% if now().weekday() in [0,1,2,3] %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_wd_time') %} 0
{% else %} 1
{% endif %}
{% elif now().weekday() == 4 %}
{% if is_state('input_boolean.alarmclock_we_enabled','on') %}
{% if now().time().strftime('%H:%M') < states('sensor.alarmclock_wd_time') %} 0
{% else %} 1
{% endif %}
Why are you checking the is_state('input_boolean.alarmclock_we_enabled','on') in every statement? Does this have to be checked every time? Normally, anything inside the first if-statement should only be there, if the state is on.
Again, this is a noob question, maybe thereās a reason for.
there might be a prettier way to do so, and I admit this is a verbose template. best hop over to Spot the error... nested template for this particular template.
just be precise, Im not checking for the same here, its all about weekdays alarms (wd) and weekend alarms (we)ā¦on weekdays and weekend daysā¦
Another improvement is to create binary sensors for templates you use in more than one place. It only has to be evaluated once and the state changes are easy to implement in automations and quick to trigger.
yes, thanks, working on that now evaluating if that would be an improvement in my particular template. As a general rule, that is a thing to keep in mind indeed.