Industrierouter online, MQTT sendet nicht? Auftrag prüfen
Angenommen, ein Industrierouter an einer Pumpstation erfasst vor Ort Druck- und Wasserstandswerte und führt selbst einen MQTT-Sendeauftrag aus. Er sendet die Werte an einen entfernten Broker; eine Plattform bezieht sie per Subscription. Nach zunächst kontinuierlicher Übertragung bleiben die angezeigten Werte stehen. Der Router meldet aber weiterhin eine 4G/5G-Verbindung und kann ein externes Ziel anpingen.
In dieser Konfiguration ist der Router der publizierende Client, nicht der Broker. Ein MQTT-Client kann Nachrichten veröffentlichen, abonnieren oder beides tun. Die Verbindung zu einem Broker macht ihn nicht automatisch zum reinen Empfänger. Siehe die Begriffsbestimmungen in MQTT 3.1.1, §1.2.
Die entscheidende Frage lautet: Kommt der lokale Sendeauftrag noch voran, oder versucht er zu senden und scheitert bei Verbindung oder Veröffentlichung? Eine funktionierende Internetverbindung beantwortet das nicht.
Diese Diagnose gilt für Geräte, die lokale Erfassung und MQTT-Publishing tatsächlich unterstützen und entsprechend eingerichtet sind. Prüfen Sie zuerst die reale Topologie. Leitet der Router nur den Verkehr eines separaten Gateways weiter, ist dessen Sendeauftrag zu untersuchen. Arbeitet der Router als Broker oder Subscriber, prüfen Sie den Dienst in dieser Rolle. Hintergrund zu Rollen und Datenpfad bietet der MQTT-Überblick von Wavetel.
Eine neue Messung durch den Datenpfad verfolgen
Wählen Sie einen eindeutig erkennbaren Messpunkt. Halten Sie Zeitstempel, Kennung und MQTT-Topic einer neuen Messung fest. Suchen Sie Belege an drei Stellen:
Neue Messung entstanden → lokaler Auftrag startet einen Publish-Versuch → dieselbe neue Nachricht erscheint im Ziel-Topic des entfernten Brokers.
Beobachteter Beleg | Nächste Prüfung |
|---|---|
Neue Messung vorhanden, aber kein nachfolgender Publish-Versuch sichtbar | Übergabe von der Erfassung an den lokalen Sendeauftrag und dessen Zustand |
Der Auftrag versucht weiterhin zu senden, aber Verbindung oder Veröffentlichung scheitert | Tatsächliche Client-Verbindung zum entfernten Broker, Authentifizierung und Publish-Ergebnis |
Dieselbe neue Nachricht liegt im Ziel-Topic des Brokers vor | Subscription und Verarbeitung auf der Plattform |
Entsteht gar keine neue Messung, beginnen Sie bei Datenquelle und Erfassung. Fehlt lediglich ein sichtbarer Publish-Versuch, ist ein Stillstand des Auftrags noch nicht bewiesen. Nutzen Sie die vom Gerät unterstützten Protokolle und Diagnosen, um diesen Schritt nachzuweisen.
Sichern Sie vor Änderungen die Protokolle vor und nach dem Fehler, die Laufzeit des Clients, Broker-Adresse und Port, Client-ID und Topic. Notieren Sie Zeitabweichungen zwischen Gerät und Broker, damit sich derselbe Versuch in beiden Protokollen zuordnen lässt.
Neue Messungen, aber kein Publish-Versuch: lokalen Auftrag prüfen
Prüfen Sie zunächst, ob der Publishing-Dienst noch läuft. Ist der Prozess beendet, dokumentieren Sie Zeitpunkt, Fehlermeldung und Neustarts und stellen den Dienst nach dem vorgesehenen Wartungsverfahren wieder her. Eine Änderung der MQTT-Verbindungsparameter startet keinen beendeten Dienst.
Läuft der Prozess, prüfen Sie seinen letzten nachweisbaren Fortschritt: Wurde die Messung an den Sendeauftrag übergeben? Ist die Codierung abgeschlossen? Bewegen sich Warteschlange oder Publish-Aufrufe weiter? Ein laufender Prozess ist nicht automatisch ein vorankommender Auftrag. Er kann auf Daten, eine Verbindung, einen Datensatz oder einen Wiederholungsversuch warten. Wartet er auf die Verbindung, fahren Sie mit dem nächsten Abschnitt fort.
Formulieren Sie das Ergebnis anhand des tatsächlich beobachteten Schritts. „Messwerte werden aktualisiert, aber kein neuer Publish-Aufruf ist zu sehen“ ist aussagekräftiger als „MQTT ist defekt“. Auch das ist noch keine Ursachenfeststellung; prüfen Sie Zustand und Fehlerprotokoll des Auftrags.
Publish-Versuche laufen, scheitern aber: die reale Verbindung prüfen
Nehmen Sie den letzten fehlgeschlagenen Publish-Versuch. Vergleichen Sie die tatsächlich verwendete Broker-Adresse und den Port, das Verbindungsergebnis und das Broker-Protokoll zur selben Zeit.
Kam keine Verbindung zustande, prüfen Sie anhand der Fehlerstufe Namensauflösung, TCP und bei aktivierter Verschlüsselung TLS. Bei TLS sind Gerätezeit, Vertrauenskette und Servername relevant. Das Abschalten der Zertifikatsprüfung ist kein Reparaturnachweis. Ein erfolgreicher Ping bestätigt weder den MQTT-Port noch den TLS-Handshake.
Wird die MQTT-Verbindung abgelehnt, vergleichen Sie die tatsächlich verwendeten Zugangsdaten mit der Broker-Antwort. Besteht die Verbindung, aber die Veröffentlichung scheitert, prüfen Sie Topic, Publish-Recht und Client-Fehler. Ordnen Sie einem Fehler jeweils eine konkrete Prüfung zu, statt mehrere Parameter gleichzeitig zu ändern. Für die vorgelagerten Ebenen Stromversorgung, Mobilfunk und IP-Pfad siehe den Wavetel-Leitfaden zur schichtweisen Routerdiagnose.
Testen Sie unter den tatsächlichen Ausgangs- und Konfigurationsbedingungen des lokalen Dienstes. Ein Test-Client auf einem Laptop belegt nur seinen eigenen erfolgreichen Versuch; er beweist nicht, dass der Router denselben Pfad, dieselbe Identität, dasselbe Topic oder dieselbe Datenquelle verwendet.
Unterscheiden Sie schließlich eine Bestätigung an den Client von einer neuen Nachricht im Broker-Ziel-Topic. MQTT 3.1.1 sieht für QoS 0 keine Publish-Bestätigung vor. Bei QoS 1 beweist PUBACK allein weder die Berechtigung zur Veröffentlichung noch die Verarbeitung durch die Plattform. Laut Standard darf ein Broker eine nicht autorisierte Veröffentlichung nach den normalen QoS-Regeln positiv bestätigen oder die Verbindung schließen. Prüfen Sie die Topic-Nachrichten am Broker oder beobachten Sie dieselbe neue Messung über eine autorisierte Diagnose-Subscription. Siehe MQTT 3.1.1, §§3.3.4, 3.3.5 und 4.3.2.
Wiederherstellung mit einer neuen Messung belegen
Sichern Sie die Fehlerbelege und stellen Sie anschließend den eingegrenzten Dienst oder die Verbindung im zulässigen Wartungsrahmen wieder her. „Online“ und „verbunden“ reichen nicht als Abschluss. Verfolgen Sie eine erst nach der Wiederherstellung entstandene Messung:
Die lokale Erfassung zeichnet sie auf und startet den zugehörigen Publish-Versuch.
Dieselbe Nachricht erscheint im Ziel-Topic des entfernten Brokers; Messzeit und Kennung stimmen überein.
Die Übertragung setzt sich im erwarteten Intervall fort; weiterer manueller Eingriff wird dokumentiert.
Das sind empfohlene Prüfschritte, keine Behauptung über einen durchgeführten Gerätetest. Hat der Broker die neue Messung, während die Plattform weiterhin einen alten Wert zeigt, ist der Abschnitt vom lokalen Client bis zum Broker belegt. Prüfen Sie nun Subscription und Plattformverarbeitung, statt den bereits sendenden Dienst wiederholt neu zu starten.
Eine hilfreiche Übergabe benennt die beobachtete Grenze: „Neue lokale Messungen liegen vor, aber der Sendeauftrag ruft Publish nicht erneut auf“ oder „Der Auftrag versucht weiter zu senden, aber die Verbindung scheitert bei TLS“. Fügen Sie die zugehörigen Protokolle und das tatsächlich verifizierte Wiederherstellungsergebnis hinzu.
FAQ
Ist ein Router an einem externen Broker zwangsläufig ein Empfänger?
Nein. Ein Client kann veröffentlichen, abonnieren oder beides. Hier sendet der Router erfasste Daten an einen entfernten Broker. Eine zusätzliche Subscriber-Rolle muss aus der tatsächlichen Konfiguration hervorgehen.
Warum kann ein Test-Client senden, der lokale Auftrag aber nicht?
Test-Client und Router-Auftrag können unterschiedliche Netzwerkausgänge, Identitäten, Topics oder Datenquellen nutzen. Prüfen Sie am lokalen Auftrag, ob eine neue Messung den Versuch ausgelöst hat und welches Verbindungs- und Publish-Ergebnis er meldet.
Nach einem Neustart kommen wieder Daten. Ist der Vorfall geklärt?
Die Übertragung funktioniert wieder; die Ursache des Stopps ist damit nicht erklärt. Bewahren Sie die Protokolle von vor dem Neustart auf, bestätigen Sie fortlaufend neue Messungen im erwarteten Rhythmus und dokumentieren Sie eine mögliche Wiederholung.
