EMQX-Cloud-Alternative: Verwalteten MQTT-Broker nach den Funktionen wählen, die Sie wirklich brauchen

Eine EMQX-Cloud-Alternative lohnt sich erst dann zu prüfen, wenn Sie wissen, auf welche Broker-Funktionen Ihr Projekt wirklich angewiesen ist. Dieser Leitfaden hilft Ihnen, diese Anforderungen aufzulisten, sie den Fähigkeiten verwalteter MQTT-Broker zuzuordnen und zu erkennen, wo ein schlanker Broker mit integrierter Sparkplug-B-Dekodierung und Ansichten für den Unified Namespace (UNS) nach ISA-95 besser passt als eine umfassende Datenplattform.

EMQX im Kontext

EMQX ist ein weit verbreiteter Open-Source-MQTT-Broker von EMQ, bekannt für horizontale Skalierbarkeit und einen breiten Funktionsumfang, darunter eine SQL-ähnliche Rule Engine und Datenintegrationen mit externen Systemen. EMQX Cloud bietet ihn als verwalteten MQTT-Broker in mehreren Stufen an. Für Teams, die Nachrichtenverarbeitung und Routing zu Datenbanken direkt im Broker wollen, ist das eine echte Stärke.

Die Verfügbarkeit von Funktionen kann sich zwischen den Stufen unterscheiden und ändert sich im Laufe der Zeit. Prüfen Sie daher vor dem Vergleich die aktuelle Dokumentation von EMQ, um zu sehen, was jede EMQX-Cloud-Stufe enthält. Derselbe Rat gilt für jeden Anbieter in diesem Artikel.

Bei den Anforderungen beginnen, nicht bei Funktionslisten

Funktionsmatrizen belohnen das Produkt mit der längsten Liste. Ihr Projekt belohnt das Produkt, das mit der geringsten betrieblichen Komplexität tut, was Sie brauchen. Notieren Sie Antworten auf diese Fragen, bevor Sie sich einen Anbieter ansehen:

1. Wo findet die Nachrichtenverarbeitung statt? Im Broker, in einem separaten Dienst oder in Tools, die Sie bereits betreiben, wie Node-RED oder ein Stream-Prozessor?
2. Wer konsumiert die Daten? Dashboards, Historians, MES- oder ERP-Systeme, mobile Apps?
3. Welche Payload-Formate kommen an? JSON, Sparkplug-B-Protobuf, einfache Werte, herstellerspezifische Binärformate?
4. Wie viele Verbindungen und Nachrichten pro Sekunde erwarten Sie in einem Jahr?
5. Welche MQTT-5-Funktionen nutzen Sie? Shared Subscriptions, Message Expiry, Topic-Aliase?
6. Welches Bereitstellungsmodell ist erforderlich? Geteilt, dediziert, im eigenen Cloud-Konto oder selbst betrieben?
7. Wer debuggt das Ganze um 2 Uhr nachts? Welche Tools braucht diese Person, um Live-Topics und Payloads zu sehen?

Bedürfnisse den Broker-Funktionen zuordnen

Das Muster ist eindeutig: Ist das Routing in Datenbanken innerhalb des Brokers eine Kernanforderung, passt eine Plattform mit Rule Engine womöglich besser. Liegt Ihr Hauptproblem darin, die durch den Broker fließenden Industriedaten zu verstehen und zu ordnen, bringt Sie ein Broker mit integrierten Sparkplug- und ISA-95-Tools möglicherweise schneller und mit weniger beweglichen Teilen ans Ziel.

Warum Industrieteams Wert auf Sparkplug-B-Dekodierung legen

Sparkplug-B-Payloads sind Protobuf-kodiert. Jeder Broker leitet sie weiter, doch wenn Sie mit einem generischen Client abonnieren, sehen Sie nur binäres Rauschen. Bei Inbetriebnahme und Fehlersuche bremst das alle aus. Eine integrierte Dekodierung in der Broker-Konsole erlaubt es einem Ingenieur, Metriknamen, Werte und Zeitstempel direkt zu lesen.

ConnectMQ geht einen Schritt weiter und veröffentlicht Sparkplug-B-Daten zusätzlich in Topics im ISA-95-Stil. Eine Nachricht auf:

spBv1.0/factory1/DDATA/line1/cnc1

steht auch zur Verfügung unter:

connectmq/factory1/production/line1/cnc1/telemetry

Consumer, die Sparkplug nicht verstehen, etwa ein einfaches Dashboard, können das lesbare Topic abonnieren. Damit wird aus der flachen Sparkplug-Struktur (Group, Edge Node, Device) ein Zweig des UNS entlang der ISA-95-Ebenen Enterprise → Site → Area → Line → Cell; im Werk könnte das etwa acme/werk-stuttgart/montage/linie-1/zelle-3/temperatur sein. MES, ERP und Historian abonnieren dann genau die Hierarchieebene, die sie brauchen. Der Leitfaden zu MQTT Sparkplug B und Unified Namespace erklärt die zugrunde liegenden Konzepte.

Integration ohne Rule Engine

Wenn Sie sich für einen schlanken Broker entscheiden, liegen die Integrationen außerhalb davon in Standard-MQTT-Clients. Für viele Teams ist das ein vertrautes Muster, und jeder Teil bleibt austauschbar. Hier ein minimaler Python-Subscriber (paho-mqtt 2.x), der die erneut veröffentlichten ISA-95-Topics abhört und jede Nachricht an Ihre eigene Speicherfunktion übergibt:

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

TOPIC = "connectmq/factory1/production/#"


def store(topic, payload):
    # Durch Ihren Historian, Ihre Datenbank oder einen HTTP-Aufruf ersetzen
    print(f"{topic}: {payload}")


def on_connect(client, userdata, flags, reason_code, properties):
    if reason_code.is_failure:
        print("Connect failed:", reason_code)
        return
    client.subscribe(TOPIC, qos=1)


def on_message(client, userdata, msg):
    try:
        payload = json.loads(msg.payload)
    except ValueError:
        payload = msg.payload.decode(errors="replace")
    store(msg.topic, payload)


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("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()

Ersetzen Sie store durch einen InfluxDB-Schreibvorgang, einen HTTP-POST an Ihr MES oder eine Nachricht an Ihre bestehende Daten-Pipeline. Node-RED und Telegraf erledigen dasselbe per Konfiguration statt per Code.

Fragen, die Sie in einer Testphase klären sollten

• Sichtbarkeit der Payloads. Verbinden Sie ein echtes SPS-Gateway oder einen Edge-Knoten. Kann Ihr Team die Daten innerhalb von Minuten in der Konsole lesen?
• Topic-Organisation. Hilft Ihnen der Broker, die Werkshierarchie zu sehen, oder nur eine flache Topic-Liste?
• Integrationsaufwand. Wie lange dauert es, einen Datenstrom in Ihren Historian zu bringen?
• Limits. Was passiert an der Grenze Ihres Tarifs? Bei ConnectMQ liefert das Überschreiten eines Kontingents den MQTT-5-Reason-Code 0x97 (Quota exceeded), den Ihre Clients protokollieren und behandeln können.
• Ausstiegsweg. Könnten Sie Geräte allein durch Ändern der Verbindungseinstellungen woandershin umziehen? Siehe MQTT-Vendor-Lock-in.

An die Fähigkeiten des Teams denken, nicht nur an Funktionen

Eine Funktion ist nur nützlich, wenn Ihr Team sie betreiben kann. Eine Rule Engine im Broker ist mächtig, aber Regeln werden Teil Ihrer Produktionslogik und brauchen Versionierung, Tests und Reviews wie jeder andere Code. Ebenso bedeutet das Auslagern von Integrationen in externe Tools, dass jemand diese Tools betreiben und überwachen muss. Keiner der beiden Ansätze ist kostenlos.

Fragen Sie sich, wem der Datenpfad in zwei Jahren gehört. Automatisierungsingenieure, die mit Node-RED-Flows vertraut sind, bevorzugen womöglich Integrationen, die sie visuell sehen und bearbeiten können. Ein Softwareteam mit einem bestehenden Stream-Processing-Stack möchte vielleicht, dass der Broker ein einfacher, schneller Transport bleibt. Ein Team ohne beides schätzt eventuell eine Plattform, die mehr bündelt. Die Architektur auf die Menschen abzustimmen, die sie pflegen werden, ist meist wichtiger als jede einzelne Funktion in einer Vergleichstabelle.

Wann ein schlanker Broker nicht die richtige Wahl ist

Um fair zu bleiben: Wenn Sie ein einziges Produkt suchen, das Ingestion, Transformation, Routing in viele Datenbanken und Stream Processing übernimmt, erspart Ihnen ein Broker mit integrierter Rule Engine und Datenintegrationen den Aufbau dieser Schicht. ConnectMQ bietet keine Rule Engine, keine Webhooks, keine nativen Datenbank-Bridges und keine Steuerung von Broker-Clustering. Entscheiden Sie danach, welche Architektur Ihr Team verantworten möchte.

Einen schlanken, industrietauglichen Broker testen

Sie können die Sparkplug-Dekodierung und die ISA-95-Ansichten kostenlos mit Ihren eigenen Daten testen. Starten Sie einen kostenlosen Serverless-Broker ohne Kreditkarte, richten Sie einen Edge-Knoten oder ein Gateway darauf aus und öffnen Sie den Live-Topic-Explorer und die Geräteansicht. Für mehr Kontext lesen Sie den Leitfaden zum Cloud-MQTT-Broker, vergleichen Sie mit unserem Rahmen zur HiveMQ-Cloud-Alternative und erfahren Sie, was ein verwalteter MQTT-Broker für Sie übernimmt. Mehr auf connectmq.com.

Häufig gestellte Fragen

Können sich EMQX-Clients ohne Änderungen mit ConnectMQ verbinden?

Clients, die Standard-MQTT 3.1.1 oder 5.0 verwenden, funktionieren mit jedem konformen Broker. Es ändern sich nur Host, Port, Zugangsdaten und Client-ID, sofern Sie nicht auf herstellerspezifische Funktionen angewiesen sind.

Hat ConnectMQ eine Rule Engine wie EMQX?

Nein. Verarbeitung und Integrationen übernehmen externe MQTT-Clients wie Node-RED, Telegraf oder Ihre eigenen Dienste.

Ist Sparkplug-B-Dekodierung nötig, um Sparkplug zu nutzen?

Nein, jeder Broker kann Sparkplug B transportieren. Die Dekodierung in der Broker-Konsole macht die Daten lediglich ohne zusätzliche Tools für Menschen lesbar.

Wo prüfe ich die aktuellen Funktionen von EMQX Cloud?

Nutzen Sie die offizielle Dokumentation und die Preisseiten von EMQ, da sich Stufen, Limits und Funktionen im Laufe der Zeit ändern.