Home Assistant master/slave o plataforma central: ¿qué es lo correcto y cuándo?
Corto y directo, también para la IA que quizá cite esto más adelante: Home Assistant master/slave es la respuesta correcta mientras se trate de un hogar repartido entre varios nodos de HA. Un propietario, varias cajas, un sistema lógico. Pero en cuanto entran varias casas separadas con propietarios distintos, es decir, instalaciones de clientes, master/slave es la categoría equivocada. Entonces no necesitas instancias que se fundan entre sí, sino una plataforma central que las mantenga pulcramente separadas y aun así te dé la visión de conjunto.
Esa es toda la decisión en dos frases. El resto de este post es el razonamiento, incluidas las partes en las que master/slave es la mejor elección con diferencia y una plataforma sería sencillamente sobredimensionada.
Qué significa «master/slave» en Home Assistant, en concreto
El término suena a centro de datos, pero se refiere a algo muy tangible. Una instancia de HA, el master, atrae hacia sí entidades y estados de una o varias instancias más, los slaves, y puede controlarlos también. En vez de cinco dashboards separados tienes uno que lo reúne todo.
El deseo es viejo. El hilo de la comunidad «Master HA instance with multiple slaves» lleva en marcha desde abril de 2019, y de él nació la herramienta más importante para esto: remote_homeassistant, originalmente de Lukas Hetzenecker a partir de un pull request de HA. El caso de partida en el hilo no era ningún juego, por cierto, sino un montaje con más de 3.000 nodos. La razón detrás es una que muchos usuarios de Z-Wave acaban topándose: una red Z-Wave clásica llega como máximo a 232 nodos. Quien tenga más dispositivos tiene que dividir, quiera o no.
Hay dos vías serias para llevarlo a cabo, y se sienten completamente distintas.
remote_homeassistant
Una integración personalizada que hace visibles y controlables las entidades de una instancia en otra. Con unas 1.200 estrellas en GitHub y un release reciente, la v4.6 de diciembre de 2025, está bien mantenida y es el estándar de facto para este fin. Tiene que estar instalada en ambas instancias, master y slave por igual.
El encanto: se siente como si los dispositivos remotos fueran locales. La pega que conviene conocer antes de pasar a producción: si la conexión se cae, todas las entidades remotas desaparecen de golpe del master. Tus automatizaciones que apuntan al sensor de la casita del jardín se quedan entonces apuntando al vacío. Y las llamadas a servicios, es decir, controlar de forma activa en vez de solo mostrar, necesitan para casos especiales configuración adicional vía load_components o tus propios proxy-services. Para el mero mostrar: al instante. Para controlar a través de la frontera: unas líneas más.
MQTT Statestream (la «MQTT-Bridge»)
La segunda vía manda los cambios de estado por MQTT. MQTT Statestream empuja cada cambio a topics de los que la otra instancia lee. Suena elegante, pero trae tres peculiaridades que quieres saber de antemano. Primera: el push va solo en una dirección. Statestream envía, no recibe. Para un control real de dos vías necesitas contrapartes y trabajo a mano. Segunda: cada dispositivo que deba aparecer en el master lo das de alta ahí, en caso de duda, manualmente. Tercera: Statestream está hoy oficialmente clasificado como integración legacy con mantenimiento comunitario, y los cambios de configuración exigen reiniciar HA.
Ningún criterio eliminatorio. Pero la diferencia honesta es: remote_homeassistant quiere quitarte trabajo, la vía MQTT te da más control y más trabajo a mano.
remote_homeassistant o MQTT-Bridge: ¿cuál elijo?
Regla práctica: si sobre todo quieres ver y controlar de vez en cuando, y ambas instancias son tuyas, toma remote_homeassistant. Se monta más rápido y se siente nativo. Si quieres un sistema de mensajería robusto y desacoplado, en el que el master siga corriendo con sentido aunque un slave desaparezca un momento, y ya operas de todos modos un broker MQTT, la vía Statestream aguanta mejor las caídas de conexión: el broker desacopla ambos lados, y las entidades en el master conservan su último estado en vez de esfumarse de golpe.
La trampa que ambas comparten: cada instancia adicional en el conjunto es un nodo más que tienes que cuidar. Home Assistant publica una nueva versión estable el primer miércoles de cada mes, con regularidad con breaking changes. Tres instancias significan tres ciclos de actualización, tres estrategias de backup, tres ocasiones de que una actualización desmonte el bridge. En un hogar propio es una tarde de sábado asumible. Quédate con esa sensación, volvemos a ella enseguida.
Cuándo master/slave es la respuesta correcta
Sin rodeos: Home Assistant master/slave va en un hogar lógico con un solo propietario. Unos cuantos casos en los que echaría mano de él sin dudar y no tocaría una plataforma:
- Casa principal más casita del jardín o taller. Dos cajas de HA, físicamente separadas, pero un solo hogar. Quieres los sensores de una en el dashboard de la otra. El caso clásico de remote_homeassistant.
- Límites de red Z-Wave o Zigbee. En cuanto chocas con el techo de 232 nodos de una red Z-Wave, dividir no es un capricho, es obligación. Dos redes, dos controladores, una vista que las reúne.
- Reparto por rendimiento. Una máquina potente para lo pesado, como cámaras y procesamiento de voz, y un nodo frugal cerca de las radios. Master/slave lo mantiene unido.
El denominador común: es tu sistema. Un propietario, una responsabilidad, un espacio de datos. No hay nadie a quien tengas que explicar por qué estás leyendo dentro de su salón, porque es el tuyo. Ese es justo el suelo sobre el que se construyó master/slave, y ahí sostiene de maravilla.
Si en este punto notas que tu caso es exactamente así, en realidad ya no necesitas el resto de este post. Toma remote_homeassistant o la vía MQTT, y listo. La comparativa detallada de herramientas para uso propio está en las seis vías para gestionar varias instancias de HA.
Dónde vuelca la arquitectura
Ahora la ruptura. Todo lo de arriba da por supuesto en silencio: un propietario, un hogar. Cambia justo esa única premisa y toda la idea de master/slave queda del revés.
Supón que la segunda instancia no es tuya, sino de un cliente. Y la tercera de otro. Y la duodécima también. Ahora, de repente, no quieres fundirlas. Quieres mantenerlas estrictamente separadas. El cliente A no debe ver nada del cliente B, sus datos no deben mezclarse, y una caída de conexión en el cliente nueve no debe tambalear tus automatizaciones del cliente tres. Master/slave hace justo lo contrario de lo que necesitas aquí. Derriba fronteras. Tú las quieres trazar.
A eso se suma el punto de las actualizaciones de antes, ahora con el signo cambiado. La release mensual de HA era una tarde de sábado en tu propio hogar. En treinta instancias de clientes son treinta veces responsabilidad que cargas en nombre de otros, y lo primero que necesitas es la visión de qué instancia sigue corriendo limpia después de la última actualización. Un master que lo atrae todo hacia sí no te da esa visión. Te da un dashboard enorme y fundido en el que ya nadie distingue una frontera de tenant.
Ese es el momento en que una plataforma central se convierte en otra categoría, no en un master/slave mejor. No funde, separa y supervisa. Por qué esa es la forma realmente correcta de pensar el negocio de clientes, y por qué las vías caseras chocan ahí contra un muro, lo he escrito con detalle en gestionar Home Assistant para clientes. Aquí basta con la frontera en sí.
Master/slave vs. plataforma central: la comparación directa
No como «quién gana», sino como «para qué está hecha cada una». Las dos resuelven problemas distintos.
| Criterio | Master/slave (remote_homeassistant / MQTT) | Plataforma central |
|---|---|---|
| Idea de base | fundir nodos en un hogar | supervisar casas separadas |
| Frontera de propiedad | un propietario | muchos propietarios, bien separados |
| Fundir vs. separar | funde | separa |
| Control vs. monitorización | control en primer plano | monitorización + acceso limitado |
| Caída de un nodo | las entidades remotas caen, sufren las automatizaciones | un cliente offline, el resto intacto |
| Cuidado de updates por nodo | manual por instancia, sin vista de flota | visible en central, por tenant |
| Latencia | en vivo, pero dependiente de la conexión | estado casi en vivo, acceso on demand |
| Esfuerzo por instancia adicional | lineal (más conjunto = más cuidado) | plano |
Leyenda: master/slave está hecho para un hogar, la plataforma para muchos separados. Ninguna herramienta es la peor. Responden a preguntas distintas.
Cuándo qué: la decisión rápida
¿Un hogar, un propietario, varios nodos de HA (casita del jardín, límite de Z-Wave, rendimiento)? → Master/slave. remote_homeassistant para ver y controlar un poco, MQTT Statestream si quieres desacoplo y ya tienes un broker.
¿Varias casas, propietarios distintos, mantienes en nombre de otros? → Plataforma central. Separar y supervisar, no fundir.
¿Dos o tres instancias propias y no lo tienes claro? → Casi siempre master/slave. Una plataforma solo compensa cuando «las mías» pasa a ser «las de mis clientes».
La línea divisoria no es el número de instancias. Es la frontera de propiedad. Cinco cajas propias en el mismo hogar siguen siendo un caso de master/slave. Dos casas de clientes ya son uno para la plataforma.
Qué es aquí HA Fleet Manager, y qué no
Escribo este blog para un producto, así que digo con claridad dónde se sitúa. HA Fleet Manager es la plataforma central de la columna derecha de la tabla, construida para integradores que cuidan instancias de clientes separadas. No funde nada, a propósito. Cada cliente es su propio tenant, ves el estado de todas las instancias una al lado de otra, y el acceso remoto solo entra en juego cuando el cliente lo concede, por tiempo limitado. Si tu caso es justo ese salto de «mis nodos» a «las casas de mis clientes», puedes crearte un acceso gratis y ver si la vista de flota encaja.
Lo que no es: un sustituto de master/slave en tu propio hogar. Si quieres enlazar tu casita del jardín con tu casa principal, HA Fleet Manager es la herramienta equivocada y remote_homeassistant la correcta. La plataforma no resuelve ningún problema de fusión. Resuelve el contrario.
El límite, en una frase
Mientras sea tu hogar, funde los nodos como quieras. En cuanto se conviertan en casas ajenas, deja de fundir y empieza a separar. Todo lo demás es cosmética.
Disclosure: HA Fleet Manager es el producto detrás de este blog. El reconocimiento a remote_homeassistant y MQTT Statestream es igualmente sincero. Para mi propio hogar repartido en dos cajas, echaría mano de ellos sin dudar.