Un bridge MQTT conecta dos brokers para que los mensajes de determinados topics fluyan automáticamente de uno a otro. Al terminar esta guía entenderás cuándo tiene sentido un bridge y cómo funcionan el remapeo de topics y la prevención de bucles, y tendrás una configuración de bridge de Mosquitto funcional y una alternativa con Node-RED que reenvían datos locales a un broker en la nube.
Qué hace realmente un bridge MQTT
Un bridge no es un protocolo especial. Un broker (o un programa auxiliar) simplemente abre una conexión cliente MQTT normal con otro broker, se suscribe en un lado y vuelve a publicar en el otro. Desde el punto de vista del broker remoto, el bridge es un cliente más, con su usuario, contraseña y client ID.
Ese detalle importa a la hora de construirlo. Muchos brokers alojados, incluido ConnectMQ, no ejecutan por sí mismos un bridge saliente. En su lugar, el bridge se ejecuta en el edge: una instancia de Mosquitto en una planta de Monterrey o Bilbao, o un flujo de Node-RED en un gateway, se conecta hacia el broker en la nube como cliente. Además, es la dirección más amigable con el firewall, ya que la sede solo necesita acceso saliente por el puerto 8883.
Motivos habituales para usar un bridge:
- Autonomía local. Los adaptadores de PLC, los HMI y los controladores siguen hablando con un broker de la red de planta aunque se caiga el enlace a internet.
- Exportación selectiva. Solo salen de la sede los topics agregados o aprobados, no todas las señales en bruto.
- Menos conexiones en la nube. Cientos de dispositivos locales comparten una sola conexión superior, lo que te mantiene dentro de las cuotas de conexiones.
- Mapeo del espacio de nombres. Topics locales como
line4/press/tempse convierten en topics globalmente únicos en la nube, comoacme/izmir/line4/press/temp.
Topologías de bridge
| Topología | Descripción | Ideal para | Cuidado con |
|---|---|---|---|
| Del edge a la nube (out) | El broker local envía topics seleccionados hacia arriba | Telemetría, dashboards, historians | El buffer durante las caídas |
| De la nube al edge (in) | Los comandos de la nube bajan a la sede | Consignas, configuración, disparadores OTA | Autorizar quién puede enviar comandos |
| Bidireccional | Ambas direcciones en árboles de topics separados | Operación remota completa | Bucles de mensajes |
| Hub and spoke | Muchas sedes hacen bridge a un broker central | Unified Namespace multisede | Colisiones de topics entre sedes |
El patrón hub and spoke es la columna vertebral de muchos diseños de Unified Namespace y Sparkplug B: cada sede es dueña de su broker local y aporta una rama al árbol de topics corporativo en la nube. Esa misma rama puede alimentar dashboards o un gemelo digital 3D de cada planta.
Opción 1: bridge de Mosquitto a un broker en la nube
Eclipse Mosquitto incluye una función de bridge que se configura en mosquitto.conf. El ejemplo siguiente ejecuta un broker local para los dispositivos de planta en el puerto 1883 y hace bridge con un broker de ConnectMQ por TLS en el 8883 usando las credenciales generadas en el portal.
# /etc/mosquitto/conf.d/bridge-connectmq.conf
# --- Listener local para los dispositivos de la red de planta ---
listener 1883
# En producción, restríngelo con password_file
allow_anonymous true
# --- Bridge a ConnectMQ (nube) ---
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
# Conserva la sesión remota para que los mensajes QoS 1 sobrevivan a reconexiones cortas
cleansession false
keepalive_interval 60
restart_timeout 5 60
# El broker remoto no es Mosquitto: no uses el flag de bridge privado
try_private false
notifications false
# Buffer local mientras el enlace superior está caído
max_queued_messages 10000
# topic <pattern> <direction> <qos> <local-prefix> <remote-prefix>
# Local plant/line4/... -> nube acme/izmir/line4/...
topic # out 1 plant/ acme/izmir/
# Nube acme/izmir/cmd/... -> local cmd/...
topic # in 1 cmd/ acme/izmir/cmd/
Cómo funcionan las líneas topic: Mosquitto toma el patrón (#), le antepone el prefijo local para construir la suscripción local (plant/#) y, al reenviar, sustituye el prefijo local por el remoto. Un mensaje local en plant/line4/press/temp aparece en la nube como acme/izmir/line4/press/temp. La línea in hace lo contrario para los comandos.
Notas sobre los ajustes importantes:
remote_clientiddebe ser el client ID emitido con tus credenciales. El broker vincula los client IDs a las credenciales, así que un ID aleatorio será rechazado.try_private false. El flag de bridge privado de Mosquitto es una extensión entre Mosquittos; otros brokers pueden rechazarlo.notifications false. Si no, Mosquitto publica mensajes de estado del bridge en topics$SYS/broker/connection/..., que un remoto que no sea Mosquitto puede no aceptar.bridge_capath. Apunta al almacén de CA del sistema. El broker presenta un certificado de Let's Encrypt, que está en ese almacén en las distribuciones Linux estándar.max_queued_messages. Limita cuántos mensajes almacena el broker local mientras el enlace superior está caído. Dimensiónalo según tu tolerancia a cortes y tu disco.
Reinicia Mosquitto y observa su log en busca de Connecting bridge connectmq-cloud seguido de una conexión correcta. Si falla, la línea del log con el código CONNACK te dirá si es un problema de credenciales o de TLS.
Prueba el bridge de extremo a extremo
# En un portátil: observa el lado de la nube
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_OTHER_CLIENT_ID \
-t "acme/izmir/#" -v
# En la red de planta: publica en el broker local
mosquitto_pub -h 192.168.10.5 -p 1883 -i press-sim-01 \
-t "plant/line4/press/temp" -m "78.2" -q 1
Deberías ver acme/izmir/line4/press/temp 78.2 en el suscriptor de la nube. Ten en cuenta que el portátil necesita su propio conjunto de credenciales; dos conexiones no pueden compartir un client ID. Para una prueba sin credenciales, apunta el bridge al servidor MQTT público gratuito en el puerto 1883, elimina las líneas de usuario y contraseña, usa un remote_clientid único y un prefijo remoto como connectmq/demo/b7e2/ (los datos públicos son visibles para todo el mundo; úsalo solo para pruebas, nunca para datos de producción).
Opción 2: Node-RED como bridge
Si la sede ya ejecuta Node-RED, puede que ni siquiera necesites un segundo proceso de broker. Un flujo con dos nodos de configuración MQTT actúa como bridge y te da un lugar donde filtrar, renombrar y transformar mensajes.
- Añade un nodo
mqtt incon una configuración de broker para el broker local (por ejemplo192.168.10.5:1883) suscrito aplant/#con QoS 1. - Añade un nodo
functionpara remapear topics y descartar todo lo que no quieras exportar. - Añade un nodo
mqtt outcon una segunda configuración de broker: servidorbroker.connectmq.com, puerto 8883, "Use TLS" activado, con el usuario, la contraseña y el client ID del portal.
// Nodo function: remapea los topics locales al espacio de nombres de la nube
const LOCAL_PREFIX = "plant/";
const REMOTE_PREFIX = "acme/izmir/";
if (!msg.topic.startsWith(LOCAL_PREFIX)) {
return null; // ignora topics inesperados
}
// Filtro de ejemplo: no exportar señales de depuración en bruto
if (msg.topic.includes("/debug/")) {
return null;
}
msg.topic = REMOTE_PREFIX + msg.topic.slice(LOCAL_PREFIX.length);
msg.qos = 1;
return msg;
Para los comandos de bajada, añade una ruta espejo: mqtt in con la configuración de la nube suscrito a acme/izmir/cmd/#, un nodo function que reescriba el prefijo a cmd/ y un mqtt out hacia el broker local. El tutorial de MQTT con Node-RED cubre en detalle los nodos de configuración y los ajustes de TLS, y la documentación oficial de Node-RED recoge todas las opciones de los nodos MQTT.
La contrapartida: Node-RED no guarda en disco como puede hacerlo un broker. Si el enlace superior cae, los mensajes que atraviesan el flujo se pierden, salvo que añadas tu propia cola. Mosquitto es mejor opción cuando necesitas store-and-forward; Node-RED gana cuando necesitas lógica.
Cómo evitar bucles de mensajes
Los bridges bidireccionales pueden crear bucles: un mensaje sube, coincide con la regla de bajada, vuelve, sube otra vez. Reglas que te mantienen a salvo:
- Usa árboles de topics disjuntos para cada dirección, como arriba (
plant/sale,cmd/entra). - Nunca hagas bridge de
#en ambas direcciones con los mismos prefijos. - En configuraciones MQTT 5, la opción de suscripción No Local impide que un cliente reciba sus propias publicaciones, lo que ayuda cuando el bridge se suscribe y publica por la misma conexión.
- Prueba con un solo mensaje y observa ambos lados antes de habilitar el tráfico de producción.
Lista de comprobación para solucionar problemas
| Síntoma | Causa probable | Solución |
|---|---|---|
| CONNACK not authorized | Credenciales o client ID incorrectos | Copia los tres valores del portal |
| Error TLS al conectar | Falta el almacén de CA o la ruta es incorrecta | Instala ca-certificates y revisa bridge_capath |
| El bridge se conecta y luego se cae | Client ID duplicado usado en otro sitio | Da a cada cliente su propio conjunto de credenciales |
| Los topics aparecen sin prefijo | Prefijos intercambiados en la línea topic | El orden es prefijo local y luego prefijo remoto |
| Huecos de datos tras un corte | Cola demasiado pequeña o QoS 0 | Usa QoS 1 y aumenta max_queued_messages |
| Los mensajes rebotan sin fin | Reglas in/out solapadas | Separa los árboles por dirección |
Elegir un endpoint en la nube para tus bridges
El lado de la nube debería ser aburrido: siempre disponible, con TLS por defecto y capaz de aceptar una conexión superior por sede además de tus dashboards y servicios. Un broker MQTT gestionado elimina el trabajo de parches y certificados, y la guía de brokers MQTT en la nube repasa las ventajas e inconvenientes de cada alojamiento. Si estos componentes son nuevos para ti, el tutorial de MQTT para principiantes y el modelo publish/subscribe son buenos complementos para este artículo.
Conecta tus sedes a ConnectMQ
Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, y pega el usuario, la contraseña y el client ID generados en tu bridge de Mosquitto o en el nodo de configuración de Node-RED. El explorador de topics en vivo de ConnectMQ muestra en tiempo real los topics que llegan por el bridge, así que puedes confirmar el mapeo antes de conectar más sedes.
Preguntas frecuentes
¿ConnectMQ tiene un bridge integrado?
No. Haces bridge hacia él ejecutando Mosquitto, Node-RED u otro cliente MQTT en el edge que se conecta al broker como un cliente normal por TLS.
¿Puedo hacer bridge de funciones de MQTT 5 como las user properties?
Configura bridge_protocol_version mqttv50 en Mosquitto para hacer bridge con MQTT 5. Comprueba que ambos brokers admiten MQTT 5 y verifica que se reenvían las propiedades de las que dependes.
¿Cuántas conexiones usa un bridge?
Un bridge de Mosquitto usa una sola conexión con el broker remoto, independientemente de cuántos dispositivos locales publiquen a través de él. Un bridge de Node-RED usa una conexión por cada nodo de configuración de broker.
¿Qué pasa con los datos cuando se cae el enlace a internet?
Un bridge de Mosquitto encola los mensajes localmente hasta max_queued_messages y los reenvía cuando vuelve el enlace. Los flujos de Node-RED sin más no guardan nada en buffer a menos que lo añadas.
