What's the difference between these yaml anchors

Configuration Frontend
8

@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 :man_shrugging:

9

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 :wink:
maybe I can still try that as a WTH…

1 Like
10

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 :slightly_smiling_face:

11

not sure either :wink:

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)

12

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 :slightly_smiling_face:

13

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 :slightly_smiling_face:

14

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…

1 Like
15

have one more:

  - alias: Send notification when alarm is Disarmed
    trigger:
      platform: state
      entity_id: alarm_control_panel.ha_rpi4_alarm
      to: disarmed
    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}}

  - 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… :wink:

16

anchors defined like that only work on 1 field.

17

this passes:

  - alias: Send notification when alarm is Disarmed
    trigger:
      platform: state
      entity_id: alarm_control_panel.ha_rpi4_alarm
      to: disarmed
    condition: &notify_condition
      condition: state
      entity_id: input_boolean.notify_alarm
      state: 'on'
    action: &notify_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?

18

nope, not possible with automations.

19

why do you even have 2 automations there? just have 1 with 2 triggers.

1 Like
20

ok thanks, will leave it like this then, thanks for confirming

21

I agree with @petro that this should be one automation, but you can use anchors to do this. Untested, but something like this (if not exactly)…

- alias: Send notification when alarm is Disarmed
  trigger:
    platform: state
    entity_id: alarm_control_panel.ha_rpi4_alarm
    to: disarmed
  <<: &notify_alarm 
    condition:
      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
  <<: *notify_alarm
2 Likes
22

If that works, TIL

23

Edited it slightly, but I’m pretty sure that will do it.

24

@Mariusthvdb - Just tested it in a yaml to json converter, and then just to be sure took the resulting json and put that in a json to yaml converter and I’m happy that the code in my post 3 up from this one is correct.

25

yes, thanks!
so this means that depending on the indentation you can simply anchor anything. great. cut yet again a few lines, and make the editing so much less error prone. Thanks Marc.

    <<: &notify_alarm
    condition:
      condition: state
      entity_id: input_boolean.notify_alarm
      state: 'on'
    action:
      service: notify.notify
      data:
        title: >
          {% set mode = trigger.to_state.state|replace('_',' ')|capitalize %}
          ALARM: {{mode}}
        message: >
          {% set mode = trigger.to_state.state|replace('_',' ')|capitalize %}
          {{as_timestamp(now())|timestamp_custom('%X')}}: The alarm is in '{{mode}}' mode

could we use the new variables here? for the mode?

like:

<<: &notify_alarm
condition:
  condition: state
  entity_id: input_boolean.notify_alarm
  state: 'on'
action:
  variables:
    mode: >
      trigger.to_state.state|replace('_',' ')|capitalize
     
  service: notify.notify
  data:
    title: >
      ALARM: {{variables.mode}}
    message: >
      {{as_timestamp(now())|timestamp_custom('%X')}}: The alarm is in '{{variables.mode}}' mode
1 Like
26

Not quite anything, but yeah indentation is the key to it.

As for the variables I don’t know, haven’t had chance to play with them yet.

27

ha, cool, will do some testing. reading this https://www.home-assistant.io/blog/2020/09/17/release-115/#variables I shouldn’t use the keyword variables in the final template I suppose, and just use the {{mode}}.

Which would be nice, and as it is now, only taking declaring the variable outside the 2, title and message.

edit

forget what I posted above, it had the wrong indentation below the anchor definition.

this works (config checker says ‘configuration valid’)

  - alias: Send notification when alarm is Disarmed
    trigger:
      platform: state
      entity_id: alarm_control_panel.ha_rpi4_alarm
      to: disarmed
    <<: &notify_alarm
      condition:
        condition: state
        entity_id: input_boolean.notify_alarm
        state: 'on'
      action:
        - variables:
            mode: >
              {{trigger.to_state.state|replace('_',' ')|capitalize}}
        - service: notify.notify
          data:
            title: >
              ALARM: {{mode}}
            message: >
              {{as_timestamp(now())|timestamp_custom('%X')}}: The alarm is in '{{mode}}' mode

apparently, setting a variable is seen as a separate action in the action block, hence needs a dash.
can confirm this works nicely!

1 Like