Um bridge MQTT conecta dois brokers para que as mensagens de tópicos selecionados fluam automaticamente de um para o outro. Ao final deste guia, você vai entender quando um bridge faz sentido, como funcionam o remapeamento de tópicos e a prevenção de loops, e terá uma configuração funcional de bridge no Mosquitto e uma alternativa em Node-RED que encaminham dados locais para um broker na nuvem.
O que um bridge MQTT realmente faz
Um bridge não é um protocolo especial. Um broker (ou um programa auxiliar) simplesmente abre uma conexão de cliente MQTT comum com outro broker, assina de um lado e republica do outro. Do ponto de vista do broker remoto, o bridge é apenas mais um cliente com usuário, senha e client ID.
Esse detalhe influencia a forma de montá-lo. Muitos brokers hospedados, incluindo o ConnectMQ, não executam eles mesmos um bridge de saída. Em vez disso, você roda o bridge na borda: uma instância do Mosquitto na planta, ou um fluxo Node-RED em um gateway, se conecta ao broker na nuvem como cliente. Essa também é a direção mais amigável a firewalls, já que a planta só precisa de acesso de saída na porta 8883.
Motivos típicos para usar um bridge:
- Autonomia local. Adaptadores de CLP, IHMs e controladores continuam conversando com um broker na rede da planta mesmo se o link de internet cair.
- Exportação seletiva. Apenas tópicos agregados ou aprovados saem da planta, e não cada sinal bruto.
- Menos conexões na nuvem. Centenas de dispositivos locais compartilham uma única conexão upstream, o que mantém você dentro das cotas de conexão.
- Mapeamento de namespace. Tópicos locais como
line4/press/tempse tornam tópicos globalmente únicos na nuvem, comoacme/izmir/line4/press/temp.
Topologias de bridge
| Topologia | Descrição | Bom para | Atenção a |
|---|---|---|---|
| Borda para nuvem (out) | O broker local envia tópicos selecionados para cima | Telemetria, painéis, historiadores | Buffer durante interrupções |
| Nuvem para borda (in) | Comandos da nuvem descem até a planta | Setpoints, configuração, gatilhos de OTA | Autorizar quem pode comandar |
| Bidirecional | As duas direções em árvores de tópicos separadas | Operação remota completa | Loops de mensagens |
| Hub and spoke | Muitas plantas fazem bridge para um broker central | Unified Namespace multiplanta | Colisão de tópicos entre plantas |
O padrão hub and spoke é a espinha dorsal de muitos projetos de Unified Namespace e Sparkplug B: cada planta tem seu broker local e contribui com um ramo para a árvore de tópicos corporativa na nuvem. Pense em uma indústria com plantas em Campinas, Joinville e Manaus: cada uma mantém seu broker local, e a nuvem consolida os dados que alimentam painéis, historiadores e um gêmeo digital de cada linha.
Opção 1: bridge do Mosquitto para um broker na nuvem
O Eclipse Mosquitto tem um recurso de bridge nativo, configurado no mosquitto.conf. O exemplo abaixo executa um broker local para os dispositivos da planta na porta 1883 e faz bridge para um broker ConnectMQ via TLS na 8883, usando as credenciais geradas no portal.
# /etc/mosquitto/conf.d/bridge-connectmq.conf
# --- Listener local para dispositivos na rede da planta ---
listener 1883
# Restrinja com password_file em produção
allow_anonymous true
# --- Bridge para o ConnectMQ (nuvem) ---
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
# Mantém a sessão remota para que mensagens QoS 1 sobrevivam a reconexões curtas
cleansession false
keepalive_interval 60
restart_timeout 5 60
# O broker remoto não é Mosquitto: não use a flag de bridge privado
try_private false
notifications false
# Buffer local enquanto o uplink estiver fora
max_queued_messages 10000
# topic <pattern> <direction> <qos> <local-prefix> <remote-prefix>
# Local plant/line4/... -> nuvem acme/izmir/line4/...
topic # out 1 plant/ acme/izmir/
# Nuvem acme/izmir/cmd/... -> local cmd/...
topic # in 1 cmd/ acme/izmir/cmd/
Como funcionam as linhas topic: o Mosquitto pega o padrão (#), adiciona o prefixo local na frente para montar a assinatura local (plant/#) e, ao encaminhar, troca o prefixo local pelo prefixo remoto. Uma mensagem local em plant/line4/press/temp aparece na nuvem como acme/izmir/line4/press/temp. A linha in faz o inverso para os comandos.
Observações sobre as configurações importantes:
remote_clientidprecisa ser o client ID emitido com suas credenciais. O broker vincula client IDs às credenciais, então um ID aleatório será rejeitado.try_private false. A flag de bridge privado do Mosquitto é uma extensão Mosquitto-para-Mosquitto; outros brokers podem recusá-la.notifications false. Caso contrário, o Mosquitto publica mensagens de estado do bridge em tópicos$SYS/broker/connection/..., que um broker remoto que não seja Mosquitto pode não aceitar.bridge_capath. Aponta para o repositório de CAs do sistema. O broker apresenta um certificado Let's Encrypt, que está nesse repositório nas distribuições Linux padrão.max_queued_messages. Limita quantas mensagens o broker local armazena enquanto o uplink está fora. Dimensione conforme a sua tolerância a interrupções e o disco disponível.
Reinicie o Mosquitto e acompanhe o log em busca de Connecting bridge connectmq-cloud, seguido de uma conexão bem-sucedida. Se falhar, a linha do log com o código do CONNACK indica se o problema é de credenciais ou de TLS.
Teste o bridge de ponta a ponta
# Em um notebook: observe o lado da nuvem
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
# Na rede da planta: publique no 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
Você deve ver acme/izmir/line4/press/temp 78.2 no assinante da nuvem. Observe que o notebook precisa do seu próprio conjunto de credenciais; duas conexões não podem compartilhar um client ID. Para um teste sem credenciais, aponte o bridge para o servidor MQTT público (gratuito, apenas para testes e protótipos) na porta 1883, remova as linhas de usuário e senha, use um remote_clientid único e um prefixo remoto como connectmq/demo/b7e2/ (dados públicos são visíveis para todos).
Opção 2: Node-RED como bridge
Se a planta já roda Node-RED, talvez você nem precise de um segundo processo de broker. Um fluxo com dois nós de configuração MQTT funciona como bridge e oferece um lugar para filtrar, renomear e transformar mensagens.
- Adicione um nó
mqtt inusando uma configuração de broker para o broker local (por exemplo192.168.10.5:1883) assinandoplant/#com QoS 1. - Adicione um nó
functionpara remapear os tópicos e descartar tudo o que você não quer exportar. - Adicione um nó
mqtt outusando uma segunda configuração de broker: servidorbroker.connectmq.com, porta 8883, "Use TLS" ativado, com o usuário, a senha e o client ID do portal.
// Nó function: remapeia tópicos locais para o namespace da nuvem
const LOCAL_PREFIX = "plant/";
const REMOTE_PREFIX = "acme/izmir/";
if (!msg.topic.startsWith(LOCAL_PREFIX)) {
return null; // ignora tópicos inesperados
}
// Filtro de exemplo: não exporta sinais brutos de depuração
if (msg.topic.includes("/debug/")) {
return null;
}
msg.topic = REMOTE_PREFIX + msg.topic.slice(LOCAL_PREFIX.length);
msg.qos = 1;
return msg;
Para os comandos que descem, adicione um caminho espelhado: mqtt in na configuração da nuvem assinando acme/izmir/cmd/#, um nó function que reescreve o prefixo para cmd/ e um mqtt out para o broker local. O tutorial de MQTT com Node-RED aborda em detalhes os nós de configuração e as opções de TLS, e a documentação oficial do Node-RED lista todas as opções dos nós MQTT.
A contrapartida: o Node-RED não faz buffer em disco como um broker. Se o uplink cair, as mensagens que passam pelo fluxo se perdem, a menos que você adicione sua própria fila. O Mosquitto é a melhor escolha quando você precisa de store-and-forward; o Node-RED vence quando você precisa de lógica.
Evitando loops de mensagens
Bridges bidirecionais podem criar loops: uma mensagem sobe, corresponde à regra de descida, volta e sobe de novo. Regras que mantêm você seguro:
- Use árvores de tópicos disjuntas para cada direção, como acima (
plant/sai,cmd/entra). - Nunca faça bridge de
#nas duas direções com os mesmos prefixos. - Em configurações MQTT 5, a opção de assinatura No Local impede que um cliente receba as próprias publicações, o que ajuda quando o bridge assina e publica na mesma conexão.
- Teste com uma única mensagem e observe os dois lados antes de liberar o tráfego de produção.
Checklist de solução de problemas
| Sintoma | Causa provável | Solução |
|---|---|---|
| CONNACK not authorized | Credenciais ou client ID errados | Copie os três valores do portal |
| Erro de TLS ao conectar | Repositório de CAs ausente ou caminho errado | Instale ca-certificates e verifique bridge_capath |
| Bridge conecta e cai | Client ID duplicado usado em outro lugar | Dê a cada cliente seu próprio conjunto de credenciais |
| Tópicos aparecem sem prefixo | Prefixos invertidos na linha topic | A ordem é prefixo local, depois prefixo remoto |
| Lacunas de dados após interrupção | Fila pequena demais ou QoS 0 | Use QoS 1 e aumente max_queued_messages |
| Mensagens ecoam sem parar | Regras in/out sobrepostas | Separe as árvores por direção |
Escolhendo um endpoint na nuvem para seus bridges
O lado da nuvem deve ser monótono: sempre no ar, com TLS por padrão e capaz de aceitar uma conexão upstream por planta, além dos seus painéis e serviços. Um broker MQTT gerenciado elimina o trabalho de patches e certificados, e o guia de broker MQTT na nuvem analisa os prós e contras de hospedagem. Se esses blocos de construção ainda são novos para você, o tutorial de MQTT para iniciantes e o modelo publish/subscribe são bons complementos para este artigo.
Conecte suas plantas ao ConnectMQ
Crie um broker Serverless gratuito em app.connectmq.com, sem cartão de crédito, e cole o usuário, a senha e o client ID gerados no seu bridge do Mosquitto ou no nó de configuração do Node-RED. O explorador de tópicos ao vivo do ConnectMQ mostra os tópicos do bridge chegando em tempo real, para que você confirme o mapeamento antes de conectar mais plantas.
Perguntas frequentes
O ConnectMQ tem um bridge embutido?
Não. Você faz o bridge para dentro dele executando Mosquitto, Node-RED ou outro cliente MQTT na borda, que se conecta ao broker como um cliente comum via TLS.
Posso fazer bridge de recursos do MQTT 5, como user properties?
Defina bridge_protocol_version mqttv50 no Mosquitto para fazer bridge com MQTT 5. Confirme que os dois brokers suportam MQTT 5 e teste se as propriedades das quais você depende são encaminhadas.
Quantas conexões um bridge usa?
Um bridge do Mosquitto usa uma conexão com o broker remoto, independentemente de quantos dispositivos locais publiquem por meio dele. Um bridge em Node-RED usa uma conexão por nó de configuração de broker.
O que acontece com os dados quando o link de internet cai?
Um bridge do Mosquitto enfileira as mensagens localmente até o limite de max_queued_messages e as encaminha quando o link volta. Fluxos Node-RED simples não fazem buffer, a menos que você o adicione.
