I have a motion sensor automation that uses different trigger-id’s to select which actions to run. trigger-id’s are “Motion” and “No motion”
Now I want to trigger the “Motion” actions from another automation. So I want to call automation.trigger, but I’m not able to set the trigger-id to “Motion” is such thing possible?
I was about to ask this question and found yours.
There’s another one on here: Add trigger.id as option to automation.trigger - #6 by bpuetz
I’m not sure how to do this either. I have lots of automations that I don’t want to duplicate, and I’d like to call them like functions in code; sometimes recursively.
Use scripts. And call them in the automation where you ahve the trigger that you want to use. The only difference between an automation and a script is that the automation has a trigger. So if you don’t need it to have a trigger and instead be triggered by another automation, there’s no need to keep it as automation.
In fact, scripts are like functions, so that does seem like what you want.
I can’t know what to do in the script though.
The problem with triggering a script is I have to know what that automation will do when it turns something on. That’s tight coupling.
For instance, if I want to turn on the kitchen lights, no big deal right?
But what if the TV is on? The kitchen lights automation has some special logic to not turn on the lights around the TV while it’s on.
I can’t script that without hard-coding the logic for “if it’s the kitchen, and the kitchen TV is on”.
That doesn’t belong in a script because it’s a one-off. If I do move it to a non-portable script, then I have indirection. Also, the script would be more than a simple “do this” script, it would have to have Trigger IDs as well, and I’ve been unsuccessful at adding Trigger IDs to scripts.
Given that a trigger id is part of a trigger, and scripts have no triggers, how exactly were you attempting to combine them?
Were you trying to pass the trigger id from an automation as a variable to a script?
BTW, an automation attempting to trigger another automation is an anti-pattern.
I don’t understand how in your example one automation being triggered by another automation would help.
So how would you want to do it? Anyway to do it, you need to have somewhere that logic. Do you expect the kitchen lights automation to be triggered by the tv automation? Why? How would that be better?
I don’t understand how a check “if tv is on” is worse than a check “if another automation was triggered by trigger X”. I must be missing something here.
Yes, exactly that. I was trying to say "this trigger has a Trigger ID, and in my script, I was trying to say “this trigger ID variable === X, then do Y”.
Yeah, I don’t wanna trigger automation from automations, but I’m trying to make a single script to handle the things I want to script.
Blueprints don’t have a UI; so they’re literally impossible to debug. I wasted hours over 3 nights and finally got it saving, but it had an error in the config, so I had to disable it. I’ve been unsuccessful. What I want is an Automation Template (Blueprint), but that won’t work. So instead, I wanna make a “god script” that can do all of the lower-half of my automation.
Exactly what you’re saying, it doesn’t make sense to trigger an automation from an automation.
It makes more sense to me to script out what you want and then call that script dynamically “passing in” the current trigger ID just like a function. If I can do that, it’d be exactly like calling an automation from another automation but using scripts.
What’s the reason to put everything in one script? In my experience, are useful when used for generic actions that can be triggered by unrelated things. For example I have a script that passes a voice announcement. And I have different surroundings for different announcements, all of the call that script, passing a variable with the messages to announce.
But otherwise it didn’t make sense to move actions out of automation into a script, it makes debugging more complicated, because you have traces in two places. If the script would handle different things, it’s going to be even more complicated to debug.
I figured it out last night. What @123 said got me thinking:
Were you trying to pass the trigger id from an automation as a variable to a script?
Before, I was trying to get the trigger context in my script, but it doesn’t get passed to it. What solved this for me was passing data: { trigger_id: "{{ trigger.id }}" } and then I have a bunch of template checks in my script:
{{ trigger_id == "Button: Turn on Lights" }}
Now I have the “god script”, and it calls out to other scripts. It’s just like having functions that call smaller functions. It lets me put the orchestration logic in a single place, so I’m not having to duplicate that in 100 places.
Last night, when I was fixing other scripts, I noticed so many errors. I copy-pasted something from one place to another and missed changing the motion sensor toggle, so when you turned on the basement lights, it’d disable the motion sensor in the bathroom. Weird crap like that which is extremely hard to debug.
This looks ridiculous now:
And my script looks like I’d expect:
Now that it’s centralized, the big downside occurs when trying to Trace a specific issue while my kids are running around triggering motion detectors.
In the picture, the motion sensor is triggering this script but it’s been deactivated for this room because I pressed a button.
were you successful in calling a specific triggerID section in an automation from another automation? I personally, see a lot of value in this. from your example above I was not completely sure how to make this happen - could you elaborate?
the proper solution is to move the section you want to call into a script. and call that script from the automation as well as when you want to trigger that specific section.
What i like about triggerIDs is it let’s me consolidate multiple automations (that relate to each other) into one single automation. ie: control 5 shades within one automation using trigger IDs. manage it in one spot. in your suggestion would each trigger ID call it’s own script? or is there a way to have one script and call an option within that script from the automation based on the trigger ID? seems to me it would be cumbersome to manage multiple scripts vs. having it all in one automation.
if you wanted to consolidate it all, you can still do so by having one script take multiple arguments. (see add field in the script ui).
you could then pass in the trigger id. something like this:
sequence:
- choose:
- conditions:
- condition: template
value_template: "{{ original_trigger_id == 'trigger1' }}"
sequence:
- service: homeassistant.turn_off
metadata: {}
data: {}
- conditions:
- condition: template
value_template: "{{ original_trigger_id == 'trigger2' }}"
sequence:
- service: homeassistant.turn_off
metadata: {}
data: {}
fields:
original_trigger_id:
selector:
text: null
name: original_trigger_id
thanks for that example. I did some quick tests and can see how that would be helpful to consolidate and call a portion of the script using an ID.
I appear to be in the minority here but I also see a value in the ability to call a section of an automation from an automation using the triggerID.
there are quite a large number of things in language design that “can be useful” but also can lead to confusion and bad practice… e.g. goto statements… always a challenging debate on where to draw that line.
totally agree with your point about language design. keeping it clean so it makes sense 6 months from now when debugging.
a follow up question on trigger IDs. it is possible to have a trigger ID run two or more conditions? in my simple example below I use the same trigger ID but I only get the first message “test one”. any way to have a trigger Id run multiple conditions?
alias: test
description: ""
trigger:
- platform: time
at: "14:59:00"
id: time
condition: []
action:
- choose:
- conditions:
- condition: trigger
id:
- time
sequence:
- service: notify.mobile_app_mikeiphone
metadata: {}
data:
message: test one
- conditions:
- condition: trigger
id:
- time
sequence:
- service: notify.mobile_app_mikeiphone
metadata: {}
data:
message: test two
mode: parallel
max: 10
a choose will only execute the first condition that evaluates to true.
so for your scenario, you are better served by multiple if statements if you want different conditions. or in your case if it’s the exact same condition then just stack the actions together in a single sequence
thanks, I will try the If statements.
This is what I eventually settled on to pass triggers to scripts. Not sure if it’s still helpful:
I setup a template field that took {{ trigger.id }} and passed it through. Then I could use it as a variable instead. Bad part is I had to do templates for conditions like if variable === "Trigger Name" rather than the native trigger control.