Problem statement
For each trigger the user defines, we allow them to set a trigger ID. This setting is hidden in the UI by the default, but can be shown from the trigger's overflow menu:
Next, the user is presented with a blank text input, allowing them to set whatever they want as the ID. In conditions and actions, they can then choose the "triggered by" condition and choose from the trigger IDs that they've set:
We feel that this is an unnecessarily complex flow to introduce more flexibility into automations. Given our goal of making Home Assistant more approachable, we feel addressing this represents a quick win.
Community signals
Scope & Boundaries
In scope
- Improving how users can reference triggers within the automation editor UI by:
- Auto-generating trigger IDs (keeping backward compatibility for those that have manually defined them)
- Showing the trigger itself in the UI picker for the "triggered by" condition, rather than the IDs.
Not in scope
- Defining trigger/condition/action input and output, paving the way for a node-based editor. We want to keep this small.
Foreseen solution
Manually setting trigger IDs should be something advanced, to be used in case you really want fine-grained control over what a trigger is referred to as. We will make this a YAML-only feature going forward. For anyone else, changing what happens based on what triggered the automation should just work.
This means:
- We will auto-generate a static trigger IDs behind the scenes when the user needs them (when a trigger is selected in a "triggered by" condition) and store it in the YAML configuration. These IDs will be non-numeric and identifiable as being generated (perhaps by using a
generated- prefix).
- We will display more of the actual trigger in the condition picker, rather than just the ID.
- To allow the user to easily link the actual trigger to the representation in the picker, we will label each with their indexes. These will not be used as the actual IDs and only serve to make reference easy.
- Generated IDs will be stored in the YAML in the same structure as before. The ability to manually edit IDs through the UI will be removed. We will consider setting manual trigger IDs a YAML-only feature going forward.
On current trigger ID / index behaviour
Currently, trigger IDs fall back to the trigger indexes behind the scenes. This is documented behaviour that is only available through YAML in the sense that in the UI picker within the "triggered by" condition, we will not surface triggers identified by their index. However, the following is possible:
triggers:
- trigger: time_pattern
id: "1"
seconds: "20"
- trigger: time_pattern
seconds: "10"
conditions:
- condition: trigger
id:
- "1"In the example above, both triggers are identified as "1": the first trigger manually, and the second automatically through the index fallback. This is problematic because the index IDs aren't stable (which is exactly the point of IDs).
We cannot remove this behaviour as it would represent a breaking change. Since the managed IDs will not be numeric, the problem becomes smaller. It will be up to the YAML-user's own discretion not to use strings that can be parsed as numbers.
On auto-clean-up and "dangling" IDs
When a trigger is removed through the UI, we will automatically clean up any references to that trigger in triggered_by conditions within the automation, but only if the trigger ID was automatically generated.
In case any trigger is removed through YAML, we will flag, in the UI, that there is a reference to a trigger that no longer exists, like so:
On duplicate IDs
By default, we will make sure that there are no collisions between generated trigger IDs. But, we will not prevent the user from intentionally setting the trigger ID on multiple triggers to the same value through YAML.
If the user chooses to assign IDs manually and use duplicates, checking one trigger in the triggered by condition through the UI will also check any other trigger with the same ID, regardless of their index. This will be intended intend behaviour. We will, however, flag these duplicates to the user and offer a migration to assign unique IDs to each trigger.
Risks & open questions
None at this time
Appetite
1 week. This is a relatively minor feature that we should not (have to) spend a lot of time on.
Execution issues
No response
Decision log
Problem statement
For each trigger the user defines, we allow them to set a trigger ID. This setting is hidden in the UI by the default, but can be shown from the trigger's overflow menu:
Next, the user is presented with a blank text input, allowing them to set whatever they want as the ID. In conditions and actions, they can then choose the "triggered by" condition and choose from the trigger IDs that they've set:
We feel that this is an unnecessarily complex flow to introduce more flexibility into automations. Given our goal of making Home Assistant more approachable, we feel addressing this represents a quick win.
Community signals
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Manually setting trigger IDs should be something advanced, to be used in case you really want fine-grained control over what a trigger is referred to as. We will make this a YAML-only feature going forward. For anyone else, changing what happens based on what triggered the automation should just work.
This means:
generated-prefix).On current trigger ID / index behaviour
Currently, trigger IDs fall back to the trigger indexes behind the scenes. This is documented behaviour that is only available through YAML in the sense that in the UI picker within the "triggered by" condition, we will not surface triggers identified by their index. However, the following is possible:
In the example above, both triggers are identified as "1": the first trigger manually, and the second automatically through the index fallback. This is problematic because the index IDs aren't stable (which is exactly the point of IDs).
We cannot remove this behaviour as it would represent a breaking change. Since the managed IDs will not be numeric, the problem becomes smaller. It will be up to the YAML-user's own discretion not to use strings that can be parsed as numbers.
On auto-clean-up and "dangling" IDs
When a trigger is removed through the UI, we will automatically clean up any references to that trigger in
triggered_byconditions within the automation, but only if the trigger ID was automatically generated.In case any trigger is removed through YAML, we will flag, in the UI, that there is a reference to a trigger that no longer exists, like so:
On duplicate IDs
By default, we will make sure that there are no collisions between generated trigger IDs. But, we will not prevent the user from intentionally setting the trigger ID on multiple triggers to the same value through YAML.
If the user chooses to assign IDs manually and use duplicates, checking one trigger in the triggered by condition through the UI will also check any other trigger with the same ID, regardless of their index. This will be intended intend behaviour. We will, however, flag these duplicates to the user and offer a migration to assign unique IDs to each trigger.
Risks & open questions
None at this time
Appetite
1 week. This is a relatively minor feature that we should not (have to) spend a lot of time on.
Execution issues
No response
Decision log