MQTT est un protocole de messagerie : des éditeurs publient et des abonnés reçoivent les messages sur les sujets concernés. Il relie notamment un collecteur industriel aux applications. Il ne définit ni la mesure d’un capteur, ni l’unité d’une valeur, ni le déclenchement d’une alarme : ces éléments relèvent du contrat de données applicatif.
Concevoir le courtier et les sujets
Le courtier, souvent appelé broker, achemine les publications. L’éditeur n’a pas besoin de connaître chaque destinataire, mais accès, capacité, permissions et santé du courtier deviennent des responsabilités d’exploitation. Autoriser chaque appareil à publier partout n’est pas un bon défaut.
Les sujets suivent une hiérarchie d’équipements claire. site-a/line-2/machine-7/state est un nom illustratif, sans adresse réelle. Séparez identité stable et nom d’affichage pour éviter de fragmenter l’historique lors d’un renommage. N’incluez ni secrets ni informations personnelles dans les sujets.
Le message peut contenir valeur, unité, horodatage source, qualité et version du schéma. Documentez taille limite et champs facultatifs. Les consommateurs doivent interpréter le même message de façon cohérente, sans deviner chacun le registre d’origine.
Ce que couvre réellement le QoS
La norme OASIS MQTT 5.0 définit trois niveaux. Leur comportement concerne le segment de communication du protocole. Ils ne garantissent pas automatiquement une seule écriture en base ni une seule action physique.
| Niveau | Livraison sur le segment | Question applicative |
|---|---|---|
| QoS 0 | Au plus une fois | Peut-on perdre cette observation ? |
| QoS 1 | Au moins une fois | Comment reconnaître les répétitions ? |
| QoS 2 | Exactement une fois sur le segment | Que font les services en aval ? |
Un abonné peut traiter un message puis perdre l’accusé de la base. Une nouvelle tentative peut répéter l’opération applicative. Identité stable, contraintes d’unicité et transactions comptent donc au-delà du paramétrage MQTT. QoS 2 n’est pas une garantie métier illimitée d’unicité de bout en bout.
Conservé ne veut pas dire actuel
Un message conservé peut fournir au nouvel abonné le dernier message du sujet. Sa valeur peut être ancienne. L’interface vérifie horodatage et politique de fraîcheur. Une réception immédiate après connexion ne prouve pas le bon fonctionnement actuel du capteur.
Le testament, ou Last Will, peut signaler une perte de connexion sans diagnostiquer tous les défauts terrain. Un collecteur connecté peut avoir perdu un capteur. Disponibilité de l’appareil, santé du collecteur et connectivité applicative restent distinctes.
Exemple de température
Un collecteur met en mémoire des températures horodatées pendant une coupure amont. Il les retransmet avec leurs identités d’origine. L’application déduplique, insère les données tardives dans l’historique et évite de remplacer l’affichage courant par une ancienne mesure rejouée.
La file est finie. Définissez durée couverte, alarmes de stockage et comportement en cas de panne du support. Testez des reconnexions simultanées et limitez la reprise pour préserver collecte actuelle et interrogations terrain. Des tentatives espacées et bornées évitent d’aggraver un réseau en cours de rétablissement.
Questions à préciser
- Où fonctionnera le courtier et qui l’exploitera ?
- Comment gérer identités et permissions des sujets ?
- Quels champs rendent le message valide ?
- Comment tester tampon, reprise et doublons ?
- Que se passe-t-il au renouvellement des identifiants ou certificats ?
MQTT ne remplace ni modèle de données ni plan d’exploitation. Validez un petit flux en fonctionnement normal, en déconnexion et en livraison répétée avant l’extension.
Exemple de doublon applicatif
Un collecteur publie la température observation-1042. L’application la stocke, mais son accusé de traitement n’arrive pas. La nouvelle tentative garde identité et horodatage initial. Le récepteur reconnaît l’enregistrement existant au lieu d’ajouter un échantillon. Une nouvelle identité à chaque tentative supprimerait cette preuve d’une observation unique.
Un autre consommateur peut évaluer une alarme. Son état de traitement doit aussi être pensé : éviter les mesures doubles n’évite pas automatiquement les notifications doubles. Reliez événement d’entrée, transition d’alarme et tâche de notification. Si le prestataire expire sans réponse, gardez un résultat incertain plutôt que d’affirmer qu’aucun envoi n’a eu lieu. C’est un exemple de conception applicative, pas une garantie supplémentaire de MQTT.
Prévoyez les messages rejetés. Schéma inconnu, unité invalide ou identité impossible doivent être diagnostiquables. Réessayer aveuglément un message définitivement malformé consomme des ressources sans créer de données utilisables. Proposez un traitement borné et une vue opérationnelle de la source affectée. Ne copiez pas identifiants secrets ou contenus complets dans les journaux pour simplifier le débogage.
Tester autorisations et reprise
Testez l’identité d’un appareil sur les sujets autorisés en publication et abonnement. Tentez hors périmètre et vérifiez le rejet. Traitez séparément identifiants remplacés, appareil retiré et reconnexion ordinaire. Une connexion réussie ne démontre pas les limites de ses droits.
Coupez l’amont pendant que la collecte continue, puis reconnectez avec historique et mesures actuelles. Vérifiez dates d’origine, identités et âge affiché. Examinez le stockage local plein : cette condition doit rester visible même lorsque le courtier redevient disponible. Documentez version MQTT, comportement des sessions et règles d’accusé applicatif avec les configurations réelles. Apportez ce relevé, un exemple de message et la hiérarchie des sujets à la revue d’intégration. Ils rendent les limites de fiabilité évaluables sans attribuer à un seul QoS la résolution de tous les problèmes de livraison.