Can a template variable be used in an action alias

Configuration
,
1

Is it allowed to include a variable in the definition of an alias in a choose or if section of an automation action e.g.

In the choose alias below I have added the trigger.id to the string defining the alias i.e. - alias: "Light on request from: {{trigger.id}}"

With this in my automation I do not get any errors or warnings in the logs but have noticed that since adding it I now get “Not all shown logbook entries might be related to this automation.” in the Trace Timeline for this automation. I used to get the full trace timeline details.

action:
  - choose:
      - alias: "Room becomes occupied"
        conditions:
          - "{{ trigger.id == 'occupied' }}"
          - "{{ current_luminance <= light_on_luminance }}"
          - "{{ is_state(nighttime_killswitch, 'off') }}"
          - "{{ is_state(occupancy_killswitch, 'off') }}"
        sequence:
          - alias: "Turn on light"
            service: light.turn_on
            entity_id: !input light_entity_id
            data: !input light_on_attributes

      - alias: "Room becomes unoccupied"
        conditions:
          - "{{ trigger.id == 'unoccupied' }}"
          - "{{ is_state(occupancy_killswitch, 'off') }}"
        sequence:
          - alias: "Turn off light"
            service: light.turn_off
            entity_id: !input light_entity_id
            data: !input light_off_attributes

      - alias: "Light on request from: {{trigger.id}}"
        conditions:
        - condition: or
          conditions:
            - "{{ trigger.id.endswith('button_press') and button_press == 'turn_on' }}"
            - "{{ trigger.id == 'homekit_turn_on' }}"
            - "{{ trigger.id == 'alexa_turn_on' }}"
            - "{{ trigger.id == 'all_lights_on' }}"
        sequence:
          - alias: "Enable Occupancy killswitch"
            service: input_boolean.turn_on
            entity_id: !input occupancy_killswitch
          - alias: "Turn on light(s)"
            service: light.turn_on
            entity_id: !input light_entity_id
            data: !input light_on_attributes

    default: []
2

Based on the experiment I performed, the Jinja2 interpreter doesn’t process the alias option so any template you put there is retained verbatim.

You can prove it to yourself by examining your automation’s trace. Check the value of alias and you should see that the template you put there still looks like a template. For example, in the following trace the template is shown unchanged and wasn’t replaced by the actual value of trigger.id.

Screenshot_20230123-182332~2
Screenshot_20230123-182332~2837×880 71.9 KB

3

Thanks @123
What about your Trace Timeline? Does that still show the trace or has that stopped working for this example?

4

The automation’s Trace Timeline completed nominally.

If you’re concerned about the “Not all shown logbook etc” message, I just checked a random bunch of my automations (all work perfectly) and their traces all have that message.

I even have one that stopped at its initial condition so there’s effectively no Trace Timeline produced and even that one has the message. I just treat it as boilerplate disclaimer.

Screenshot_20230123-191032~2
Screenshot_20230123-191032~21470×860 46.6 KB

5

Yes. Thanks. I’ve come to the same conclusion that the Trace Timeline not showing on some of my automations does not seem to have any correlation to the operation of the automation itself.

Seems to be a half implemented feature that can be useful when it works, but should not be relied upon :frowning:

6

Sorry, not following you. What exactly is only ‘half-implemented’ and unreliable?

7

I don’t understand why, for some traces I get this:

Screenshot 2023-01-24 at 21.56.09
Screenshot 2023-01-24 at 21.56.091119×429 51.6 KB

and, for others, I get this:

Screenshot 2023-01-24 at 21.57.49
Screenshot 2023-01-24 at 21.57.491235×595 51.2 KB

I think most users would expect the information shown in the first diagram for all automations. That’s what I mean about half implemented.
There may be good technical reasons why it does what it does, but a feature is only half a feature when it sets an expectation for the user and then fails to deliver it.

I do not mean offence. What we have in HA today is significantly better than what we had when I started using it, but to me, the Trace Timeline does not meet the expectations it sets i.e. it’s only half implemented.

Full disclosure: I am (amongst other things) a Product Manager and care about delivering features that meet the users expectations :slight_smile:

8

Download the trace file for the example in the second screenshot and post it as an Issue in Home Assistant’s GitHub Core repository. Ask why there’s no trace timeline shown despite the fact the diagram appears to indicate it executed actions in the automation.

9

Good idea.
Issue created here: Trace timeline shows no information · Issue #15186 · home-assistant/frontend · GitHub

Let’s see what they have to say :grimacing: