MQTT-SN Explicado: MQTT para Redes de Sensores

O MQTT-SN é uma variante do MQTT projetada para redes de sensores em que o TCP é pesado demais ou simplesmente não está disponível. Neste artigo você vai aprender como o MQTT-SN difere do MQTT convencional, o que são topic IDs, gateways e clientes em modo sleep, e como encaminhar dispositivos MQTT-SN para um broker padrão, de modo que o restante da sua stack nem precise saber que eles existem.

O que é MQTT-SN?

MQTT-SN significa MQTT for Sensor Networks (MQTT para redes de sensores). Foi publicado originalmente por pesquisadores da IBM no fim dos anos 2000 (primeiro como MQTT-S) para levar o publish/subscribe a redes de sensores sem fio como Zigbee, em que os nós têm rádios minúsculos, baterias minúsculas e nenhuma pilha TCP/IP. A versão mais implementada é a MQTT-SN 1.2; desde então, a OASIS trabalha em um sucessor padronizado.

O objetivo do design é simples: manter o modelo de programação do MQTT (tópicos, publish, subscribe, QoS), mas eliminar tudo o que é caro em um enlace limitado. O MQTT-SN não exige um transporte orientado a conexão. Ele funciona sobre UDP e sobre redes de datagramas não IP, como Zigbee ou camadas mesh baseadas em BLE, desde que a rede consiga entregar datagramas endereçados.

A consequência importante: um cliente MQTT-SN não consegue falar diretamente com um broker MQTT comum. Ele precisa de um gateway que fale MQTT-SN de um lado e MQTT sobre TCP do outro.

MQTT-SN vs. MQTT em resumo

Topic IDs: economizando bytes em cada publicação

Um tópico como factory/izmir/hall2/line4/temperature custa dezenas de bytes em cada pacote PUBLISH. Em um enlace em que um frame inteiro pode carregar cerca de cem bytes, isso é inaceitável. O MQTT-SN substitui a string por um número de dois bytes.

Há três formas de obter um:

1. Topic IDs registrados. O cliente envia REGISTER com o nome completo do tópico; o gateway responde com REGACK contendo um ID. O cliente então publica com esse ID. Os mapeamentos valem pela duração da sessão.
2. Topic IDs predefinidos. Cliente e gateway combinam os IDs antecipadamente via configuração, então nenhum registro é necessário. Essa é a opção mais eficiente para firmware fixo.
3. Nomes de tópico curtos. Exatamente dois caracteres, como t1, transportados diretamente no campo de ID.

Quando um cliente assina com um nome de tópico completo, o gateway devolve o ID que usará ao encaminhar as mensagens correspondentes. Assinaturas com curingas são suportadas, mas o gateway precisa então registrar cada tópico concreto com o cliente antes de entregá-lo, o que acrescenta idas e voltas.

Gateways e forwarders

O gateway é o coração de toda implantação MQTT-SN. A especificação descreve dois estilos:

• Gateway transparente. Para cada cliente MQTT-SN, o gateway abre uma conexão MQTT separada com o broker. Simples e fiel à semântica por cliente, mas o broker vê tantas conexões quanto o número de sensores.
• Gateway agregador. O gateway mantém uma única conexão MQTT com o broker e multiplexa todo o tráfego dos sensores por ela. Menos conexões no broker, mais lógica no gateway.

Um forwarder é um nó ainda mais simples, que apenas encapsula mensagens MQTT-SN e as retransmite entre clientes e um gateway sem interpretá-las, útil quando os clientes estão a vários saltos de rádio de distância.

Os gateways se anunciam com mensagens ADVERTISE periódicas. Um cliente que não ouviu nenhuma pode enviar SEARCHGW em broadcast, e os gateways (ou outros clientes que conheçam um gateway) respondem com GWINFO.

Clientes em modo sleep

Sensores alimentados por bateria passam a maior parte da vida com o rádio desligado. O MQTT-SN modela isso explicitamente:

1. O cliente envia DISCONNECT com uma duração de sono e entra no estado asleep.
2. Enquanto ele dorme, o gateway armazena em buffer as mensagens destinadas a ele.
3. O cliente acorda, envia PINGREQ com seu client ID, recebe as mensagens armazenadas e obtém PINGRESP quando o buffer fica vazio.
4. Ele volta a dormir.

O MQTT comum não tem nada equivalente: um dispositivo que perde a conexão TCP simplesmente fica offline, e apenas sessões persistentes no broker conseguem guardar mensagens para ele.

QoS -1: publicar sem conexão

O MQTT-SN acrescenta um nível às vezes escrito como QoS -1 (ou QoS 3 em rascunhos posteriores). Um cliente pode enviar um PUBLISH para o endereço de um gateway conhecido usando um topic ID predefinido ou um nome curto, sem nunca se conectar. Não há confirmação nem sessão. É ideal para beacons muito simples que apenas anunciam um valor a cada poucos minutos.

Encaminhando MQTT-SN para um broker MQTT padrão

Como o gateway converte MQTT-SN em MQTT convencional, o lado da nuvem pode ser qualquer broker compatível com o padrão. Uma escolha open source comum é o Eclipse Paho MQTT-SN Gateway (do projeto paho.mqtt-sn.embedded-c), que roda em Linux, escuta MQTT-SN via UDP e se conecta a um broker upstream.

Uma configuração que aponta o gateway para um broker MQTT gerenciado como o ConnectMQ fica mais ou menos assim. Os nomes das chaves vêm do gateway.conf de exemplo do gateway; confira o README da versão que você compilar, pois as opções mudam entre releases.

# gateway.conf (Paho MQTT-SN Gateway, trecho)
GatewayID=1
GatewayName=site1-mqttsn-gw
KeepAlive=60

# Broker MQTT upstream (ConnectMQ, TLS)
BrokerName=broker.connectmq.com
BrokerPortNo=1883
BrokerSecurePortNo=8883
LoginID=YOUR_USERNAME
Password=YOUR_PASSWORD

# Uma única conexão TLS para todos os sensores
AggregatingGateway=YES
TransparentGateway=NO

# Lado MQTT-SN: listener UDP para os sensores
GatewayPortNo=10000
MulticastIP=225.1.1.1
MulticastPortNo=1883

Dois pontos de atenção específicos do ConnectMQ:

• Client IDs são vinculados às credenciais. Cada conjunto de credenciais do broker vem com seu próprio client ID, então um gateway transparente que abre uma conexão upstream por sensor precisa de um conjunto de credenciais por sensor. Um gateway agregador com uma única identidade upstream costuma ser a melhor opção.
• Cotas de conexão. O plano Serverless gratuito permite até 25 conexões e o Serverless pago até 1.000. A agregação mantém você bem dentro desses limites, mesmo com grandes campos de sensores.

Verifique o lado da nuvem

Com o gateway rodando, assine a partir de um notebook para ver os dados dos sensores chegando como MQTT comum. Durante uma prova de conceito, você pode apontar o gateway para o servidor MQTT público (gratuito), apenas com dados de teste (anônimo, porta 1883, prefixo de tópico único):

mosquitto_sub -h broker.connectmq.com -p 1883 -i mqttsn-check-4d1e \
  -t "connectmq/demo/4d1e/#" -v

Com credenciais de produção, adicione -p 8883 --capath /etc/ssl/certs -u YOUR_USERNAME -P YOUR_PASSWORD e o client ID do portal. Tudo o que vem depois (painéis, fluxos Node-RED, historiadores) consome os dados exatamente como se os sensores falassem MQTT nativamente.

Quando escolher o MQTT-SN (e quando não)

Use este checklist antes de se comprometer:

1. O dispositivo tem uma pilha IP com TCP? Se ele tem Wi-Fi ou rede celular com TCP, o MQTT comum sobre TLS é mais simples e mais bem suportado. O tutorial de MQTT com ESP32 é um bom exemplo.
2. O rádio trabalha só com datagramas? Zigbee, 6LoWPAN, enlaces brutos no estilo LoRa ou rádios sub-GHz personalizados são território natural do MQTT-SN.
3. A duração da bateria é a principal restrição? Clientes em modo sleep e topic IDs compensam quando cada byte transmitido custa energia.
4. Você consegue operar e proteger um gateway? O gateway se torna um componente crítico. Planeje monitoramento, reinicializações e suas credenciais upstream.
5. E a segurança? O MQTT-SN não tem criptografia embutida. Conte com segurança na camada de enlace ou DTLS do lado dos sensores, e TLS no trecho entre gateway e broker.
6. Disponibilidade de bibliotecas. Existem bibliotecas cliente para C e plataformas embarcadas, mas o ecossistema é bem menor que o do MQTT.

Em muitos projetos, o melhor é uma solução híbrida: os nós limitados falam MQTT-SN com um gateway local, enquanto todo o resto, inclusive o enlace upstream do gateway, fala MQTT padrão. Se você ainda está aprendendo o protocolo base, comece pelo tutorial de MQTT e pela explicação sobre se o MQTT usa TCP ou UDP.

Armadilhas comuns do MQTT-SN

• Desvio de topic IDs. IDs registrados valem por sessão. Após uma reinicialização do gateway, os clientes precisam se registrar novamente, ou vão publicar no tópico errado. IDs predefinidos evitam isso, mas precisam ser mantidos em sincronia entre o firmware e a configuração do gateway.
• Perda de pacotes UDP. QoS 0 sobre UDP pode, de fato, perder dados. Use QoS 1 para tudo o que importa e dimensione os temporizadores de retentativa de acordo com o seu rádio.
• Fragmentação. Mantenha os payloads pequenos; as mensagens MQTT-SN foram feitas para caber em um único frame de rede.
• Gateway como ponto único de falha. Se o gateway cair, os sensores não armazenam nada. Projete para reinicialização rápida e alertas.

Leve sua rede de sensores para o ConnectMQ

O gateway é seu; o broker não precisa ser. O ConnectMQ oferece ao seu gateway MQTT-SN um endpoint TLS na 8883, suporte a MQTT 3.1.1 e 5.0 e um explorador de tópicos ao vivo para confirmar que os dados estão fluindo. Crie um broker Serverless gratuito em app.connectmq.com sem cartão de crédito, copie as credenciais geradas para a configuração do gateway e seus sensores estarão na nuvem.

Perguntas frequentes

Um cliente MQTT-SN pode se conectar diretamente a um broker MQTT?

Não a um broker padrão. O MQTT-SN usa um formato de pacote e um transporte diferentes, então um gateway precisa traduzi-lo para MQTT sobre TCP para o broker.

O MQTT-SN suporta QoS 2?

Sim. O MQTT-SN 1.2 suporta QoS 0, 1 e 2, além do modo sem conexão QoS -1 para publicadores simples.

O MQTT-SN é seguro?

O protocolo em si não tem criptografia. Use segurança na camada de enlace ou DTLS entre os sensores e o gateway, e TLS entre o gateway e o broker.

Qual porta o MQTT-SN usa?

Não há uma porta única registrada; depende da configuração do gateway. Muitos exemplos usam uma porta UDP como 10000 ou reutilizam a 1883 sobre UDP.