Die Wahl eines IoT-MQTT-Brokers ist eine der wenigen Infrastrukturentscheidungen, die jedes Gerät betrifft, das Sie jemals ausliefern – deshalb lohnt es sich, sie vor dem ersten Firmware-Release richtig zu treffen. Dieser Leitfaden liefert Ihnen eine Checkliste mit 12 Punkten, eine Tabelle mit Fragen an jeden Anbieter und einen kurzen Praxistest, den Sie in fünf Minuten durchführen können. Nebenbei zeigen wir, wie ConnectMQ jeden Punkt abdeckt – und zwar nur mit Funktionen, die es tatsächlich bietet.
Wenn Sie noch zwischen einem eigenen Broker und einem Service schwanken, lesen Sie zuerst Was ist ein verwalteter MQTT-Broker?.
Warum die Wahl des IoT-MQTT-Brokers so wichtig ist
Der Broker steht in der Mitte jeder Nachricht: Geräte veröffentlichen an ihn, Anwendungen abonnieren über ihn. Sobald Tausende Geräte Hostname, Port, Zertifikatskette und Topic-Struktur fest in ihrer Firmware haben, wird ein Broker-Wechsel zur teuren Migration. Der Broker definiert außerdem Ihre Sicherheitsgrenze, Ihre Skalierungsobergrenze und einen großen Teil Ihrer monatlichen Betriebskosten.
Ein guter Auswahlprozess fragt deshalb nicht nur „Spricht er MQTT?“, sondern prüft Protokolltiefe, Sicherheit, Isolation, Betrieb und den Weg vom Prototyp zur Produktion.
Die Checkliste für IoT-MQTT-Broker in 12 Punkten
1. Protokollunterstützung: MQTT 3.1.1 und MQTT 5.0
Die meisten bestehenden Geräte und Bibliotheken sprechen MQTT 3.1.1, während neue Projekte von den Funktionen von MQTT 5.0 profitieren: Reason Codes, Session und Message Expiry, Topic Aliases, Shared Subscriptions und Request/Response. Ein Broker sollte beide Versionen parallel unterstützen, damit alte und neue Geräte nebeneinander existieren können. Prüfen Sie, welche MQTT-5-Funktionen tatsächlich implementiert sind – nicht nur, ob das CONNECT-Paket akzeptiert wird. Die vollständige Funktionsliste finden Sie in der OASIS-Spezifikation zu MQTT 5.0, und unser Leitfaden zu den Funktionen von MQTT 5 erklärt sie in der Praxis.
ConnectMQ: unterstützt MQTT 3.1.1 und MQTT 5.0, einschließlich Shared Subscriptions, Retained Messages, Session Expiry, Topic Alias, Message Expiry Interval, Response Topic und Reason Codes. Das CONNACK kündigt die Limits des Brokers an (Maximum QoS, Retain Available, Wildcard und Shared Subscription Available, Receive Maximum).
2. Transport: TCP, TLS und WebSocket
Geräte in eingeschränkten Netzen nutzen während der Entwicklung vielleicht unverschlüsseltes TCP, doch Produktivverkehr sollte verschlüsselt sein. Browser und Dashboards benötigen MQTT über WebSocket, idealerweise Secure WebSocket (WSS), damit sie auch von HTTPS-Seiten aus funktionieren.
ConnectMQ: TCP auf 1883, TLS auf 8883, WebSocket auf 8083 und WSS auf 8084 (Pfad /mqtt), mit einem Let's-Encrypt-Zertifikat, dem Standard-CA-Speicher bereits vertrauen.
3. Authentifizierung
Fragen Sie, wie Geräte ihre Identität nachweisen und wie Zugangsdaten ausgegeben und rotiert werden. Mindestens brauchen Sie Zugangsdaten pro Broker und Schutz davor, dass sich Clients über die Client-ID als andere ausgeben.
ConnectMQ: Benutzername und Passwort werden pro Broker im Portal ausgegeben, und Client-IDs sind auf die ausgegebene Client-ID und deren _suffix-Varianten beschränkt (zum Beispiel YOUR_CLIENT_ID_sensor1). Das Gesamtbild finden Sie in den Best Practices zur MQTT-Sicherheit.
4. Mandantenfähigkeit und Isolation
Auf einem geteilten Service müssen Ihre Topics für alle anderen Kunden unsichtbar sein. Wenn Sie ein Produkt für Ihre eigenen Kunden bauen, brauchen Sie dieselbe Garantie eine Ebene tiefer.
ConnectMQ: Die Topics jedes Mandanten sind von anderen Mandanten und vom öffentlichen MQTT-Broker isoliert. Wenn Sie zusätzlich Isolation auf Infrastrukturebene benötigen, erhalten Sie mit dem Dedicated-Plan einen eigenen Broker-Cluster.
5. Skalierbarkeit und Verbindungslimits
Achten Sie auf die Limits für gleichzeitige Verbindungen pro Plan, auf Limits für die Nachrichtengröße und darauf, wie Sie von einer Stufe zur nächsten wachsen, ohne Gerätecode zu ändern.
ConnectMQ: Serverless (Free) erlaubt bis zu 25 gleichzeitige Verbindungen und Nachrichten bis 256 KB; Serverless (Paid) bis zu 1.000 Verbindungen und Nachrichten bis 1 MB; Dedicated, BYOC und Self Managed Enterprise decken größere und isolierte Installationen ab.
6. QoS und Sessions
QoS 1 und 2 bieten Zustellgarantien; mit persistenten Sessions können Geräte nach dem Wiederverbinden aufgelaufene Nachrichten abholen. Prüfen Sie, welche QoS-Stufen jeder Plan unterstützt und wie lange Sessions vorgehalten werden. Hintergrund: MQTT QoS-Stufen erklärt.
ConnectMQ: QoS bis 1 bei Serverless (Free), QoS 2 bei Serverless (Paid); Session Expiry ist pro Plan begrenzt.
7. Retained Messages und Offline-Nachrichten
Retained Messages liefern jedem neuen Subscriber sofort den letzten bekannten Wert – unverzichtbar für Gerätestatus und Konfiguration. Last-Will-Nachrichten teilen dem restlichen System mit, wenn ein Gerät ausfällt.
ConnectMQ: Retained Messages werden in jedem Plan unterstützt, Last-Will-Nachrichten werden spezifikationsgemäß zugestellt, und $SYS/broker/connection/{clientId}/state macht den Verbindungsstatus eines Clients sichtbar.
8. Industriestandards: Sparkplug B und ISA-95
Fabriken organisieren ihre Daten zunehmend in einem Unified Namespace (UNS) nach ISA-95-Ebenen (Enterprise, Site, Area, Line, Cell, also Unternehmen, Standort, Bereich, Linie, Zelle) und nutzen Sparkplug B für typisierte, zustandsbehaftete Payloads. Die ISA-95-Hierarchie wird dabei zur Topic-Struktur auf dem Broker, etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur, sodass MES, ERP und SCADA Daten über ihren Ort im Werk finden. Ein Broker, der diese Konventionen versteht, spart Integrationsaufwand, gerade in Industrie-4.0-Projekten im Mittelstand.
ConnectMQ: erkennt ISA-95- bzw. UNS-Topic-Strukturen, erkennt und dekodiert Sparkplug B (Protobuf und JSON) und kann Sparkplug B in eine ISA-95-Struktur republizieren – so wird zum Beispiel aus spBv1.0/factory1/DDATA/line1/cnc1 das Topic connectmq/factory1/production/line1/cnc1/telemetry. Mehr dazu in Sparkplug B und Unified Namespace.
9. Beobachtbarkeit
Wenn sich ein Gerät um drei Uhr nachts seltsam verhält, müssen Sie sehen, was es veröffentlicht hat und warum es abgelehnt wurde. Achten Sie auf eine Live-Ansicht der Topics, den Verbindungsstatus und aussagekräftige Fehlercodes.
ConnectMQ: Das Portal umfasst ein Dashboard, einen MQTT-Client im Browser, einen Live-Topic-Explorer, eine nach ISA-95-Ebenen gegliederte Geräteansicht, Schwellwert-Alarmregeln und ein Alarmprotokoll. MQTT-5-Reason-Codes wie 0x97 (Quota exceeded) und 0x89 (Server busy) erklären Ablehnungen, und die ConnectMQ-Erweiterung für VS Code zeigt während der Entwicklung die Reason Codes von CONNACK, SUBACK und PUBACK an.
10. Betriebsmodelle
Manche Teams wollen null Betriebsaufwand, andere müssen Daten im eigenen Cloud-Konto oder On-Premises halten.
ConnectMQ: Serverless (geteilter Cluster), Dedicated (isolierter Cluster), BYOC (Broker in Ihrem eigenen Cloud-Konto, verwaltet von ConnectMQ) und Self Managed Enterprise (lizenzierter Broker auf Ihrer eigenen Infrastruktur).
11. Quotas und Schutzmechanismen
Ein einziges fehlerhaftes Gerät in einer Reconnect-Schleife kann allen auf dem Broker schaden. Fragen Sie, wie sich der Broker selbst und Ihren Mandanten schützt.
ConnectMQ: planbezogene Quotas, Schutz vor Verbindungsfluten mit temporären Sperren, IP-Sperren nach wiederholten Anmeldeversuchen mit falschen Zugangsdaten und adaptiver Überlastschutz.
12. Kosten und Betrieb
Vergleichen Sie die Gesamtkosten: Rechenleistung, Speicher, Patching, Zertifikatserneuerung, Monitoring, Bereitschaftszeit und Upgrades. Ein kostenloser Tarif, mit dem Sie ohne Kreditkarte Prototypen bauen können, senkt das Risiko der Evaluierung.
ConnectMQ: ein verwalteter MQTT-Broker mit einem kostenlosen Serverless-Plan (ohne Kreditkarte) und kostenpflichtigen Stufen, wenn Sie Produktionslimits benötigen. Die aktuellen Plandetails finden Sie auf connectmq.com.
Was Sie Ihren IoT-MQTT-Broker-Anbieter fragen sollten
Nutzen Sie diese Tabelle als Bewertungsbogen. Kopieren Sie sie in Ihr eigenes Dokument und füllen Sie für jeden Kandidaten eine Spalte aus.
| Kriterium | Frage an den Anbieter | Antwort von ConnectMQ |
|---|---|---|
| Protokoll | Welche MQTT-Versionen und welche MQTT-5-Funktionen sind implementiert? | MQTT 3.1.1 und 5.0; Shared Subscriptions, Topic Alias, Expiry, Response Topic, Reason Codes |
| Transport | Welche Ports für TCP, TLS, WS und WSS? Welches Zertifikat? | 1883, 8883, 8083, 8084; Let's Encrypt |
| Authentifizierung | Wie werden Zugangsdaten ausgegeben? Kann ein Gerät eine fremde Client-ID vortäuschen? | Benutzername/Passwort pro Broker; Client-ID auf ausgegebene ID und _suffix-Varianten beschränkt |
| Isolation | Können andere Kunden meine Topics sehen? | Nein, Mandanten-Topics sind isoliert |
| Skalierung | Welche Limits für Verbindungen und Nachrichtengröße gelten pro Plan? | 25 / 256 KB (Free), 1.000 / 1 MB (Paid), Dedicated für mehr |
| QoS | Welche QoS-Stufen pro Plan? Session Expiry? | QoS 1 (Free), QoS 2 (Paid); Session Expiry pro Plan begrenzt |
| Zustand | Retained Messages, Last Will, Verbindungsstatus? | Ja; $SYS/broker/connection/{clientId}/state |
| Industrie | Unterstützung für Sparkplug B, ISA-95 und UNS? | Erkennt und dekodiert Sparkplug B, republiziert in ISA-95-Topics |
| Beobachtbarkeit | Kann ich Live-Topics, Geräte und Alarme sehen? | Portal-Dashboard, Topic-Explorer, Geräteansicht, Alarmregeln |
| Betriebsmodell | Geteilt, dediziert, meine Cloud, On-Premises? | Serverless, Dedicated, BYOC, Self Managed Enterprise |
| Schutz | Wie werden Fluten und Brute-Force-Versuche behandelt? | Quotas, Flood-Sperren, IP-Sperren, Überlastschutz |
| Test | Kann ich ohne Kreditkarte testen? | Ja, Serverless (Free) und der öffentliche MQTT-Broker |
Fragen Sie jeden Anbieter auch, was nicht enthalten ist. ConnectMQ konzentriert sich zum Beispiel auf den Broker selbst: Es bietet keine serverseitige Rule Engine, keine Webhooks und keine integrierten Daten-Bridges zu Kafka oder Datenbanken. Wenn Sie so etwas brauchen, planen Sie einen eigenen Subscriber-Dienst ein, der die Daten abnimmt.
Schnelltest gegen broker.connectmq.com
Datenblätter sagen nur begrenzt etwas aus. Bevor Sie einen IoT-MQTT-Broker in die engere Wahl nehmen, verbinden Sie einen echten Client. Der öffentliche MQTT-Broker von ConnectMQ braucht kein Konto – nur eine nicht leere Client-ID und ein eindeutiges Topic-Präfix. Er ist für Tests und Prototypen gedacht, nicht für Produktionsdaten: Alles im öffentlichen Bereich ist für andere lesbar, verwenden Sie also nur Testdaten. Details finden Sie in unserem Leitfaden zum kostenlosen öffentlichen MQTT-Broker.
export ID=eval-$(openssl rand -hex 3)
# Terminal 1: mit MQTT 5 abonnieren
mosquitto_sub -h broker.connectmq.com -p 1883 -i $ID-sub -t "connectmq/demo/$ID/#" -v -V mqttv5
# Terminal 2: einen Retained-Status und einen Telemetriewert über TLS veröffentlichen
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -i $ID-pub -V mqttv5 -t "connectmq/demo/$ID/status" -m "online" -r -q 1
mosquitto_pub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -i $ID-pub -V mqttv5 -t "connectmq/demo/$ID/telemetry" -m '{"temp": 23.1}'
# Die Retained Message aufräumen
mosquitto_pub -h broker.connectmq.com -p 1883 -i $ID-pub -t "connectmq/demo/$ID/status" -n -r
Unter Windows oder macOS ersetzen Sie --capath /etc/ssl/certs durch --cafile mit dem Pfad zu einem PEM-CA-Bundle. Prüfen Sie während des Tests die Kriterien, die Sie direkt beobachten können:
- Latenz: Nachrichten sollten nahezu sofort in Terminal 1 erscheinen.
- Retained Messages: Stoppen Sie den Subscriber und starten Sie ihn neu – der Status
onlinekommt sofort an. - Last Will: Ergänzen Sie bei einem Client
--will-topic "connectmq/demo/$ID/status" --will-payload offlineund beenden Sie ihn abrupt; der Subscriber erhältoffline. - Limits: Der öffentliche MQTT-Broker erlaubt 64 KB pro Nachricht und 10 Nachrichten pro Sekunde und Client; bei Überschreitung gibt es MQTT-5-Reason-Codes statt stiller Verluste.
Für eine Evaluierung unter Produktionsbedingungen wiederholen Sie den Test mit einem privaten Broker und den Zugangsdaten aus dem Portal:
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs -V mqttv5 -u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID -t "#" -v
Starten Sie mit ConnectMQ
Am besten bewerten Sie einen IoT-MQTT-Broker, indem Sie Ihre eigenen Geräte damit verbinden. Registrieren Sie sich unter app.connectmq.com – der Plan Serverless (Free) benötigt keine Kreditkarte. Legen Sie einen Broker an, kopieren Sie den generierten Benutzernamen, das Passwort und die Client-ID und sehen Sie zu, wie Ihre ersten Nachrichten im Live-Topic-Explorer eintreffen.
Häufig gestellte Fragen
Was ist das wichtigste Kriterium bei der Wahl eines IoT-MQTT-Brokers?
Sicherheit und Isolation stehen an erster Stelle: verschlüsselter Transport, Authentifizierung pro Gerät und garantierte Trennung von anderen Mandanten. Danach prüfen Sie die Unterstützung für MQTT 5 und Limits, die zur Größe Ihrer Geräteflotte passen.
Brauche ich MQTT 5.0 für ein IoT-Projekt?
Nicht zwingend, denn MQTT 3.1.1 funktioniert weiterhin gut. MQTT 5 ergänzt jedoch Reason Codes, Expiry-Intervalle, Shared Subscriptions und Request/Response, die größere Systeme leichter beherrschbar machen. Wählen Sie einen Broker, der beide Versionen unterstützt.
Unterstützt ConnectMQ Sparkplug B?
Ja. ConnectMQ erkennt und dekodiert Sparkplug-B-Payloads (Protobuf und JSON) und kann sie in eine Topic-Struktur nach ISA-95 im Unified Namespace (UNS) republizieren.
Kann ich ConnectMQ testen, ohne ein Konto anzulegen?
Ja. Verbinden Sie sich ohne Zugangsdaten mit broker.connectmq.com, mit einer nicht leeren Client-ID und einem eindeutigen Topic-Präfix. Denken Sie daran, dass der öffentliche MQTT-Broker nur für Tests und Prototypen gedacht und für alle lesbar ist.
Kann ich ConnectMQ in meiner eigenen Cloud oder meinem Rechenzentrum betreiben?
Ja. Neben den Plänen Serverless und Dedicated bietet ConnectMQ BYOC (Broker in Ihrem eigenen Cloud-Konto, verwaltet von ConnectMQ) und Self Managed Enterprise für Ihre eigene Infrastruktur.
