Os casos de uso do MQTT abrangem praticamente todos os setores que conectam máquinas, veículos ou edifícios a software. Este guia apresenta 15 padrões do mundo real agrupados por setor, mostrando para cada um a estrutura de tópicos, os recursos do MQTT que o fazem funcionar e a escala de broker de que precisa, para que você possa mapear seu próprio projeto em um design comprovado.
Por que o MQTT aparece em toda parte
O MQTT nasceu na telemetria industrial (a história de quem inventou o MQTT começa em um oleoduto), e as mesmas propriedades o tornam adequado para muito além disso: pacotes pequenos, entrega por push sobre uma conexão de saída, níveis de QoS por mensagem, mensagens retidas com o "último valor conhecido" e Last Will para presença. Onde quer que muitos dispositivos produzam dados que várias aplicações precisam consumir, o modelo centrado no broker se encaixa. Se o protocolo é novidade para você, comece pelo nosso tutorial de MQTT para iniciantes.
Casos de uso do MQTT na manufatura
1. Monitoramento de máquinas e OEE
Máquinas CNC, prensas e linhas de embalagem, por exemplo em uma planta em Joinville, publicam estado, contagens e alarmes por meio de gateways de CLP. Painéis, calculadoras de OEE e o gêmeo digital da linha assinam esses dados. Mensagens de estado retidas fazem com que um painel recém-aberto mostre instantaneamente o status atual de cada máquina.
Exemplo de tópico: acme/izmir/machining/line1/cnc1/status
2. Unified Namespace
Em vez de integrações ponto a ponto, cada sistema (CLPs, MES, ERP, qualidade) publica em uma única árvore de tópicos estruturada segundo o ISA-95. Os consumidores assinam os ramos de que precisam. O Sparkplug B acrescenta payloads padronizados e estado de birth/death. Veja Sparkplug B e Unified Namespace para o padrão completo.
3. Manutenção preditiva
Sensores de vibração, temperatura e corrente publicam resumos de alta frequência. Um serviço de análise separado assina, pontua os dados e publica alertas de volta no broker para os painéis de manutenção. QoS 0 é adequada para os resumos brutos; QoS 1, para os alertas.
4. Agregação multiplanta
Cada planta roda um broker local para ter autonomia e faz bridge de um conjunto selecionado de tópicos para um broker central na nuvem, para que a matriz veja todas as plantas em uma única árvore. Nosso guia de bridge MQTT mostra as configurações em Mosquitto e Node-RED.
Energia e utilities
5. Monitoramento solar e de baterias
Inversores de uma usina solar e sistemas de gerenciamento de baterias informam potência, estado de carga e falhas. Proprietários e instaladores acompanham os valores ao vivo em um aplicativo; o backend do instalador assina várias instalações usando curingas.
6. Medição inteligente e submedição
Submedidores de edifícios publicam o consumo em intervalos para faturamento de inquilinos e painéis de energia. Sessões persistentes e QoS 1 protegem as leituras durante interrupções curtas de rede.
7. Estações de recarga de veículos elétricos
Os carregadores publicam o estado da sessão e recebem comandos (iniciar, parar, limites de potência) em tópicos de comando separados. O Last Will marca um carregador como offline imediatamente quando ele sai da rede. A expiração de mensagens do MQTT 5 impede que comandos obsoletos sejam executados após uma reconexão.
Automotivo e logística
8. Rastreamento de frotas e veículos
Os veículos publicam posição GPS, velocidade e estado da ignição pela rede celular. O pequeno overhead do MQTT mantém os custos de dados baixos, e a conexão persistente permite que a central envie mensagens instantaneamente. O guia de rastreamento de veículos com MQTT aborda design de tópicos e dimensionamento de payloads.
9. Monitoramento da cadeia fria
Registradores de temperatura em caminhões e armazéns publicam leituras e alertas de limite. Mensagens retidas mostram a leitura mais recente de cada contêiner; os alertas saem no momento em que um limite é ultrapassado. Combine isso com um assinante historiador externo para que todas as leituras fiquem armazenadas para auditorias de conformidade.
10. Automação de armazéns
Esteiras, scanners e carrinhos autônomos se coordenam por meio do broker. Shared subscriptions distribuem os eventos de leitura recebidos entre vários serviços worker, de modo que a vazão escala com a adição de workers.
Casa inteligente e edifícios
11. Automação residencial
Home Assistant, Node-RED e dispositivos Zigbee ou Wi-Fi trocam estados e comandos por meio de um broker. O modelo publish/subscribe permite que um interruptor, um assistente de voz e uma regra de automação controlem a mesma lâmpada.
12. Gestão predial
Controladores de climatização, sensores de ocupação e iluminação publicam em uma árvore de tópicos por andar. Os painéis de facilities assinam com curingas, e alertas de limite sinalizam salas que saem da faixa de conforto.
Agricultura, saúde e produtos de consumo
13. Agricultura inteligente e irrigação
Sensores de umidade do solo e estações meteorológicas de uma fazenda, muitas vezes alimentados por bateria ou energia solar, publicam com pouca frequência. Os controladores de irrigação assinam os comandos. Pouca banda e tolerância a links intermitentes são exatamente o que o MQTT foi projetado para oferecer.
14. Monitoramento remoto de pacientes e equipamentos
Dispositivos correlatos à área médica e equipamentos de laboratório enviam status e leituras para aplicativos de monitoramento. TLS, credenciais únicas por dispositivo e um design de tópicos cuidadoso mantêm os dados privados. Nunca use um servidor MQTT público para nada sensível.
15. Produtos conectados e aplicativos móveis
Eletrodomésticos, wearables e gadgets de consumo usam MQTT para receber comandos de um aplicativo móvel em tempo real. Navegadores e aplicativos se conectam via WebSocket seguro, enquanto os dispositivos usam TLS na 8883.
Blocos de construção comuns entre os casos de uso do MQTT
Observando esses 15 exemplos, os mesmos recursos aparecem repetidamente:
- Tópicos hierárquicos do geral para o específico, muitas vezes seguindo o ISA-95 na indústria.
- Mensagens retidas para o estado atual.
- Last Will para um status online/offline confiável.
- QoS 0 para telemetria frequente, QoS 1 para comandos e alertas.
- Ramos separados para comandos e telemetria, para manter permissões e loops sob controle.
- Ferramentas externas como clientes (Node-RED, Telegraf, serviços em Python, Home Assistant) para armazenamento, análise e integrações.
Escolhendo um plano ConnectMQ para cada escala
Esses padrões diferem principalmente em escala e em requisitos de isolamento. Veja como eles se relacionam com os planos do ConnectMQ, com base nos limites documentados de cada plano:
| Plano | Principais limites e recursos | Adequado para casos como |
|---|---|---|
| Serverless (Free) | Cluster compartilhado, até 25 conexões, QoS 0 e 1, mensagens de 256 KB | Protótipos, automação residencial, uma única máquina ou uma pequena estufa |
| Serverless (Paid) | Até 1.000 conexões, QoS 2, mensagens de 1 MB, shared subscriptions | Frotas pequenas, redes de carregadores, monitoramento predial, workers de armazém |
| Dedicated | Cluster isolado | Unified Namespace de toda a planta, agregação multiplanta |
| BYOC | Roda na sua própria conta de nuvem, gerenciado para você | Requisitos de residência de dados ou políticas de conta de nuvem |
| Self Managed Enterprise | Você mesmo opera | Requisitos totalmente on-premises ou air-gapped |
Além de operar como um broker MQTT gerenciado, em projetos industriais o ConnectMQ também detecta tópicos ISA-95 e Unified Namespace, decodifica Sparkplug B e pode republicar dados Sparkplug B em tópicos ISA-95 legíveis. O guia de broker MQTT na nuvem compara as opções de hospedagem com mais profundidade.
Teste um caso de uso em cinco minutos
Escolha qualquer exemplo acima e simule-o no servidor MQTT público (gratuito), pensado para testes e protótipos. Aqui está o caso de monitoramento de máquinas com um status retido e um fluxo de temperatura ao vivo:
# Assinante: um "painel" observando uma linha
mosquitto_sub -h broker.connectmq.com -p 1883 -i uc-dash-3a8f \
-t "connectmq/demo/3a8f/line1/+/#" -v
# Publicador: uma "máquina" informando status retido e leituras
mosquitto_pub -h broker.connectmq.com -p 1883 -i uc-cnc-3a8f \
-t "connectmq/demo/3a8f/line1/cnc1/status" -m "RUNNING" -r -q 1
for t in 61.2 62.0 63.5; do
mosquitto_pub -h broker.connectmq.com -p 1883 -i uc-cnc-3a8f \
-t "connectmq/demo/3a8f/line1/cnc1/spindle_temp" -m "$t"
sleep 1
done
Reinicie o assinante e o status retido RUNNING aparece imediatamente. Para adaptar a demonstração a outro caso de uso, mude apenas a árvore de tópicos e os payloads: um carregador poderia publicar site4/charger2/session, uma estufa zone1/soil_moisture. O broker, os comandos e o código do cliente continuam os mesmos, e é exatamente por isso que o conhecimento em MQTT se transfere entre setores. Os dados no servidor MQTT público são visíveis para todos, então use apenas valores fictícios e nunca dados de produção.
Comece a usar o ConnectMQ
Transforme seu caso de uso em uma implantação privada e autenticada. Cadastre-se em app.connectmq.com, comece no plano Serverless gratuito sem cartão de crédito e use o painel, a visão de dispositivos e as regras de alerta por limite do portal para ver seus primeiros dispositivos ficarem online.
Perguntas frequentes
Para que o MQTT é mais usado?
Telemetria e controle entre dispositivos e software: monitoramento de máquinas, energia e rastreamento de frotas, casas e edifícios inteligentes e qualquer cenário em que muitos dispositivos enviam dados para vários consumidores.
O MQTT é adequado para controle em tempo real?
Ele é bem adequado para controle supervisório e comandos com tempos de resposta abaixo de um segundo até a ordem de segundos em boas redes. Malhas de controle em tempo real rígido devem permanecer em fieldbuses locais.
O MQTT consegue lidar com vídeo ou arquivos grandes?
O MQTT pode transportar payloads binários até o limite de tamanho de mensagem do broker, mas não foi projetado para streaming de vídeo. Envie metadados ou links via MQTT e a mídia por um serviço dedicado.
Quais recursos do MQTT mais importam em casos de uso industriais?
Tópicos hierárquicos, estado retido, Last Will, QoS 1 para eventos e convenções como Sparkplug B ou um Unified Namespace para modelos de dados consistentes.



