TapHome
Interesse wird gesammelt Funktion

Nachrichtenprotokoll für Packet Parser und MQTT: sehen, was ein Modul gesendet und empfangen hat

Eine kurze Aufzeichnung der Nachrichten, die ein Packet-Parser-Modul sendet und empfängt, mit Zeit, Richtung, MQTT-Topic oder Adresse und Inhalt, angezeigt in seinen Serviceeinstellungen bei der Fehlersuche. Ohne Netzwerk-Sniffer und nur die eigenen Nachrichten des Moduls, nicht das ganze Netzwerk.

Messages over MQTT, HTTP, TCP and UDP go in and out of a Packet Parser module on the Core, which hands each received one to its devices: two process it, one message is processed by none. The record lists every message, marked as processed or not, while other network traffic stays outside.
Messages over MQTT, HTTP, TCP and UDP go in and out of a Packet Parser module on the Core, which hands each received one to its devices: two process it, one message is processed by none. The record lists every message, marked as processed or not, while other network traffic stays outside.

Warum und wofür Sie es nutzen würden

Packet Parser bindet Geräte von Drittanbietern über HTTP, TCP, UDP, FTP und MQTT an den Core an. Wenn ein Wert nicht ankommt oder viel häufiger ankommt, als er sollte, muss der Installateur die Nachrichten selbst sehen: was hereinkam, auf welchem Topic, mit welchem Inhalt, und was der Core gesendet hat. Heute zeigen die Serviceeinstellungen eines Packet-Parser-Moduls Statistiken: wie viele Nachrichten in den letzten 5 und 30 Minuten empfangen und gesendet wurden, wie viele Bytes empfangen wurden und bei MQTT die Nachrichten pro Topic. Sie zeigen Ihnen, dass etwas ankommt, aber nicht, was es ist oder welches Gerät es gesendet hat.

Ein typischer Fall: Ein Installateur beobachtet den MQTT-Broker und sieht den Zustand einer Lampe alle paar Sekunden, manchmal mehrmals pro Sekunde, obwohl er einmal pro Minute geschrieben werden sollte. Sendet ihn der Core oder ein anderes System? Wenn es der Core ist, welches Gerät und welches Skript? Heute braucht man dafür einen Netzwerk-Sniffer oder einen MQTT-Client auf einem Computer neben der Installation. Ein anderer Fall: Eine neuere Generation eines Geräts veröffentlicht unter anderen Topics, als das Listener-Skript erwartet. Der Wert bleibt leer und die App zeigt keinen Fehler, weil nie etwas Passendes ankommt.

Draft of the message log window in the TapHome app on a Mac for an MQTT module: messages with time, direction, topic, size, content and device. A lamp's write script sends the same message every second, and one message is marked Not processed. Below, the selected message with its full content.

Die Aufzeichnung würde beide Fälle auf einen Blick zeigen. In diesem Entwurf sendet das Schreibskript einer Lampe jede Sekunde dieselbe Nachricht, und eine Nachricht auf einem anderen Topic ist als nicht verarbeitet markiert, also liest sie kein Gerät.

HeuteMit dieser Idee
Nachrichten pro TopicNur AnzahlAnzahl und Inhalt
Inhalt einer NachrichtSeparates ToolServiceeinstellungen
Wer sie gesendet hatNicht sichtbarGerät und Skript

Was möglich sein wird

Wir prüfen diese Idee. Nichts von dem Folgenden ist bereits geplant, und Details können sich noch ändern.

  • Aufzeichnung auf Abruf. Sie würden die Aufzeichnung bei der Fehlersuche in den Serviceeinstellungen eines Packet-Parser-Moduls für eine begrenzte Zeit starten und sie auf einem Computer in einem eigenen Fenster öffnen. Sie würde von selbst enden, und solange sie ausgeschaltet ist, wird nichts aufgezeichnet.
  • Beide Richtungen. Jede Zeile würde die Zeit auf die Millisekunde genau, die Richtung (empfangen oder gesendet), das MQTT-Topic oder die Adresse und den Port, die Größe und den Inhalt als Text oder als Bytes enthalten.
  • Welches Gerät sie verwendet hat. Bei einer empfangenen Nachricht würde die Aufzeichnung zeigen, welche Geräte des Moduls sie verarbeitet haben, oder dass es keines getan hat: ein Topic, das kein Listener-Skript liest. Bei einer gesendeten Nachricht würde sie das Gerät und das Skript zeigen, die sie gesendet haben, zum Beispiel ein Schreibskript mit MQTTPUBLISH.
  • Jedes Protokoll mit seinen eigenen Angaben. MQTT: Topic und Inhalt der Nachricht. HTTP: Methode, Pfad, Statuscode, Antwortzeit und ein gekürzter Body. TCP und UDP: die mit SENDDATA gesendeten und die empfangenen Daten. FTP: Dateiname, Größe und Ergebnis, nicht die Datei selbst.
  • Verbindungsereignisse. Verbunden, getrennt und Verbindung fehlgeschlagen, mit dem Grund und der Adresse des Brokers oder Geräts.
  • Passwörter verborgen. Authorization-Header, Cookies, Benutzernamen, Passwörter und Tokens in Adressen würden maskiert, bevor sie geschrieben werden. Die Aufzeichnung würde im Speicher des Cores bleiben: Sie würde nicht in die Cloud gesendet, wäre nicht Teil eines Backups und wäre nach einem Neustart verschwunden.

Was nicht möglich sein wird

  • Mitschnitt des ganzen Netzwerks. Der Core würde nicht den gesamten Datenverkehr an seinem Netzwerkport mitschneiden und keine Datei für Wireshark erzeugen. Ein solcher Mitschnitt würde den Datenverkehr aller Geräte im Haus enthalten, einschließlich der Passwörter anderer Systeme.
  • Der gesamte Datenverkehr des MQTT-Brokers auf dem Core, in einer ersten Version. Die Aufzeichnung würde enthalten, was das Packet-Parser-Modul selbst sendet und empfängt. Nachrichten, die andere Geräte über den Broker auf dem Core austauschen, ohne dass ein TapHome-Modul sie abonniert, wären nicht darin.
  • Eine lange Historie. Die Aufzeichnung würde die letzten paar hundert Nachrichten behalten und lange Inhalte kürzen. Sie ist ein Werkzeug für die Fehlersuche, kein dauerhaftes Protokoll.
  • Nachrichten aus der Zeit vor dem Start. Was ankam, bevor Sie die Aufzeichnung gestartet haben, zum Beispiel direkt nach einem Neustart des Cores, wäre nicht darin.
  • Andere Integrationen. Modbus, der TapHome-Bus, Zigbee und andere Integrationen sind nicht Teil dieser Idee.

Wie man es heute löst

  • Statistiken in den Serviceeinstellungen. Öffnen Sie die Serviceeinstellungen des Packet-Parser-Moduls und vergleichen Sie die Anzahl der empfangenen und gesendeten Nachrichten und bei MQTT die Topics. Ein Topic, das Sie nicht erwartet haben, zeigt, dass das Gerät unter einem anderen Namen veröffentlicht; ein Topic mit vielen Nachrichten ist ein Grund, den Topic-Filter enger zu fassen, siehe Packet-Analyse.
  • Prüfen Sie im Listener-Skript zuerst das Topic. Vergleichen Sie RECEIVEDMSG.Topic, bevor Sie den Inhalt lesen, damit Nachrichten, die Sie nicht brauchen, fast nichts kosten, siehe Listener-Skript.
  • Ein MQTT-Client auf einem Computer. Verbinden Sie einen MQTT-Client (zum Beispiel MQTT Explorer) mit demselben Broker, auch mit dem MQTT-Broker auf dem Core, und abonnieren Sie das Topic des Geräts oder #. Er zeigt jede Nachricht mit ihrer Zeit und ihrem Inhalt.
  • Ein Mirror-Port an einem Switch. Für HTTP, TCP und UDP kann ein Managed Switch den Datenverkehr am Port des Cores auf einen Computer mit Wireshark kopieren. Der Inhalt von HTTPS bleibt verschlüsselt.

Wie es aussehen könnte

Draft of the message log window for an HTTP module: each request with method and path, each answer with status code and response time, a timeout and an Unauthorized answer in pink. The selected request shows its headers with the Authorization value hidden.

Bei einem HTTP-Modul würde die Aufzeichnung jeder Anfrage ihre Antwort zuordnen, den Statuscode und die Antwortzeit zeigen, Fehler wie eine Zeitüberschreitung markieren und den Authorization-Header verbergen. Die Bilder sind ein Entwurf: Die endgültigen Bildschirme können anders aussehen.

Mehr erfahren

Bei welchem Protokoll suchen Sie am häufigsten Fehler, und was müssten Sie in der Aufzeichnung sehen? Stimmen Sie für diese Idee ab und folgen Sie ihr für Neuigkeiten.

Verwandt

Daikin Onecta in TapHome: Daikin-Klimaanlagen und -Wärmepumpen über die Daikin-Cloud steuernInteresse wird gesammelt Ajax-Alarmanlage in TapHome: scharf und unscharf schalten und Ajax-Melder in smart rules nutzenInteresse wird gesammelt WLAN für den Core: die Steuereinheit ohne LAN-Kabel mit dem Heimnetz verbindenInteresse wird gesammelt

Statusverlauf

  • 04.11.2026 Interesse wird gesammelt Veröffentlicht

Kommentare 0

Diskutieren Sie mit

Melden Sie sich mit Ihrem TapHome-Konto an, um zu kommentieren. Das Team gibt Kommentare frei, bevor sie erscheinen.

Anmelden Kostenloses Konto erstellen

Noch keine Kommentare.

Ideen zeigen die Richtung, keine Zusagen. Wir nennen keine Termine; veröffentlichte Funktionen kündigen wir in den Release Notes an.