Pergunte a um vendedor de PLC sobre MQTT e você receberá um roteiro: "ano que vem, talvez, no modelo premium." Então você olha a letra miúda e encontra um gateway, um conversor ou uma assinatura na nuvem escondidos atrás do recurso. O suporte MQTT nas CPUs Ethernet xLogic não tem nada disso — está no firmware desde a revisão 1.04, e publica diretamente do controlador.
Isso muda o que uma máquina de orçamento pode fazer, e a maioria dos integradores não percebeu.
Por que MQTT para umMicro PLC
MQTT foi construído exatamente para essa situação: um dispositivo em uma rede não confiável, publicando pequenas mensagens para um broker, com assinantes que vão e vêm. Uma máquina em uma fábrica, uma estação de bombeamento em um campo, uma estufa a duas horas do escritório — cada uma publica seu status; o painel na nuvem, o aplicativo do telefone e o laptop do engenheiro todos assinam o mesmo tópico. Sem polling, sem portas abertas na planta, sem servidor SCADA cuidando da conexão.
O broker lida com o caos. O PLC apenas publica.
O Que Você Realmente Configura
Os blocos de conexão vivem no programa: defina o endereço do broker, o tópico, o intervalo de publicação e mapeie quais valores vão na carga útil. A CPU gerencia o ciclo de vida da conexão — reconectar após uma queda, republicar após uma lacuna — que é a parte que mata implementações feitas à mão.
Combine isso com o servidor web e o SMS de alarme e você terá três canais remotos independentes em um controlador. Painel na nuvem para o escritório, página do navegador para o operador, SMS para o engenheiro de plantão. Escolha seu canal por público.
Caso Real: Monitoramento Remoto de Estufa
Uma viveiro com quatro baias queria visibilidade na nuvem sem reconstruir a rede do site. Cada controlador de baia publicava temperatura, umidade e status da válvula para um broker em um VPS alugado; um painel simples assinou e mostrou todas as quatro baias em uma tela. Quando a internet caiu por uma tarde, os controladores continuaram publicando em uma fila local e os valores foram recuperados na reconexão.
O resumo do cultivador, traduzido de forma entusiástica: "Eu assisti ao gráfico de temperatura do meu telefone enquanto estava de férias. Foi melhor do que estar lá."
Onde MQTT É a Resposta Errada
Seja honesto sobre os limites. MQTT é orientado a eventos e telemetria — não é um loop de controle determinístico. Se você precisa de entrega garantida e resposta em milissegundos, use Modbus TCP localmente. MQTT é para supervisão e relatórios, não para intertravamento de segurança. Projete-o dessa forma e ele servirá você por anos.
E mantenha as credenciais do broker em ordem. Um PLC que publica em um tópico público é um PLC divulgando seus negócios. Tópicos privados, um broker local ou, no mínimo, TLS no broker — o custo de configuração é de minutos, e a vergonha evitada é real.
O Padrão Que Vale a Pena Roubar
Design de Tópicos que Escalam
MQTT é tão limpo quanto sua estrutura de tópicos, e a estrutura de tópicos é onde pequenos projetos silenciosamente se tornam inadministráveis. A abordagem ingênua — um tópico por dispositivo, uma carga útil com tudo dentro — funciona para uma máquina e colapsa em dez. Cada assinante reanalisa cada carga útil, cada mudança na carga útil quebra cada painel, e a depuração se torna uma busca tópico por tópico.
Projete a hierarquia antes da primeira publicação. Um padrão que me serviu bem:site/dispositivo/categoria/valor. Entãoplant1/pump1/status/run, plant1/pump1/sensor/level, plant1/pump2/alarm/high-level. Os assinantes curinga — um painel para planta1, uma página para bomba1, um ouvinte de alarme para tudo — cada um assina exatamente a fatia que precisa. Novos dispositivos se encaixam sem tocar nos tópicos antigos, e as cargas úteis permanecem pequenas e tipadas.
Mantenha as cargas úteis simples: um valor e um timestamp. Sem blobs JSON aninhados contendo onze campos, a menos que você realmente precise deles. Cargas úteis simples são depuráveis — você pode ler uma no console do broker e saber imediatamente se está correta. E defina a flag de retenção nos tópicos de status para que um novo assinante veja instantaneamente o último estado conhecido em vez de esperar pela próxima publicação. O estado retido é a diferença entre um painel que se abre pronto e um que fica olhando em branco por minutos.
A última regra é a que as pessoas resistem: versionar o tópico quando o formato da carga útil muda.plant1/pump1/status/v2. É feio. Isso evita que você quebre cinco assinantes em produção com uma mudança. Tópicos feios que funcionam vencem tópicos limpos que explodem.
Os Dados que Valem a Pena Publicar
Publicar tudo é tão ruim quanto publicar nada — isso inunda o broker, incha o log e enterra os valores que importam. Comece pela pergunta que o assinante fará, não pela lista de registros. Um operador quer status, alarmes e os totais acumulados. Um engenheiro quer tendências: temperatura, pressão, horas de funcionamento. Um gerente quer tempo de atividade e contagens. Publique esses, e somente esses.
As taxas também importam. Transições de alarme: publique imediatamente, sempre. Status: na mudança mais um heartbeat. Valores analógicos: no intervalo que realmente mostra o processo — dez segundos para uma temperatura de estufa lenta, um segundo para uma máquina-ferramenta. Cada tópico rápido que você não precisa é carga desperdiçada no broker e dados SIM desperdiçados nos modelos sem fio.
E registre os importantes localmente também. A gravação de dados da CPU mais as mensagens retidas do broker lhe dá duas cópias da história crítica. Quando o broker tem um dia ruim — todos têm — o log do lado da máquina é a fonte da verdade, e a conversa de recuperação é curta.
Controle local na CPU, visibilidade na nuvem via MQTT, e os dois nunca se interferem. Essa separação é a arquitetura da automação moderna em pequena escala, e se encaixa em um trilho DIN. O roteiro do vendedor não chegou. O firmware já foi enviado.
