Protocole MQTT : guide complet, des principes de base aux applications industrielles
Une station de pompage distante peut envoyer une mesure de température à un tableau de maintenance sans donner à celui-ci un accès direct à l’automate. MQTT permet de transporter cette valeur : un client publie un message vers un broker, puis les abonnés autorisés le reçoivent sur les topics correspondants. Le protocole ne définit pas le sens de la mesure, ne lit pas tout seul un registre Modbus et ne rend pas une liaison cellulaire fiable.
Avant de choisir les paramètres MQTT, identifiez la source de chaque donnée, l’émetteur, le broker, les abonnés et la décision prise à partir du message. La spécification MQTT 5.0 décrit le comportement du protocole ; les fonctions des équipements et la sémantique de l’application doivent encore être vérifiées pour le modèle et le projet concernés.
Suivre une donnée jusqu’au broker
Supposons qu’une passerelle lise la température d’une pompe dans un registre documenté de l’automate. Elle horodate et valide la valeur, puis la publie sur site1/pump01/telemetry/temperature, et un service de supervision s’abonne à ce topic. Le guide capteurs, automates et Modbus explique pourquoi une passerelle doit connaître la carte des registres. Un routeur qui ne fait que transférer des paquets IP ne réalise pas automatiquement une conversion Modbus vers MQTT.
Définissez les topics selon le site, l’équipement, la fonction du message et son responsable. Séparez télémétrie et commandes, par exemple site1/pump01/telemetry/... et site1/pump01/command/.... Les noms de topics servent au routage ; ils ne constituent ni schéma de données ni politique d’accès. Documentez les champs du payload, les unités, la source de l’horodatage, les indicateurs de qualité et les versions. L’application destinataire doit savoir traiter une mesure absente ou périmée.
Suivre les paquets et les abonnements
L’émetteur se connecte d’abord au broker avec un identifiant de client et des paramètres négociés, puis envoie des paquets PUBLISH sur un topic. Un abonné établit sa propre connexion et transmet SUBSCRIBE avec un ou plusieurs filtres ; le broker associe les publications et les transmet selon les autorisations et le QoS demandé. Il ne produit pas la valeur de l’automate. Dans l’exemple de la pompe, relevez le registre source, la conversion du payload, l’identité du client et le topic. Si le tableau reste vide, contrôlez dans l’ordre la lecture, la publication, son acceptation par le broker et la correspondance de l’abonnement.
Concevoir ensemble filtres de topics et droits d’accès
Un topic est composé de niveaux séparés par une barre oblique. Un abonné peut utiliser + pour un niveau ou # pour les niveaux restants ; un émetteur publie sur un topic précis, sans joker. Gardez des identifiants cohérents de site et d’équipement, sans secrets dans les noms. Définissez une ACL par rôle : émetteurs de télémétrie, abonnés des tableaux et éventuels émetteurs de commandes séparés. Testez un filtre autorisé et un filtre refusé. Un abonnement large comme site/# peut exposer plus d’appareils que nécessaire.
Choisir le QoS selon les conséquences d’une perte ou d’un doublon
MQTT propose les QoS 0, 1 et 2. Au niveau 0, le message est envoyé une fois sans accusé de réception du protocole. Au niveau 1, un accusé est utilisé mais un doublon reste possible. Le niveau 2 emploie un échange en quatre étapes pour éviter une double livraison dans cet échange MQTT. Aucun niveau ne prouve que l’application finale a traité le message exactement une fois ni qu’une commande a été exécutée par l’automate.
Usage | Question de départ | Vérification applicative |
|---|---|---|
Télémétrie fréquente | L’échantillon suivant peut-il remplacer une valeur manquée ? | Détecter les lacunes et les horodatages anciens |
Alarme ou événement | Faut-il réessayer et les destinataires savent-ils dédupliquer ? | Attribuer un identifiant à chaque événement et vérifier son traitement par l’application |
Demande de commande | MQTT est-il un chemin de commande approuvé sur ce site ? | Autoriser l’émetteur, rejeter les demandes périmées et confirmer le résultat réel de l’appareil |
Ne choisissez pas le QoS 2 comme réglage de sécurité universel. Il ajoute de l’état et du trafic ; les réessais, la session et le traitement propre à l’application restent déterminants.
Documentez le choix du QoS pour chaque type de message et testez-le sur la liaison cellulaire réelle.
Interpréter les accusés de réception à la bonne étape
Au QoS 1, PUBACK confirme une étape MQTT ; une retransmission peut produire des doublons. Le QoS 2 ajoute un échange pour une livraison unique dans le protocole, au prix d’un état et de paquets supplémentaires. Aucun accusé ne confirme que l’affichage de l’utilisateur a changé ou qu’une action de contrôle est terminée. Si traiter deux fois a des conséquences, ajoutez un identifiant applicatif et une règle de déduplication. Pour la télémétrie, déterminez si perte, doublon ou retard de file est le plus dommageable, puis testez pendant une coupure cellulaire.
Utiliser les diagnostics MQTT 5 seulement si les clients les prennent en charge
MQTT 5 ajoute des codes de raison et des propriétés utiles pour comprendre les connexions, abonnements et publications refusés. Message Expiry Interval peut limiter la durée utile d’un message en attente ; Session Expiry Interval peut conserver l’état d’une session pour une durée définie. User Properties et alias de topics sont facultatifs et ne remplacent pas un schéma de payload documenté. Vérifiez que broker, bibliothèque cliente et firmware du routeur emploient une version et des réglages compatibles. Lisez le code réellement renvoyé avant de modifier pare-feu ou identifiants.
Gérer messages conservés, sessions et déconnexions
Une publication avec l’option retain garde au broker le dernier message conservé pour son topic et peut être envoyée à un nouvel abonné. C’est utile pour certains indicateurs d’état, mais la valeur peut être ancienne. Ajoutez horodatage et règle de validité ; ne traitez pas une commande conservée comme une nouvelle instruction. Un message Will peut signaler une déconnexion inattendue, sans prouver que la machine elle-même est en panne.
MQTT 5.0 propose des réglages d’expiration des sessions et des messages. Leur effet dépend du client, du broker et de l’abonnement. Testez ce qui reste en file pendant la coupure du site et ce qui arrive à la reconnexion. Prévoyez le traitement des messages tardifs, des doublons et de l’ordre. Pour une mesure variable, une longue file ancienne peut être moins utile qu’une lecture récente.
Définir volontairement le cycle de vie de la session
Client ID, Clean Start et Session Expiry influencent la conservation des abonnements et de l’état QoS en attente après reconnexion. Une session persistante ne signifie pas stockage hors ligne illimité : politique du broker, quotas et expiration des messages s’appliquent toujours. Décidez combien de temps la pompe déconnectée doit accumuler des valeurs, comment le client reprend et si le destinataire a besoin de tout l’historique ou d’une mesure fraîche. Testez une coupure courte et une longue, ainsi que le redémarrage du broker si nécessaire, puis consignez les limites observées.
Traiter le Will comme un signal de connexion
Un client peut enregistrer un message Will lors de la connexion ; le broker l’envoie si la connexion se termine de manière inattendue dans les conditions prévues. Utilisez-le pour signaler la perte de connexion MQTT, sans conclure que la machine est physiquement arrêtée. Associez-le à des horodatages et, si nécessaire, à un heartbeat ou une règle de qualité des données. Une déconnexion propre et une coupure réseau produisent des comportements différents. Testez les deux et empêchez un Will retardé d’écraser un état sain plus récent.
Sécuriser le chemin du broker et le mettre en service
Utilisez TLS lorsque le déploiement l’exige et le permet, validez le certificat du broker, protégez les identifiants clients et limitez chaque client aux topics nécessaires. Séparez les droits de publication et d’abonnement : un émetteur de télémétrie ne doit pas obtenir le droit de commander par la même connexion. Le guide du logiciel des routeurs industriels aide à distinguer connectivité, pare-feu, application et administration. MQTT ne chiffre pas une connexion sans transport sécurisé configuré.
Commencez avec un point d’automate connu et un abonné. Vérifiez adresse du registre, unité, horodatage et payload, puis publication, abonnement et droits sur les topics. Déconnectez le WAN et redémarrez client et broker lors de tests contrôlés ; comparez ce qui arrive après reprise. Examinez doublons, données conservées périmées, croissance des files et usage cellulaire. Gardez les fonctions de commande et de sécurité de l’automate dans le système approuvé, sauf conception MQTT distincte et validée.
Configurer le broker comme un service, pas seulement ouvrir un port
Documentez l’adresse d’écoute et le transport, la confiance des certificats, l’authentification des clients, les ACL de publication et d’abonnement par topic, les limites de session et de file, la persistance et les journaux. MQTT en clair et MQTT sous TLS utilisent souvent des ports différents, mais l’écouteur précis dépend du déploiement. Limitez l’accès depuis le site et évitez l’écriture anonyme sur un broker public. Si la haute disponibilité est nécessaire, vérifiez comment le produit gère sessions, abonnements et messages conservés lors d’une bascule ; MQTT ne garantit pas le clustering.
Mettre en service avec quatre observations
Pour un point connu, relevez valeur source, tentative de publication, acceptation par le broker et réception par l’abonné, avec horodatages. Refusez ensuite le droit du client sur le topic et observez la réponse ; rétablissez-le puis coupez le WAN pour examiner reconnexion, doublons et valeurs anciennes. Conservez versions du client et du broker, mode TLS, topic, QoS et schéma du payload. Une connexion TCP au broker prouve seulement la joignabilité. L’acceptation applicative exige une valeur correcte, récente et autorisée chez l’abonné.
FAQ
MQTT remplace-t-il Modbus sur le réseau des machines ?
Non. Une passerelle peut lire des données Modbus et publier un payload MQTT correspondant, mais les deux protocoles ont des rôles différents. Vérifiez la carte des registres et la conversion de l’appareil.
Le QoS 2 garantit-il qu’une commande machine est exécutée une seule fois ?
Non. Le QoS 2 couvre l’échange MQTT, pas le contrôleur ni l’opération métier en aval. Donnez des identifiants aux demandes et vérifiez le résultat applicatif dans une conception de commande approuvée.
Un message conservé contient-il toujours la valeur actuelle ?
Non. Il s’agit de la dernière publication conservée au broker pour ce topic. Vérifiez horodatage, qualité et règle d’expiration avant de l’utiliser.
MQTT fonctionne-t-il sur une liaison cellulaire dont l’adresse IP change ?
Souvent, un client peut ouvrir une connexion sortante vers un broker joignable, selon l’opérateur, le pare-feu et la configuration du broker. Testez reconnexion et messages en file ; MQTT ne fiabilise pas à lui seul une liaison faible.
Un émetteur peut-il publier sur un topic avec joker ?
Non. Les jokers servent aux filtres d’abonnement. L’émetteur utilise un topic précis que le broker compare aux filtres autorisés.
PUBACK prouve-t-il que le tableau a traité la valeur ?
Non. Il confirme une étape MQTT de QoS 1, pas la décision de l’application abonnée. Vérifiez séparément acceptation par le broker, réception et affichage ou stockage.
