¿Cómo se hace Home Assistant más fiable?
La respuesta corta, por delante: tratando a Home Assistant como cerebro y no como médula espinal. La lógica de conmutación básica (pulso el botón, se enciende la luz) baja a los dispositivos o se tiende entre ellos: como automatización ESPHome en el microcontrolador, como Zigbee binding del pulsador a la lámpara, como asociación Z-Wave. Home Assistant se queda con todo lo que de verdad necesita cerebro: contexto, escenas, estadísticas, el panel. Y cuando el servidor está instalando una actualización, reiniciándose o sencillamente muerto, la luz de la ducha se enciende igual.
Esa es toda la tesis de este artículo. El resto es la justificación, dos recetas concretas y una tabla honesta de lo que da de sí cada camino.
Por qué no me suelto del tema: Home Assistant dejó hace tiempo de ser un juguete de fin de semana y se convirtió en infraestructura. Más de 654.000 instalaciones activas se reportan voluntariamente a las estadísticas del proyecto, y eso es solo la parte que aceptó el opt-in; la cifra real queda bastante por encima. Pero la infraestructura no se juzga por su panel. Se juzga por el interruptor de la luz. Un interruptor de 1975 tiene una disponibilidad que cualquier stack de software solo puede mirar con envidia. Quien instala tecnología inteligente compite contra ese listón, quiera o no.
El cuello de botella entre el pulsador y la lámpara
Repasa a cámara lenta lo que pasa en un montaje típico cuando alguien pulsa un botón Zigbee. El pulsador emite hacia el stick coordinador. El stick entrega la trama a Zigbee2MQTT. Zigbee2MQTT publica en el broker MQTT. Home Assistant está suscrito, una automatización se dispara, llama a light.turn_on, y la orden recorre el mismo camino de vuelta: broker, Zigbee2MQTT, stick, radio, lámpara.
Según cómo se cuente, son siete estaciones para «enciende la luz». Cada una es un proceso que tiene que estar corriendo. Cada una recibe actualizaciones. Varias comparten la misma tarjeta SD, el mismo disco, el mismo ordenador pequeño del pasillo. Si una estación cae, no pierdes una función de confort. Pierdes el interruptor. Cómo se siente un fallo así cuando llega en el peor momento lo conté en la historia de la cascada de Z2M un jueves por la tarde — desde entonces, cada automatización que monto pasa por la pregunta: ¿qué ocurre cuando esta cadena se rompe?
Que quede claro: nada de esto es un reproche a Home Assistant. El stack es asombrosamente estable y la mayoría de esas siete estaciones corren durante meses sin rechistar. Pero estabilidad no es lo mismo que independencia. Una actualización sigue siendo una actualización, un reinicio sigue siendo un reinicio, y ambos forman parte de operar con honestidad. La pregunta no es si el servidor se ausenta un momento. La pregunta es qué sigue funcionando en ese momento.
Cerebro y médula espinal
El cuerpo humano resolvió este problema con elegancia. Si tocas una placa de cocina caliente, el arco reflejo retira la mano antes de que la señal llegue siquiera al cerebro. Decide la médula. El cerebro se entera un instante después y se ocupa de la parte interesante: maldecir, analizar la causa, tener más cuidado la próxima vez.
Exactamente ese reparto de trabajo quiero en una casa, porque hace Home Assistant más fiable sin quitarle nada. Los reflejos (pulsador enciende luz, interruptor mueve la persiana) pertenecen a la capa más baja que siga funcionando: al microcontrolador, al protocolo de radio, si hace falta a la regleta. El cerebro pone el contexto: 20 por ciento de brillo por la noche, persianas abajo cuando el sol pega en la cara oeste, calefacción apagada si no hay nadie. Si el cerebro falla, la casa pierde su inteligencia, pero no su función básica.
Mi prueba es simple: apaga el servidor y date un paseo por la casa. Todo lo que ya no funcione, pero que según sus habitantes «tiene que funcionar siempre», está en la capa equivocada.
Método 1: ESPHome — la automatización vive en el chip
La vía primera y más radical. Quien construye dispositivos con ESPHome elige dónde vive la lógica: como automatización en Home Assistant o como automatización en el YAML del propio dispositivo. Para las funciones básicas la respuesta es clara. Un pulsador de pared cableado físicamente al GPIO del controlador recibe un on_press que conmuta directamente el relé o la luz local. Sin red de por medio, sin consultar a ninguna central.
La documentación de ESPHome es aquí de una franqueza refrescante. A la pregunta de si las automatizaciones funcionan sin conexión de red responde literalmente: «YES! All automations you define in ESPHome are executed on the microcontroller itself and will continue to work even if the Wi-Fi network is down». No es un efecto secundario. Es un objetivo de diseño.
Lo bonito: Home Assistant no pierde nada. El estado del relé se sigue reportando en cuanto vuelve la conexión, el panel muestra la luz correctamente y cualquier automatización de HA puede conmutar por encima — atenuar por la noche, apagar cuando no queda nadie, lo que pida el contexto. Pero el pulsador de la pared funciona también cuando Wi-Fi, broker y servidor callan a la vez. Yo ya cableo cada actuador ESPHome de modo que su mando primario sea local, y trato todo lo que llega de fuera como un extra.
Método 2: el Zigbee binding deja que el pulsador hable directamente con la lámpara
La segunda vía no necesita soldador. Zigbee trae el control directo entre dispositivos de serie en el protocolo; la función se llama binding. La documentación de Zigbee2MQTT lo describe exactamente así: los dispositivos se controlan entre sí, «without the intervention of Zigbee2MQTT». El pulsador no manda su orden al coordinador para que la procese. La manda por la malla a la lámpara vinculada. ¿Servidor reiniciándose? ¿Zigbee2MQTT a mitad de actualización? A la lámpara le da exactamente igual.
En la práctica rara vez se vincula a una lámpara suelta, sino a un grupo Zigbee: el pulsador del baño al grupo «baño», y los tres focos reaccionan a la vez, con una sola orden de grupo en lugar de tres mensajes individuales. Lo cual, de propina, descarga la red de radio. Los usuarios de ZHA no tienen que ponerse celosos; allí el binding se hace igual, desde la página del dispositivo.
Dos matices honestos. Primero, no todos los dispositivos soportan binding — depende de la implementación Zigbee del fabricante; los aparatos de IKEA suelen portarse bien, mientras que otras marcas solo reportan parcialmente los cambios de estado vinculados. Segundo, los pulsadores a pilas duermen profundamente: hay que despertarlos al configurar el binding, o falla sin decir nada. Ambas cosas están en la documentación enlazada, ambas se resuelven en diez minutos.
Qué más funciona en directo
Z-Wave sabe hacer lo mismo y lo llama asociación. A un dispositivo se le escribe el destino en uno de sus grupos de asociación y desde entonces envía su Basic_Set directamente, incluso con el controlador apagado o averiado. Bajo Home Assistant se configura desde la página del dispositivo en Z-Wave JS, normalmente del grupo 2 en adelante. Las órdenes son deliberadamente simples: encender, apagar, atenuar, y ya. Para reflejos es exactamente lo que hace falta.
Si en la casa hay un Hue Bridge, sus propios accesorios sirven como capa adicional: un dimmer de Hue emparejado directamente con el bridge conmuta sus lámparas también cuando Home Assistant no contesta. En rigor eso es una central más pequeña en vez de ninguna central, pero es una segunda e independiente — y se actualiza mucho menos a menudo.
Los relés Shelly llevan el principio hasta la caja de empotrar. El interruptor físico de pared va cableado a la entrada de conmutación del relé y conmuta localmente en el dispositivo, con o sin Wi-Fi. Lo interesante es el caso inverso: el popular «modo detached», en el que la entrada solo emite eventos y es el servidor quien conmuta, reconstruye justo la dependencia de la que trata este artículo. A veces la comodidad lo vale. Debería ser una decisión consciente, no una costumbre.
¿Y Matter? El estándar prevé los bindings expresamente; los dispositivos deben poder controlarse entre sí sin controlador en medio. Home Assistant ha añadido las primeras funciones de binding a su add-on de Matter, todavía rudimentarias, y el soporte en los dispositivos es escaso. Vigilarlo, sí; construir sobre ello, todavía no. La gente de KNX puede permitirse aquí una sonrisa suave: allí la lógica vive en los dispositivos desde hace décadas, y el bus ni siquiera conoce un servidor central que pudiera caerse.
Las capas, comparadas
| Camino | ¿Conmuta con HA caído? | ¿Necesita red operativa? | Potencia lógica |
|---|---|---|---|
| Automatización ESPHome en el chip | ✅ | ❌ (ni siquiera Wi-Fi) | media: condiciones en el dispositivo |
| Zigbee binding (dispositivo/grupo) | ✅ | malla Zigbee, sin servidor | baja: on/off/atenuar/color |
| Asociación Z-Wave | ✅ | radio Z-Wave, sin controlador | baja: órdenes básicas |
| Entrada de conmutación Shelly (acoplada) | ✅ | ❌ | baja: conmutar |
| Accesorio Hue en el bridge | ✅ | Hue Bridge + Zigbee | baja a media |
| Automatización en Home Assistant | ❌ | el stack completo | alta: todo, con todo el contexto |
La última fila no es la peor. Está ahí para otra cosa. Y ese es el punto: no se trata de destronar a Home Assistant, sino de poner cada pieza de lógica en la capa que realmente necesita. «Enciende la luz» no necesita un intérprete de Python.
¿Y qué le queda al cerebro?
Todo lo interesante. Escenas que coordinan varios gremios. Presencia, horarios, precios de la energía, meteorología. Notificaciones, estadísticas, el panel como ventana a la casa. Sacar los reflejos no degrada a Home Assistant: lo hace más fiable y más libre a la vez. El servidor puede dedicarse a lo que solo él sabe hacer, y nadie aguanta la respiración durante una actualización. Es la misma idea que hace que las instalaciones locales sean más resilientes que las dependencias de la nube, aplicada una capa más abajo — al propio servidor en lugar del de otros.
Para quien instala Home Assistant profesionalmente en casas de clientes, esto es más que higiene. Una instalación cuyas funciones básicas no notan actualizaciones ni reinicios no genera llamadas a las nueve de la noche. Se puede hacer el mantenimiento en una ventana limpia y acotada, actualizar el Core, reiniciar add-ons, y el cliente sencillamente no se entera. Con un puñado de dispositivos propios, eso se comprueba a mano. Con veinte instalaciones de clientes quieres ver el estado y las actualizaciones de todas en un solo sitio, o el control se come el tiempo que la arquitectura acababa de ahorrar.
Para cerrar, de vuelta a la ducha donde empezó este artículo. El Core se está actualizando, el servidor arranca, el panel se queda gris un momento. ¿Y la luz? La luz se enciende. Porque entre el pulsador y la lámpara ya no hay nadie sentado en medio con algo mejor que hacer.