MQTT et Modbus répondent généralement à des questions différentes. Modbus lit des zones de données d’un appareil ; MQTT distribue les enregistrements du collecteur. Ils peuvent fonctionner ensemble, une passerelle reliant deux couches distinctes d’un même flux.
Attribuer le bon rôle à chaque protocole
Un client Modbus demande des données précises et reçoit une réponse. Un éditeur MQTT publie sur un sujet, puis le courtier distribue aux abonnés. Le pont doit souvent faire davantage que déplacer des octets : il définit le sens de la valeur brute.
Un registre contenant 184 ne signifie 18,4 °C que selon la documentation de l’appareil. Le collecteur applique échelle, unité et qualité vérifiées. Sans transformation documentée, plusieurs services peuvent interpréter le même registre différemment.
Responsabilités par couche
| Question | Appareil / Modbus | Messagerie / MQTT |
|---|---|---|
| D’où vient la valeur ? | Registre et table de l’appareil | Sujet et identité de publication |
| Comment connaître l’unité ? | Définition fabricant | Contrat du message |
| Que faire en déconnexion ? | Délai de lecture et qualité | Session, mémoire et reprise |
| Comment reconnaître les répétitions ? | Modèle de mesure/événement | Identité d’événement applicative |
Séparer ces responsabilités facilite le diagnostic. Un message absent ne prouve pas une panne de capteur Modbus. Examinez liaison série, collecteur, connexion au courtier et service de stockage séparément. Chacun a besoin d’un indicateur de dernière opération réussie.
Flux combiné illustratif
Un module de chambre froide est lu en Modbus RTU. La passerelle convertit vers l’unité convenue, ajoute identité et heure, puis publie en MQTT. L’application valide et stocke l’historique. Le tableau de bord exploite cet enregistrement pour tracer une tendance.
La collecte série peut continuer sans réseau amont. La passerelle conserve les données dans un tampon borné. À la reconnexion, dates et identités restent d’origine. Le serveur les place dans l’historique sans les présenter comme actuelles ; une répétition ne crée pas une seconde observation.
Pourquoi un convertisseur ne suffit pas
Lecture Modbus échouée, défaut de capteur déclaré et courtier inaccessible sont distincts. Tout convertir en zéro ou en valeur nulle indifférenciée complique la recherche de panne. Préservez catégorie de qualité, heure de dernière mesure valide et santé de la source lorsqu’elles sont disponibles.
Le choix du QoS ne garantit pas non plus une seule écriture dans la base aval. Acceptation du message, traitement du record et évaluation d’alarme sont des frontières séparées. Les règles de livraison OASIS ne remplacent pas transactions et déduplication applicatives.
Valider les deux connexions
L’étude doit préciser table des registres, signaux événementiels et périodiques, pertes acceptables, gestion des horloges et droits des sujets. Il faut comprendre la capacité finie du stockage et sa saturation. Davantage de mémoire ne recrée aucune mesure jamais collectée.
La réception coupe appareil–passerelle puis passerelle–serveur. Consignez qualités attendues, ordre de reprise et doublons. Testez aussi valeur appareil invalide et message malformé. Le résultat est un flux explicable aux limites visibles, pas deux protocoles paraissant connectés.
Écrire le contrat du pont avant les sujets
Dans l’exemple frigorifique, reliez chaque champ normalisé à son origine. Température : grandeur documentée. Unité : conversion vérifiée. Identité : inventaire de configuration. L’heure peut venir de l’appareil ou de la lecture par le collecteur. Ces preuves différentes ne doivent pas fusionner en un horodatage ambigu intitulé direct.
La passerelle doit définir l’identité d’une observation. Une nouvelle lecture peut produire une nouvelle observation sans changement de valeur numérique. Retransmettre une observation ancienne doit conserver son identité. Sinon, l’application distingue mal température inchangée et livraison dupliquée. Documentez la conservation, l’agrégation ou la suppression de valeurs égales successives : cela affecte historique et contrôle d’actualité.
Traitez un changement de correspondance comme un événement versionné. Si un technicien corrige un facteur d’échelle, messages futurs et historique doivent rester interprétables. Appliquer silencieusement le nouveau facteur à un mélange de valeurs brutes et normalisées peut corrompre un rapport. Rendez la frontière de conversion explicite et décidez si une correction historique produit une révision ou un recalcul documenté séparément.
Essai d’interruption des deux côtés
Déconnectez d’abord la source Modbus en gardant le courtier disponible. Le résultat attendu est un problème terrain, pas une mesure actuelle saine au seul motif que des messages arrivent. Rétablissez ensuite le terrain et coupez seulement le chemin vers le courtier. La collecte peut continuer localement si le matériel le permet. Les observations historiques reviennent avec heure et qualité initiales.
Interrompez enfin un accusé après stockage applicatif. Vérifiez que la reprise ne crée ni second échantillon ni série illimitée d’alarmes répétées. Incluez message malformé et défaut de qualité : aucun ne doit devenir un zéro inexpliqué dans la courbe. Notez le résultat dans passerelle, récepteur et écran pour localiser la frontière défaillante lors d’une future maintenance.
Choisir les protocoles n’est donc qu’une partie de l’intégration. Le livrable utile comprend table appareil, exemple de message, règles d’identité et de qualité, permissions et reprise. Partagez-les lors de l’étude d’un pont entre équipements existants et supervision, sans supposer qu’un convertisseur fournit à lui seul le modèle d’exploitation complet.