MQTT é um protocolo de mensagens: publicadores enviam mensagens e subscritores recebem as dos tópicos relevantes. Pode ligar um coletor industrial às aplicações. Não define como medir um sensor, qual a unidade nem quando ativar um alarme; isso pertence ao contrato de dados da aplicação.
Broker e desenho dos tópicos
O broker encaminha as mensagens aos subscritores. Os publicadores não precisam de conhecer cada recetor, mas acesso, capacidade, permissões e estado do broker tornam-se responsabilidades operacionais. Dar a todos os dispositivos publicação em qualquer tópico não é uma boa configuração inicial.
Os nomes devem refletir uma hierarquia clara. site-a/line-2/machine-7/state é ilustrativo, não um endereço real. Separe identidade estável e nome apresentado para não fragmentar o histórico ao renomear. Não coloque segredos ou dados pessoais nos tópicos.
O conteúdo pode transportar valor, unidade, hora de origem, qualidade e versão do esquema. Documente limites de dimensão e campos opcionais. Os consumidores devem interpretar coerentemente, sem adivinhar o significado dos registos.
O que QoS realmente cobre
A norma OASIS MQTT 5.0 define três níveis. A entrega refere-se ao segmento de comunicação do protocolo relevante. Não garante automaticamente uma única escrita na base de dados ou uma ação física executada uma só vez.
| Nível | Entrega no protocolo | Pergunta da aplicação |
|---|---|---|
| QoS 0 | No máximo uma vez | Esta observação pode perder-se? |
| QoS 1 | Pelo menos uma vez | Como se reconhecem repetições? |
| QoS 2 | Exatamente uma vez no segmento do protocolo | O que acontece nos serviços seguintes? |
Um subscritor pode processar e perder a confirmação da base de dados. Repetir pode repetir a operação. Identidade estável, unicidade e limites transacionais importam para além da configuração MQTT. QoS 2 não constitui uma garantia ilimitada de operação empresarial única de ponta a ponta.
Retido não significa atual
Uma mensagem retida pode dar ao novo subscritor a última mensagem guardada do tópico. Pode ser antiga. A interface verifica hora de origem e política de atualidade. Receber imediatamente após ligar não demonstra que o dispositivo esteja saudável agora.
Last Will pode sinalizar perda de ligação, mas não diagnostica toda a avaria no terreno. Um coletor ligado pode ter perdido um sensor. Distinga disponibilidade do dispositivo, saúde do coletor e ligação da aplicação.
Fluxo ilustrativo de temperatura
Um coletor conserva leituras datadas sem ligação de saída. Ao reconectar envia identidades originais. A aplicação elimina duplicados, coloca as observações tardias no histórico e não substitui o presente por um ponto antigo reenviado.
A fila é finita. Defina duração coberta, alarmes de espaço e comportamento quando o armazenamento falha. Teste reconexões simultâneas e limite o reenvio para manter utilizáveis leitura atual e consulta de campo. Esperas progressivas limitadas evitam agravar a recuperação da rede.
Perguntas iniciais
- Onde funcionará o broker e quem o opera?
- Como se gerem identidades e permissões dos tópicos?
- Que campos são obrigatórios numa mensagem válida?
- Como se testam armazenamento temporário, reenvio e duplicados?
- O que acontece ao renovar credenciais ou certificados?
MQTT não substitui modelo de dados e plano operacional. Valide um fluxo pequeno em funcionamento normal, desconexão e duplicação antes de ampliar.
Exemplo de duplicação na aplicação
Imagine a observação observation-1042. O recetor guarda-a, mas a confirmação de processamento não chega. O coletor repete com a mesma identidade e hora original. O recetor reconhece o registo existente, em vez de acrescentar outra amostra. Uma identidade nova eliminaria a evidência de que ambas as entregas representam a mesma observação.
Outro consumidor pode avaliar um alarme. O seu estado também importa: impedir medições duplicadas não impede automaticamente notificações duplicadas. Guarde a relação entre entrada, transição de alarme e tarefa de notificação. Se o fornecedor atingir o tempo limite, mantenha resultado incerto em vez de afirmar que nada foi enviado. É um exemplo de aplicação, não uma promessa adicional de MQTT.
Defina o tratamento das rejeições. Esquema desconhecido, unidade inválida e identidade impossível devem ser diagnosticáveis. Repetir indefinidamente uma mensagem permanentemente malformada consome recursos sem dados úteis. Disponibilize um processo limitado e uma vista da origem afetada. Não copie credenciais ou conteúdos sem restrição para os registos de erros por conveniência.
Teste permissões e recuperação
Teste cada identidade nos tópicos permitidos e tente aceder fora do âmbito, verificando rejeição. Teste credenciais substituídas e dispositivos retirados separadamente da reconexão normal. Uma ligação bem-sucedida diz pouco sobre os seus limites.
Interrompa a saída enquanto a recolha continua e reconecte com observações atuais e históricas. Verifique horas originais, identidades e idade mostrada. Examine o limite do armazenamento local: a condição de cheio deve ser visível mesmo após o broker regressar. Documente versão MQTT, sessões suportadas e confirmações da aplicação com a configuração real. Leve esse registo, um exemplo de mensagem e a hierarquia dos tópicos à revisão. Permitem avaliar limites de fiabilidade sem afirmar que uma escolha QoS resolve todos os problemas de entrega.