Add new Home Assistant package for Assistant

[gregology]

This issue is to track the addition of a new Home Assistant package for Assistant. We should define the package structure and the integration logic.

[gregology]

A few thoughts on how we could approach this. The package structure itself is pretty clear — we follow the same pattern as assistant-email and assistant-github — but the interesting question is what this integration actually does. HA's API surface is huge, so scoping matters a lot here.

Approach A: Service-only (like assistant-gemini)

No platforms, just callable services exposed through chat. Two services to start:

• query_state — read current state of HA entities (lights, sensors, locks, etc.). Fully reversible since it's read-only.
• control_device — turn things on/off, set brightness, adjust thermostats. Reversibility depends on the device domain.

Connection via HA REST API + long-lived access tokens.

Pros:

• Smallest possible scope, ships fast
• Chat-driven control feels natural for home automation ("turn off the living room lights")
• Follows the proven assistant-gemini pattern exactly

Cons:

• No automated monitoring — it only does things when you ask
• Doesn't use the handler pipeline at all

Complexity: Low

Approach B: Platform + Services

A notifications or events platform that monitors HA for notable events (door left open, motion detected at odd hours, device went offline) and runs them through the classify -> evaluate -> act pipeline. Plus the control services from Approach A.

Pros:

• Full use of the handler pipeline — automation rules can react to home events
• Way more useful day-to-day than pure chat control

Cons:

• Much bigger scope
• Requires deciding which HA events are worth monitoring (there are thousands of possible state changes)
• Safety classification gets tricky — what's the reversibility tier of "send a notification to my phone"?

Complexity: High

Approach C: Read-only platform first

A status platform that periodically polls HA and surfaces anomalies (offline devices, unusual sensor readings, battery low on sensors). No control actions at all.

Pros:

• Safe by design — zero irreversible actions to worry about
• Useful on its own for home monitoring
• Easy to layer control services on top later

Cons:

• Limited without the ability to actually do anything about the problems it finds
• Polling frequency needs tuning to avoid hammering HA

Complexity: Medium

Recommendation

I'd go with Approach A to start. It's the smallest useful thing we can ship, and it sidesteps the hard scoping questions around which HA events to monitor. The query_state service is trivially safe (read-only), and for control_device we can map HA domains to reversibility tiers pretty naturally — light.* and climate.* are reversible, lock.unlock is irreversible, etc.

Once that's working we can layer on a platform for event monitoring as a follow-up.

A couple things worth deciding up front though:

1. Entity filtering — should users configure which HA entities are visible to Assistant, or do we expose everything and let the LLM figure it out? I lean toward explicit config.
2. Auth — HA long-lived access tokens are the simplest option. Any reason to support OAuth or the WebSocket API from the start?

Developer metrics

Total duration: 2m 54s
Turns: 37
Tool calls: 34
Tokens: 106,954 input / 2,272 output

Stage	Model	Duration	Turns	Tool calls	Tokens (in/out)	Cache read	Cache creation
triage	claude-opus-4-6	2m 23s	36	33	60,142 / 1,455	44,070	16,068
comment_draft	claude-opus-4-6	0m 30s	1	1	46,812 / 817	29,293	17,516