MQTT com TLS no ESP32: telemetria, estados e comandos seguros
Guia conceitual de MQTT/TLS no ESP32 com manifesto, tópicos de telemetria, estados reais, ACK e validação de comandos IoT.
Publicado em 01/11/2026Separe os tópicos por finalidade
Em uma arquitetura IoT, telemetria, estado, evento, disponibilidade e comando são fluxos diferentes. Na referência TechRib V2, os tópicos usam o identificador autorizado do dispositivo para evitar misturar mensagens de placas distintas.
O contrato publica um manifesto de capacidades e mensagens com campos como contract, version, message_id, device_id, kind, timestamp e payload. Os exemplos da documentação não contêm credenciais de produção.
Envie inventário antes dos primeiros estados
O manifesto anuncia somente componentes efetivamente presentes. A referência documenta publicação QoS 1 com retained e confirmação PUBACK antes do envio de estados iniciais.
Isso reduz inconsistências na formação de cards do aplicativo: o backend pode validar tipo e comandos antes de aceitar um estado associado ao componente.
Estado observado não é comando aceito
O aplicativo pode solicitar uma ação, mas não deve inferir que a saída física realmente mudou. Use mensagens de confirmação de execução e depois publique o estado observado, associando IDs de correlação quando disponíveis.
Um dispositivo offline, uma falha de sensor ou uma intertravamento local precisam ser refletidos adequadamente, sem inventar leitura de temperatura ou potência.
Cuidados de segurança
Use TLS, credenciais e identidade emitidas pelo processo autorizado. Valide destinatário, idade, duplicação de message_id, tipo de comando e argumentos antes de qualquer atuação.
A segurança elétrica de motores, relés e cargas permanece no projeto físico. Uma camada MQTT não substitui fusíveis, isolamento, intertravamentos ou análise de riscos.