Der sicherste Weg, HiveMQ Cloud Serverless ohne Serviceunterbrechung zu verlassen, besteht darin, beide Broker eine Zeit lang parallel zu betreiben und Nachrichten zwischen ihnen weiterzuleiten. Geräte und Anwendungen können dann gruppenweise umziehen, und ein Gerät, das noch an HiveMQ hängt, kommuniziert weiter mit einer Anwendung, die bereits umgezogen ist. Dieser Artikel zeigt, wie Sie dieses Relay aufbauen, wie Sie Nachrichtenschleifen vermeiden und wie Sie Clients vor der Frist am 31. Dezember 2026 in Wellen umziehen. Gerade in der Fertigung, wo ein Datenausfall schnell einen Linienstillstand bedeutet, ist dieser Ansatz der Standard.
Warum ein Relay nötig ist
Weder HiveMQ Cloud Serverless noch ein verwalteter Cloud-Broker wie ConnectMQ stellt für Sie auf Cloud-Seite eine Bridge zu einem anderen Broker her. Die Lösung ist ein kleiner Relay-Prozess, den Sie selbst betreiben: Er verbindet sich als gewöhnlicher MQTT-Client mit beiden Brokern, abonniert ausgewählte Topics auf der einen Seite und veröffentlicht sie auf der anderen erneut. Da er nur ein Client ist, funktioniert er mit jedem standardkonformen Broker und braucht keine besonderen Berechtigungen.
devices (still on HiveMQ) --> HiveMQ Serverless --relay--> ConnectMQ --> moved consumers
moved command senders --> ConnectMQ --relay--> HiveMQ Serverless --> devices
Wenn Sie vor Ort bereits Mosquitto betreiben, kann dessen Bridge-Funktion dieselbe Aufgabe übernehmen; siehe Mosquitto zu einem Cloud-MQTT-Broker migrieren und Mosquitto-Bridge-Konfiguration.
Das Schleifenproblem und wie Sie es vermeiden
Leitet das Relay das Topic site1/# von HiveMQ zu ConnectMQ und zugleich von ConnectMQ zu HiveMQ weiter, springt jede Nachricht endlos hin und her. Verhindern Sie Schleifen konstruktiv:
- Gerichtet weiterleiten. Telemetrie fließt in eine Richtung (alt nach neu), Befehle in die andere (neu nach alt). Leiten Sie denselben Topic-Filter nie in beide Richtungen weiter.
- MQTT 5 No Local bei Abonnements nutzen, damit das Relay seine eigenen Veröffentlichungen auf demselben Broker nicht empfängt.
- Weitergeleitete Nachrichten markieren, etwa mit der MQTT-5-User-Property
relayed=1, und Nachrichten verwerfen, die sie bereits tragen.
Das folgende Skript setzt alle drei Maßnahmen um.
Ein vollständiges Relay in Python
Dieses Relay nutzt paho-mqtt 2.x und MQTT 5 auf beiden Seiten. Telemetrie und Status fließen von HiveMQ zu ConnectMQ, Befehle von ConnectMQ zu HiveMQ.
# pip install "paho-mqtt>=2.0"
import os, ssl
import paho.mqtt.client as mqtt
from paho.mqtt.packettypes import PacketTypes
from paho.mqtt.properties import Properties
from paho.mqtt.subscribeoptions import SubscribeOptions
# Topic-Filter pro Richtung (denselben Filter nie in beiden Listen eintragen)
OLD_TO_NEW = ["site1/+/telemetry", "site1/+/status"]
NEW_TO_OLD = ["site1/+/cmd"]
def make_client(client_id, user, password):
c = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id=client_id, protocol=mqtt.MQTTv5)
c.username_pw_set(user, password)
c.tls_set(cert_reqs=ssl.CERT_REQUIRED)
c.reconnect_delay_set(min_delay=1, max_delay=60)
return c
old = make_client("relay-old-1", os.environ["HIVEMQ_USER"], os.environ["HIVEMQ_PASSWORD"])
new = make_client(os.environ["CMQ_CLIENT_ID"] + "_relay", os.environ["CMQ_USER"], os.environ["CMQ_PASSWORD"])
def is_relayed(msg):
props = getattr(msg, "properties", None)
return any(k == "relayed" for k, _ in (getattr(props, "UserProperty", None) or []))
def forward(target):
def on_message(client, userdata, msg):
if is_relayed(msg):
return
props = Properties(PacketTypes.PUBLISH)
props.UserProperty = [("relayed", "1")]
target.publish(msg.topic, msg.payload, qos=min(msg.qos, 1), retain=msg.retain, properties=props)
return on_message
def subscriber(filters):
def on_connect(client, userdata, flags, reason_code, properties):
print("verbunden:", reason_code, "abonniere", filters)
opts = SubscribeOptions(qos=1, noLocal=True)
for f in filters:
client.subscribe(f, options=opts)
return on_connect
old.on_connect, old.on_message = subscriber(OLD_TO_NEW), forward(new)
new.on_connect, new.on_message = subscriber(NEW_TO_OLD), forward(old)
old.connect(os.environ["HIVEMQ_HOST"], 8883)
new.connect("broker.connectmq.com", 8883)
new.loop_start()
old.loop_forever()
Betreiben Sie es auf einem zuverlässigen Host in der Nähe beider Broker, zum Beispiel auf einer kleinen Cloud-VM oder in einem Container, mit den Zugangsdaten in Umgebungsvariablen. QoS ist auf 1 begrenzt, damit das Relay auch im kostenlosen Serverless-Tarif funktioniert; ab Serverless (Paid) können Sie auf 2 erhöhen, wenn Ihre Datenflüsse das erfordern. Retain-Flags bleiben erhalten, sodass auf HiveMQ veröffentlichte Retained-Statusmeldungen auch auf ConnectMQ als retained erscheinen.
Zwei praktische Hinweise:
- Das Relay zählt auf jedem Broker als eine Verbindung. Berücksichtigen Sie es bei der Dimensionierung des neuen Tarifs.
- Überwachen Sie es wie ein Produktivsystem. Stoppt das Relay, stoppen auch die Nachrichten zwischen umgezogenen und noch nicht umgezogenen Clients. Betreiben Sie es unter systemd oder mit einer Neustart-Richtlinie für Container.
Der Wellenplan
Ziehen Sie Clients in einer Reihenfolge um, bei der jeder Datenfluss weiter funktioniert.
| Welle | Wer umzieht | Warum in dieser Reihenfolge |
|---|---|---|
| 0 | Das Relay startet | Beide Broker sehen dieselbe Telemetrie und dieselben Befehle |
| 1 | Backend-Consumer: Datenbanken, Regel-Engines, Node-RED, Dashboards | Sie erhalten Gerätedaten über das Relay |
| 2 | Eine Pilotgruppe von Geräten aus verschiedenen Standorten und Firmware-Versionen | Praxisvalidierung mit begrenztem Risiko |
| 3 bis N | Die übrigen Geräte in Gruppen nach Standort oder Produktlinie | Kontrollierter Rollout mit Kontrollpunkten |
| Final | Befehlsgeber, dann Relay stoppen | Die Geräte sind bereits auf dem neuen Broker |
Prüfen Sie nach jeder Welle:
- Die Verbindungszahl im ConnectMQ-Dashboard entspricht der Zahl der umgezogenen Clients.
- Die erwarteten Topics erscheinen im Live-Topic-Explorer – bei einem Unified Namespace (UNS) nach ISA-95 also jede Ebene von Standort bis Zelle.
- Der Verbindungsstatus pro Client unter
$SYS/broker/connection/{clientId}/statezeigt die umgezogenen Geräte als online. - Kein umgezogener Client verbindet sich noch mit HiveMQ (in der HiveMQ-Konsole prüfen).
- Die Verbindungszahl bleibt innerhalb der Tariflimits; MQTT-5-Clients erhalten
0x97, wenn ein Kontingent überschritten wird.
Rollback
Solange der alte Cluster noch läuft, lässt sich jede Welle zurückrollen, indem Sie die vorherigen Verbindungseinstellungen wiederherstellen. Halten Sie die alten Einstellungen in Ihrem Provisionierungssystem bereit, bis die letzte Welle abgeschlossen ist. Das ist der Hauptgrund, die Migration nicht auf die letzten Dezembertage zu verschieben: Nach dem 31. Dezember 2026 gibt es nichts mehr, wohin Sie zurückrollen könnten.
Checkliste für die Umschaltung
- Alle Geräte und Anwendungen laufen auf dem neuen Broker.
- Die HiveMQ-Konsole zeigt außer dem Relay keine Client-Verbindungen mehr.
- Der Retained-Zustand liegt auf dem neuen Broker vor, von Geräten erneut veröffentlicht oder aus einem Export wiederhergestellt. Siehe Datenlöschung bei HiveMQ Serverless.
- Stoppen Sie das Relay und beobachten Sie einen Tag lang, ob ein Client wieder bei HiveMQ auftaucht.
- Löschen Sie den HiveMQ-Serverless-Cluster und entfernen Sie den alten Hostnamen aus Konfiguration, Firmware-Standardwerten und Dokumentation.
Den gesamten Ablauf beschreibt der Migrationsleitfaden für HiveMQ Serverless. Sie können das Relay schon heute gegen einen kostenlosen Broker unter app.connectmq.com aufbauen und testen.
Häufig gestellte Fragen
Kann HiveMQ Cloud direkt eine Bridge zu ConnectMQ aufbauen?
Nicht auf Cloud-Seite. Betreiben Sie einen Relay-Client wie das obige Skript oder eine Mosquitto-Bridge auf Ihrer eigenen Infrastruktur, die sich als normaler MQTT-Client mit beiden Brokern verbindet.
Bemerken Geräte die Migration?
Umziehende Geräte sehen einen kurzen Reconnect, wenn sich ihre Einstellungen ändern. Geräte, die noch nicht umgezogen sind, bemerken gar nichts, weil das Relay ihre Daten weiter zu den umgezogenen Anwendungen leitet.
Erhöht das Relay die Latenz?
Es fügt einen zusätzlichen Hop hinzu, typischerweise einige bis einige Dutzend Millisekunden, je nachdem, wo es läuft. Platzieren Sie es nahe an beiden Brokern und entfernen Sie es nach Abschluss der Migration.
Sollte das Relay QoS 1 oder QoS 2 verwenden?
QoS 1 ist ein guter Standard und funktioniert in jedem ConnectMQ-Tarif. Stellen Sie sicher, dass Consumer gelegentliche Duplikate verkraften, die QoS 1 zulässt. Nutzen Sie QoS 2 nur, wo Duplikate inakzeptabel sind und Ihr Tarif es unterstützt.
