Le bridging MQTT relie deux brokers afin que les messages publiés sur des topics sélectionnés passent automatiquement de l'un à l'autre. À la fin de ce guide, vous saurez quand un bridge (pont) est pertinent, comment fonctionnent le remappage des topics et la prévention des boucles, et vous disposerez d'une configuration de bridge Mosquitto fonctionnelle ainsi que d'une alternative Node-RED qui transfèrent les données locales vers un broker cloud.
Ce que fait réellement un bridge MQTT
Un bridge n'est pas un protocole particulier. Un broker (ou un programme auxiliaire) ouvre simplement une connexion cliente MQTT ordinaire vers un autre broker, s'abonne d'un côté et republie de l'autre. Du point de vue du broker distant, le bridge n'est qu'un client de plus, avec un nom d'utilisateur, un mot de passe et un client ID.
Ce détail compte pour la façon de le construire. De nombreux brokers hébergés, dont ConnectMQ, n'exécutent pas eux-mêmes de bridge sortant. C'est vous qui exécutez le bridge en périphérie : une instance Mosquitto dans l'usine, ou un flux Node-RED sur une passerelle, se connecte au broker cloud en tant que client. C'est aussi le sens le plus compatible avec les pare-feu, puisque le site n'a besoin que d'un accès sortant sur le port 8883.
Raisons courantes de mettre en place un bridge :
- Autonomie locale. Les adaptateurs d'automates, les IHM et les contrôleurs continuent de dialoguer avec un broker sur le réseau de l'usine, même si la liaison Internet tombe.
- Export sélectif. Seuls les topics agrégés ou approuvés quittent le site, pas chaque signal brut.
- Moins de connexions cloud. Des centaines d'appareils locaux partagent une seule connexion amont, ce qui vous maintient dans les quotas de connexions.
- Correspondance d'espaces de noms. Des topics locaux comme
line4/press/tempdeviennent des topics cloud uniques à l'échelle globale, commeacme/izmir/line4/press/temp.
Topologies de bridging
| Topologie | Description | Idéale pour | Points de vigilance |
|---|---|---|---|
| Edge vers cloud (sortant) | Le broker local remonte des topics sélectionnés | Télémétrie, tableaux de bord, historiens | Mise en mémoire tampon pendant les coupures |
| Cloud vers edge (entrant) | Les commandes cloud descendent vers le site | Consignes, configuration, déclenchements OTA | Autoriser qui peut commander |
| Bidirectionnelle | Les deux sens, sur des arbres de topics distincts | Exploitation à distance complète | Boucles de messages |
| Hub and spoke (en étoile) | De nombreux sites se relient à un broker central | Unified Namespace multisite | Collisions de topics entre sites |
Le modèle en étoile est l'ossature de nombreuses architectures Unified Namespace et Sparkplug B : chaque site possède son broker local et contribue une branche à l'arbre de topics de l'entreprise dans le cloud.
Option 1 : un bridge Mosquitto vers un broker cloud
Eclipse Mosquitto intègre une fonction de bridge configurée dans mosquitto.conf. L'exemple ci-dessous exécute un broker local pour les appareils de l'usine sur le port 1883 et le relie à un broker ConnectMQ en TLS sur le port 8883, avec les identifiants générés dans le portail.
# /etc/mosquitto/conf.d/bridge-connectmq.conf
# --- Listener local pour les appareils du réseau de l'usine ---
listener 1883
# À durcir avec password_file en production
allow_anonymous true
# --- Bridge vers ConnectMQ (cloud) ---
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
# Conserver la session distante pour que les messages QoS 1 survivent aux reconnexions courtes
cleansession false
keepalive_interval 60
restart_timeout 5 60
# Le broker distant n'est pas Mosquitto : ne pas utiliser le drapeau de bridge privé
try_private false
notifications false
# Mise en mémoire tampon locale pendant la coupure de la liaison
max_queued_messages 10000
# topic <pattern> <direction> <qos> <local-prefix> <remote-prefix>
# Local plant/line4/... -> cloud acme/izmir/line4/...
topic # out 1 plant/ acme/izmir/
# Cloud acme/izmir/cmd/... -> local cmd/...
topic # in 1 cmd/ acme/izmir/cmd/
Fonctionnement des lignes topic : Mosquitto prend le motif (#), lui ajoute le préfixe local pour construire l'abonnement local (plant/#) et, lors du transfert, remplace le préfixe local par le préfixe distant. Un message local sur plant/line4/press/temp apparaît dans le cloud sous acme/izmir/line4/press/temp. La ligne in fait l'inverse pour les commandes.
Remarques sur les paramètres importants :
remote_clientiddoit être le client ID délivré avec vos identifiants. Le broker lie les client IDs aux identifiants : un ID aléatoire sera rejeté.try_private false. Le drapeau de bridge privé de Mosquitto est une extension Mosquitto-vers-Mosquitto ; d'autres brokers peuvent le refuser.notifications false. Sinon, Mosquitto publie des messages d'état du bridge sur des topics$SYS/broker/connection/..., qu'un broker distant autre que Mosquitto peut ne pas accepter.bridge_capath. Pointe vers le magasin de CA du système. Le broker présente un certificat Let's Encrypt, présent dans ce magasin sur les distributions Linux standard.max_queued_messages. Limite le nombre de messages que le broker local met en mémoire tampon pendant la coupure de la liaison. Dimensionnez-le selon votre tolérance aux coupures et votre espace disque.
Redémarrez Mosquitto et surveillez son journal : Connecting bridge connectmq-cloud doit être suivi d'une connexion réussie. En cas d'échec, la ligne du journal contenant le code CONNACK vous indique s'il s'agit d'un problème d'identifiants ou de TLS.
Tester le bridge de bout en bout
# Sur un ordinateur portable : observer le côté cloud
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_OTHER_CLIENT_ID \
-t "acme/izmir/#" -v
# Sur le réseau de l'usine : publier vers le broker local
mosquitto_pub -h 192.168.10.5 -p 1883 -i press-sim-01 \
-t "plant/line4/press/temp" -m "78.2" -q 1
Vous devriez voir acme/izmir/line4/press/temp 78.2 dans l'abonné cloud. Notez que l'ordinateur portable a besoin de son propre jeu d'identifiants : deux connexions ne peuvent pas partager un même client ID. Pour un essai sans identifiants, pointez le bridge vers le serveur MQTT public gratuit sur le port 1883, supprimez les lignes de nom d'utilisateur et de mot de passe, utilisez un remote_clientid unique et un préfixe distant comme connectmq/demo/b7e2/ (les données publiques sont visibles par tous).
Option 2 : Node-RED comme bridge
Si le site exécute déjà Node-RED, vous n'avez peut-être pas besoin d'un second processus broker. Un flux avec deux nœuds de configuration MQTT fait office de bridge et vous offre un endroit pour filtrer, renommer et transformer les messages.
- Ajoutez un nœud
mqtt inutilisant une configuration de broker pour le broker local (par exemple192.168.10.5:1883), abonné àplant/#en QoS 1. - Ajoutez un nœud
functionpour remapper les topics et écarter tout ce que vous ne souhaitez pas exporter. - Ajoutez un nœud
mqtt oututilisant une seconde configuration de broker : serveurbroker.connectmq.com, port 8883, option « Use TLS » activée, avec le nom d'utilisateur, le mot de passe et le client ID de votre portail.
// Nœud function : remapper les topics locaux vers l'espace de noms cloud
const LOCAL_PREFIX = "plant/";
const REMOTE_PREFIX = "acme/izmir/";
if (!msg.topic.startsWith(LOCAL_PREFIX)) {
return null; // ignorer les topics inattendus
}
// Exemple de filtre : ne pas exporter les signaux de débogage bruts
if (msg.topic.includes("/debug/")) {
return null;
}
msg.topic = REMOTE_PREFIX + msg.topic.slice(LOCAL_PREFIX.length);
msg.qos = 1;
return msg;
Pour les commandes descendantes, ajoutez un chemin miroir : un mqtt in sur la configuration cloud abonné à acme/izmir/cmd/#, un nœud function qui réécrit le préfixe en cmd/, et un mqtt out vers le broker local. Le tutoriel MQTT Node-RED détaille les nœuds de configuration et les réglages TLS, et la documentation officielle de Node-RED répertorie toutes les options des nœuds MQTT.
Le compromis : Node-RED ne met pas en mémoire tampon sur disque comme peut le faire un broker. Si la liaison amont est coupée, les messages qui traversent le flux sont perdus, à moins d'ajouter votre propre file d'attente. Mosquitto est le meilleur choix lorsque vous avez besoin de store-and-forward ; Node-RED l'emporte lorsque vous avez besoin de logique.
Éviter les boucles de messages
Les bridges bidirectionnels peuvent créer des boucles : un message monte, correspond à la règle descendante, redescend, puis remonte. Les règles qui vous protègent :
- Utilisez des arbres de topics disjoints pour chaque sens, comme ci-dessus (
plant/sort,cmd/entre). - Ne reliez jamais
#dans les deux sens avec les mêmes préfixes. - Dans les configurations MQTT 5, l'option d'abonnement No Local empêche un client de recevoir ses propres publications, ce qui aide lorsque le bridge s'abonne et publie sur la même connexion.
- Testez avec un seul message et observez les deux côtés avant d'activer le trafic de production.
Checklist de dépannage
| Symptôme | Cause probable | Correctif |
|---|---|---|
| CONNACK not authorized | Identifiants ou client ID erronés | Copier les trois valeurs depuis le portail |
| Erreur TLS à la connexion | Magasin de CA absent ou chemin erroné | Installer ca-certificates, vérifier bridge_capath |
| Le bridge se connecte puis décroche | Client ID dupliqué utilisé ailleurs | Donner à chaque client son propre jeu d'identifiants |
| Les topics apparaissent sans préfixe | Préfixes inversés dans la ligne topic | L'ordre est préfixe local, puis préfixe distant |
| Trous dans les données après une coupure | File trop petite ou QoS 0 | Utiliser la QoS 1 et augmenter max_queued_messages |
| Les messages tournent en boucle | Règles in/out qui se chevauchent | Séparer les arbres pour chaque sens |
Choisir un point d'accès cloud pour vos bridges
Le côté cloud doit être sans surprise : toujours disponible, TLS par défaut et capable d'accepter une connexion amont par site, en plus de vos tableaux de bord et services. Un broker MQTT managé supprime le travail de correctifs et de certificats, et le guide du broker MQTT cloud passe en revue les compromis d'hébergement. Si vous découvrez ces briques de base, le tutoriel MQTT pour débutants et le modèle publish/subscribe complètent bien cet article.
Reliez vos sites à ConnectMQ
Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, puis collez le nom d'utilisateur, le mot de passe et le client ID générés dans votre bridge Mosquitto ou dans votre nœud de configuration Node-RED. L'explorateur de topics en direct de ConnectMQ affiche l'arrivée des topics relayés en temps réel, ce qui vous permet de valider la correspondance avant de connecter d'autres sites.
Questions fréquentes
ConnectMQ dispose-t-il d'un bridge intégré ?
Non. Vous vous y reliez en exécutant en périphérie Mosquitto, Node-RED ou un autre client MQTT qui se connecte au broker comme un client ordinaire, en TLS.
Puis-je relayer des fonctionnalités MQTT 5 comme les user properties ?
Définissez bridge_protocol_version mqttv50 dans Mosquitto pour établir le bridge en MQTT 5. Vérifiez que les deux brokers prennent en charge MQTT 5 et testez que les propriétés dont vous dépendez sont bien transmises.
Combien de connexions un bridge utilise-t-il ?
Un bridge Mosquitto utilise une seule connexion vers le broker distant, quel que soit le nombre d'appareils locaux qui publient à travers lui. Un bridge Node-RED utilise une connexion par nœud de configuration de broker.
Que deviennent les données quand la liaison Internet tombe ?
Un bridge Mosquitto met les messages en file d'attente localement jusqu'à max_queued_messages et les transmet au retour de la liaison. Les flux Node-RED simples ne mettent rien en mémoire tampon, sauf si vous l'ajoutez.
