Passerelles MQTT en périphérie
Passerelles MQTT en périphérie pour Kilo IoT — Modbus, BACnet, OPC-UA, Sparkplug B, ponts Zigbee2MQTT vers MQTT.
Dans les déploiements commerciaux, le connecteur MQTT est souvent la surface d'intégration pour les passerelles de périphérie — de petits ordinateurs ou appareils industriels qui traduisent des protocoles non-MQTT en publications MQTT. Les automates Modbus PLC, les systèmes de gestion de bâtiment BACnet, les systèmes de contrôle exposés via OPC-UA, l’automatisation équipée de Sparkplug B et les maillages Zigbee ne parlent pas MQTT nativement, mais un logiciel de passerelle bien pris en charge peut relier chacun d’eux au connecteur de la plateforme avec un modèle uniforme de sujets et de charges utiles.
Cette page couvre les modèles architecturaux des passerelles de périphérie MQTT et les choix de conception qui influencent la qualité de leur intégration. Ce n’est pas un guide de configuration pas à pas pour un produit de passerelle spécifique — la documentation du fournisseur s’occupe de l’installation ; cette page est la référence d’intégration.
Ce que fait une passerelle de périphérie MQTT
La passerelle de périphérie se place entre l’équipement de terrain non MQTT et le broker MQTT. Ses responsabilités :
Lire à partir du protocole source — cycles d’interrogation Modbus RTU/TCP, abonnements BACnet COV, abonnements OPC-UA, sessions de nœud Sparkplug B, participation à des maillages Zigbee.
Normaliser les valeurs — appliquer des facteurs d’échelle, convertir les unités vers un ensemble cohérent, décoder les champs de bits et les énumérations en valeurs lisibles.
Publier sur MQTT — émettre des charges utiles JSON vers une forme de sujet consommable par les abonnés en aval. (Les Protocol Buffers Sparkplug B doivent être traduits en JSON avant publication vers les sujets que le connecteur MQTT de la plateforme consomme — voir « Catégories courantes de passerelles » ci-dessous.)
Accepter éventuellement des commandes — s’abonner aux sujets de commande (
/set,/cmd, spécifiques au fournisseur) et réécrire vers le protocole source. (Le connecteur de la plateforme consomme la télémétrie ; les flux de commande sont gérés côté passerelle.)
La passerelle est généralement un petit appareil Linux près de l’équipement de terrain — un PC industriel, un ordinateur sur rail DIN, un Raspberry Pi ou un appareil du fournisseur. Sur le plan opérationnel, elle s’exécute comme un service système avec une sémantique de redémarrage en cas d’échec.
Catégories courantes de passerelles
Modbus → MQTT
Modbus2MQTT, passerelles fournies par les fabricants (Advantech, Moxa), flux Node-RED personnalisés
{site}/{plc}/{deviceId}/data ou sujets par registre
Objet JSON ou une valeur par sujet
BACnet → MQTT
Passerelles BMS du fournisseur, EasyIO, plateformes d’intégration personnalisées
building/{floor}/{ahu-id}/{point}
JSON avec correspondance point-valeur
OPC-UA → MQTT
OPC Router, FactoryStudio, nœuds de périphérie Sparkplug B
Sparkplug spBv1.0/{group}/DDATA/{node}/{device} ou personnalisé
Doit être en JSON pour que le connecteur de la plateforme puisse l’ingérer. Les Protocol Buffers Sparkplug B doivent être traduits en JSON par la passerelle de périphérie avant publication.
Sparkplug B natif
Inductive Automation Ignition Edge, passerelles de périphérie Cirrus Link
spBv1.0/{group}/DDATA/{node}/{device}
Doit être traduit en JSON par la passerelle de périphérie avant ingestion par le connecteur MQTT. Le connecteur MQTT de la plateforme ne décode pas les Protocol Buffers Sparkplug B.
Zigbee → MQTT
Zigbee2MQTT (open source, courant dans les pilotes et les petits déploiements commerciaux)
zigbee2mqtt/{friendlyName}
JSON plat
Passerelles personnalisées
Passerelles Python/Node.js bricolées sur les API du fournisseur
Ce que l’auteur de la passerelle a choisi
Généralement JSON
La plateforme consomme tout cela — le connecteur est agnostique au protocole. Ce qui compte lors de l’intégration est de faire correspondre la forme du sujet de la passerelle dans le champ Topic de l’ID du dispositif et la structure de charge utile de la passerelle dans l’onglet Mappage. Voir Sujets et routage des dispositifs pour les détails du routage.
Considérations de conception pour de nouvelles intégrations de passerelles de périphérie
Lors du choix ou de la configuration d’une passerelle de périphérie pour une nouvelle intégration commerciale, quatre décisions de conception influencent la qualité de l’ingestion :
Forme du sujet
Une forme de sujet hiérarchique et prévisible simplifie l’enregistrement des dispositifs et rend les modèles de sujets réutilisables entre appareils similaires. Recommandé :
Par exemple, plant-3/line-a/extruder-04/data pour un objet d’état en JSON plat, ou plant-3/line-a/extruder-04/temperature pour une valeur par sujet. Des formes compatibles avec les modèles permettent à un seul modèle de Topic d’ID de dispositif de couvrir de nombreux appareils de la même famille — plant-3/line-a/{{deviceId}}/data fonctionne pour chaque appareil de la ligne A.
À éviter :
Les espaces blancs dans n’importe quel segment, en particulier le segment identifiant du dispositif. Le champ de saisie de l’ID du dispositif supprime les espaces blancs.
Mélanger les conventions d’identifiant au sein d’une même intégration. Si certains appareils utilisent des tirets et d’autres des underscores, documentez le choix et appliquez-le de manière cohérente.
Intégrer des métadonnées en texte libre dans le sujet (noms d’opérateurs, dates, numéros d’ordre de travail). Les sujets sont des clés de routage, pas des annotations — mettez les métadonnées dans la charge utile.
Format de la charge utile
Un JSON plat ou peu imbriqué simplifie l’onglet Mappage. La plateforme aplatit automatiquement les objets imbriqués en chemins en notation pointée, donc {"vibration": {"rms": 0.42, "peak": 1.8}} devient vibration.rms et vibration.peak comme candidats de clé de connecteur. Les hiérarchies profondément imbriquées fonctionnent toujours, mais sont moins ergonomiques pour les opérateurs qui examinent les mappages.
Sparkplug B nécessite une traduction en JSON à la périphérie. Le connecteur MQTT de la plateforme consomme des charges utiles JSON — il ne décode pas nativement les Protocol Buffers Sparkplug B. Les passerelles de périphérie utilisant Sparkplug B (Inductive Automation Ignition Edge, modules MQTT Cirrus Link, OPC Router avec sortie Sparkplug) doivent être configurées pour traduire les Protocol Buffers en JSON avant publication vers les sujets auxquels le connecteur s’abonne. La plupart des passerelles de périphérie commerciales compatibles Sparkplug offrent cette traduction comme option de configuration standard.
Cadence de publication
La cadence de publication est une décision propre au déploiement, guidée par les objectifs de temps de réponse du moteur de règles, la capacité du broker et les capacités du firmware de l’appareil. La configuration COV / bande morte de la passerelle de périphérie est le levier qui permet de réduire les publications redondantes une fois une cadence de base choisie pour une classe d’appareils donnée. Vérifiez la cadence que la passerelle de périphérie peut soutenir par rapport aux règles et tableaux de bord qui consomment les données, et ajustez-la à mesure que le déploiement mûrit.
Fiabilité et comportement en cas de déconnexion
Pour les télémétries importantes pour la mission, configurez la passerelle avec :
QoS MQTT 1 pour les sujets de télémétrie — livraison au moins une fois ; la passerelle réessaie lors de la reconnexion au broker.
Last Will and Testament (LWT) MQTT — l’annonce « je me suis déconnecté de manière inattendue » de la passerelle, généralement publiée comme message conservé sur un sujet d’état. Si votre broker transmet le message LWT au connecteur comme une publication abonnée standard, un
étatchamp peut être mappé pour refléter la connectivité de la passerelle — validez le chemin par un test de déconnexion volontaire avant de vous y fier en exploitation.Messages « en ligne » conservés — publiés à la connexion, remplacés par le LWT à la déconnexion. Les abonnés (y compris les nouveaux qui se connectent plus tard) voient immédiatement l’état actuel de la connectivité.
Stockage local persistant — la passerelle met en mémoire tampon la télémétrie lorsqu’elle est déconnectée du broker et la rejoue à la reconnexion. La plupart des passerelles de périphérie commerciales prennent cela en charge ; vérifiez que la taille du tampon correspond aux fenêtres de déconnexion attendues.
Dans cette section
Hubs Zigbee2MQTT — Zigbee2MQTT comme un modèle de passerelle de périphérie MQTT : topologie de hub, adéquation au déploiement, conseils de validation de capacité, et manière dont le flux MQTT résultant alimente le flux standard de routage des dispositifs.
Où aller ensuite
Sujets et routage des dispositifs — en enregistrant les dispositifs derrière l’une quelconque de ces passerelles.
MQTT Cloud et MQTT externe — en choisissant le côté broker.
Dépannage — en diagnostiquant les problèmes d’ingestion.
Mis à jour