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
Automations are the heart of a smart home. They're what make a home behave intelligently rather than just respond to manual commands. But authoring automations requires real investment: learning the editor, understanding triggers and conditions, knowing which entities and services to use and how to combine them. We work tirelessly to reduce that amount of time through projects like #2, but we can't bring it back to zero if we require users to keep doing the manual work. For some users, this is not a problem at all. They are willing to put in the time, and find the tinkering and tweaking rewarding. But this is not for everyone, and it shouldn't have to be.
This is the gap AI can close. An AI assistant that knows your home, which devices you have, how they're organised, what services they expose, can translate a plain description of what you want into a working automation. The user describes the outcome; the assistant handles the rest. No learning curve, no YAML, no trial and error. This makes automating a smart home significantly more approachable.
In #44 we established the "assistant" surface and context-passing architecture, meaning we gave users a persistent "assistant" that knew where in Home Assistant they were and what they were doing. This project now gives it the ability to act: creating and editing automations on the maintainer's behalf, directly within HA, grounded in the home's actual configuration, delivering on that approachability promise.
Community signals
The community-built ha-mcp integration has (at the time of writing) 2.4k GitHub stars and is being featured in posts like this Reddit thread and covered by outlets like The Verge — almost entirely on the strength of automation authoring use cases.
TODO: expand with other signals.
Scope & Boundaries
In scope
A tool layer with typed tools for automation management: list, read, create, update, enable/disable, and delete automations
Dashboard, script, or scene authoring (these will come in separate projects)
Bulk automation import or migration
Non-administrator access to authoring tools
Real-time conflict detection if a user edits an automation simultaneously in the UI
Foreseen solution
Introduce a tool layer: a set of typed, named automation tools that wrap existing HA WebSocket commands and REST endpoints.
The interaction pattern for destructive or generative actions: the assistant proposes the automation config with a preview, the maintainer confirms before anything is saved. Read operations (listing, inspecting) require no confirmation.
Tool inputs should be constrained enough that the AI can produce valid configurations without deep HA knowledge, leaning on HA's existing automation validation logic to catch errors before commit.
Risks & open questions
Automation format: The automation schema has and continues to evolve. Do we target only the current format, or build a migration-aware interface?
Confirmation UX: What does the preview/confirmation step look like?
Appetite
Large — 2 release cycles. The assistant surface and context-passing infrastructure come from #44. The underlying HA automation APIs are mature. The work here is tool API design, the permission model, validation strategy, and the confirmation UX pattern. Because this is the first time we're doing such a thing in Home Assistant, we should tread carefully and take our time.
Problem statement
Automations are the heart of a smart home. They're what make a home behave intelligently rather than just respond to manual commands. But authoring automations requires real investment: learning the editor, understanding triggers and conditions, knowing which entities and services to use and how to combine them. We work tirelessly to reduce that amount of time through projects like #2, but we can't bring it back to zero if we require users to keep doing the manual work. For some users, this is not a problem at all. They are willing to put in the time, and find the tinkering and tweaking rewarding. But this is not for everyone, and it shouldn't have to be.
This is the gap AI can close. An AI assistant that knows your home, which devices you have, how they're organised, what services they expose, can translate a plain description of what you want into a working automation. The user describes the outcome; the assistant handles the rest. No learning curve, no YAML, no trial and error. This makes automating a smart home significantly more approachable.
In #44 we established the "assistant" surface and context-passing architecture, meaning we gave users a persistent "assistant" that knew where in Home Assistant they were and what they were doing. This project now gives it the ability to act: creating and editing automations on the maintainer's behalf, directly within HA, grounded in the home's actual configuration, delivering on that approachability promise.
Community signals
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Introduce a tool layer: a set of typed, named automation tools that wrap existing HA WebSocket commands and REST endpoints.
The interaction pattern for destructive or generative actions: the assistant proposes the automation config with a preview, the maintainer confirms before anything is saved. Read operations (listing, inspecting) require no confirmation.
Tool inputs should be constrained enough that the AI can produce valid configurations without deep HA knowledge, leaning on HA's existing automation validation logic to catch errors before commit.
Risks & open questions
Appetite
Large — 2 release cycles. The assistant surface and context-passing infrastructure come from #44. The underlying HA automation APIs are mature. The work here is tool API design, the permission model, validation strategy, and the confirmation UX pattern. Because this is the first time we're doing such a thing in Home Assistant, we should tread carefully and take our time.
Execution issues
No response
Decision log