MQTT vom Prototyp zur Produktion: Ein Migrationspfad Schritt für Schritt

Einen MQTT-Prototyp in die Produktion zu bringen heißt vor allem, die Lücken zu schließen, die eine Demo ignorieren kann: wer sich verbinden darf, wer die Daten lesen kann, wie Topics organisiert sind und wie Sie erfahren, dass etwas kaputtgegangen ist. Dieser Leitfaden führt ein typisches Pilotprojekt, ob Bastelaufbau oder erster Industrie-4.0-Versuch an einer Maschine im Mittelstand, vom öffentlichen MQTT-Broker zu einem privaten, TLS-geschützten Broker mit sauberem Namespace und grundlegendem Monitoring, und zwar in der Reihenfolge, die am wenigsten Nacharbeit verursacht.

Der Ausgangspunkt: ein funktionierender Prototyp

Die meisten MQTT-Projekte beginnen gleich. Ein Sensor oder ein ESP32 publiziert JSON an einen öffentlichen MQTT-Broker, auf einem Laptop läuft mosquitto_sub oder ein Node-RED-Flow, und die Daten erscheinen. Ein typischer Prototyp sieht so aus:

mosquitto_pub -h broker.connectmq.com -p 1883 -i proto-dev-x9f3 \
  -t "connectmq/demo/x9f3/temp" -m '{"c":22.1}'

Das ist ein völlig guter Start. Produktionsreif ist es jedoch nicht, und zwar aus fünf Gründen:

1. Keine Authentifizierung. Jeder kann sich verbinden; der öffentliche MQTT-Broker broker.connectmq.com ist für alle lesbar und nur für Tests und Prototypen gedacht.
2. Keine Verschlüsselung. Port 1883 überträgt Zugangsdaten und Payloads im Klartext.
3. Spontan entstandene Topics. Der Topic-Baum ist organisch gewachsen und übersteht nicht mehr als eine Handvoll Geräte.
4. Keine Präsenzerkennung. Sie können ein Offline-Gerät nicht von einem ruhigen unterscheiden.
5. Keine Transparenz. Wenn keine Daten mehr kommen, merken Sie es daran, dass ein Diagramm flach aussieht.

Die folgenden Schritte schließen nacheinander jede dieser Lücken.

Schritt 1: Auf private Zugangsdaten umstellen

Erstellen Sie ein Konto unter app.connectmq.com, wählen Sie einen Plan, erstellen Sie einen Broker und kopieren Sie den generierten Benutzernamen, das Passwort und die Client ID. Der kostenlose Serverless-Plan reicht für ein Pilotprojekt mit bis zu 25 Verbindungen; der kostenpflichtige Serverless-Plan erhöht das auf 1.000 und ergänzt QoS 2, Nachrichten bis 1 MB und Shared Subscriptions.

Zwei Regeln machen den Rest der Migration schmerzlos:

• Ein Satz Zugangsdaten pro Gerät oder Dienst. Client IDs sind an ausgegebene Zugangsdaten gebunden; teilen sich zwei Geräte einen Satz, trennen sie sich gegenseitig.
• Zugangsdaten gehören nicht in die Versionsverwaltung. Laden Sie sie aus Umgebungsvariablen, aus einer von git ausgeschlossenen Secrets-Datei oder über einen Provisionierungsschritt im Werk.

# .env (diese Datei niemals committen)
MQTT_HOST=broker.connectmq.com
MQTT_PORT=8883
MQTT_USERNAME=YOUR_USERNAME
MQTT_PASSWORD=YOUR_PASSWORD
MQTT_CLIENT_ID=YOUR_CLIENT_ID

Schritt 2: TLS überall aktivieren

Produktiver Traffic sollte für Geräte TLS auf Port 8883 und für Browser Secure WebSocket auf Port 8084 mit dem Pfad /mqtt verwenden. ConnectMQ nutzt ein Let's-Encrypt-Zertifikat, dem die meisten Betriebssysteme und Laufzeitumgebungen bereits vertrauen. Auf Mikrocontrollern betten Sie üblicherweise das ISRG-Root-X1-Zertifikat ein; unser ESP32-MQTT-SSL-Leitfaden zeigt die Details.

Hier ist der Prototyp-Publisher, für die Produktion in Python mit paho-mqtt 2.x neu geschrieben. Er liest die Zugangsdaten aus der Umgebung, verbindet sich über TLS mit MQTT 5, setzt einen Last Will, damit der Broker unerwartete Verbindungsabbrüche melden kann, und publiziert einen Retained-Online-Status.

import json
import os
import time

import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes

HOST = os.environ["MQTT_HOST"]
PORT = int(os.environ.get("MQTT_PORT", "8883"))
CLIENT_ID = os.environ["MQTT_CLIENT_ID"]
BASE = "acme/site1/greenhouse/zone2/sensor-01"   # Produktions-Namespace

def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("connect failed:", reason_code)
        return
    print("connected")
    client.publish(f"{BASE}/status", "online", qos=1, retain=True)

def on_disconnect(client, userdata, flags, reason_code, properties):
    print("disconnected:", reason_code)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                     client_id=CLIENT_ID, protocol=mqtt.MQTTv5)
client.username_pw_set(os.environ["MQTT_USERNAME"], os.environ["MQTT_PASSWORD"])
client.tls_set()
client.will_set(f"{BASE}/status", "offline", qos=1, retain=True)
client.reconnect_delay_set(min_delay=1, max_delay=60)
client.on_connect = on_connect
client.on_disconnect = on_disconnect

connect_props = Properties(PacketTypes.CONNECT)
connect_props.SessionExpiryInterval = 3600   # Sitzung eine Stunde offline aufbewahren

client.connect(HOST, PORT, keepalive=60, properties=connect_props)
client.loop_start()

try:
    while True:
        reading = {"ts": int(time.time()), "temp_c": 22.1, "rh": 61}
        client.publish(f"{BASE}/telemetry", json.dumps(reading), qos=1)
        time.sleep(30)
except KeyboardInterrupt:
    client.publish(f"{BASE}/status", "offline", qos=1, retain=True).wait_for_publish()
    client.disconnect()
    client.loop_stop()

Beachten Sie, wie wenig sich gegenüber dem Prototyp geändert hat: Hostname, Port, Zugangsdaten, TLS und einige Properties. Genau darum geht es, wenn man durchgängig Standard-MQTT verwendet.

Schritt 3: Einen produktiven Topic-Namespace entwerfen

Ein Prototyp-Topic wie connectmq/demo/x9f3/temp funktioniert für einen Sensor. Ein produktiver Namespace muss neue Standorte, neue Gerätetypen und neue Consumer überstehen, ohne dass etwas umbenannt werden muss. Eine gute Struktur geht vom Allgemeinen zum Spezifischen und trennt Daten von Befehlen und Status.

Praktische Regeln, die später Ärger ersparen:

• Ebenen kleinschreiben, keine Leerzeichen, kein führender Schrägstrich.
• Die Geräte-ID ins Topic aufnehmen, nicht nur in den Payload, damit Subscriber mit Wildcards filtern können.
• Einen eigenen cmd-Zweig für Befehle verwenden, damit Geräte eng abonnieren.
• Status-Topics als Retained Messages publizieren, damit spät hinzukommende Subscriber den aktuellen Zustand sofort sehen.
• Die Tiefe vernünftig halten; der öffentliche MQTT-Broker erlaubt 8 Ebenen, was überall ein sinnvolles Budget ist.

Wenn Ihr Projekt industriell ist, sollten Sie sich von Anfang an an den ISA-95-Ebenen orientieren und den Namespace als Unified Namespace (UNS) anlegen: Die ISA-95-Ausrüstungshierarchie (Enterprise → Site → Area → Line → Cell) wird zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. So können später MES, SCADA, Historian und ERP-Anbindung denselben Baum abonnieren, ohne dass Geräte umbenannt werden müssen. Der Leitfaden zu Sparkplug B und Unified Namespace erklärt das Muster. Die Geräteansicht von ConnectMQ gruppiert Clients nach ISA-95-Ebenen, wenn Ihre Topics diesem Muster folgen. Unser Leitfaden zur MQTT-Topic-Struktur im Smart Home behandelt Projekte im Wohnbereich.

Schritt 4: Gerätepräsenz verfolgen

Retained-Statusmeldungen online und offline mit einem Last Will, wie im obigen Code, geben jedem Subscriber eine verlässliche Sicht darauf, welche Geräte verbunden sind. Sie können den Zustand auch brokerseitig über $SYS/broker/connection/{clientId}/state beobachten, was für einen Backend-Dienst nützlich ist, der wissen muss, wann ein bestimmter Client wegfällt.

mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
  -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -V mqttv5 \
  -t 'acme/site1/+/+/+/status' -v

Schritt 5: Monitoring und Alarme ergänzen

Produktion bedeutet, dass jemand von Problemen erfährt, bevor die Nutzer es tun. Beginnen Sie einfach:

• Nutzen Sie das Portal-Dashboard und den Live-Topic-Explorer, um nach jeder Bereitstellung zu bestätigen, dass Daten fließen.
• Legen Sie Schwellwert-Alarmregeln für relevante Werte an, etwa eine Temperatur außerhalb des Sollbereichs, und prüfen Sie das Alarmprotokoll.
• Protokollieren Sie auf jedem Client die MQTT-5-Reason-Codes, damit Kontingent- und Autorisierungsprobleme diagnostizierbar sind.
• Wenn Sie Langzeitspeicherung oder eigene Benachrichtigungen brauchen, betreiben Sie einen eigenen Subscriber, etwa einen Python-Dienst, Telegraf oder Node-RED, der sich als normaler MQTT-Client mit dem Broker verbindet und in Ihre Datenbank oder Ihr Messaging-Tool schreibt.

Eine ausführlichere Liste finden Sie in unserem Leitfaden zum Monitoring von MQTT-Brokern.

Die Checkliste zur Produktionsreife

Bestätigen Sie vor dem Go-live jeden Punkt:

1. Jedes Gerät und jeder Dienst hat eigene Zugangsdaten und eine eigene Client ID.
2. Alle Verbindungen nutzen TLS (8883) oder Secure WebSocket (8084).
3. Keine Zugangsdaten liegen in der Versionsverwaltung der Firmware.
4. Der Topic-Namespace ist dokumentiert und beginnt mit einer Organisations- oder Mandantenebene.
5. Geräte publizieren einen Retained-Status mit Last Will.
6. Die Reconnect-Logik nutzt exponentielles Backoff mit Jitter.
7. Payloads bleiben deutlich unter dem Limit für die Nachrichtengröße des Plans.
8. Befehle nutzen mindestens QoS 1 und dürfen gefahrlos zweimal ankommen.
9. Sie haben einen Plan für Firmware-Updates, die Zugangsdaten rotieren.
10. Alarme erreichen einen Menschen, wenn sich wichtige Werte oder die Gerätepräsenz ändern.

Ist die Liste abgearbeitet, gehen die MQTT-Produktions-Checkliste und die Best Practices für MQTT-Sicherheit bei der Härtung noch weiter.

Den richtigen Plan für die Produktion wählen

Beginnen Sie mit dem kleinsten Plan, der Ihre Verbindungszahl mit Reserve abdeckt. Wechseln Sie zu Serverless (Paid), wenn Sie mehr als 25 Verbindungen, QoS 2, größere Nachrichten oder Shared Subscriptions für Backend-Consumer brauchen. Wählen Sie Dedicated für einen isolierten Cluster, BYOC, wenn der Broker in Ihrem eigenen Cloud-Konto laufen muss, und Self Managed Enterprise, wenn Sie ihn selbst betreiben müssen. Der Leitfaden zum Cloud-MQTT-Broker vergleicht diese Hosting-Modelle ausführlicher.

Bringen Sie Ihren Prototyp mit ConnectMQ in die Produktion

ConnectMQ bietet Ihnen private Zugangsdaten, TLS, MQTT 5 und ein Portal mit Live-Topic-Explorer und Alarmregeln, auf demselben Standard-MQTT, das Ihr Prototyp bereits spricht. Registrieren Sie sich unter app.connectmq.com, erstellen Sie ohne Kreditkarte einen Broker im kostenlosen Serverless-Plan und richten Sie Ihren Prototyp in wenigen Minuten darauf aus. Wenn Sie überhaupt keine Infrastruktur selbst betreiben möchten, ist ein verwalteter MQTT-Broker der kürzeste Weg.

Häufig gestellte Fragen

Kann ich den öffentlichen MQTT-Broker weiterhin in der Produktion nutzen?

Nein. Der öffentliche MQTT-Broker broker.connectmq.com ist für alle lesbar und hat enge Limits pro Client, er ist also nur zum Testen gedacht. Produktionsdaten gehören auf einen privaten Broker mit Zugangsdaten und TLS.

Muss ich meinen Gerätecode für die Produktion ändern?

Meist ändern sich nur die Verbindungseinstellungen: Hostname, Port 8883, Zugangsdaten und TLS. Die Topic-Namen ändern sich, wenn Sie einen neuen Namespace einführen, was sich vor dem Skalieren lohnt.

Wie gehe ich mit Zugangsdaten auf vielen Geräten um?

Geben Sie einen Satz Zugangsdaten pro Gerät aus, laden Sie ihn bei der Provisionierung, statt ihn in eine gemeinsame Firmware einzukompilieren, und führen Sie Buch darüber, damit Sie ein einzelnes Gerät sperren können, ohne die anderen anzufassen.

Welchen Plan sollte ein kleines Pilotprojekt nutzen?

Ein Pilotprojekt mit bis zu 25 gleichzeitigen Verbindungen passt in den kostenlosen Serverless-Plan. Wechseln Sie zu Serverless (Paid), wenn Sie mehr Verbindungen, QoS 2 oder größere Nachrichten brauchen.