IoT-Plattform vs. MQTT-Broker: Brauchen Sie beides?

Die Frage IoT-Plattform vs. MQTT-Broker verwirrt viele Teams, weil sich beides überschneidet und Anbieter die Begriffe locker verwenden. Dieser Artikel trennt die Ebenen klar voneinander, erklärt, was eine vollständige IoT-Plattform über einen Broker hinaus bietet, und gibt Ihnen einen praktischen Weg an die Hand, um zu entscheiden, ob Sie eine Plattform brauchen oder ob ein schlanker verwalteter MQTT-Broker plus einige offene Tools Ihr Projekt abdeckt.

Zwei verschiedene Ebenen

Ein MQTT-Broker ist ein Nachrichten-Router. Clients verbinden sich, veröffentlichen Nachrichten auf Topics und abonnieren Topics; der Broker stellt jede Nachricht mit der angeforderten QoS jedem passenden Subscriber zu. Er verwaltet Sessions, Retained Messages, Will Messages und mit MQTT 5 Funktionen wie Shared Subscriptions und Message Expiry. Wenn Sie eine Auffrischung brauchen, lesen Sie, was ein MQTT-Broker leistet.

Eine IoT-Plattform ist ein Bündel von Diensten rund um einen Messaging-Kern. Je nach Produkt ergänzt sie einige oder alle der folgenden Bausteine:

Geräteregistrierung, Provisioning und Identitätsverwaltung.
Dienste für den Gerätezustand wie Shadows oder Twins.
Orchestrierung von Firmware-Updates over the air.
Rule Engines, die Daten filtern, transformieren und weiterleiten.
Zeitreihenspeicherung und historische Abfragen.
Dashboards, Alarme und Benachrichtigungen.
Benutzerverwaltung, Mandantenfähigkeit für Ihre eigenen Kunden und Anwendungs-APIs.

Viele Plattformen enthalten einen MQTT-Endpunkt, manchmal einen vollwertigen Broker und manchmal ein Gateway von Gerät zu Cloud mit festen Topics. Der Wert der Plattform liegt in der Integration all dieser Teile.

IoT-Plattform vs. MQTT-Broker im Vergleich

Fähigkeit	Nur MQTT-Broker	Vollständige IoT-Plattform	Schlanker Broker plus offene Tools
Echtzeit-Pub/Sub	Ja	Meist, teils nur von Gerät zu Cloud	Ja
Geräteidentität	Zugangsdaten pro Client	Registrierung mit Lebenszyklus	Zugangsdaten plus eigenes Inventar
Gerätezustand	Retained Messages	Shadow- oder Twin-Dienst	Retained Status-Topics
Datenverarbeitung	Nein	Integrierte Regeln	Node-RED, kleine Dienste
Speicherung und Historie	Nein	Integriert	InfluxDB, TimescaleDB, PostgreSQL
Dashboards	Nur Broker-Konsole	Integriert	Grafana, Node-RED Dashboard
Alarme	Abhängig vom Broker	Integriert	Broker-Alarme oder Grafana-Alerting
Firmware-Updates	Nein	Oft integriert	Separate OTA-Tools
Portabilität	Hoch	Oft geringer	Hoch
Aufwand für den Einstieg	Gering	Gering bis mittel	Mittel

Die mittlere Spalte ist bequem und folgt festen Vorgaben. Die rechte Spalte erfordert etwas mehr Zusammenbau, lässt aber jeden Teil austauschbar.

Wann eine vollständige IoT-Plattform die richtige Wahl ist

Eine Plattform rechtfertigt ihre Kosten und Einschränkungen, wenn:

Sie Lebenszyklusverwaltung für Geräte in großem Maßstab brauchen, etwa Massen-Provisioning, Zertifikatsrotation und gestaffelte OTA-Updates über viele Gerätetypen hinweg.
Ihnen die Leute fehlen, um Komponenten zu integrieren, und Sie einen einzigen Anbieter für den gesamten Stack verantwortlich machen wollen.
Ihr Backend bereits in der Cloud dieser Plattform läuft und die Daten mit minimalem Verbindungscode dort landen sollen.
Sie ein Produkt für mehrere Kunden entwickeln und das Mandanten-, Benutzer- und API-Modell der Plattform zu Ihrem passt.

Wählen Sie in diesen Fällen die Plattform bewusst und lesen Sie MQTT-Vendor-Lock-in, um die Geräte-Firmware so portabel wie möglich zu halten.

Wann ein schlanker Broker genügt

Ein verwalteter MQTT-Broker plus einige offene Tools ist oft die bessere Wahl, wenn:

Ihr Kernbedarf die Bewegung von Live-Daten ist, zwischen Maschinen, Gateways, Apps und Dashboards.
Sie bereits Tools nutzen wie Node-RED, Grafana, Telegraf oder eine Zeitreihendatenbank.
Sie einen Unified Namespace (UNS) aufbauen und die Topic-Hierarchie vollständig selbst verantworten wollen. In der Fertigung folgt diese Hierarchie meist ISA-95: Unternehmen → Standort → Bereich → Linie → Zelle wird zur Topic-Struktur, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur. Eine Plattform mit festen Topic-Vorgaben passt dazu oft schlecht; Details zu diesem Muster finden Sie unter Sparkplug B und der Unified Namespace.
Ihnen Portabilität wichtig ist, über Clouds und On-Premises-Systeme hinweg.
Ihre Flotte überschaubar ist und die Geräteverwaltung in einem einfachen Inventar Platz findet.

ConnectMQ ist für dieses Muster konzipiert. Es ist ein verwalteter MQTT-Broker mit MQTT 3.1.1 und 5.0, TLS und Secure WebSocket sowie einem Portal, das mehrere „plattformähnliche" Grundfunktionen abdeckt, ohne zur Plattform zu werden: einen MQTT-Client im Browser, einen Live-Topic-Explorer, ein Dashboard, eine Geräteansicht nach ISA-95-Ebenen passend zum UNS, Schwellwert-Alarmregeln mit Alarmprotokoll, Sparkplug-B-Dekodierung und das erneute Veröffentlichen in ISA-95-Topics. Bewusst nicht enthalten sind eine Rule Engine, Webhooks oder Datenbank-Bridges; diese Aufgaben übernehmen externe Tools.

Eine schlanke Referenzarchitektur

Ein gängiger, vollständig offener Stack rund um einen verwalteten MQTT-Broker sieht so aus:

Devices / PLC gateways --MQTT/TLS--> Verwalteter MQTT-Broker (ConnectMQ)
                                         |
         +-------------------------------+-----------------------------+
         |                               |                             |
   Telegraf (mqtt_consumer)        Node-RED flows               Browser apps (WSS 8084)
         |                         (logic, alerts, APIs)
   InfluxDB (time series)
         |
   Grafana (dashboards, alerting)

Jede Komponente verbindet sich als gewöhnlicher MQTT-Client mit dem Broker. Sie können jede davon ersetzen, ohne die Geräte anzufassen.

Beispiel: Telemetrie mit Telegraf speichern

Der MQTT-Consumer-Input von Telegraf kann Ihren Broker abonnieren und allein per Konfiguration in InfluxDB schreiben:

# telegraf.conf
[[inputs.mqtt_consumer]]
  servers = ["ssl://broker.connectmq.com:8883"]
  topics = ["acme/plant1/+/+/telemetry"]
  qos = 1
  client_id = "YOUR_CLIENT_ID"
  username = "YOUR_USERNAME"
  password = "YOUR_PASSWORD"
  data_format = "json"
  topic_tag = "topic"

[[outputs.influxdb_v2]]
  urls = ["http://localhost:8086"]
  token = "${INFLUX_TOKEN}"
  organization = "acme"
  bucket = "telemetry"

Starten Sie Telegraf und prüfen Sie, ob Datenpunkte ankommen:

export INFLUX_TOKEN=your-influx-token
telegraf --config telegraf.conf --test   # einmalige Prüfung des Parsings
telegraf --config telegraf.conf          # dauerhaft ausführen

Bei JSON-Payloads wie {"temp": 72.4, "rpm": 1450} werden numerische Felder zu InfluxDB-Feldern, und das Topic wird zu einem Tag, nach dem Sie in Grafana filtern können. Denken Sie daran, dass jede gleichzeitige Verbindung eigene Zugangsdaten und eine eigene Client-ID braucht; bei ConnectMQ sind Client-IDs an die ausgegebenen Zugangsdaten gebunden.

Versteckte Kosten auf beiden Seiten

Keiner der beiden Wege ist frei von Kompromissen, und es hilft, sie vor der Entscheidung zu benennen.

Bei einer vollständigen Plattform sind die versteckten Kosten meist konzeptioneller und vertraglicher Art. Ihr Team lernt das Modell der Plattform für Geräte, Regeln und Zustand, und dieses Wissen lässt sich nicht anderswohin übertragen. Die Preise wachsen oft in mehreren Dimensionen zugleich, etwa Verbindungen, Nachrichten, Regelausführungen und Speicher, was Prognosen erschwert. Und Funktionen, die Sie nicht nutzen, prägen trotzdem, wie Sie die genutzten gestalten.

Bei einem schlanken Broker plus Tools sind die versteckten Kosten betrieblicher Art. Jemand muss Node-RED, die Zeitreihendatenbank und Grafana betreiben, aktuell halten und sichern. Integrationsentscheidungen wie Topic-Benennung und Payload-Formate müssen Sie selbst dokumentieren und durchsetzen. Für ein kleines Team ist das beherrschbar; in einer großen Organisation ohne Plattform-Team kann es zersplittern.

Der praktische Test: Skizzieren Sie die nächsten zwei Jahre. Wie viele Geräte, welche Datenziele, und wer pflegt welchen Teil? Die Option, deren Wartungsaufwand zu Ihrem Team passt, ist meist die richtige.

Entscheidungs-Checkliste

Beantworten Sie jede Frage mit Ja oder Nein:

Brauchen Sie OTA-Firmware-Orchestrierung für eine große Flotte aus einer einzigen Konsole?
Brauchen Sie eine Geräteregistrierung mit Lebenszyklusstatus, die über eine Liste von Zugangsdaten hinausgeht?
Müssen Daten automatisch in den Diensten einer bestimmten Cloud landen?
Fehlt Ihnen jemand, der Node-RED, Grafana oder einen kleinen Dienst sicher betreiben kann?
Brauchen Sie eine fertige mandantenfähige Anwendungsschicht für Ihre eigenen Kunden?

Überwiegend Ja: Prüfen Sie vollständige IoT-Plattformen. Überwiegend Nein: Starten Sie mit einem schlanken verwalteten MQTT-Broker und ergänzen Sie Tools nach Bedarf. Viele Teams kombinieren auch beides und nutzen einen Broker als neutrales Echtzeit-Rückgrat und eine Plattform für eine bestimmte Aufgabe wie OTA-Updates.

Für tiefere Vergleiche siehe AWS-IoT-Core-Alternative und Azure-IoT-Hub-Alternative, die zwei bekannte Plattformen aus diesem Blickwinkel betrachten.

Mit einem schlanken verwalteten MQTT-Broker starten

Sie können den schlanken Ansatz an einem Nachmittag validieren. Erstellen Sie einen kostenlosen Serverless-Broker ohne Kreditkarte, verbinden Sie ein Gerät und richten Sie Telegraf oder Node-RED darauf aus. Der Leitfaden zum Cloud-MQTT-Broker erklärt die Bereitstellungsoptionen, wenn Ihr Projekt wächst, und auf connectmq.com finden Sie die vollständige Tarifübersicht, von Serverless über Dedicated und BYOC bis Self Managed Enterprise.

Häufig gestellte Fragen

Ist ein MQTT-Broker eine IoT-Plattform?

Nein. Ein Broker leitet Nachrichten zwischen Clients weiter. Eine IoT-Plattform bündelt eine Messaging-Ebene mit Geräteverwaltung, Speicherung, Regeln und Dashboards.

Kann ich eine IoT-Lösung nur mit einem MQTT-Broker bauen?

Ja, mit einigen externen Tools. Ein Broker plus Node-RED, eine Zeitreihendatenbank und Grafana decken viele Überwachungs- und Steuerungsprojekte ab.

Enthält ConnectMQ eine Rule Engine oder Datenbankintegrationen?

Nein. Integrationen laufen als externe MQTT-Clients wie Node-RED, Telegraf oder Ihre eigenen Dienste, wodurch sie portabel bleiben.

Kann ich eine IoT-Plattform und einen separaten MQTT-Broker zusammen nutzen?

Ja. Viele Teams nutzen einen neutralen Broker als Echtzeit-Rückgrat und eine Plattform für bestimmte Aufgaben wie Firmware-Updates oder Geräte-Provisioning.