Add name or friendly_name to the trigger variable

[jca001]

Describe the feature

With the release of HA 2026.10 the trigger.id is no generated unless you edit the trigger in YAML and add or change it.
I would like to be able to add a name or friendly_name to the trigger variable like use to be done for ID.

Use cases

I have several automations that have a couple if triggers to indicate a door is open or close and send a message, email, text, etc. I use trigger.id in the message to indicate the door has been Opened or Closed, the value of {{ trigger.id }}. This only requires 1 simple message instead of 2, or logic in the message to get the state of the sensor.

When writing an automation that has many triggers, say several motion sensors around the house and I need to make sure all triggers are working, I have a different ID for each and can use {{ trigger.id }} in a message to see which one was triggered using a single message.

The trigger.id is now a generated name (generated-XXXXX) which does not really tell me which trigger caused the automation to run. You can use trigger.idx, but then you have to remember the order of the triggers to know which trigger caused the automation to run.

Current workarounds

I have to select Edit in YAML to add or change trigger.id. This means getting the YAML syntax correct, which is fairly simple.

Anything else?

There is another enhancement request #4602 to add trigger.id to the trigger display in the GUI Editor. There is a comment there about the new way trigger.id is done, generated or editing in YAML to use your own. I added a comment there about adding trigger.name or trigger.friendly_name that could be used. So both could be implemented at the same time hopefully.

[TheFes]

For entity based triggers, the name and all the entity attributes are already available as trigger variables.
The name will be trigger.to_state.name. The friendly name attribute will be trigger.to_state.attributes.friendly_name

See: https://www.home-assistant.io/docs/automation/templating#state

[jca001]

@TheFes
I am aware of that, but by having trigger.name that I can put what ever I want to identify the trigger makes it more flexible. The example you provided is for a state change which could be open/close, on/off, etc. The other trigger.platform provide the same or different information and you then have to know which platform the trigger is for to reference the correct field. With trigger.name I can use a single message to state which trigger caused the automation to run.

The example for a door Open/Close was just a simple example. I use it a lot when writing a new automation and/or debugging an automation later by having a log message as the first action that shows {{ trigger.id }} which now is not very helpful, but {{ trigger.name }} would allow me to define what will be logged no matter what the trigger.platform is. This is real useful when the automation runs maybe at unwanted times or in the middle of the night, like one of many outside motion sensors that causes outside lights to be turned on. I can look at Notifications the next day to see what happened.

I know I can look at TRACE for the automation, but by having the information in Notifications allows better understanding of the time line of event and maybe how other automations and/or scripts running at or near the same time may have affected which trigger caused the automation to run.

I would prefer to have trigger.name vs trigger.friendly_name, I just suggested it could be either.

[jca001]

@TheFes
I just looked at the trigger documentation and noticed the section ALL,

Triggers from all platforms will include the following properties.

Template variable Data
trigger.platform Trigger object type.
trigger.alias Alias of the trigger.
trigger.id The id of the trigger.
trigger.idx Index of the trigger. (The first trigger idx is 0.)

So maybe trigger.name is not really needed if "alias" could be edited like "id" use to.

"id" is used by "choose" and "wait_for_trigger" and maybe something else I am not aware of. Is "alias" used by anything?

[jca001]

@TheFes
I just tested editing a trigger in YAML and adding alias: Button 1, and it changed "1_single" action for button 1 of a Zigbee Remote in the trigger in the GUI. So it would appear "alias" is used at least in one place. Therefore I would still like to see trigger.name added and allowed to be edited like trigger.id use to instead of having to edit YAML for the trigger.

If this enhancement is implemented, then others may make use of it.

[jca001]

@TheFes
Doing a little more investigating I found out that clicking the 3 dots on the trigger in the GUI opens menus and Rename, which I have never had a reason to use, adds alias and changes the trigger display. So that could be used as a work around, but you loose what the original trigger was unless you click on the trigger. I would still like to see trigger.name implemented because others may be using trigger.alias in other ways.