Source: HA Blog "Building the AI-powered local smart home" (2025-09)¶
Tesis oficial del HA team sobre AI en HA. Confirma que HA tiene stack nativo de AI runtime: Assist + LLM agents, AI Task entity, MCP bidireccional (consume + serve), AI Suggestions. Todo opt-in, agnóstico de cloud vs local. Es la base para Q7 — el wiki ya no tiene que "armar" un LLM runtime; HA lo tiene.
Por qué entró al wiki¶
- Pregunta guía Q7 (LLM en runtime para automation reasoning) — el HA team la respondió oficialmente con AI Task + MCP serve mode.
- Confirmación institucional de que AI está en el roadmap oficial, no es un hack community.
- Validación de la Opción 1 del Q10: HA serve como MCP server → Claude Code MCP client es directo, sin intermediarios.
Páginas derivadas¶
- ../analysis/q7-llm-runtime-strategy-v1 — síntesis para el setup del usuario.
- ../entities/ai-task — entidad para el AI Task system de HA.
- Update ../entities/home-assistant con el AI stack documentado.
Take-aways accionables¶
1. AI Task entity = trigger LLM desde automations¶
- service: ai_task.generate_data
data:
entity_id: ai_task.default
task: "Cuenta cuántas personas hay en la imagen"
attachments:
- "camera.living_snapshot"
structure:
person_count: int
Output structured JSON, accesible vía template. Esto es Q7 implementado por HA oficial.
2. MCP serve mode¶
HA expone su API entities + automation capability como MCP server. Esto significa:
- Tu agente externo (Claude Code en mini-PC) consume HA vía MCP standard.
- El agente del Q10 strategy no necesita inventar el protocolo — HA ya habla MCP.
- Los 82 tools del ha-mcp server (citados en Dan Malone) son la implementación community.
3. Voice/Assist con LLM¶
Out of scope per CLAUDE.md (voice assistants locales out). PERO el patrón de "routing simple → deterministic, complex → LLM" se puede aplicar a automations en runtime:
- Trigger simple (door opens at 6pm) → automation YAML clásica.
- Trigger ambiguo (someone is at the door, maybe a delivery?) → AI Task evalúa contexto y decide.
4. Cloud vs local¶
Posición oficial: agnóstico. Para el usuario: - Local Ollama si querés full privacy + tenés GPU dedicada (>= 8GB VRAM). - Anthropic/OpenAI/Google cloud si la calidad importa más que la privacidad estricta. - OpenRouter como middle ground (unified API, 400+ models).
Citas¶
-
"if users don't want AI in their homes, that's their choice"
-
"now it's hard to go wrong" (sobre model choice)
- TTS streaming: 13× faster cloud, 9.5× faster local.
Implicancia operativa para el setup¶
El usuario tiene 3 lugares donde AI corre:
| Capa | Where | Modelo |
|---|---|---|
| AI ops (Q10) | Mini-PC (Claude Code + cron) | Anthropic cloud o Ollama |
| AI automation runtime (Q7) | HA Yellow + HA Container (AI Task) | Configurable por user (opt-in) |
| AI dev tooling (Beguelin) | Local laptop (Claude Code interactive) | Anthropic cloud típicamente |
Los tres pueden coexistir. No hay conflicto.
Abierto / gaps¶
- ¿AI Task se puede correr sólo cuando essentials NO es afectado? (e.g. solo en el twin). Verificar.
- Latencia real de AI Task con local Ollama vs cloud Anthropic — afecta usability en automations time-sensitive.
- ¿El HA Matter server tiene relación con esto? (mencionado en otro source pero no integrado).
- Cómo combinan AI Suggestions con el patrón multi-agent review de Dan Malone — ambos auditarían YAML, ¿overlap?