which in the frontend seem to have the same effect:
homeassistant:
customize:
binary_sensor.asus_router:
templates: &binary_color
icon_color: >
if (state == 'on') return 'green';
return 'red';
binary_sensor.iungo:
templates: *binary_color
and
binary_sensor.iungo:
templates:
<<: *binary_color
havent been able to find a clear description of the difference between these options, so hope anyone here can help me out?
thanks
I know this, but explaining it may be beyond my grasp.
The first one duplicates the contents of a key, the second one kind of merges the bits from the first one in in to the key you add it to. I can’t copy from my config as I’m on my phone, so permit a screenshot of the ‘merge’ one…
And a link to an example of the other one I did for someone recently…
Which hopefully explains it 
will try to make myself believe that 
but thanks! need some time to consume this.
Maybe a quick (… ) other question.
my use case for these yaml anchors mostly is I the customize department. for most entities, I want a customization for icon, and icon_color. I know how to declare the anchor for the individual icon: and icon_color templates, and how to merge them:
switch:
templates:
icon: >
if (state == 'on') return 'mdi:toggle-switch';
return 'mdi:toggle-switch-off';
<<: *state_color
assuming I have the &state_color declared before that.
even use them like:
switch.netwerk_auditorium:
templates:
<<: *wifi_icon
<<: *state_color
what I dont know is how to create a new anchor in an existing one, like the first example I posted above, eg how to create a new anchor for the icon_template:
switch:
templates:
icon: >
if (state == 'on') return 'mdi:toggle-switch';
return 'mdi:toggle-switch-off';
<<: *state_color
What I do now, is create a fake entity atop of the file
customize:
# fake entities to use below
sensor.amp_icon:
templates: &_icon
icon: >
if (state == 'on') return 'mdi:amplifier';
return 'mdi:amplifier-off';
sensor.child_bed_icon:
templates: &child_bed_icon
icon: >
if (state == 'on') return 'mdi:human-child';
return 'mdi:bed';
sensor.fridge_icon:
templates: &fridge_icon
icon: >
if (state == 'on') return 'mdi:fridge';
return 'mdi:fridge-off';
to write that anchor and reuse it below. But shouldn’t we be able to create it on the fly in that existing set for the icon alone (while the icon_color already is using another anchor?
It’s a bit fiddly with indentation, but it’s something like this…
switch:
templates:
<<: &icon_template
icon: >
if (state == 'on') return 'mdi:toggle-switch';
return 'mdi:toggle-switch-off';
<<: *state_color
And depending on whether you want *state_color as part of *icon_template or not you may have to move the last line back (or maybe forward 
) two spaces.
Best thing is to lob it in an online yaml-to-json converter and observe the resulting output.
thanks! that was exactly what I was looking for. cool. no more fake entities 
have only 1 anchor wish left. discussed before, but maybe now is possible since Ive change the setup since then:
dorm_sensor_light_level_raw:
value_template: >
{{state_attr('sensor.dorm_sensor_light_level','lightlevel')}}
friendly_name_template: >
Dorm:
{% set light_level = state_attr('sensor.dorm_sensor_light_level','lightlevel')|int %}
{% if light_level < 1 %} dark #<---- from here identical to all the others
{% elif light_level < 3000 %} bright moonlight
{% elif light_level < 10000 %} night light
{% elif light_level < 17000 %} dimmed light
{% elif light_level < 22000 %} 'cosy' living room
{% elif light_level < 25500 %} 'normal' non-task light
{% elif light_level < 28500 %} working / reading
{% elif light_level < 33000 %} inside daylight
{% elif light_level < 40000 %} maximum to avoid glare
{% elif light_level < 51000 %} clear daylight
{% else %} direct sunlight
{% endif %}
device_class: illuminance
is a template sensor, I have for all my motion sensors (20). I am still wondering if there would be no way to create an anchor from the section I indicated above to inject into all my other sensors.
a bit like this:
driveway_buiten_sensor_light_level_raw:
value_template: >
{{state_attr('sensor.driveway_buiten_sensor_light_level','lightlevel')}}
friendly_name_template: >
Driveway buiten:
{% set light_level = state_attr('sensor.driveway_buiten_sensor_light_level','lightlevel')|int %}
<<: &name_template
{% if light_level < 1 %} dark
{% elif light_level < 3000 %} bright moonlight
{% elif light_level < 10000 %} night light
{% elif light_level < 17000 %} dimmed light
{% elif light_level < 22000 %} 'cosy' living room
{% elif light_level < 25500 %} 'normal' non-task light
{% elif light_level < 28500 %} working / reading
{% elif light_level < 33000 %} inside daylight
{% elif light_level < 40000 %} maximum to avoid glare
{% elif light_level < 51000 %} clear daylight
{% else %} direct sunlight
{% endif %}
device_class: illuminance
porch_buiten_sensor_light_level_raw:
value_template: >
{{state_attr('sensor.porch_buiten_sensor_light_level','lightlevel')}}
friendly_name_template: >
Porch buiten:
{% set light_level = state_attr('sensor.porch_buiten_sensor_light_level','lightlevel')|int %}
<<: *name_template
# {% if light_level < 1 %} dark
# {% elif light_level < 3000 %} bright moonlight
# {% elif light_level < 10000 %} night light
# {% elif light_level < 17000 %} dimmed light
# {% elif light_level < 22000 %} 'cosy' living room
# {% elif light_level < 25500 %} 'normal' non-task light
# {% elif light_level < 28500 %} working / reading
# {% elif light_level < 33000 %} inside daylight
# {% elif light_level < 40000 %} maximum to avoid glare
# {% elif light_level < 51000 %} clear daylight
# {% else %} direct sunlight
# {% endif %}
# device_class: illuminance
but, since this is declared in the template itself is shows as:
…I don’t think that can be done as it’s in the middle of the a template 
. If I get chance later today I’ll have a play with it and see if I can get it to work but I’m not hopeful.
Thanks if you would !
Happy to report all other suggestions and tips worked right away.
Cut yet another 40 lines or so and over 10 additional fake entities. From my customization package alone…
Very nice indeed. 
@Mariusthvdb - Had a bit of a look at this this evening and I’m fairly confident this last one isn’t possible. The anchors duplicate either a value or a set of keys and values, and I can’t see any way to anchor only part of a value
cool. thanks for your time and effort Marc, much appreciated.
If only HA would introduce global templates per entity, we could use in all configuration variables. That would be a major improvement.
until then, I guess I’ll have to learn and live with it
maybe I can still try that as a WTH…
Indeed, I have voted for your wth although I don’t understand the mechanics of how the templates work in homeassistant so there’s potential that it’s not possible to transfer part of a template from one key to another. Of course if they can do it, the possibilities are endless 
not sure either
though if custom-ui can use things like this:
templates:
icon_color: >
if (state == 'on') return 'green';
return 'grey';
icon: >
if (state == 'on') return 'mdi:television';
return 'mdi:television-off';
friendly_name: >
return 'Television is ' + state;
why shoudn’t core HA be able to use that? (of course this is based on a known state, and not an extra set state, I realize that, but the thought would be identical: identify a global state, and use that throughout the other templates for the same entity)
Yeah absolutely, I’m thinking along the lines of scripts - you can pass a variable to the script…
script:
script_one:
sequence:
- service: script.script_two
data:
this_variable: sensor.something
script_two:
sequence:
- service: homeassistant.turn_on
data_template:
entity_id: "{{ this_variable }}"
But currently this isn’t possible
script_only:
set_variable:
this_variable: sensor.something
sequence:
- service: homeassistant.turn_on
data_template:
entity_id: "{{ this_variable }}"
So I would have thought it was possible, but as I said I don’t understand the mechanics of how the variable gets passed to the script
Reading the release notes for 0.115 you can now add variables like this in automations and scripts, maybe worth finding the dev that added it and seeing if he/she can transpose it across to template sensors as this would solve your problem
yes, there’s a lot of movement on the subject. would be truly nice if we could use global variables in the near future.
for now this new variable does seem to interfere with the CC variables though, so might need some inspection before upgrading. I asked about that here before it was merged, but at that time was told it wouldn’t interfere…
have one more:
- alias: Send notification when alarm is Disarmed
trigger:
platform: state
entity_id: alarm_control_panel.ha_rpi4_alarm
to: disarmed
condition: ¬ify_alarm
condition: state
entity_id: input_boolean.notify_alarm
state: 'on'
action:
service: notify.notify
data:
title: >
ALARM: {{trigger.to_state.state))
message: >
{{as_timestamp(now())|timestamp_custom('%X')}}: The alarm is {{trigger.to_state.state}}
- alias: Send notification when alarm is in arming status
trigger:
platform: state
entity_id: alarm_control_panel.ha_rpi4_alarm
to: arming
condition: *notify_alarm
# condition: state
# entity_id: input_boolean.notify_alarm
# state: 'on'
# action:
# service: notify.notify
# data:
# title: >
# ALARM: {{trigger.to_state.state}}
# message: >
# {{as_timestamp(now())|timestamp_custom('%X')}}: The alarm is {{trigger.to_state.state}}
seems not tow work. Is that because I want to to span both condition and action block (which would exactly be the charm of it here…)
Have one of these for all alarm modes…
anchors defined like that only work on 1 field.
this passes:
- alias: Send notification when alarm is Disarmed
trigger:
platform: state
entity_id: alarm_control_panel.ha_rpi4_alarm
to: disarmed
condition: ¬ify_condition
condition: state
entity_id: input_boolean.notify_alarm
state: 'on'
action: ¬ify_action
service: notify.notify
data:
title: >
ALARM: {{trigger.to_state.state}}
message: >
{{as_timestamp(now())|timestamp_custom('%X')}}: The alarm is {{trigger.to_state.state}}
- alias: Send notification when alarm is in arming status
trigger:
platform: state
entity_id: alarm_control_panel.ha_rpi4_alarm
to: arming
condition: *notify_condition
action: *notify_action
is there another way to do it, so it works for the whole section from condition: to the end?
nope, not possible with automations.
why do you even have 2 automations there? just have 1 with 2 triggers.
ok thanks, will leave it like this then, thanks for confirming