Demandez à un vendeur de PLC à propos de MQTT et vous obtenez une feuille de route : "l'année prochaine, peut-être, sur le modèle premium." Ensuite, vous regardez les petites lignes et trouvez une passerelle, un convertisseur, ou un abonnement cloud caché derrière la fonctionnalité. Le support MQTT sur les CPU Ethernet xLogic n'a rien de tout cela - il est présent dans le firmware depuis la révision 1.04, et il publie directement depuis le contrôleur.
Cela change ce qu'une machine à budget peut faire, et la plupart des intégrateurs ne l'ont pas remarqué.
Pourquoi MQTT pour unMicro PLC
MQTT est conçu pour exactement cette situation : un appareil sur un réseau peu fiable, publiant de petits messages à un courtier, avec des abonnés qui vont et viennent. Une machine dans une usine, une station de pompage dans un champ, une serre à deux heures du bureau - chacune publie son statut ; le tableau de bord cloud, l'application téléphonique et l'ordinateur portable de l'ingénieur s'abonnent tous au même sujet. Pas de sondage, pas de ports ouverts dans l'usine, pas de serveur SCADA surveillant la connexion.
Le courtier gère le chaos. Le PLC se contente de publier.
Ce que vous configurez réellement
Les blocs de connexion vivent dans le programme : définissez l'adresse du courtier, le sujet, l'intervalle de publication, et mappez quelles valeurs vont dans la charge utile. Le CPU gère le cycle de vie de la connexion - reconnectez après une coupure, republiez après un écart - ce qui est la partie qui tue les implémentations faites à la main.
Associez-le au serveur web et à l'alarme SMS et vous avez trois canaux distants indépendants sur un seul contrôleur. Tableau de bord cloud pour le bureau, page navigateur pour l'opérateur, SMS pour l'ingénieur de service. Choisissez votre canal par audience.
Cas réel : surveillance à distance de serre
Une pépinière avec quatre baies voulait une visibilité cloud sans reconstruire le réseau du site. Chaque contrôleur de baie publiait la température, l'humidité et l'état de la vanne à un courtier sur un VPS loué ; un tableau de bord simple s'abonnait et affichait les quatre baies sur un seul écran. Lorsque l'internet est tombé en panne pendant un après-midi, les contrôleurs ont continué à publier dans une file d'attente locale et les valeurs ont été mises à jour lors de la reconnexion.
Le résumé du cultivateur, traduit de manière enthousiaste : "J'ai regardé le graphique de température depuis mon téléphone pendant mes vacances. C'était mieux que d'y être."
Où MQTT est la mauvaise réponse
Soyez honnête sur les limites. MQTT est orienté événements et télémétrie - ce n'est pas une boucle de contrôle déterministe. Si vous avez besoin d'une livraison garantie et d'une réponse en millisecondes, utilisez Modbus TCP localement. MQTT est pour la supervision et le reporting, pas pour le verrouillage de sécurité. Concevez-le de cette manière et il vous servira pendant des années.
Et gardez les identifiants du courtier en ordre. Un PLC qui publie sur un sujet public est un PLC qui diffuse ses affaires. Sujets privés, un courtier local, ou au minimum TLS sur le courtier - le coût de configuration est de quelques minutes, et l'embarras évité est réel.
Le modèle qui vaut la peine d'être volé
Conception de sujet évolutive
MQTT est aussi propre que votre structure de sujet, et la structure de sujet est là où les petits projets deviennent silencieusement ingérables. L'approche naïve - un sujet par appareil, une charge utile avec tout dedans - fonctionne pour une machine et s'effondre à dix. Chaque abonné re-parse chaque charge utile, chaque changement de la charge utile casse chaque tableau de bord, et le débogage devient une chasse sujet par sujet.
Concevez la hiérarchie avant la première publication. Un modèle qui m'a bien servi :site/appareil/catégorie/valeur. Doncplant1/pump1/status/run, plant1/pump1/sensor/level, plant1/pump2/alarm/high-level. Les abonnés par joker - un tableau de bord pour plant1, une page pour pump1, un écouteur d'alarme pour tout - s'abonnent chacun exactement à la tranche dont ils ont besoin. De nouveaux appareils s'insèrent sans toucher aux anciens sujets, et les charges utiles restent petites et typées.
Gardez les charges utiles simples : une valeur et un horodatage. Pas de blobs JSON imbriqués contenant onze champs à moins que vous ne les ayez vraiment besoin. Les charges utiles simples sont débogables - vous pouvez en lire une dans la console du courtier et savoir immédiatement si elle est correcte. Et définissez le drapeau de conservation sur les sujets de statut afin qu'un nouvel abonné voie instantanément le dernier état connu au lieu d'attendre la prochaine publication. L'état conservé est la différence entre un tableau de bord qui s'ouvre prêt et un qui reste vide pendant des minutes.
La dernière règle est celle que les gens résistent : versionnez le sujet lorsque le format de la charge utile change.plant1/pump1/status/v2. C'est moche. Cela vous évite de casser cinq abonnés en production avec un seul changement. Des sujets moches qui fonctionnent battent des sujets propres qui explosent.
Les données qui valent la peine d'être publiées
Publier tout est aussi mauvais que de ne rien publier - cela inonde le courtier, gonfle le journal, et enterre les valeurs qui comptent. Commencez par la question que l'abonné posera, pas par la liste des registres. Un opérateur veut le statut, les alarmes et les totaux en cours. Un ingénieur veut des tendances : température, pression, heures de fonctionnement. Un manager veut le temps de fonctionnement et les comptes. Publiez ceux-là, et seulement ceux-là.
Les taux comptent aussi. Transitions d'alarme : publiez immédiatement, toujours. Statut : sur changement plus un battement de cœur. Valeurs analogiques : à l'intervalle qui montre réellement le processus - dix secondes pour une température de serre lente, une seconde pour un outil de machine. Chaque sujet rapide dont vous n'avez pas besoin est une charge inutile pour le courtier et des données SIM gaspillées sur les modèles sans fil.
Et enregistrez les importants localement aussi. La journalisation de données du CPU plus les messages conservés du courtier vous donne deux copies de l'historique critique. Lorsque le courtier a une mauvaise journée - ils en ont tous - le journal côté machine est la source de vérité, et la conversation de récupération est courte.
Contrôle local sur le CPU, visibilité cloud via MQTT, et les deux n'interfèrent jamais. Cette séparation est l'architecture de l'automatisation moderne à petite échelle, et elle s'adapte sur un rail DIN. La feuille de route du vendeur n'est pas arrivée. Le firmware a déjà été expédié.
