Monitr Managed — logotipoMonitr Managed
Voltar
Automação Industrial

MQTT explicado para engenheiros: tópicos, QoS, retenção e last will

Rodrigo5 min de leitura
Facebook X LinkedIn WhatsApp E-mail

O MQTT é um protocolo leve de publicação/assinatura (pub/sub) ideal para telemetria industrial. Seu design minimiza overhead de rede e CPU, oferecendo entrega confiável e flexível por meio de topics, QoS, retained messages e Last Will & Testament (LWT). Este artigo destrincha esses elementos com foco prático para quem projeta integrações entre PLCs/gateways e nuvem.

1) Tópicos: a espinha dorsal do MQTT

Um tópico é uma string hierárquica que representa o “endereço lógico” da informação. É comum adotar um padrão consistente desde o primeiro dia para prevenir caos à medida que o projeto cresce.

1.1 Padrão recomendado

org/<site>/<area>/<equipamento>/<variavel>

Exemplos:

  • org/acme/plantaA/linha1/bomba03/state
  • org/acme/plantaA/linha1/tanque01/level_m
  • org/acme/plantaA/eletrica/medidor02/power_kw

Boas práticas: usar snake_case para variáveis, evitar acentos no caminho do tópico e não incluir metadados (unidade, limites) no payload o tempo todo; prefira um catálogo separado.

1.2 Curingas (+ e #)

  • + corresponde a exatamente um nível: org/acme/+/linha1/bomba03/state
  • # corresponde a zero ou mais níveis a partir do ponto: org/acme/#

Use curingas com parcimônia em produção; assinaturas muito amplas podem impactar desempenho e segurança.

2) Payloads: claros, compactos e versionados

Padronize um JSON enxuto com versão, timestamp e valor. Evite “inflar” cada mensagem com metadados repetidos.

{
  "v": 1,
  "ts": 1730155200000,
  "value": 3.42,
  "unit": "m",
  "q": "ok"
}

Para estados digitais/strings, mantenha a coerência:

{"v":1,"ts":1730155205000,"value":"on"}
{"v":1,"ts":1730155207000,"value":true}

3) QoS (Quality of Service): qual nível escolher?

O QoS define a garantia de entrega entre cliente e broker. Você pode usar QoS diferentes por mensagem/assinatura.

QoS Garantia Quando usar Observações
0 Entrega melhor esforço (no máximo uma vez) Métricas muito frequentes e descartáveis (e.g., amostras de alta taxa) Menor overhead; pode haver perda em redes instáveis
1 Pelo menos uma vez Estados, alarmes, leituras operacionais Compromisso mais seguro e leve para 80% dos casos
2 Exatamente uma vez Transações críticas e idempotência difícil Maior overhead; use apenas quando necessário

3.1 Estratégias práticas

  • Padrão: QoS 1 para quase tudo; QoS 0 em streams efêmeros; QoS 2 só em exceções.
  • Combine com buffer offline no gateway (store & forward) e deduplicação no consumidor.

4) Retained Messages: o último valor sempre disponível

Mensagens com a flag retained permanecem armazenadas no broker como “estado atual”. Ao se inscrever num tópico, o assinante recebe imediatamente o último valor retido, sem precisar esperar a próxima publicação.

Quando reter:

  • Estados de equipamento (on/off), setpoints, versão de configuração.
  • Valores “lentos” (e.g., nível do tanque, quando a taxa de publicação é baixa).

Cuidados:

  • Evite reter eventos transitórios (ex.: “alarme disparou agora”). Prefira um tópico separado para estado do alarme retido (ex.: alarms/overcurrent/state).
  • Para “limpar” um retido, publique o tópico com payload vazio e retained.

5) Last Will & Testament (LWT): detectando quedas

O LWT é uma mensagem que o broker publica automaticamente quando o cliente desconecta de forma inesperada. Isso permite sinalizar indisponibilidade de um gateway/PLC.

Exemplo de configuração:

// Ao conectar:
ClientID: gw-plantaA-linha1
LWT topic: org/acme/plantaA/linha1/gateway/status
LWT payload: {"v":1,"ts":1730155210000,"value":"offline"}
LWT QoS: 1
LWT retained: true

// Logo após conectar com sucesso:
Publish: org/acme/plantaA/linha1/gateway/status
Payload: {"v":1,"ts":1730155210500,"value":"online"}
QoS: 1, Retained: true

Assim, dashboards e alarmes podem refletir o status do gateway de forma confiável.

6) Padrões de tópicos para escalabilidade

Defina desde o início um esquema que acomode crescimento e multi-site:

  • Prefixo de organização: org/<org>/... ou <org>/<ambiente>/... para separar clientes/ambientes (prod, hml).
  • Subárvores por domínio: process/, electrical/, alarms/, meta/.
  • Estados vs eventos: .../state (retido) e .../events/<evento> (não retido).

Exemplos práticos:

// Estado (retido)
org/acme/plantaA/linha1/bomba03/state
{"v":1,"ts":1730155220000,"value":"on"}

// Evento (não retido)
org/acme/plantaA/linha1/bomba03/events/overcurrent
{"v":1,"ts":1730155223000,"value":true}

7) Segurança (essencial e objetiva)

  • TLS sempre que possível; certificados válidos ou CA interna.
  • Autenticação por usuário/senha ou certificados; ACL por tópico (quem publica/assina o quê).
  • Separe redes OT/IT; evite expor brokers diretamente à internet.
  • Monitore métricas do broker: conexões, taxa de mensagens, fila de inflight, erros.

8) Checklist de implementação

  1. Defina catálogo de tags (nome, unidade, limites, frequência).
  2. Especifique padrão de tópicos e versões de payload (v1, v2).
  3. Escolha QoS por tipo de dado (padrão QoS 1; QoS 0 em streams efêmeros; QoS 2 apenas se indispensável).
  4. Habilite mensagens retidas para estados relevantes (gateway online/offline, setpoints, estados de equipamentos).
  5. Configure LWT para cada gateway/PLC com tópico de status retido.
  6. Implemente store & forward no edge e deduplicação no consumidor.
  7. Crie políticas de retenção/compactação no armazenamento (bruto curto prazo, agregados longo prazo).
  8. Teste cenários de falha: queda de rede, reinício de gateway, perda de energia.

9) Erros comuns e como evitar

  • Tópicos sem padrão → difícil filtrar/ACL. Corrija com convenções documentadas e lint de tópicos no gateway.
  • QoS 2 em tudo → overhead desnecessário. Prefira QoS 1; otimize idempotência na aplicação.
  • Retidos em eventos transitórios → painéis “congelam” alertas. Separe estado (retido) de evento (não retido).
  • Sem LWT → cegueira operacional sobre disponibilidade de gateways.
  • Payloads verborrágicos → custos e latência maiores. Use JSON compacto e catálogo de metadados.

10) Exemplo completo de publicação com QoS e retido

// Tópico de estado (retido), QoS 1
org/acme/plantaA/linha1/tanque01/level_m
{"v":1,"ts":1730155230000,"value":3.58,"unit":"m"}

// Tópico de evento (não retido), QoS 1
org/acme/plantaA/linha1/tanque01/events/low_level
{"v":1,"ts":1730155232000,"value":true}

// Status do gateway via LWT (retido)
org/acme/plantaA/linha1/gateway/status
{"v":1,"ts":1730155234000,"value":"online"}

Conclusão: dominar tópicos, QoS, mensagens retidas e LWT é metade do caminho para uma telemetria confiável. A outra metade está em governança (catálogo de tags), segurança (TLS/ACL) e operações (buffer offline, métricas do broker). Com esses fundamentos, projetos de IoT industrial ganham previsibilidade e escala.

Veja também

MQTT explicado para engenheiros: tópicos, QoS, retenção e last will — Monitr