---
categoria: Automação
tempo_medio: 10-15 min
nivel_tecnico: Intermediário
---

# QoS no MQTT

## Objetivo

Orientar técnicos e operadores a escolher garantia de entrega adequada, com foco em automação aplicada, bancada, campo, diagnóstico e documentação.

---

## Conceito

QoS no MQTT é um tema importante em automação porque interfere diretamente na leitura de sinais, no acionamento de cargas, na estabilidade do sistema e na segurança operacional.

O conteúdo deve ser usado como referência prática para montagem, validação, manutenção e investigação de falhas.

---

## Onde se aplica

Aplica-se a telemetria, sensores IoT, ESP32, Node-RED, Zabbix, automação distribuída, integração entre sistemas e monitoramento operacional.

Também é útil em testes de bancada, comissionamento, manutenção preventiva, atendimento corretivo e documentação de projetos.

---

## Funcionamento

MQTT usa clientes conectados a um broker. Os clientes publicam e assinam tópicos, e o broker distribui as mensagens conforme sessão, QoS e permissões.

Na prática, o funcionamento deve ser confirmado por medições, logs, observação do sinal e comparação com o comportamento esperado do projeto.

---

## Parâmetros importantes

Pontos que precisam ser observados:

- broker;
- cliente;
- tópico;
- QoS;
- retain;
- last will;
- usuário e senha;
- logs de conexão;
- QoS 0;
- QoS 1;
- QoS 2;
- latência;
- duplicidade;

Esses parâmetros devem ser registrados quando houver falha, alteração ou entrega técnica.

---

## Ligações e cuidados elétricos

Cuidados antes de energizar:

- validar alimentação do dispositivo antes de investigar MQTT;
- confirmar rede, GND e sensores conectados quando o cliente for embarcado;
- separar falha elétrica de falha de comunicação;
- registrar IP, RSSI e fonte usada no teste;

Grande parte das falhas em automação vem de ligação incorreta, fonte subdimensionada ou ausência de referência comum.

---

## Procedimento prático

Sequência recomendada:

- confirmar broker online;
- testar publish e subscribe com cliente conhecido;
- validar usuário, senha e ACL;
- verificar tópico e payload;
- registrar logs do cliente e do broker;

Ao final, valide o comportamento real do sistema e registre o resultado.

---

## Evidências obrigatórias

Quando houver diagnóstico ou entrega, colete:

- log do broker;
- print do publish/subscribe;
- tópico usado;
- payload recebido;
- IP do cliente;
- timestamp da falha;

Essas evidências ajudam a separar falha elétrica, erro de código, problema de comunicação e defeito físico.

---

## Falhas comuns

Sintomas e causas frequentes:

- broker inacessível;
- tópico escrito errado;
- credencial inválida;
- QoS mal escolhido;
- retain causando leitura antiga;
- cliente reconectando por Wi-Fi instável;

Evite trocar módulos sem antes medir alimentação, sinal e continuidade do caminho.

---

## Diagnóstico em campo ou bancada

Primeiro prove que o broker responde. Depois teste um cliente simples. Se funcionar, investigue firmware, rede, tópico e autenticação do dispositivo real.

Escalone quando houver risco elétrico, falha de segurança, equipamento crítico parado, divergência entre diagrama e instalação ou necessidade de alteração fora da permissão do técnico.

---

## Boas práticas

Recomendações:

- padronizar tópicos;
- usar autenticação;
- registrar logs;
- evitar payload ambíguo;
- documentar QoS e retain usados;

Projetos bem documentados reduzem tempo de manutenção e facilitam continuidade por outra pessoa da equipe.

---

## Documentos relacionados

- [12 - MQTT com ESP32](../ESP32/12 - MQTT com ESP32.md)
- [17 - Diagnóstico de Projetos ESP32](../ESP32/17 - Diagnóstico de Projetos ESP32.md)
- [17 - Diagnóstico de Sensores em Campo](../Sensores/17 - Diagnóstico de Sensores em Campo.md)
- [17 - Logs e Diagnóstico](../../Telecom/Mikrotik/17 - Logs e Diagnóstico.md)

---

## Resumo

QoS no MQTT deve ser tratado com método: validar alimentação, conferir ligações, testar sinais, analisar logs quando existirem e documentar evidências. Isso torna a automação mais confiável e fácil de manter.