Saltar a contenido

Análisis: qué install method en 2026 — aplicado al setup del usuario

El usuario corre HA OS sobre HA Yellow con Zigbee, BLE, WiFi y ESPHome custom. La deprecación oficial de Supervised reduce el universo a HAOS vs Container. Este análisis aplica la comparación general a la situación concreta y deja una recomendación condicional, no una decisión final — esa requiere ingerir más sources (patrones de hardening, postmortems de upgrades, IaC concreta).

Contexto

Esta es la primera página del wiki que opina sobre el setup del usuario. Hasta ahora todo era contexto institucional o comparativa neutral. La opinión acá es condicional — está armada para que la siguiente iteración de ingest la mejore o la contradiga. Cuando se ingieran los postmortems de upgrade y los sources de IaC/observabilidad, esta página se actualiza y posiblemente cambia de recomendación.

Contenido

Restricciones que vienen del usuario

  1. Frustración explícita: rupturas en upgrades, integraciones inmaduras. ⇒ La decisión debe maximizar control sobre el momento y la verificabilidad del update.
  2. Tracks declarados serios: HA hardeneado y custom from-scratch. ⇒ Quedarse en HAOS o moverse a Container no excluye el track custom; pueden coexistir.
  3. k8s descartado (intento fallido previo). ⇒ Container significa Docker/Podman sobre un host plano, no orquestación compleja.
  4. AI angle: dev tooling (Claude Code escribiendo YAML/IaC) y runtime reasoning. ⇒ Hace falta que el config viva en un git repo accesible a agentes. Eso favorece Container.
  5. Modular essentials vs experimental: el usuario quiere separar lo crítico de lo experimental en hardware/red distinta. ⇒ Importa qué install method facilita esa partición.

Aplicando la matriz al usuario

HAOS sobre HA Yellow (status quo): - ✅ Es lo que ya funciona. El Yellow está discontinuado pero sigue recibiendo updates de HAOS (validar con review de Neil Grogan cuando se ingiera). - ✅ Snapshot/restore desde UI: bajo time-to-recovery sin involucrar al host. - ⚠️ Affinity baja con IaC del host: el config de HA vive en /config del appliance, no en un repo del homelab. Workaround: bind mount + repo en otro lado. - ⚠️ Co-locar otros servicios del homelab: no es la fortaleza del Yellow (recursos limitados, además). - ⚠️ Para AI tooling: agentes pueden tocar el config vía API/MCP, pero el host no.

HA Container sobre otro hardware (mini-PC / NUC / VM): - ✅ Pin de versión explícito → control total sobre cuándo se aplica un upgrade. - ✅ Config vivo en un repo git → Claude Code / agentes operan directo sobre el repo, no contra una UI. - ✅ Co-existencia con Z2M, Mosquitto, Prometheus, Grafana, Loki en el mismo host vía compose. - ✅ Affinity alta con IaC (Compose + Ansible cubre el 100% del setup). - ⚠️ Add-ons: hay que correr cada uno como container separado. Add-ons "fáciles" (ESPHome dashboard, Studio Code Server) requieren más config manual. - ⚠️ Snapshot/restore: hay que armar el equivalente (snapshot del bind mount + DB dump si aplica). - ⚠️ Costo de migración inicial no trivial.

Recomendación condicional

Estructura propuesta (sujeta a validación en próximas iteraciones):

  1. Essentials (luces críticas, calefacción, seguridad, lo que romper duele): se quedan en HAOS sobre el HA Yellow. Es lo que ya funciona; no se toca hasta que haya razón concreta. Snapshot pre-upgrade obligatorio.
  2. Experimental (LLM automations, vision, energy monitoring, AI agents managing infra): nuevo nodo (mini-PC o VM) con HA Container + Z2M externo opcional + observabilidad full. Conectado al Yellow vía MQTT bridge si hace falta.
  3. Migración Zigbee: NO mover los Zigbee del Yellow al nodo experimental todavía. Esa decisión depende de ingerir Q9 (migration path + ZHA vs Z2M).

Justificación corta: minimiza el riesgo (no se toca lo que funciona) y maximiza el espacio de experimentación con AI/IaC/testing. Cumple la consigna "tratar como problema de software engineering" sin pagar el costo de migrar todo de una.

Lo que esta recomendación no está diciendo todavía

  • No dice "Container es mejor que HAOS" en abstracto.
  • No dice "abandoná el Yellow". Al contrario: el Yellow es la base estable.
  • No resuelve la pregunta de Zigbee migration ni la de IaC concreta — esas son iteraciones siguientes.

Relaciones

Citas / evidencia

Abierto / gaps

  • Validar con un source que el HA Yellow sigue recibiendo updates de HAOS post-discontinuación (gaps media: review de Neil Grogan).
  • Encontrar un ejemplo público de arquitectura HAOS + HA Container coexistiendo vía MQTT bridge u otro mecanismo. Si no existe documentado, escribir el patrón propio.
  • Cuantificar el "costo de migración inicial" del Container path con un walkthrough concreto.
  • ¿La arquitectura "2 HA instances" es realmente mejor que "1 HA + agents externos"? Cross-check cuando se ingiera la serie de Dan Malone (Q10).