Trigger ids are great for allowing me to consolidate automations. However there is a bit of limitation with these use cases:
Manually testing automations from UI while developing: you can’t supply the trigger id to fake a certain trigger and most of the time the actions will have a ‘choose’ based on trigger id and therefore nothing happens
Manually triggering an automation via service call: I had a use case where I want to trigger automation B from A but I couldn’t get the behaviour I wanted as automation B uses trigger ids.
Your FR can’t be fulfilled because the trigger object only exists when the automation is triggered by one of its triggers.
An automation’s Run command only executes the automation’s actions.
The (misleadingly named) automation.trigger command does the same thing (with an option to evaluate the automation’s conditions).
Neither of the two serves to trigger any of the automation’s triggers therefore no trigger object is produced.
To test the automation, you must trigger one of its triggers. If you can’t wait for an entity’s state to change, you can manually set its state to a new value using the Set State feature in Developer Tools > States.
Thanks for the insight. Is it possible to check for a null trigger somehow, and from that I could infer the execution came from another automation, this would help with use case 2
If you’re using automation.trigger to make one automation execute another another automation, that’s an anti-pattern (i.e. not a recommended design method). You should avoid doing that. There are cleaner ways of designing multiple automations that share common actions. For example, consider having both automations call a script.
This template reports true if the trigger variable doesn’t exist.