MQTT é um protocolo de mensagens leve que permite que os dispositivos enviem mensagens pequenas através de um servidor central, chamado broker, em vez de se comunicarem diretamente entre si. Um dispositivo publica uma mensagem com uma etiqueta chamada tópico, e cada programa inscrito nesse tópico recebe uma cópia. É por isso que se encontra MQTT em sensores, gateways industriais, hubs Zigbee e sistemas de edifícios.

Andy Stanford-Clark, da IBM, e Arlen Nipper, na época na Arcom Control Systems, criaram o protocolo em 1999 para monitorar oleodutos através de conexões por satélite lentas e caras. Essa origem continua a explicar grande parte do seu funcionamento, desde os pacotes minúsculos à possibilidade de um dispositivo deixar preparado um aviso dsua própria desconexão.

O essencial

  • O MQTT funciona por publicação/assinatura: os dispositivos publicam mensagens em tópicos em um broker, que encaminha cada mensagem para todos os assinantes correspondentes.
  • Quem publica e quem assina não precisam se conhecer. É possível acrescentar um dashboard, uma banco de dados ou um serviço de alertas mais tarde sem alterar o dispositivo.
  • Três níveis de QoS permitem equilibrar largura de banda e garantias de entrega, e a mensagem de última vontade avisa quando um dispositivo perde a conexão.
  • O Sparkplug acrescenta ao MQTT uma estrutura comum de tópicos, um formato de dados e o acompanhamento do estado online/offline para sistemas industriais.

Para que serve o MQTT?

O MQTT é usado quando muitos dispositivos comunicam pequenas quantidades de dados com frequência e algum sistema precisa reagir. Exemplos típicos são uma sonda de temperatura em uma câmara frigorífica que envia uma leitura por minuto, um controlador de bomba que comunica se está funcionando ou um hub Zigbee que encaminha eventos de portas e movimento. A mesma conexão funciona no sentido inverso: uma aplicação pode enviar uma ordem a um dispositivo, como comutar um relé ou alterar um valor de referência.

Três características explicam sua adequação. A primeira é a reduzida quantidade de dados adicionais: o cabeçalho fixo de um pacote MQTT pode ter apenas dois bytes, enquanto um pedido HTTP costuma incluir algumas centenas de bytes de cabeçalhos antes da própria leitura. Quando um dispositivo envia um número a cada poucos segundos, essa diferença acumula-se.

A conexão também permanece aberta. Como foi o dispositivo a iniciá-la para o exterior, o broker pode enviar-lhe mensagens mesmo que esteja atrás de uma firewall ou em uma rede móvel que bloqueie pedidos de entrada.

Além disso, o emissor e os destinatários são independentes. Um sensor que publica em um tópico não sabe se há um programa ou vinte a escutá-lo. Assim, acrescentar um dashboard ou um serviço de alertas um ano depois não exige alterações ao firmware do sensor.

Muitos equipamentos que interessa acompanhar não usam MQTT de origem. Medidores de energia e inversores usam frequentemente Modbus, controladores de edifícios usam BACnet, máquinas industriais disponibilizam OPC UA e muitos sensores sem fio de edifícios usam Zigbee. A solução habitual é um gateway instalado no local que lê o protocolo original e publica os valores como mensagens MQTT. Pode ser um equipamento industrial da Advantech ou da Moxa, um pequeno computador com Node-RED ou um hub Zigbee2MQTT que publica em JSON os dados de cada dispositivo Zigbee. A partir daí, o resto do sistema só precisa compreender um protocolo.

O MQTT não é a resposta para todas as situações. O HTTP é muitas vezes mais simples para trocas ocasionais de pedido e resposta, como um dispositivo que envia um relatório por dia ou uma aplicação que obtém um arquivo de configuração. Um sensor a bateria concebido para durar anos normalmente não pode manter uma conexão TCP aberta. Por isso, costuma usar uma conexão de rádio de baixo consumo, como LoRaWAN, e chegar ao resto do sistema através de um gateway. A transmissão contínua de vídeo e a transferência de arquivos grandes também pertencem a outros protocolos.

O que é um servidor MQTT?

Um servidor MQTT é o programa ao qual todos os dispositivos e aplicações se conectam. É habitualmente chamado broker porque não fornece páginas como um servidor web. Recebe cada mensagem, consulta o respectivo tópico e entrega uma cópia a cada cliente com uma assinatura correspondente. Entre os brokers conhecidos estão o Eclipse Mosquitto, de código aberto, o EMQX e o HiveMQ, além de serviços em nuvem como o AWS IoT Core.

Os tópicos são cadeias de texto divididas em níveis por barras, à semelhança de um caminho de arquivo. Um sensor de câmara frigorífica pode publicar em plant1/coldroom3/temperature, e um contato de porta em plant1/dock2/door. Ninguém precisa criar o tópico antecipadamente: ele existe assim que alguém publica nele. É por isso que as equipes definem desde o início uma estrutura de tópicos. O broker aceita qualquer grafia, e um erro de digitação passa simplesmente a ser um tópico novo que ninguém escuta.

Os assinantes podem usar dois curingas. O sinal mais corresponde exatamente a um nível: plant1/+/temperature recebe as temperaturas de todas as salas da unidade 1. O sinal de cerquilha corresponde a tudo o que está abaixo de um nível: plant1/# recebe todas as mensagens dessa unidade. Esses caracteres só funcionam nas assinaturas; quem publica indica sempre um tópico exato.

O broker nunca analisa o conteúdo da mensagem. O payload é apenas uma sequência de bytes: um número, um objeto JSON como {"temperature": 4.2, "battery": 87} ou um formato binário. Cada assinante precisa saber interpretá-lo. É esse o problema que o Sparkplug resolve nos sistemas industriais.

Duas outras funções do broker influenciam o comportamento do sistema. Quando uma mensagem é publicada com a opção retain, o broker guarda-a como mensagem retida desse tópico, uma por tópico, e entrega-a imediatamente a cada novo assinante. Assim, um dashboard que acabou de ser aberto mostra a posição atual de uma válvula sem esperar pela próxima atualização. Uma sessão persistente permite ao broker recordar as assinaturas de um cliente enquanto está offline e colocar em fila as mensagens QoS 1 e QoS 2 até se reconectar. A inclusão de mensagens QoS 0 nessa fila depende do broker.

Você pode gerenciar seu próprio broker ou usar um serviço gerenciado por terceiros: a conexão de dispositivos MQTT ao Kilo funciona em ambos os casos. Com Cloud MQTT, o Kilo disponibiliza um broker com um endereço de conexão e credenciais próprios para cada conector. Aceita apenas conexões MQTTS criptografadas na porta 1884. Com External MQTT, o Kilo se conecta a um broker que já utiliza, como Mosquitto, HiveMQ ou AWS IoT Core. Nos dois casos, decide como associar cada mensagem ao dispositivo: através de um padrão de tópico ou de um identificador do dispositivo incluído no JSON.

O que é um cliente MQTT?

Um cliente MQTT é qualquer elemento que se conecta ao broker: um sensor, um gateway, uma aplicativo móvel, um programa que escreve em uma banco de dados ou uma plataforma em nuvem. Além do próprio broker, o protocolo não distingue papéis separados. Qualquer cliente pode publicar, assinar ou fazer ambas as coisas.

Ao se conectar, o cliente envia um identificador que precisa ser único nesse broker. Se chegar uma segunda conexão com o mesmo identificador, o broker fecha a primeira. Esta é uma razão comum para dois dispositivos se desconectarem mutuamente de forma repetida. O cliente também pode enviar um nome de usuário e uma senha ou apresentar um certificado. Indica ainda um intervalo de manutenção da conexão, por exemplo 60 segundos. Se não tiver nada para enviar nesse período, transmite um pequeno ping para o broker saber que continua presente.

Existem bibliotecas cliente, como a família Eclipse Paho, para quase todas as linguagens de programação e para pequenos microcontroladores. Um script Python e uma placa ESP32 podem, por isso, compartilhar o mesmo broker. Para diagnosticar problemas, um cliente MQTT de computador inscrito em # em um broker de teste mostra todas as mensagens à medida que chegam.

Quais são os níveis de QoS do MQTT?

A qualidade de serviço, ou QoS, é uma definição de cada mensagem que determina o esforço do emissor e do destinatário para a entregar. O MQTT tem três níveis.

  • QoS 0, no máximo uma vez. A mensagem é enviada uma vez, sem confirmação. Se a rede a perder, perde-se definitivamente, o que é aceitável para leituras frequentes.
  • QoS 1, pelo menos uma vez. O destinatário confirma cada mensagem, e o emissor volta a enviá-la, normalmente após restabelecer a conexão, se não tiver recebido confirmação. Nada se perde, mas uma mensagem pode chegar duas vezes. O destinatário precisa, por isso, tolerar duplicados.
  • QoS 2, exatamente uma vez. Uma troca em quatro passos garante que a mensagem é entregue uma única vez. É o nível que exige mais trocas de mensagens e serve situações em que um duplicado seria prejudicial, como a faturamento por evento.

A QoS aplica-se separadamente a cada percurso: do emissor ao broker e do broker a cada assinante. O assinante recebe cada mensagem no menor dos dois níveis.

Considere um sensor de depósito que publica o nível de enchimento a cada 30 segundos através de uma conexão móvel. Com QoS 0, perder ocasionalmente uma leitura não traz problemas, porque a seguinte chega 30 segundos depois. Uma ordem para fechar uma válvula é diferente: perdê-la tem consequências. É enviada com QoS 1, e o controlador trata uma segunda ordem de «fechar» sem efeitos adicionais.

O que é a mensagem de última vontade do MQTT?

A mensagem de última vontade, ou Last Will and Testament, geralmente chamada de LWT, é uma mensagem que o cliente entrega ao broker quando se conecta. Inclui um tópico, um payload e um nível de QoS. O broker guarda-a e só a publica se o cliente desaparecer sem se despedir: a rede cai, falta a energia ou o intervalo de manutenção termina sem tráfego. Se o cliente terminar a conexão corretamente, o broker descarta a mensagem de última vontade.

O padrão habitual funciona assim. Quando um gateway se conecta, publica online como mensagem retida em plant1/gateway7/status e registra uma mensagem de última vontade que publicará offline, também como mensagem retida, no mesmo tópico. Qualquer assinante desse tópico passa a conhecer o estado atual do gateway, mesmo depois de uma falha.

A especificação concede ao broker uma vez e meia o intervalo de manutenção antes de considerar desligado um cliente silencioso. Com um intervalo de 60 segundos, a mensagem de desconexão pode demorar cerca de 90 segundos a aparecer. O MQTT 5, a versão atual do protocolo, também permite definir um atraso para a mensagem de última vontade, evitando que uma breve reconexão seja anunciada como falha.

O que é MQTT Sparkplug?

O MQTT Sparkplug é uma especificação que define as regras que o MQTT deixa em aberto. O MQTT não determina como nomear tópicos, codificar um payload ou saber se uma máquina está online. Assim, dois fabricantes podem usar MQTT sem conseguirem interpretar os dados um do outro. O Sparkplug foi criado pela Cirrus Link Solutions e passou em 2019 para a Eclipse Foundation, que o mantém atualmente.

A estrutura dos tópicos é fixa: spBv1.0/<group>/<message type>/<edge node>/<device>. Os payloads usam uma codificação binária compacta baseada em Protocol Buffers, com métricas identificadas pelo nome, tipos de dados e marcas de tempo. O estado é acompanhado através de certificados de nascimento e de óbito. Quando um nó de borda fica online, publica uma mensagem de nascimento com todas as métricas que vai comunicar, incluindo o nome e o tipo de cada uma. Depois envia apenas os valores que mudaram, reduzindo o tráfego em instalações de grande dimensão. O certificado de óbito do nó é registrado como sua mensagem de última vontade MQTT. Se o nó perder a conexão, o broker informa todos os assinantes sem que tenham de perguntar.

O «B» de Sparkplug B refere-se à versão do formato do payload que está em utilização hoje. É sobretudo encontrado em fábricas e sistemas SCADA, onde equipamentos de vários fabricantes compartilham um broker.

Perguntas frequentes sobre MQTT

Que porta utiliza o MQTT?

O MQTT sem criptografia utiliza a porta TCP 1883, e o MQTT sobre TLS utiliza a porta 8883. Ambas estão registradas na IANA para MQTT. Um broker também pode ser configurado para escutar em outra porta.

O MQTT utiliza TCP ou UDP?

O MQTT normal funciona sobre TCP, porque depende de uma conexão bidirecional confiável que mantém a ordem dos dados. Também pode funcionar sobre WebSockets, permitindo que uma página no navegador atue como cliente MQTT. Existe uma variante separada, MQTT-SN, para UDP e redes de sensores que não transportam TCP.

O MQTT é seguro?

O MQTT não criptografa nada por si só, por isso a segurança depende da configuração do broker. As medidas habituais são criptografar a conexão com TLS, atribuir credenciais ou um certificado cliente a cada dispositivo e limitar os tópicos em que cada cliente pode publicar ou assinar. Um broker que aceite conexões anônimas e não criptografadas a partir da Internet permite que qualquer pessoa que consiga acessá-lo leia todas as mensagens e publique comandos.

Qual é a diferença entre MQTT 3.1.1 e MQTT 5?

O MQTT 3.1.1 tornou-se uma norma OASIS em 2014 e foi posteriormente publicado como ISO/IEC 20922. O MQTT 5 surgiu em 2019 e acrescenta códigos de motivo nas confirmações, expiração de mensagens e sessões, assinaturas compartilhadas que distribuem as mensagens de um tópico por vários clientes, propriedades do usuário e aliases de tópicos. Muitos brokers suportam ambas as versões, e cada cliente escolhe a sua quando se conecta.

Crie um conector Cloud MQTT em uma conta gratuita Kilo, publique uma leitura JSON por TLS a partir de qualquer cliente MQTT para o endereço indicado e registre um dispositivo para esse tópico. A aba Mapping do dispositivo passa a listar todos os campos enviados com o respectivo valor atual. O JSON aninhado é convertido em chaves como sensor.temperature, e pode escolher os campos que passam a ser métricas. Um dispositivo de teste deixa espaço no plano gratuito para mais quatro, assim que o primeiro estiver transmitindo corretamente.