Stop making users choose between automations and scripts

[nielsrowinbik]

Problem statement

Home Assistant asks users to learn two building blocks that do almost the same thing. An automation is a set of triggers, conditions, and a sequence of actions. A script is a sequence of actions. The action sequence inside an automation is a script in everything but name, yet the two live in separate editors, separate YAML keys, separate entity domains, and separate mental models. New users hit the distinction early, when they follow community advice like "move that into a script and call it from your automation", and they have to understand why the same list of steps needs a different object.

Two capabilities keep the split alive. Scripts accept parameters when they are called, and scripts can return data to their caller. Automations support neither, so anyone who needs reuse, arguments, or a return value gets pushed out of the automation editor and into a second concept. Users who stay inside automations get a worse product: no way to pass values into a shared sequence, no way to get a result back, and a "Run actions" button that exists to paper over the missing ability to trigger an automation by hand. This serves OpenHomeFoundation/goals#7, since the cost of learning a redundant concept falls hardest on the least technical users.

Community signals

• No external signals gathered. This item originates from internal product thinking in the Automation and Intelligence area.

Scope & Boundaries

In scope

• Parameters for automations: a declared, typed input contract that a caller supplies when it triggers the automation.
• Response data from automations: an automation can return data to its caller, matching what scripts do today.
• Calling an automation from another automation's action sequence, covering the case that script.turn_on and script service calls cover today.
• Adding manual triggering of automations as a first-class trigger, replacing the "Run actions" affordance in the automation editor, allowing users to make an automation behave differently when a person runs it versus when a trigger fires.
• A migration path that moves existing scripts onto manually triggerable automations, including existing call sites.
• Retiring scripts as a user-facing concept once the migration path holds.

Not in scope

• Redesigning the automation editor beyond what parameters, manual triggering, and return values require.
• Changing the action sequence language itself.

Foreseen solution

Automations gain a manual trigger that declares the parameters it accepts, in the same shape script fields take today. Declaring inputs on the trigger rather than on the automation gives two things at once: the caller has a documented contract to fill in, and the sequence can inspect which trigger fired and branch on manual versus automatic execution. Automations also gain a way to return data to the caller, so a called automation can answer a question rather than only performing an effect. With both in place, an automation can be called from another automation's action sequence, and the "Run actions" button in the editor becomes a manual trigger the user can invoke, name, and reason about.

Scripts then become a subset of automations: an automation with a manual trigger and no automatic ones. Migration converts each existing script into such an automation, maps its fields onto the manual trigger's parameters, and rewrites call sites so that action sequences referencing script.foo reference the migrated automation instead. The script: key and the script domain stay readable for a deprecation window while the editor, documentation, and new-user path present a single concept.

Risks & open questions

• Scripts are entities, and users expose them to dashboards, voice assistants, and the REST API. What replaces script.foo as a callable, exposable entity, and what happens to existing dashboard cards and voice exposure?
• Automation entity IDs and script entity IDs live in different domains. A migration that renames every entity breaks user configurations, templates, and third-party tooling that references them.
• Custom integrations, add-ons, and HACS blueprints call scripts directly. How long does the compatibility window run, and who is on the hook for the ecosystem breakage?
• Recursion and re-entrancy: automations calling automations needs an answer for loops, mode interaction, and what a called automation's max_exceeded behaviour means.
• Does an automation with a manual trigger and no automatic triggers read as sensible to a new user, or does it need its own presentation in the UI to avoid looking like a broken automation?
• The problem is stated from internal reasoning. Community evidence that users are confused by the two concepts, or that they want scripts kept as a distinct thing, has not been gathered.
• Traces, debugging, and history for a called automation are shaped around a triggered automation. Nested calls need a trace model that a user can follow.

Appetite

No response

Execution issues

No response

Decision log

Date	Decision	Outcome

[BBE-FR]

Interresting subject. Difficult to really make up your mind when you are so use to both...

I have an open question that I did not get by reading the description:
If an automation can have manual and/or automatic "triggers", does also the "condition" apply to both ? Or they should only apply to the automatic triggers ?

There are pro and cons...

• On one hand thinking about scripts, trying to protect script actions through conditions today need to adapt the sequence of action and introduce building blocks and this is cumbersome, whereas a condition might be simpler and very effective.
• On the other hand if you imagine the manual trigger as a way to bypass the auto trigger and launch the action, it should also bypass the conditions... (or the condition to protect a manual trigger could be fundamentaly different to the one to apply to an auto trigger)

Maybe we could imagine different condition for automatic triggers and manual trigger, maybe it would be too complex...