Home Assistant: Tres años después

Artículo original ↗ Discusión en Hacker News ↗

Home Assistant es elogiado como una forma potente de unificar dispositivos de hogar inteligente y mantener el control local, pero muchos usuarios describen un intercambio entre flexibilidad y una sobrecarga de mantenimiento continua. Los comentaristas destacan puntos de dolor recurrentes como el almacenamiento frágil en Raspberry Pi, los cambios que rompen cosas con actualizaciones frecuentes, el hardware Zigbee/Z-Wave poco fiable y los riesgos de los dispositivos dependientes de la nube. Hay un amplio apoyo a estándares como Matter y a configuraciones local-first, pero persiste el escepticismo sobre la fiabilidad a largo plazo, el despliegue profesional y cuánto complejidad merece la pena introducir en funciones básicas del hogar como la calefacción, la iluminación y la seguridad.

Control remoto y conmutación de energía tipo watchdog

  • Para reiniciar dispositivos de forma remota en otra ubicación, muchos ven los enchufes inteligentes basados en la nube como aceptables, ya que una caída de Internet bloquea cualquier solución.
  • Alternativas sugeridas: TP-Link Kasa (protocolo TCP local simple), enchufes Sonoff/Shelly flasheados con ESPHome/Tasmota, enchufes controlados por SMS/GSM y cables de alimentación dedicados de “watchdog” que ciclan ante fallo de ping (aunque algunos los consideran demasiado caros).

Patrones de adopción y opciones de despliegue

  • Varios migraron desde otras plataformas (OpenHAB, Homebridge, X10, apps de fabricantes) y encontraron que HA es mucho más capaz, especialmente para configuraciones complejas o desconectadas de la red.
  • Despliegues comunes: contenedores Docker, VMs y cajas dedicadas con HAOS; algunos prefieren ZFS, Proxmox o almacenamiento respaldado por NFS por su resiliencia.
  • Complementos como HACS aportan extensibilidad tipo HAOS en Docker, aunque la configuración puede ser engorrosa.

Automatizaciones vs paneles y filosofía de UX

  • Existe un sentimiento fuerte de que, si usas con regularidad un panel para controlar dispositivos, el diseño de automatizaciones es deficiente; interruptores, sensores y presencia deberían manejar la mayor parte del comportamiento.
  • Otros valoran los paneles para supervisión (p. ej., energía, estado de toda la casa) y controles masivos (p. ej., “apagar todas las luces”).
  • Algunos ejecutan automatizaciones muy “ligeras”; otros automatizan agresivamente iluminación, HVAC y “modos” (casa/ausente/invitado).

Interruptores, escenas y estado mecánico frente a digital

  • El deseo de interruptores físicos que reflejen siempre el estado real de las luces lleva a hablar de interruptores sin estado/momentáneos, reguladores capacitivos/LED y configuraciones basadas en botones con relés.
  • Muchos sostienen que la luz de la habitación es el indicador relevante; la simetría de la posición mecánica es, en gran medida, una cuestión estética.

Protocolos: Zigbee, Z-Wave, Matter y otros

  • Zigbee y Z-Wave se usan ampliamente; Z-Wave se percibe como más caro y más exigente en energía, pero fiable y con menos tipos de dispositivos.
  • Algunos prefieren Zigbee2MQTT frente al ZHA de HA por su mayor compatibilidad de dispositivos y flexibilidad, a costa de una complejidad extra.
  • Las opiniones sobre Matter están divididas: optimismo por el control local y el soporte multiecosistema frente a la frustración de que los dispositivos Matter actuales suelen exponer menos funciones (p. ej., faltan métricas de energía) y se sienten inmaduros.

Fiabilidad, actualizaciones y almacenamiento

  • Las experiencias van desde “sólido como una roca durante años” hasta “cada actualización corre el riesgo de romper algo”, especialmente en configuraciones pesadas en YAML o más antiguas.
  • Las tarjetas SD en Raspberry Pis se consideran en general poco fiables para almacenamiento a largo plazo de HA; las recomendaciones incluyen SSD, arranque por USB, NAS o hipervisores con instantáneas y copias de seguridad.
  • Algunos usuarios actualizan mensualmente y siguen las notas de lanzamiento; otros retrasan las actualizaciones y aceptan dolorosas puestas al día de varias versiones.

Instaladores profesionales y viabilidad a largo plazo

  • Varios comentaristas ven una brecha: quienes tienen sistemas heredados o complejos quieren integración profesional con HA, pero escasea un ecosistema de servicios.
  • Motivos citados: cambios rápidos, actualizaciones que rompen cosas, integraciones de terceros fuera del control del instalador, acoplamiento estrecho entre backend y frontend y una gran carga de soporte.
  • Las sugerencias incluyen una vía de versión LTS/estable y una separación más clara entre “plataforma” y UI personalizada, aunque esto requeriría un esfuerzo considerable.

Nube frente a enfoque local primero

  • En el hilo hay una fuerte preferencia por el control local para evitar bloqueo de proveedor, cortes, prohibiciones en los Términos de servicio y el cierre de productos.
  • Algunos siguen pagando por la nube de HA para acceder fácilmente de forma remota, o dependen de servicios de voz en la nube, citando falta de tiempo y mejor precisión que las opciones en el dispositivo.
  • Experiencias pasadas con proveedores que inutilizaron o degradaron productos empujan a muchos hacia hardware abierto y controlable localmente (a menudo mediante Zigbee + HA).

Seguridad, watchdogs y modos de fallo

  • Preocupa que las automatizaciones controlen estados “absolutos” como consignas de calefacción o carga de batería sin salvaguardas independientes.
  • Patrón recomendado: dejar que HA elija modos o horarios, pero mantener la lógica independiente del termostato/seguridad en el dispositivo.
  • Las notificaciones por pérdida de contacto, baja temperatura o fallo del dispositivo se consideran esenciales para sistemas críticos.

UI, paneles y curva de aprendizaje

  • El panel de Energía de HA recibe elogios por estar pulido; la creación general de paneles se considera potente pero intimidante y muy laboriosa.
  • Las peticiones de mejores valores predeterminados, asistentes de configuración, interfaces basadas en planos e incluso mapeo de “gemelo digital” con LiDAR reflejan el deseo de una configuración menos “ladrillo por ladrillo”.