Add trigger.id as option to automation.trigger

With the ability to have multiple triggers defined for an automation there should also be an option for the automation.trigger service to specify which one to trigger on.
Otherwise I don’t see a way to make use of any trigger id dependent branches of the automation.
If there is, please let me know …

If you’re looking to trigger automations using a service call, perhaps you should be using a script instead of an automation?

Of course, I wrote the automation for its triggers.

However, I seem to have problems with some of them not responding so I looked into ways to debug and found the automation.trigger service (which has been useful in automations, too).

With the current implementation it is not really helpful for my purpose …

Understood. This behaviour is documented:

but agreed, it would be helpful to be able to force a trigger with a specific ID. You could fake it up with an additional trigger with the same id:

trigger:
  - platform: numeric_state
    entity_id: sensor.some_temp_sensor
    above: 100
    id: "too_hot"
  - platform: state
    entity_id: input_boolean.trigger_test
    to: "on"
    id: "too_hot"

Flip the helper on and the rest of the automation will run with that id.

I was just thinking about making a script a few days ago that would utilize calling an automation with an id in data. Now come to find out it’s not possible…

I suppose in the automation you could check if there is no trigger.id and run a certain task that way, but this would definitely be a useful feature.

2 Likes

Thanks a lot for the pointer - that page must have escaped my attention …

The trick to do this, is by firing an event :wink:

2 Likes

How do you do this with events?

Are you saying create an event that is of type “run automation” or something and then add trigger ID to the data somehow?

I’m pretty sure this is a recent addition to the documentation: you can do it via a the service call:

You can also trigger an automation manually. This can test the conditions as if the automation was triggered by an event. Navigate to Developer tools > Services. In the service selection drop-down, select Automation: Trigger , then Choose entity to select the automation you are testing. Toggle whether to skip the conditions, then Call service . If needed, additional trigger or other data can be added in the YAML view for testing. The trigger page has more information about data within the trigger.

1 Like

I’m actually trying to trigger automations from other automations.

I have scripts, but those take variables. I’m looking to call the “Control Kitchen Lights” automation from some other automation and tell it to turn on the Kitchen Lights as if a button was pressed.

There’s an example here: Automation Trigger - Home Assistant.

This is what

said and it looks like it would work. Looks like this in the yaml:

service: automation.trigger
target:
  entity_id: automation.bathroom_door_is_open
data:
  skip_condition: true

I imagine the skip condition is optional, in your case you may need the condition but the context of that is testing, so you would want that to trigger.

If you want the event one to trigger, you just service up a random named event and add an event trigger to the automation you would want to trigger.

Here is from some of my blueprints where I fire an event. (Notice it can also pass data!)

action:
- alias: Fire Last Action event
  event: rm02_last_action
  event_data:
    event: '{{ event }}'
    entity_id: '{{ entity_id }}'
    friendly_name: '{{ friendly_name }}'

So in that case the automation you would want to fire would have an event trigger looking for event ‘rm02_last_action’ and in the trigger data you should be able to grab that data that was passed. Don’t know though, haven’t tried that myself. I would try from the example
{{ trigger.event.data.friendly_name }}
but looking at the trace might tell you as well.

Because you can pass data with the event sensor, you don’t care about the trigger_id, you have a variable that you can pass to send any info you want and look for it on the receiving end. I think that’s what Frenck meant.

You just create a variable on the receiver automation loaded with a default value, and if the trigger comes from the event, it overloads that variable with your info. No event, it runs one way, event trigger, you feed it info to use.

1 Like

I don’t get it. The documentation states as you say:

If needed, additional trigger or other data can be added in the YAML view for testing.

So I’d expect I need to put something like:

action: automation.trigger
metadata: {}
data:
  skip_condition: false
  trigger:
      id: "trigger_on" # this is the key element to signal that the trigger_id "trigger_on" has been triggered for downstream conditions based on that id!
target:
  entity_id: automation.my_automation

But this gives me:

extra keys not allowed @ data['trigger']. Got None

Has anyone a working example?

It doesn’t work.

There has been an open issue since June, but no response from anyone whether it’s a documentation error or an actual bug.

1 Like