MQTT ist ein Nachrichtenprotokoll: Herausgeber veröffentlichen Nachrichten, und Abonnenten empfangen sie über passende Topics. Es verbindet beispielsweise einen industriellen Datensammler mit Anwendungen. Wie ein Sensor misst, welche Einheit ein Wert hat oder wann ein Alarm auslöst, bestimmt MQTT nicht. Das gehört zur Datenvereinbarung der Anwendung.
Broker und Topics planen
Ein Broker verteilt veröffentlichte Nachrichten an Abonnenten. Herausgeber müssen nicht jeden Empfänger kennen; dafür werden Brokerzugriff, Kapazität, Berechtigungen und Verbindungszustand zu Betriebsaufgaben. Jedem Gerät Schreibrechte auf sämtliche Topics zu geben, ist kein sinnvoller Standard.
Topic-Namen sollten einer klaren Anlagenhierarchie folgen. site-a/line-2/machine-7/state ist ein illustratives Beispiel, keine reale Anlagenadresse. Trennen Sie stabile Gerätekennung und Anzeigename, damit Umbenennungen keine Historie aufspalten. Geheimnisse und personenbezogene Angaben gehören nicht in Topic-Namen.
Nutzdaten können Wert, Einheit, Quellzeitstempel, Qualität und Schemaversion enthalten. Dokumentieren Sie Größenbeschränkungen und optionale Felder. Unterschiedliche Empfänger sollen dieselbe Nachricht einheitlich interpretieren, statt jeweils die Bedeutung eines Registers zu erraten.
Was QoS tatsächlich abdeckt
Der OASIS-Standard MQTT 5.0 definiert drei QoS-Stufen. Ihre Zustelleigenschaften gelten für den jeweiligen Protokollabschnitt. Sie garantieren nicht automatisch genau einen Datenbankschreibvorgang oder eine einmalige physische Aktion.
| Stufe | Zustellung im Protokollabschnitt | Frage an die Anwendung |
|---|---|---|
| QoS 0 | Höchstens einmal | Darf diese Beobachtung verloren gehen? |
| QoS 1 | Mindestens einmal | Wie werden Wiederholungen erkannt? |
| QoS 2 | Genau einmal im Protokollabschnitt | Was geschieht in nachgelagerten Diensten? |
Ein Empfänger kann eine Nachricht verarbeiten und anschließend die Datenbankbestätigung verlieren. Eine Wiederholung kann den Anwendungsvorgang erneut ausführen. Stabile Ereigniskennungen, Eindeutigkeitsbedingungen und Transaktionsgrenzen bleiben deshalb zusätzlich zur MQTT-Konfiguration wichtig. QoS 2 ist keine unbegrenzte Zusage für geschäftliche Ende-zu-Ende-Einmaligkeit.
Gespeichert bedeutet nicht aktuell
Eine Retained Message liefert einem neuen Abonnenten möglicherweise die zuletzt gespeicherte Nachricht des Topics. Dieser Wert kann alt sein. Die Oberfläche muss Quellzeitstempel und Aktualitätsregel prüfen. Ein sofortiger Empfang nach Verbindungsaufbau beweist keine aktuelle Gerätegesundheit.
Last Will kann einen Verbindungsverlust signalisieren, diagnostiziert aber nicht jeden Feldfehler. Ein verbundener Datensammler kann den Zugriff auf einen einzelnen Sensor verloren haben. Geräteverfügbarkeit, Zustand des Datensammlers und Anwendungsverbindung bleiben unterscheidbar.
Beispielhafter Temperaturablauf
Angenommen, ein Datensammler puffert Temperaturwerte mit Zeitstempel während eines Ausfalls der übergeordneten Verbindung. Nach Wiederverbindung sendet er sie mit ihren ursprünglichen Ereigniskennungen. Die Anwendung erkennt Duplikate, ordnet verspätete Werte historisch ein und ersetzt die aktuelle Anzeige nicht durch ältere nachgesendete Punkte.
Die Warteschlange ist begrenzt. Definieren Sie abgedeckte Ausfalldauer, Speicheralarme und Verhalten bei Speicherfehlern. Testen Sie gleichzeitige Wiederverbindung vieler Geräte und begrenzen Sie die Nachübertragung, damit aktuelle Messungen und Feldabfragen nutzbar bleiben. Begrenzte, gestaffelte Wiederholungsabstände entlasten ein sich erholendes Netzwerk.
Fragen zur Bestandsaufnahme
- Wo läuft der Broker und wer betreibt ihn?
- Wie werden Geräteidentitäten und Topic-Rechte verwaltet?
- Welche Felder benötigt eine gültige Nachricht?
- Wie werden Pufferung, Nachübertragung und Duplikate geprüft?
- Was passiert beim Wechsel von Zugangsdaten oder Zertifikaten?
MQTT ersetzt weder ein gutes Datenmodell noch einen Betriebsplan. Prüfen Sie zunächst einen kleinen Datenfluss im Normalbetrieb, bei Trennung und bei Mehrfachzustellung, bevor Sie weitere Geräte anschließen.
Ein Duplikatbeispiel auf Anwendungsebene
Ein Datensammler veröffentlicht eine Temperaturbeobachtung mit der Kennung observation-1042. Die empfangende Anwendung speichert sie, doch ihre Verarbeitungsbestätigung erreicht den Datensammler nicht. Dieser wiederholt mit derselben Kennung und dem ursprünglichen Zeitstempel. Der Empfänger erkennt den bestehenden Eintrag, statt eine zweite Probe anzulegen. Eine neue Kennung beim Wiederholen würde den Nachweis beseitigen, dass beide Zustellungen dieselbe Beobachtung betreffen.
Ein separater Verbraucher kann aus dem Datensatz einen Alarm bewerten. Auch dessen Verarbeitungsstatus muss berücksichtigt werden: Die Vermeidung doppelter Messungen verhindert nicht automatisch doppelte Benachrichtigungen. Speichern Sie die Verbindung zwischen Eingangsereignis, Alarmübergang und Benachrichtigungsauftrag. Bei einer Zeitüberschreitung des Zustelldienstes bleibt das Ergebnis ungewiss, statt sicher zu behaupten, nichts sei versandt worden. Dies ist ein Anwendungsentwurf, keine zusätzliche MQTT-Garantie.
Bestimmen Sie ebenso die Behandlung abgewiesener Nachrichten. Unbekannte Schemaversion, ungültige Einheit oder unmögliche Gerätekennung müssen diagnostizierbar sein. Dauerhaft fehlerhafte Nachrichten blind zu wiederholen verbraucht Ressourcen ohne nutzbare Daten. Schaffen Sie eine begrenzte Fehlerbehandlung und eine Betriebsansicht betroffener Quellen. Zugangsdaten oder uneingeschränkte Nachrichteninhalte gehören nicht allein zur bequemeren Fehlersuche in Protokolle.
Berechtigungen und Wiederherstellung prüfen
Prüfen Sie eine Geräteidentität mit den zum Veröffentlichen und Abonnieren zugelassenen Topics. Versuchen Sie Zugriffe außerhalb dieses Umfangs und kontrollieren Sie die Ablehnung. Testen Sie ersetzte Zugangsdaten und stillgelegte Geräte getrennt von einer normalen Wiederverbindung. Eine erfolgreiche Verbindung allein sagt wenig über ihre tatsächlichen Grenzen aus.
Unterbrechen Sie für die Wiederherstellungsprüfung die übergeordnete Verbindung bei laufender Erfassung. Verbinden Sie anschließend mit historischen und aktuellen Beobachtungen neu. Prüfen Sie ursprüngliche Zeitstempel, Kennungen und das angezeigte Datenalter. Untersuchen Sie außerdem den vollen lokalen Speicher. Dieser Zustand muss sichtbar bleiben, auch wenn der Broker später wieder erreichbar ist. Dokumentieren Sie MQTT-Version, unterstütztes Sitzungsverhalten und anwendungsseitige Quittungsregeln zusammen mit der tatsächlichen Client- und Brokerkonfiguration. Bringen Sie Betriebsaufzeichnung, Beispielnachricht und geplante Topic-Hierarchie zur Integrationsbesprechung mit. So werden Zuverlässigkeitsgrenzen prüfbar, ohne einer einzigen QoS-Einstellung die Lösung sämtlicher Zustellprobleme zuzuschreiben.