Azure-IoT-Hub-Alternative: Der Umstieg auf einen vollwertigen MQTT-3.1.1/5.0-Broker

Eine Azure-IoT-Hub-Alternative ist eine Überlegung wert, wenn Ihr Projekt echtes Publish/Subscribe zwischen Geräten, Apps und Diensten braucht statt eines Gateways von Gerät zu Cloud. Dieser Artikel erklärt, wie sich die geräteorientierte MQTT-Unterstützung von IoT Hub von einem vollwertigen MQTT-3.1.1/5.0-Broker unterscheidet, was Sie auf beiden Seiten bewerten sollten und wie ein schrittweiser Migrationspfad zu einem Standard-Broker aussieht, bei dem Ihre Flotte durchgehend weiterläuft.

Wofür Azure IoT Hub konzipiert ist

Azure IoT Hub ist ein Managed Service, um Geräte in Azure zu verbinden, zu verwalten und mit ihnen zu kommunizieren. Seine Stärken sind flottenorientiert: eine Registrierung für Geräteidentitäten, Device Twins, Direct Methods, Cloud-to-Device-Nachrichten und das Routing von Telemetrie in andere Azure-Dienste. Geräte können MQTT, AMQP oder HTTPS verwenden und sich per SAS-Token oder X.509-Zertifikat authentifizieren.

Wenn Sie MQTT mit IoT Hub verwenden, arbeiten Sie innerhalb seines Gerätemodells. Geräte veröffentlichen Telemetrie auf ein gerätespezifisches Topic wie devices/{device_id}/messages/events/ und empfangen Nachrichten auf devices/{device_id}/messages/devicebound/#. Twin-Updates und Direct Methods haben eigene reservierte Topics. Der Dienst ist das Gegenüber jedes Geräts, kein Broker, der Nachrichten zwischen beliebigen Clients weiterleitet.

Das ist ein bewusstes Design für Geräteverwaltung und Cloud-Ingestion. Es ist schlicht nicht dasselbe wie ein universeller MQTT-Broker. Microsoft bietet zudem in Azure Event Grid eine MQTT-Broker-Funktion für Publish/Subscribe-Szenarien an, die sich zu prüfen lohnt, wenn Sie innerhalb von Azure bleiben möchten. Prüfen Sie die aktuelle Microsoft-Dokumentation zu den genauen Fähigkeiten jedes Dienstes.

Geräteorientiertes MQTT vs. vollwertiger MQTT-Broker

Die linke Spalte gewinnt, wenn Geräteverwaltung und Azure-Integration am wichtigsten sind. Die rechte Spalte gewinnt, wenn Sie überall Standard-MQTT-Semantik wollen.

Anzeichen, dass ein vollwertiger MQTT-Broker besser passt

• Dashboards und Apps brauchen Live-Daten direkt. Mit einem vollwertigen Broker abonniert eine Browser-App per Secure WebSocket, ohne Backend-Relay.
• Geräte oder Maschinen kommunizieren miteinander. Eine Steuerung, die das Topic eines Sensors abonniert, ist bei MQTT natürlich und in einem Modell von Gerät zu Cloud umständlich.
• Sie bauen einen Unified Namespace (UNS) auf. In Industrie-4.0-Projekten wird die ISA-95-Anlagenhierarchie (Enterprise → Site → Area → Line → Cell) zur Topic-Struktur, etwa acme/werk-linz/montage/linie-1/zelle-3/telemetry, und SPS-Gateways, MES und ERP tauschen Daten über diesen gemeinsamen Baum aus. Das braucht einen Broker, bei dem Ihnen der Topic-Baum gehört. Siehe MQTT Sparkplug B und Unified Namespace.
• Sie wollen portable Firmware. Standard-Topics und Standard-Authentifizierung machen Geräte unabhängig von einer einzelnen Cloud.
• Ihre Systeme erstrecken sich über mehrere Clouds oder On-Premises-Standorte.

IoT-Hub-Konzepte auf Standard-MQTT abbilden

Das Response Topic von MQTT 5 eignet sich besonders als Ersatz für Direct Methods: Der Aufrufer veröffentlicht eine Anfrage mit einem Response Topic, und das Gerät veröffentlicht seine Antwort dort.

Was Sie übernehmen, wenn Sie IoT Hub verlassen

Ein fairer Vergleich berücksichtigt die Arbeit, die auf Ihre Seite wandert. IoT Hub bündelt Geräteregistrierung, Twin-Speicher, Methodenaufrufe und Routing. Mit einem schlichten Broker verantworten Sie diese Muster selbst:

• Geräteinventar. Führen Sie eine Liste der Geräte, ihrer Zugangsdaten und Firmware-Versionen in Ihrem eigenen System.
• Konventionen für den Zustand. Legen Sie das Format der Payloads für gemeldeten und gewünschten Zustand fest und dokumentieren Sie es, damit jedes Firmware-Team denselben Regeln folgt.
• Sicherheit bei Befehlen. Legen Sie fest, wer in Befehls-Topics veröffentlichen darf, und validieren Sie jeden Befehl auf dem Gerät, bevor es ihn ausführt.
• Datenweiterleitung. Betreiben und überwachen Sie die Subscriber oder Flows, die Daten in Speicher und Analyse bringen.

Für viele Teams sind das kleine, gut verstandene Aufgaben. Für andere, insbesondere bei sehr großen Flotten mit komplexem Provisioning, lohnt es sich, die integrierte Geräteverwaltung einer Plattform zu behalten. Entscheiden Sie mit Blick auf Ihre eigene Flottengröße und Ihr Team.

Beispiel: Gerätecode nach der Migration

Hier ein ESP32-Sketch mit PubSubClient, der Telemetrie veröffentlicht und auf Befehle in von Ihnen definierten Topics hört, verbunden mit ConnectMQ über TLS:

#include <WiFi.h>
#include <WiFiClientSecure.h>
#include <PubSubClient.h>

const char* WIFI_SSID = "YOUR_WIFI";
const char* WIFI_PASS = "YOUR_WIFI_PASSWORD";
const char* MQTT_HOST = "broker.connectmq.com";
const int   MQTT_PORT = 8883;
const char* MQTT_USER = "YOUR_USERNAME";
const char* MQTT_PASS = "YOUR_PASSWORD";
const char* CLIENT_ID = "YOUR_CLIENT_ID";

const char* TOPIC_TELEMETRY = "site1/area1/line1/dev42/telemetry";
const char* TOPIC_CMD       = "site1/area1/line1/dev42/cmd";

WiFiClientSecure net;
PubSubClient mqtt(net);

void onMessage(char* topic, byte* payload, unsigned int length) {
  String msg;
  for (unsigned int i = 0; i < length; i++) msg += (char)payload[i];
  Serial.printf("Command on %s: %s\n", topic, msg.c_str());
}

void connectMqtt() {
  while (!mqtt.connected()) {
    Serial.print("Connecting to MQTT... ");
    if (mqtt.connect(CLIENT_ID, MQTT_USER, MQTT_PASS)) {
      Serial.println("connected");
      mqtt.subscribe(TOPIC_CMD, 1);
    } else {
      Serial.printf("failed, state=%d\n", mqtt.state());
      delay(5000);
    }
  }
}

void setup() {
  Serial.begin(115200);
  WiFi.begin(WIFI_SSID, WIFI_PASS);
  while (WiFi.status() != WL_CONNECTED) delay(500);
  // In Produktion die ISRG Root X1 CA mit net.setCACert(...) hinterlegen
  net.setInsecure();
  mqtt.setServer(MQTT_HOST, MQTT_PORT);
  mqtt.setCallback(onMessage);
}

void loop() {
  if (!mqtt.connected()) connectMqtt();
  mqtt.loop();

  static unsigned long last = 0;
  if (millis() - last > 10000) {
    last = millis();
    char payload[64];
    snprintf(payload, sizeof(payload), "{\"temp\":%.1f}", 20.0 + random(0, 50) / 10.0);
    mqtt.publish(TOPIC_TELEMETRY, payload);
  }
}

setInsecure() ist nur für einen ersten Test gedacht. Laden Sie in Produktion das Let's-Encrypt-Root-Zertifikat mit setCACert(), damit das Gerät den Broker verifiziert. Das ESP32-MQTT-Tutorial behandelt den Umgang mit Zertifikaten im Detail.

Ein schrittweiser Migrationspfad

1. Den Topic-Baum entwerfen. Legen Sie eine Hierarchie wie Unternehmen/Standort/Bereich/Linie/Gerät fest, also die ISA-95-Ebenen Ihres UNS, und trennen Sie Telemetrie-, Status- und Befehls-Topics.
2. Bestehende Daten überbrücken. Betreiben Sie einen kleinen Dienst, der aus Ihren aktuellen IoT-Hub-Consumern liest (zum Beispiel dem integrierten Event-Endpunkt) und auf die Topics des neuen Brokers erneut veröffentlicht. Neue Dashboards können den Broker sofort nutzen.
3. Routen ersetzen. Bilden Sie jede Azure-Route als externen Subscriber, Node-RED-Flow oder Telegraf-Output nach, der in dasselbe Ziel schreibt.
4. Eine Pilotgruppe umziehen. Aktualisieren Sie Firmware oder Gateway-Konfiguration für eine Handvoll Geräte. Prüfen Sie Reconnect-Verhalten und Tariflimits; bei ConnectMQ erhalten MQTT-5-Clients den Reason Code 0x97, wenn ein Kontingent überschritten wird.
5. In Wellen ausrollen und die vorherige Konfiguration bereithalten, bis jede Welle stabil läuft.

Fehlerbehebung nach dem Wechsel

• Das Gerät verbindet sich und trennt sich alle paar Sekunden. Zwei Geräte teilen sich eine Client-ID. Geben Sie jedem Gerät eigene Zugangsdaten und eine eigene Client-ID.
• Der Backend-Dienst sieht keine Daten. Prüfen Sie den Abonnementfilter. Ein Filter site1/+/telemetry passt nicht auf site1/area1/line1/dev42/telemetry; verwenden Sie site1/# oder die richtige Anzahl von +-Ebenen.
• Befehle kommen doppelt an. Bei QoS 1 sind Duplikate konstruktionsbedingt möglich. Fügen Sie eine Befehls-ID hinzu und ignorieren Sie Wiederholungen. Der Leitfaden zu MQTT-QoS-Stufen erklärt, warum.
• Nach einem Neustart erscheint ein alter Zustand. Retained Messages bleiben erhalten, bis sie ersetzt oder gelöscht werden. Veröffentlichen Sie eine leere Retained Payload, um eine zu löschen.

Einen vollwertigen MQTT-Broker testen

Sie können das Publish/Subscribe-Modell erkunden, bevor Sie irgendein Gerät ändern. Erstellen Sie einen kostenlosen Serverless-Broker ohne Kreditkarte, verbinden Sie ein Testgerät und einen Browser-Client und beobachten Sie die Nachrichten im Live-Topic-Explorer. Für mehr Kontext lesen Sie den Leitfaden zum Cloud-MQTT-Broker, vergleichen Sie mit dem Artikel zur AWS-IoT-Core-Alternative und lesen Sie nach, was ein MQTT-Broker leistet. Mehr erfahren Sie auf connectmq.com.

Häufig gestellte Fragen

Ist Azure IoT Hub ein MQTT-Broker?

IoT Hub unterstützt MQTT für die Gerätekommunikation, allerdings innerhalb eines Modells von Gerät zu Cloud mit reservierten Topics. Er ist nicht als universeller Publish/Subscribe-Broker zwischen beliebigen Clients konzipiert.

Wie ersetze ich Device Twins durch Standard-MQTT?

Verwenden Sie Retained Messages auf Topics für den gemeldeten und den gewünschten Zustand. Neue Subscriber erhalten sofort den zuletzt bekannten Zustand.

Kann ich Azure-Dienste nach dem Wechsel zu einem anderen Broker weiter nutzen?

Ja. Ein externer Subscriber oder Node-RED-Flow kann Daten vom Broker über die normalen APIs an jeden Azure-Dienst weiterleiten.

Wo prüfe ich die aktuellen MQTT-Fähigkeiten von IoT Hub?

Nutzen Sie die offizielle Dokumentation von Microsoft zu Azure IoT Hub, die die unterstützten MQTT-Funktionen und Limits der aktuellen Version beschreibt.