Eine MQTT-Bridge verbindet zwei Broker so, dass Nachrichten auf ausgewählten Topics automatisch vom einen zum anderen fließen. Am Ende dieses Leitfadens wissen Sie, wann eine Bridge sinnvoll ist und wie Topic-Remapping und Loop-Schutz funktionieren, und Sie haben eine funktionierende Mosquitto-Bridge-Konfiguration sowie eine Node-RED-Alternative, die lokale Daten an einen Cloud-Broker weiterleiten.
Was MQTT-Bridging tatsächlich macht
Eine Bridge ist kein spezielles Protokoll. Ein Broker (oder ein Hilfsprogramm) öffnet einfach eine gewöhnliche MQTT-Client-Verbindung zu einem anderen Broker, abonniert auf der einen Seite und publiziert auf der anderen erneut. Aus Sicht des entfernten Brokers ist die Bridge nur ein weiterer Client mit Benutzername, Passwort und Client-ID.
Dieses Detail ist für den Aufbau entscheidend. Viele verwaltete MQTT-Broker, darunter ConnectMQ, betreiben selbst keine ausgehende Bridge. Stattdessen betreiben Sie die Bridge am Edge: Eine Mosquitto-Instanz im Werk oder ein Node-RED-Flow auf einem Gateway verbindet sich als Client nach außen mit dem Cloud-Broker. Das ist auch die firewallfreundlichere Richtung, denn der Standort benötigt nur ausgehenden Zugriff auf Port 8883.
Typische Gründe für eine Bridge:
- Lokale Autonomie. SPS-Adapter, HMIs und Steuerungen kommunizieren weiter mit einem Broker im Werksnetz, selbst wenn die Internetverbindung ausfällt.
- Selektiver Export. Nur aggregierte oder freigegebene Topics verlassen den Standort, nicht jedes Rohsignal.
- Weniger Cloud-Verbindungen. Hunderte lokale Geräte teilen sich eine Upstream-Verbindung, sodass Sie innerhalb der Verbindungskontingente bleiben.
- Namespace-Mapping. Lokale Topics wie
line4/press/tempwerden zu global eindeutigen Cloud-Topics wieacme/izmir/line4/press/temp.
Bridging-Topologien
| Topologie | Beschreibung | Geeignet für | Achten Sie auf |
|---|---|---|---|
| Edge zur Cloud (out) | Lokaler Broker schiebt ausgewählte Topics nach oben | Telemetrie, Dashboards, Historians | Pufferung bei Ausfällen |
| Cloud zum Edge (in) | Cloud-Befehle fließen zum Standort | Sollwerte, Konfiguration, OTA-Trigger | Autorisierung, wer Befehle senden darf |
| Bidirektional | Beide Richtungen auf getrennten Topic-Bäumen | Vollständiger Fernbetrieb | Nachrichtenschleifen |
| Hub and Spoke | Viele Standorte bridgen zu einem zentralen Broker | Standortübergreifender Unified Namespace (UNS) | Topic-Kollisionen zwischen Standorten |
Das Hub-and-Spoke-Muster ist das Rückgrat vieler Designs mit Unified Namespace und Sparkplug B: Jeder Standort besitzt seinen lokalen Broker und steuert einen Zweig zum unternehmensweiten Topic-Baum in der Cloud bei. Die Struktur dieses UNS folgt der Equipment-Hierarchie nach ISA-95: Enterprise → Site → Area → Line → Cell. Die Bridge übernimmt dabei genau die oberen Ebenen: Lokal publizieren Geräte etwa auf montage/linie-1/zelle-3/temperatur, und das Remote-Präfix ergänzt Enterprise und Site, sodass in der Cloud acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur entsteht. Topic-Kollisionen zwischen Werken sind so ausgeschlossen, und MES, ERP oder Analytics abonnieren jede Ebene mit einer Wildcard.
Option 1: Mosquitto-Bridge zu einem Cloud-Broker
Eclipse Mosquitto hat eine integrierte Bridge-Funktion, die in mosquitto.conf konfiguriert wird. Das folgende Beispiel betreibt einen lokalen Broker für Werksgeräte auf Port 1883 und bridget über TLS auf 8883 zu einem ConnectMQ-Broker, mit den im Portal generierten Zugangsdaten.
# /etc/mosquitto/conf.d/bridge-connectmq.conf
# --- Lokaler Listener für Geräte im Werksnetz ---
listener 1883
# In Produktion mit password_file absichern
allow_anonymous true
# --- Bridge zu 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
# Remote-Session behalten, damit QoS-1-Nachrichten kurze Reconnects überstehen
cleansession false
keepalive_interval 60
restart_timeout 5 60
# Der Remote-Broker ist kein Mosquitto: kein privates Bridge-Flag verwenden
try_private false
notifications false
# Lokale Pufferung, solange der Uplink ausgefallen ist
max_queued_messages 10000
# topic <pattern> <direction> <qos> <local-prefix> <remote-prefix>
# Lokal plant/line4/... -> Cloud acme/izmir/line4/...
topic # out 1 plant/ acme/izmir/
# Cloud acme/izmir/cmd/... -> lokal cmd/...
topic # in 1 cmd/ acme/izmir/cmd/
So funktionieren die topic-Zeilen: Mosquitto nimmt das Muster (#), stellt das lokale Präfix voran, um die lokale Subscription zu bilden (plant/#), und tauscht beim Weiterleiten das lokale gegen das entfernte Präfix. Eine lokale Nachricht auf plant/line4/press/temp erscheint in der Cloud als acme/izmir/line4/press/temp. Die in-Zeile macht für Befehle das Umgekehrte.
Hinweise zu den wichtigen Einstellungen:
remote_clientidmuss die mit Ihren Zugangsdaten ausgegebene Client-ID sein. Der Broker bindet Client-IDs an Zugangsdaten, eine zufällige ID wird daher abgelehnt.try_private false. Das private Bridge-Flag von Mosquitto ist eine Erweiterung für Mosquitto-zu-Mosquitto-Verbindungen; andere Broker lehnen es möglicherweise ab.notifications false. Andernfalls publiziert Mosquitto Bridge-Statusmeldungen auf$SYS/broker/connection/...-Topics, die ein Remote-Broker, der kein Mosquitto ist, möglicherweise nicht akzeptiert.bridge_capath. Verweist auf den CA-Speicher des Systems. Der Broker präsentiert ein Let's-Encrypt-Zertifikat, das in Standard-Linux-Distributionen in diesem Speicher enthalten ist.max_queued_messages. Begrenzt, wie viele Nachrichten der lokale Broker puffert, solange der Uplink ausgefallen ist. Dimensionieren Sie den Wert nach Ihrer Ausfalltoleranz und Ihrem Speicherplatz.
Starten Sie Mosquitto neu und beobachten Sie das Log auf Connecting bridge connectmq-cloud, gefolgt von einer erfolgreichen Verbindung. Schlägt sie fehl, verrät Ihnen die Log-Zeile mit dem CONNACK-Code, ob es sich um ein Problem mit Zugangsdaten oder TLS handelt.
Die Bridge Ende-zu-Ende testen
# Auf einem Laptop: die Cloud-Seite beobachten
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
# Im Werksnetz: auf den lokalen Broker publizieren
mosquitto_pub -h 192.168.10.5 -p 1883 -i press-sim-01 \
-t "plant/line4/press/temp" -m "78.2" -q 1
Im Cloud-Subscriber sollte acme/izmir/line4/press/temp 78.2 erscheinen. Beachten Sie, dass der Laptop einen eigenen Satz Zugangsdaten braucht; zwei Verbindungen können sich keine Client-ID teilen. Für einen Test ohne Zugangsdaten richten Sie die Bridge auf den öffentlichen MQTT-Broker auf Port 1883, entfernen die Zeilen für Benutzername und Passwort, verwenden eine eindeutige remote_clientid und ein Remote-Präfix wie connectmq/demo/b7e2/ (öffentliche Daten sind für jeden sichtbar; der öffentliche MQTT-Broker ist nur für Tests gedacht, nicht für Produktionsdaten).
Option 2: Node-RED als Bridge
Läuft am Standort bereits Node-RED, brauchen Sie möglicherweise gar keinen zweiten Broker-Prozess. Ein Flow mit zwei MQTT-Konfigurationsknoten fungiert als Bridge und bietet Ihnen eine Stelle, um Nachrichten zu filtern, umzubenennen und zu transformieren.
- Fügen Sie einen
mqtt in-Knoten mit einer Broker-Konfiguration für den lokalen Broker hinzu (zum Beispiel192.168.10.5:1883), derplant/#mit QoS 1 abonniert. - Fügen Sie einen
function-Knoten hinzu, der Topics umschreibt und alles verwirft, was Sie nicht exportieren möchten. - Fügen Sie einen
mqtt out-Knoten mit einer zweiten Broker-Konfiguration hinzu: Serverbroker.connectmq.com, Port 8883, „Use TLS“ aktiviert, mit Benutzername, Passwort und Client-ID aus dem Portal.
// Function-Knoten: lokale Topics auf den Cloud-Namespace abbilden
const LOCAL_PREFIX = "plant/";
const REMOTE_PREFIX = "acme/izmir/";
if (!msg.topic.startsWith(LOCAL_PREFIX)) {
return null; // unerwartete Topics ignorieren
}
// Beispielfilter: rohe Debug-Signale nicht exportieren
if (msg.topic.includes("/debug/")) {
return null;
}
msg.topic = REMOTE_PREFIX + msg.topic.slice(LOCAL_PREFIX.length);
msg.qos = 1;
return msg;
Für Befehle in Gegenrichtung fügen Sie einen Spiegelpfad hinzu: mqtt in auf der Cloud-Konfiguration mit Subscription auf acme/izmir/cmd/#, einen function-Knoten, der das Präfix auf cmd/ umschreibt, und mqtt out zum lokalen Broker. Das Node-RED-MQTT-Tutorial behandelt Konfigurationsknoten und TLS-Einstellungen ausführlich, und die offizielle Node-RED-Dokumentation listet jede Option der MQTT-Knoten auf.
Der Kompromiss: Node-RED puffert nicht auf die Festplatte, wie es ein Broker kann. Ist der Uplink ausgefallen, gehen Nachrichten, die durch den Flow laufen, verloren, sofern Sie keine eigene Warteschlange ergänzen. Mosquitto ist die bessere Wahl, wenn Sie Store-and-Forward benötigen; Node-RED gewinnt, wenn Sie Logik brauchen.
Nachrichtenschleifen verhindern
Bidirektionale Bridges können Schleifen erzeugen: Eine Nachricht geht nach oben, passt auf die Abwärtsregel, kommt zurück und geht wieder nach oben. Diese Regeln schützen Sie:
- Verwenden Sie pro Richtung disjunkte Topic-Bäume, wie oben (
plant/geht hinaus,cmd/kommt herein). - Bridgen Sie niemals
#in beide Richtungen mit denselben Präfixen. - In MQTT-5-Setups verhindert die Subscription-Option No Local, dass ein Client seine eigenen Publishes empfängt. Das hilft, wenn die Bridge auf derselben Verbindung abonniert und publiziert.
- Testen Sie mit einer einzelnen Nachricht und beobachten Sie beide Seiten, bevor Sie Produktionsverkehr freischalten.
Checkliste zur Fehlerbehebung
| Symptom | Wahrscheinliche Ursache | Lösung |
|---|---|---|
| CONNACK not authorized | Falsche Zugangsdaten oder Client-ID | Alle drei Werte aus dem Portal kopieren |
| TLS-Fehler beim Verbinden | CA-Speicher fehlt oder falscher Pfad | ca-certificates installieren, bridge_capath prüfen |
| Bridge verbindet sich und bricht dann ab | Doppelte Client-ID anderswo in Verwendung | Jedem Client einen eigenen Satz Zugangsdaten geben |
| Topics erscheinen ohne Präfix | Präfixe in der topic-Zeile vertauscht | Reihenfolge ist lokales Präfix, dann Remote-Präfix |
| Datenlücken nach Ausfall | Warteschlange zu klein oder QoS 0 | QoS 1 verwenden und max_queued_messages erhöhen |
| Nachrichten hallen endlos wider | Überlappende in/out-Regeln | Getrennte Bäume pro Richtung |
Einen Cloud-Endpunkt für Ihre Bridges wählen
Die Cloud-Seite sollte unspektakulär sein: immer verfügbar, standardmäßig mit TLS und in der Lage, eine Upstream-Verbindung pro Standort sowie Ihre Dashboards und Dienste aufzunehmen. Ein verwalteter MQTT-Broker nimmt Ihnen Patches und Zertifikatsarbeit ab, und der Leitfaden zu Cloud-MQTT-Brokern beleuchtet die Abwägungen beim Hosting. Wenn diese Bausteine neu für Sie sind, ergänzen das MQTT-Tutorial für Einsteiger und das Publish/Subscribe-Modell diesen Artikel gut.
Verbinden Sie Ihre Standorte mit ConnectMQ
Erstellen Sie unter app.connectmq.com einen kostenlosen Serverless-Broker, ohne Kreditkarte, und fügen Sie den generierten Benutzernamen, das Passwort und die Client-ID in Ihre Mosquitto-Bridge oder Ihren Node-RED-Konfigurationsknoten ein. Der Live-Topic-Explorer von ConnectMQ zeigt gebridgte Topics in Echtzeit, sodass Sie das Mapping prüfen können, bevor Sie weitere Standorte anbinden.
Häufig gestellte Fragen
Hat ConnectMQ eine integrierte Bridge?
Nein. Sie bridgen zu ConnectMQ, indem Sie am Edge Mosquitto, Node-RED oder einen anderen MQTT-Client betreiben, der sich als normaler Client über TLS mit dem Broker verbindet.
Kann ich MQTT-5-Funktionen wie User Properties bridgen?
Setzen Sie in Mosquitto bridge_protocol_version mqttv50, um mit MQTT 5 zu bridgen. Prüfen Sie, ob beide Broker MQTT 5 unterstützen, und testen Sie, ob die Properties, auf die Sie angewiesen sind, weitergeleitet werden.
Wie viele Verbindungen nutzt eine Bridge?
Eine Mosquitto-Bridge nutzt eine Verbindung zum Remote-Broker, unabhängig davon, wie viele lokale Geräte darüber publizieren. Eine Node-RED-Bridge nutzt eine Verbindung pro Broker-Konfigurationsknoten.
Was passiert mit Daten, wenn die Internetverbindung ausfällt?
Eine Mosquitto-Bridge speichert Nachrichten lokal bis zu max_queued_messages und leitet sie weiter, sobald die Verbindung zurückkehrt. Einfache Node-RED-Flows puffern nicht, sofern Sie das nicht ergänzen.
