MQTT es una de esas piezas que suenan pequeñas hasta que empiezas a usar sensores, Zigbee2MQTT, Home Assistant, scripts caseros y algún servicio que quiere enterarse de lo que pasa en casa. Entonces deja de ser “un broker más” y se convierte en una especie de pasillo discreto por el que circulan estados, eventos y órdenes.
No es obligatorio tener MQTT en un homelab doméstico. De hecho, si solo tienes Home Assistant con cuatro integraciones directas, quizá no lo necesitas. Pero en cuanto la casa empieza a mezclar dispositivos locales, automatizaciones propias y servicios que no deberían hablar directamente entre ellos, MQTT aporta algo muy útil: desacopla.
Un sensor publica. Home Assistant escucha. Un script publica un aviso. Otro servicio lo consume. Zigbee2MQTT traduce dispositivos Zigbee a mensajes. Nadie necesita saber demasiado del resto.
Eso, bien usado, simplifica. Mal usado, crea un vertedero de topics con nombres raros, estados obsoletos y retained messages que vuelven de entre los muertos cada vez que reinicias algo.
Este artículo encaja en la ruta de automatización e IA local, aunque toca de lleno servicios para la familia porque normalmente aparece cerca de Home Assistant. Ya hablé de tratar Home Assistant como servicio crítico de casa y de diseñar un dashboard familiar que no enseñe toda la sala de máquinas. MQTT vive justo debajo de esa capa visible. Si está bien planteado, nadie lo nota. Si está mal, la domótica empieza a parecer superstición con logs.
qué problema resuelve MQTT#
MQTT es un protocolo de mensajería ligero basado en publicar y suscribirse a temas. Un cliente publica un mensaje en un topic. Otros clientes suscritos a ese topic lo reciben. En medio está el broker, que no decide la lógica de tu casa. Solo reparte mensajes.
La documentación oficial de Home Assistant sobre MQTT lo plantea como una integración que conecta Home Assistant con un broker. Ese broker puede ser el add-on de Mosquitto dentro de Home Assistant OS o un Mosquitto externo. La parte importante es entender la separación: Home Assistant no es el broker por definición. Home Assistant es un cliente más, aunque muchas veces sea el cliente principal.
En una casa pequeña esto parece una distinción académica. En una casa con sensores, scripts y varios servicios, importa bastante.
Sin MQTT, cada pieza tiende a integrarse directamente con otra. Home Assistant habla con un dispositivo. Un script llama a Home Assistant. Una automatización consulta una API. Otro servicio depende de una URL concreta. Cuando algo cambia, varias cosas se enteran a la vez.
Con MQTT, puedes plantearlo de otra manera:
- Los dispositivos publican estado.
- Las automatizaciones consumen estado.
- Las órdenes viajan por topics concretos.
- Los scripts caseros no necesitan conocer toda la API de Home Assistant.
- Algunos servicios pueden seguir funcionando aunque Home Assistant se reinicie.
No es una solución universal. Es un contrato pequeño. Y como todos los contratos, lo útil está en que sea claro.
dónde pondría el broker#
La opción cómoda es usar Mosquitto como add-on de Home Assistant. Para mucha gente será suficiente. Se instala fácil, aparece integrado, se gestiona desde la misma interfaz y reduce piezas externas. Si Home Assistant es el centro de la domótica y MQTT solo existe para Zigbee2MQTT o cuatro sensores, no veo problema.
La opción más limpia en un homelab un poco más serio es separar el broker. Un contenedor Mosquitto, una VM pequeña o un servicio en el nodo estable donde también viven DNS, acceso remoto o monitorización básica. No porque Mosquitto necesite muchos recursos, sino porque su papel puede ser más amplio que Home Assistant.
Yo lo separaría cuando se cumpla alguna de estas condiciones:
- Hay más clientes MQTT además de Home Assistant.
- Zigbee2MQTT o sensores locales dependen mucho del broker.
- Quiero que algunos mensajes sigan circulando aunque Home Assistant reinicie.
- Tengo scripts o servicios caseros que publican eventos.
- Quiero versionar y respaldar la configuración fuera de Home Assistant.
- Home Assistant vive en una VM que actualizo con más frecuencia que el broker.
Si MQTT solo existe para que Home Assistant hable con un add-on, mantenerlo dentro tiene sentido. Si empieza a ser una pieza común de la casa, prefiero darle vida propia.
Lo que no haría es ponerlo en el host más experimental. El broker consume poco, pero sostiene conversaciones importantes. Meterlo en la misma máquina donde pruebas contenedores raros cada semana es comprar una avería tonta. Para laboratorio, vale. Para sensores de casa, no.
Mosquitto sin hacerlo raro#
Mosquitto es la elección obvia para casa. Es pequeño, maduro y bien documentado. La documentación oficial de Eclipse Mosquitto tiene más profundidad de la que hace falta para un homelab normal, pero merece leer al menos las partes de autenticación, persistencia y configuración básica.
Mi configuración mental mínima sería esta:
- Usuarios y contraseñas, nada de anónimo.
- Listener limitado a la red interna o a la VLAN donde toca.
- Persistencia activada si necesito conservar sesiones o retained messages.
- Logs suficientes para diagnosticar, sin convertirlo en una trituradora de disco.
- Backups de configuración y datos persistentes.
- Acceso externo cerrado salvo una razón muy concreta.
MQTT no debería estar expuesto a internet. Si necesitas publicar desde fuera, mejor entrar por VPN, Tailscale o una pasarela controlada. Abrir el broker porque “solo es la domótica” es una de esas frases que envejecen fatal.
También evitaría montar TLS interno demasiado pronto si la red ya está controlada y el broker vive solo en LAN. TLS tiene sentido cuando atraviesas redes no confiables o quieres endurecer bastante el entorno. En una casa, muchas veces gana más valor separar redes, limitar permisos y no exponer el puerto que añadir certificados que luego nadie mantiene. Si el broker cruza redes o sale de casa, cambia la película.
La seguridad aburrida aquí funciona mejor que la seguridad teatral: usuarios separados, permisos razonables, red cerrada y copias.
topics: nombres que puedas leer medio dormido#
El mayor desastre de MQTT no suele ser técnico. Es semántico. Topics con nombres improvisados, dispositivos que publican en cualquier sitio y estados que nadie sabe si son eventos, órdenes o lecturas.
Un topic es una dirección. Si la dirección no se entiende, el sistema envejece mal.
Para casa me gustan estructuras simples:
| |
No digo que sea el único esquema bueno. Digo que se entiende. Y eso ya es mucho.
Zigbee2MQTT tiene su propia convención de topics, documentada en MQTT topics and messages. Conviene respetarla en vez de pelearse con ella. Si usas friendly_name, puedes hacer que los dispositivos tengan nombres legibles y no parezcan piezas de inventario industrial. La documentación de devices and groups explica justo esa parte.
Mi criterio:
- Separar estados de comandos.
- Evitar nombres crípticos.
- No meter datos sensibles en el nombre del topic.
- Mantener prefijos por zona o función.
- No cambiar nombres alegremente cuando ya hay automatizaciones encima.
- Documentar los topics que usen scripts propios.
Un topic como zigbee2mqtt/0x00158d00042abcde puede funcionar. Un topic como zigbee2mqtt/salon/interruptor_entrada lo entiende una persona. Dentro de seis meses, esa diferencia se agradece.
retained messages: útiles y peligrosos#
Los retained messages son una de las mejores partes de MQTT y una fuente preciosa de sustos.
Cuando un mensaje se publica como retained, el broker guarda el último valor de ese topic y se lo entrega a nuevos suscriptores. Para estados de sensores puede ser estupendo. Si Home Assistant reinicia, vuelve a ver el último valor de temperatura, humedad o disponibilidad sin esperar al siguiente mensaje.
Para órdenes puede ser horrible.
Imagina que publicas una orden retained para encender algo. Reinicias un cliente, se suscribe y recibe una orden antigua como si fuese actual. Ya tienes una automatización fantasma. No es que MQTT esté loco. Es que le pediste recordar algo que quizá no debía recordar.
Mi regla:
- Estado estable, a veces retained.
- Disponibilidad, puede tener sentido retained.
- Comandos, casi nunca retained.
- Eventos puntuales, no retained.
- Alertas que ya caducaron, no retained salvo diseño claro.
La página de mosquitto.conf documenta opciones relacionadas con retained messages y persistencia. No hace falta saberse toda la man page de Mosquitto, pero sí entender que el broker puede conservar estado y que eso forma parte de tu diseño.
Cuando algo raro pasa tras reiniciar, los retained messages son uno de los primeros sitios donde miraría. No por paranoia. Por experiencia común de domótica: muchos fantasmas tienen payload.
disponibilidad sin pasarse#
¿Tiene que tener alta disponibilidad un broker MQTT doméstico? Depende de qué controle.
Si MQTT solo alimenta sensores informativos, puede caer. Si coordina alarmas, calefacción, automatizaciones físicas o estados que la casa usa a diario, merece más respeto. Aun así, no saltaría directamente a un cluster de brokers por diversión.
Primero haría cosas más sencillas:
- Broker en una máquina estable.
- Backups de configuración.
- Persistencia si tiene sentido.
- Monitorización básica de puerto y proceso.
- Alerta si se cae durante un tiempo razonable.
- Procedimiento corto para restaurarlo.
Para una casa, muchas veces esto compra más tranquilidad que montar una arquitectura brillante y delicada. Un broker Mosquitto pequeño se restaura rápido si sabes dónde están sus ficheros y qué clientes deben conectarse.
Lo que sí me parece importante es separar impacto. Si Home Assistant cae pero el broker sigue vivo, algunos sensores y publicadores pueden seguir enviando estado. Si el broker cae, muchos clientes seguirán vivos, pero se quedan sin punto de encuentro. Saber cuál de las dos cosas ha fallado ayuda mucho a diagnosticar.
Por eso lo monitorizaría como pieza propia. No con veinte métricas, solo lo necesario: responde, acepta conexión, recibe publicaciones de prueba y no lleva días sin backup.
backups y restauración#
Un broker MQTT no suele tener datos enormes. Precisamente por eso es fácil olvidarlo en los backups.
Yo guardaría:
- Configuración de Mosquitto.
- Fichero de usuarios o mecanismo de autenticación.
- ACL si las uso.
- Datos persistentes si tengo retained messages o sesiones que me importan.
- Nota con puerto, host interno y clientes principales.
La restauración debería ser aburrida: levantar broker, cargar configuración, comprobar usuarios, publicar un mensaje de prueba y ver que Home Assistant o el cliente correspondiente lo recibe.
No hace falta convertirlo en una ceremonia. Pero sí probarlo una vez. Sobre todo si el broker está fuera de Home Assistant. Es muy cómodo separar servicios hasta que descubres que la copia solo cubría la VM de Home Assistant y el broker vivía en otro contenedor que nadie estaba respaldando.
Si MQTT forma parte de la domótica familiar, lo metería en el mismo mapa operativo que DNS, Home Assistant y acceso remoto. No porque sea enorme. Porque si falla, el síntoma puede aparecer lejos: un botón Zigbee no dispara nada, un sensor no actualiza, una automatización parece dormida.
cuándo no usaría MQTT#
MQTT engancha. Empiezas con un sensor y acabas queriendo publicar media vida doméstica en topics.
No lo usaría para todo.
Si Home Assistant tiene una integración local directa y estable, muchas veces la usaría tal cual. Si una app tiene una API clara y no necesito compartir eventos con más clientes, MQTT puede ser una capa de más. Si el servicio manda datos sensibles, pensaría antes de convertir el broker en un tablón común. Si solo busco notificaciones push, quizá ntfy encaja mejor que MQTT.
MQTT brilla cuando hay varios productores y consumidores de eventos simples. Sensores, estados, disponibilidad, comandos ligeros, telemetría doméstica, scripts que publican “ha pasado esto” y servicios que escuchan sin depender directamente de una API grande.
No brilla como base de datos. No brilla como sistema de colas complejo. No brilla como excusa para no diseñar bien automatizaciones. Si necesitas historial, guarda datos en una base de series temporales o usa el histórico de Home Assistant. Si necesitas auditoría fuerte, diseña otra cosa.
El broker reparte mensajes. Nada más. Y eso está bien.
ejemplo práctico de casa#
Una arquitectura razonable podría ser:
- Home Assistant en una VM estable.
- Mosquitto como contenedor separado en el nodo de servicios.
- Zigbee2MQTT conectado al broker.
- Sensores Zigbee publicando estado por topics de Zigbee2MQTT.
- Home Assistant suscrito mediante la integración MQTT.
- Un script pequeño publicando
casa/backups/estado. - Una automatización que avisa si
casa/backups/estadopasa demasiado tiempo sin actualizar. - ntfy o Telegram para notificación final al móvil.
La gracia no es que todo sea MQTT. La gracia es que cada pieza sabe lo justo.
Zigbee2MQTT traduce dispositivos. Mosquitto reparte mensajes. Home Assistant decide acciones de casa. El script de backups publica un estado simple. La notificación se envía por el canal que toque. Si mañana cambio Telegram por ntfy, no necesito rediseñar los sensores. Si cambio una automatización, no necesito tocar Zigbee2MQTT.
También hay límites. No pondría secretos en payloads. No publicaría datos personales sin pensar. No haría que una orden crítica dependa de retained messages. Y no permitiría que cualquier cliente publique comandos en cualquier topic.
Pequeño, claro y con permisos. Ese es el punto.
qué miraría cuando algo falla#
Cuando MQTT falla, el síntoma rara vez dice “MQTT”. Dice que un sensor no actualiza, que un botón no responde o que Home Assistant no ve algo.
Mi orden de diagnóstico sería:
- ¿El broker responde?
- ¿El cliente está conectado?
- ¿El topic correcto recibe mensajes?
- ¿El payload tiene el formato esperado?
- ¿Hay retained messages antiguos?
- ¿Home Assistant está suscrito y descubre la entidad?
- ¿La automatización depende de un nombre antiguo?
MQTT Explorer o cualquier cliente sencillo ayuda muchísimo. No para vivir dentro mirando topics, sino para comprobar qué está pasando sin culpar a Home Assistant antes de tiempo.
También miraría permisos. Si separas usuarios por cliente, un fallo de ACL puede parecer un fallo de dispositivo. El cliente conecta, pero no puede publicar donde crees. O puede leer, pero no escribir. Eso está bien desde seguridad, pero exige nombres claros y logs suficientes.
La peor situación es no saber si el problema está en el sensor, el broker, Home Assistant o la automatización. Un topic bien nombrado y un cliente de prueba reducen bastante esa niebla.
mi criterio final#
Meter MQTT en casa merece la pena cuando reduce acoplamiento. Si lo añade, sobra.
Lo usaría para sensores, Zigbee2MQTT, estados simples, scripts caseros y automatizaciones que necesitan intercambiar señales sin depender todos de Home Assistant como única puerta. Lo mantendría pequeño, interno, con usuarios, backups y topics legibles. Evitaría retained messages en comandos y no lo expondría fuera de casa.
No hace falta vender MQTT como una revolución. Es más humilde que eso. Es una pieza de fontanería doméstica. Si está bien hecha, no se ve. Si está mal, todo huele raro y nadie sabe por dónde empezar.
Para mí ese es el mejor argumento a favor: una casa con sensores y automatizaciones necesita menos magia y más contratos simples. MQTT puede ser uno de esos contratos.