MQTT für IoT SaaS auf einem verwalteten MQTT-Broker

Mit MQTT für IoT-SaaS liefern Sie Gerätedaten in Echtzeit aus einem einzigen Produkt an viele Kunden, allerdings nur, wenn Sie diese Kunden vom ersten Gerät an korrekt voneinander trennen. Dieser Leitfaden zeigt, wie Sie ein Isolationsmodell wählen, Zugangsdaten und Topic-Präfixe entwerfen, Geräte onboarden und Ihr Backend auf einem verwalteten MQTT-Broker strukturieren, damit Sie schneller starten und ohne Neuarchitektur skalieren.

Wie eine IoT-SaaS-Plattform aufgebaut ist

Die meisten IoT-SaaS-Produkte folgen demselben Muster. Geräte im Feld publizieren Telemetrie und Status. Ein Backend abonniert, speichert Daten, wertet Logik aus und stellt eine API bereit. Eine Web- oder Mobile-App zeigt jedem Kunden nur seine eigenen Geräte und schickt Befehle zurück. MQTT sitzt in der Mitte, weil es mit unterbrochener Konnektivität, kleinen Payloads und bidirektionaler Kommunikation gut umgeht. Im DACH-Raum sind typische Beispiele Maschinenbauer, die ihren Kunden Zustandsüberwachung, Predictive Maintenance oder Energiemonitoring als Service anbieten. Wenn das Protokoll neu für Sie ist, beginnen Sie damit, was ein MQTT-Broker tut.

Der Broker ist gemeinsame Infrastruktur Ihres Unternehmens, die Daten darauf gehören jedoch Ihren Kunden. Daraus ergeben sich drei Designentscheidungen:

Wie stark werden Kunden am Broker voneinander getrennt?
Wie werden Geräte identifiziert und authentifiziert?
Wie sind Topics strukturiert, damit Ihr Backend Daten pro Kunde routen kann?

Entscheidung 1: ein Isolationsmodell für Kunden wählen

Modell A: ein Broker pro Kunde

Jeder Kunde erhält einen eigenen Broker mit eigenen Endpunkt-Zugangsdaten und eigenem Topic-Raum. Geräte von Kunde A können die Topics von Kunde B physisch nicht abonnieren, weil sie sich nicht im selben Broker-Namespace befinden. Ihr Backend verbindet sich als Client mit jedem Kunden-Broker.

Das bietet die stärkste Trennung und macht kundenbezogene Limits, Offboarding und Datenlöschung einfach: Broker löschen. Der Preis dafür sind mehr Broker in der Bereitstellung und ein Backend, das viele Verbindungen verwaltet.

Modell B: ein gemeinsamer Broker mit Topic-Präfixen

Die Geräte aller Kunden verbinden sich mit einem Broker, und die Topics jedes Kunden beginnen mit einem Präfix wie acme/ oder einer Kunden-ID. Ihr Backend abonniert +/devices/+/telemetry und leitet den Kunden aus der ersten Topic-Ebene ab.

Das ist einfach und effizient, doch ein Topic-Präfix allein ist eine Ordnungskonvention, keine Grenze der Zugriffskontrolle. Wenn ein beliebiges Gerät am Broker # abonnieren kann, sieht es die Daten aller Kunden. Nutzen Sie dieses Modell nur, wenn Sie die gesamte Geräte-Firmware kontrollieren und nichts Kundenseitiges sich direkt mit dem Broker verbindet, oder wenn Ihr Broker mandantenbezogene Topic-Beschränkungen durchsetzt.

Modell C: gestaffelt

Kleinere Kunden teilen sich einen Broker, während große oder regulierte Kunden einen eigenen Broker, einen dedizierten Cluster oder ein Deployment in ihrem eigenen Cloud-Account erhalten. Das spiegelt wider, wie viele SaaS-Unternehmen ihre Pläne bepreisen.

Modell	Stärke der Trennung	Betriebsaufwand	Am besten für
A: Broker pro Kunde	Stark, vom Broker durchgesetzt	Mittel	B2B-Produkte, kundenseitiger Zugriff
B: gemeinsamer Broker, Präfixe	Hängt von der Durchsetzung ab	Gering	Vollständig kontrollierte Firmware, nur interne Daten
C: gestaffelt	Stark, wo es darauf ankommt	Mittel	Produkte mit Self-Service- und Enterprise-Stufen

Die zugrunde liegenden Konzepte behandeln die Artikel zur MQTT-Mandantentrennung und zur Architektur eines mandantenfähigen MQTT-Brokers.

Entscheidung 2: Design der Zugangsdaten

Ihr Modell für Zugangsdaten bestimmt, wie sicher Sie Geräte onboarden, sperren und rotieren können.

Client IDs pro Gerät. Jedes Gerät braucht eine eindeutige, stabile Client ID. Leiten Sie sie aus einer Seriennummer oder einem Provisionierungsdatensatz ab, niemals aus einem beim Booten erzeugten Zufallswert, sonst werden persistente Sitzungen nicht fortgesetzt.
Keine Zugangsdaten in öffentlichen Repositories oder App-Bundles. Mobile und Web-Apps sollten keine gerätebezogenen Broker-Zugangsdaten enthalten. Lassen Sie sie Ihre API aufrufen und das Backend mit dem Broker sprechen, oder stellen Sie kurzlebige, eingeschränkte Zugangsdaten aus, sofern Ihr Broker das unterstützt.
Sperrpfad. Wenn ein Kunde kündigt oder ein Gerät gestohlen wird, müssen Sie es abschneiden können, ohne andere Geräte anzufassen.
Rotationspfad. Planen Sie, wie die Firmware neue Zugangsdaten erhält, etwa über ein authentifiziertes Konfigurations-Topic oder während eines OTA-Updates.

Entscheidung 3: Topic-Design für das Routing mehrerer Kunden

Ein vorhersehbarer Topic-Baum hält das Backend einfach und Wildcard-Subscriptions sicher. Ein Muster, das sich bewährt:

<customer>/<site>/<device-id>/telemetry
<customer>/<site>/<device-id>/status
<customer>/<site>/<device-id>/cmd
<customer>/<site>/<device-id>/cmd/response

Leitlinien:

Setzen Sie den Kunden an den Anfang, sodass eine Wildcard pro Ebene eine vollständige Kundensicht ergibt.
Halten Sie Bezeichner stabil, kleingeschrieben und ohne Leerzeichen.
Nutzen Sie Retained Messages auf status, damit Dashboards den letzten bekannten Zustand sofort sehen.
Verwenden Sie für Befehl-Antwort-Abläufe die Response Topics und Correlation Data von MQTT 5, statt etwas Eigenes zu erfinden.
Vermeiden Sie personenbezogene Daten in Topic-Namen; Topics tauchen in Logs und Tools auf.

Für Industriekunden lohnt es sich, diese Struktur an der ISA-95-Hierarchie auszurichten. Kunde und Standort entsprechen den Ebenen Enterprise und Site; ergänzen Sie Area, Line und Cell, entsteht pro Kunde ein Unified Namespace (UNS), etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Ihr Produkt spricht damit dieselbe Sprache wie die MES- und SCADA-Systeme des Kunden, und Daten lassen sich später ohne Umbenennung in dessen eigenen UNS übernehmen. Hintergründe liefert Sparkplug B und Unified Namespace.

In Modell A ergibt sich die Kundenebene implizit aus dem Broker, sodass Sie sie im Topic weglassen oder aus Gründen der Konsistenz über alle Stufen hinweg beibehalten können.

Ein minimaler Ingest-Service im Backend

Das Backend abonniert, validiert und speichert. Dieses Python-Beispiel mit paho-mqtt 2.x und MQTT 5 nimmt Telemetrie von einem gemeinsamen Broker entgegen und extrahiert den Kunden aus dem Topic. Auf ConnectMQ Serverless (Paid) können Sie solche Ingest-Worker mit einer Shared Subscription wie $share/ingest/+/+/+/telemetry horizontal skalieren, die Nachrichten auf die Worker verteilt.

import json
import ssl
import paho.mqtt.client as mqtt

SUBSCRIPTION = "+/+/+/telemetry"   # in Plänen mit Shared Subscriptions $share/ingest/+/+/+/telemetry verwenden

def store(customer, site, device, data):
    # Durch Ihren Datenbank-Schreibvorgang ersetzen
    print(f"[{customer}] {site}/{device}: {data}")

def on_connect(client, userdata, flags, reason_code, properties):
    print("Ingest connected:", reason_code)
    client.subscribe(SUBSCRIPTION, qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    if len(parts) != 4:
        return
    customer, site, device, _ = parts
    try:
        data = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("Rejected non-JSON payload on", msg.topic)
        return
    store(customer, site, device, data)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883, keepalive=60)
client.loop_forever()

Integrationen wie Datenbanken, Benachrichtigungen oder Analytics hängen an diesem Service oder an Tools wie Node-RED und Telegraf, die sich als gewöhnliche MQTT-Clients mit dem Broker verbinden.

Auf ConnectMQ aufbauen

ConnectMQ ist ein verwalteter MQTT-Broker, der zu jedem dieser Modelle passt. Jeder Broker, den Sie anlegen, erhält generierte Zugangsdaten und eine daran gebundene Client ID, und Broker sind auf dem geteilten Cluster voneinander isoliert. Damit ist Modell A unkompliziert: Legen Sie pro Kunde einen Broker an, speichern Sie dessen Zugangsdaten in Ihrem Backend und verbinden Sie Ihren Ingest-Service mit jedem davon.

Die Planlimits lassen sich natürlich auf SaaS-Stufen abbilden. Der kostenlose Serverless-Plan unterstützt bis zu 25 Verbindungen, QoS bis 1 und Nachrichten bis 256 KB, ideal für Entwicklung und Pilotkunden. Serverless (Paid) unterstützt bis zu 1.000 Verbindungen, QoS 2, Nachrichten bis 1 MB und Shared Subscriptions. Dedicated gibt einem Kunden einen isolierten Cluster, und BYOC betreibt den Broker in einem Cloud-Account, den Sie oder Ihr Kunde kontrollieren, verwaltet von ConnectMQ.

Auch Support-Teams profitieren vom Portal: Mit dem Live-Topic-Explorer und dem MQTT-Client im Browser sehen Sie, was die Geräte eines Kunden tatsächlich senden, die Geräteansicht gruppiert Anlagen für Industriekunden nach ISA-95-Ebenen und passt damit zu einem UNS-Topic-Baum, und Schwellenwert-Alarmregeln mit einem Alarmprotokoll markieren Werte außerhalb des zulässigen Bereichs.

Launch-Checkliste für Ihr IoT-SaaS

Isolationsmodell pro Preisstufe gewählt und dokumentiert.
Eindeutige Client ID und Zugangsdaten pro Gerät, mit einem Sperrverfahren.
Topic-Baum dokumentiert und im Backend validiert.
Ausschließlich TLS auf Port 8883 (Geräte) und 8084 (Browser-Clients).
Reconnect mit exponentiellem Backoff und Jitter in jeder Firmware.
Ingest-Service, wo verfügbar, mit Shared Subscriptions skaliert.
Separater Staging-Broker für Firmware- und Backend-Tests.
Monitoring und Alerting für Verbindungen und Nachrichtenfluss pro Kunde; siehe die MQTT-Produktions-Checkliste.

Starten Sie mit ConnectMQ

Bauen Sie den Prototyp Ihres SaaS auf einem kostenlosen Serverless-Broker unter app.connectmq.com, ganz ohne Kreditkarte, und fügen Sie pro gewonnenem Kunden einen Broker hinzu. Sie können Ideen auch auf dem öffentlichen MQTT-Broker mit Testdaten ausprobieren, bevor Sie ein Konto anlegen, und im Leitfaden zum Cloud-MQTT-Broker Hosting-Optionen vergleichen.

Häufig gestellte Fragen

Sollte jeder SaaS-Kunde einen eigenen MQTT-Broker erhalten?

Ja, wenn Kunden oder ihre Apps sich direkt verbinden oder Verträge eine Trennung verlangen. Ein Broker pro Kunde bietet durchgesetzte Isolation und einfaches Offboarding.

Reichen Topic-Präfixe aus, um Kunden zu trennen?

Sie ordnen Daten, schützen sie aber nur, wenn der Broker durchsetzt, welche Präfixe jeder Client verwenden darf. Ohne Durchsetzung würde jeder Client, der # abonniert, alles sehen.

Wie skaliere ich das Backend, das Gerätedaten verarbeitet?

Betreiben Sie mehrere Ingest-Worker mit einer Shared Subscription aus MQTT 5, damit der Broker die Nachrichten zwischen ihnen verteilt.

Kann sich meine Mobile-App direkt mit dem Broker verbinden?

Das geht über Secure WebSocket auf Port 8084, doch betten Sie keine Geräte-Zugangsdaten in die App ein. Leiten Sie über Ihre API oder nutzen Sie eingeschränkte Zugangsdaten pro Nutzer.

MQTT für IoT-SaaS: eine Plattform für viele Kunden auf einem verwalteten MQTT-Broker