Problem statement
Home Assistant carries several generations of triggers side by side. Some old generic triggers, like sun and zone, were later replaced in practice by purpose-specific triggers and conditions (#2) that do the same job with clearer intent. Others, like the entity state and numeric state triggers, are still the workhorses of most automations but predate the target and behaviour patterns the rest of the platform has moved to. The result is a trigger list where two ways to express the same thing coexist, and where the generic triggers are missing capabilities that newer parts of the platform take for granted.
Someone learning automations meets redundant options with no signal about which to pick, copies an older pattern from a years-old forum post, and ends up on a trigger the project no longer steers people toward. Addressing this serves OpenHomeFoundation/goals#7, since a smaller, more consistent set of triggers is easier to learn, to document, and to build tooling on top of.
Community signals
- TODO: gather signals if this is going to a public thread. Niels supplied none; the item originates from internal product thinking about trigger consistency.
Scope & Boundaries
In scope
- Deprecate old generic triggers that a purpose-specific trigger or condition has functionally replaced, starting with
sun and zone, and identifying the full set prior to implementation.
- Provide automatic migration to the replacement trigger where the mapping is deterministic, for example
sun set to sunset with an optional offset moving to sun.sunset with the same offset.
- Modernise the remaining generic triggers, entity state and numeric state, so they support targets, behaviour, and the patterns newer triggers already use.
Not in scope
- Changes to conditions and actions beyond what trigger modernisation requires.
Foreseen solution
Deprecate the replaced triggers on a published timeline, and ship automatic migrations that rewrite affected automations to the modern equivalent wherever the old configuration maps cleanly onto a new one. The sun to sun.sunset rewrite with a preserved offset is the model: same behaviour, expressed through the purpose-specific trigger. Where a clean mapping does not exist, the migration surfaces the automation to the user with guidance rather than guessing.
For the generic triggers that stay, entity state and numeric state, bring them up to the target and behaviour conventions used elsewhere. Whether that means extending the existing triggers or introducing a functional replacement is an open decision, and the migration tooling built for the deprecations should be reusable for whichever path wins.
Risks & open questions
- No migration mechanism exists yet. Building one that can rewrite user automations safely is the core of the effort, and its difficulty is unvalidated.
- Extend in place versus replace, for entity state and numeric state, is unresolved.
- Deterministic mapping will not cover every deprecated trigger's configurations. The size of the manual-migration tail is unknown.
- Rewriting automations risks changing behaviour in edge cases. Users need to trust that a migration preserves intent, or they will resist upgrading.
- The full set of triggers that qualify for deprecation is not yet enumerated.
sun and zone are the confirmed starting points.
- Deprecation timelines interact with blueprints and community-shared automations that hardcode old triggers, which the project does not control.
Appetite
No response
Execution issues
No response
Decision log
Problem statement
Home Assistant carries several generations of triggers side by side. Some old generic triggers, like
sunandzone, were later replaced in practice by purpose-specific triggers and conditions (#2) that do the same job with clearer intent. Others, like the entity state and numeric state triggers, are still the workhorses of most automations but predate the target and behaviour patterns the rest of the platform has moved to. The result is a trigger list where two ways to express the same thing coexist, and where the generic triggers are missing capabilities that newer parts of the platform take for granted.Someone learning automations meets redundant options with no signal about which to pick, copies an older pattern from a years-old forum post, and ends up on a trigger the project no longer steers people toward. Addressing this serves OpenHomeFoundation/goals#7, since a smaller, more consistent set of triggers is easier to learn, to document, and to build tooling on top of.
Community signals
Scope & Boundaries
In scope
sunandzone, and identifying the full set prior to implementation.sunset tosunsetwith an optional offset moving tosun.sunsetwith the same offset.Not in scope
Foreseen solution
Deprecate the replaced triggers on a published timeline, and ship automatic migrations that rewrite affected automations to the modern equivalent wherever the old configuration maps cleanly onto a new one. The
suntosun.sunsetrewrite with a preserved offset is the model: same behaviour, expressed through the purpose-specific trigger. Where a clean mapping does not exist, the migration surfaces the automation to the user with guidance rather than guessing.For the generic triggers that stay, entity state and numeric state, bring them up to the target and behaviour conventions used elsewhere. Whether that means extending the existing triggers or introducing a functional replacement is an open decision, and the migration tooling built for the deprecations should be reusable for whichever path wins.
Risks & open questions
sunandzoneare the confirmed starting points.Appetite
No response
Execution issues
No response
Decision log