You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Recently I added the concept of trigger groups (home-assistant/core#117698), to allow blueprint writers to have a way to use one or more trigger selectors with their blueprints, so that we have a way to merge nested lists of triggers.
This is useful but it does have a limitation, that when an automation is triggered, the automation cannot determine from which group of triggers a trigger initiated from.
So if the blueprint has two selectors, call them "A triggers" and "B triggers", users can add multiple triggers to both sets, e,g.
blueprint:
input:
a_triggers:
name: "Triggers to do something"
default: []
selector:
trigger:
b_triggers:
name: "Triggers to do something else"
default: []
selector:
trigger:
triggers:
- triggers: !input a_triggers
- triggers: !input b_triggers
action:
...
But when a particular trigger fires, there's no way to identify if that trigger was from the A group or the B group.
I would like to have a way to identify this, and I had the idea that triggers could also have an id added to it, e.g.:
This could either do one of two things (I haven't decided):
All the flattened triggers would automatically inherit the trigger id from the group. So any triggers added to a_triggers would have a trigger.id of "a_trigger_group". Any trigger_id manually added to the individual triggers by the end user would be thrown away.
or
All the flattened triggers would get a new property trigger.group_id equal to "a_trigger_group". Any trigger_id manually added to individual triggers would continue to exist, so a trigger could have both an trigger.id and a trigger.group_id.
Option 2 seems slightly more flexible, but also maybe needlessly overcomplicated. In theory both could be used if a blueprint also had an action selector or condition selector, and end-user also added a manual trigger id to a trigger, and checked for the existence of that id in a manual action or condition.
Is either one of these options preferred or would be accepted?
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Recently I added the concept of trigger groups (home-assistant/core#117698), to allow blueprint writers to have a way to use one or more trigger selectors with their blueprints, so that we have a way to merge nested lists of triggers.
This is useful but it does have a limitation, that when an automation is triggered, the automation cannot determine from which group of triggers a trigger initiated from.
So if the blueprint has two selectors, call them "A triggers" and "B triggers", users can add multiple triggers to both sets, e,g.
But when a particular trigger fires, there's no way to identify if that trigger was from the A group or the B group.
I would like to have a way to identify this, and I had the idea that
triggers
could also have an id added to it, e.g.:This could either do one of two things (I haven't decided):
trigger.id
of "a_trigger_group". Any trigger_id manually added to the individual triggers by the end user would be thrown away.or
trigger.group_id
equal to "a_trigger_group". Any trigger_id manually added to individual triggers would continue to exist, so a trigger could have both antrigger.id
and atrigger.group_id
.Option 2 seems slightly more flexible, but also maybe needlessly overcomplicated. In theory both could be used if a blueprint also had an action selector or condition selector, and end-user also added a manual trigger id to a trigger, and checked for the existence of that id in a manual action or condition.
Is either one of these options preferred or would be accepted?
Beta Was this translation helpful? Give feedback.
All reactions