TapHome
Colectare interes Funcție

Jurnal de mesaje pentru Packet Parser și MQTT: vedeți ce a trimis și ce a primit un modul

Un jurnal scurt al mesajelor pe care un modul Packet Parser le trimite și le primește, cu ora, direcția, topicul MQTT sau adresa și conținutul, afișat în setările de service ale modulului în timpul depanării. Nu este nevoie de un sniffer de rețea și conține doar mesajele proprii ale modulului, nu întreaga rețea.

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.

De ce și cum l-ați folosi

Packet Parser conectează dispozitive terțe la Core prin HTTP, TCP, UDP, FTP și MQTT. Când o valoare nu sosește sau sosește mult mai des decât ar trebui, instalatorul trebuie să vadă mesajele înseși: ce a intrat, pe ce topic, cu ce conținut și ce a trimis Core-ul. Astăzi, setările de service ale unui modul Packet Parser afișează statistici: câte mesaje au fost primite și trimise în ultimele 5 și 30 de minute, câți octeți au fost primiți și, pentru MQTT, mesajele pe fiecare topic. Ele arată că sosește ceva, dar nu ce anume și nici ce dispozitiv l-a trimis.

Un caz tipic: un instalator urmărește brokerul MQTT și vede starea unei lămpi la fiecare câteva secunde, uneori de mai multe ori pe secundă, deși ar trebui scrisă o dată pe minut. O trimite Core-ul sau alt sistem? Dacă este Core-ul, ce dispozitiv și ce script? Astăzi este nevoie pentru asta de un sniffer de rețea sau de un client MQTT pe un calculator, la fața locului. Un alt caz: o generație mai nouă a unui dispozitiv publică sub alte topicuri decât cele pe care le așteaptă scriptul listener. Valoarea rămâne goală, iar aplicația nu afișează nicio eroare, pentru că nu sosește niciodată nimic care să corespundă.

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.

Jurnalul ar arăta ambele cazuri dintr-o privire. În această schiță, scriptul de scriere al unei lămpi trimite același mesaj în fiecare secundă, iar un mesaj pe un alt topic este marcat ca neprocesat, deci niciun dispozitiv nu îl citește.

AstăziCu această idee
Mesaje pe topicDoar numărulNumărul și conținutul
Conținutul unui mesajInstrument separatSetări de service
Cine l-a trimisNu se vedeDispozitiv și script

Ce va fi posibil

Evaluăm această idee. Nimic din ce urmează nu este încă planificat, iar detaliile se pot încă schimba.

  • Jurnal la cerere. Ați porni jurnalul în setările de service ale modulului Packet Parser, pentru un timp limitat, în timpul depanării, și l-ați deschide într-o fereastră separată pe un calculator. S-ar opri singur, iar cât timp este oprit nu se înregistrează nimic.
  • Ambele direcții. Fiecare rând ar conține ora cu precizie de milisecundă, direcția (primit sau trimis), topicul MQTT sau adresa și portul, dimensiunea și conținutul, ca text sau ca octeți.
  • Ce dispozitiv l-a folosit. Pentru un mesaj primit, jurnalul ar arăta ce dispozitive ale modulului l-au procesat sau că niciunul nu l-a procesat: un topic pe care niciun script listener nu îl citește. Pentru un mesaj trimis, ar arăta dispozitivul și scriptul care l-au trimis, de exemplu un script de scriere cu MQTTPUBLISH.
  • Fiecare protocol în termenii săi. MQTT: topicul și conținutul mesajului. HTTP: metoda, calea, codul de stare, timpul de răspuns și corpul scurtat. TCP și UDP: datele trimise cu SENDDATA și datele primite. FTP: numele fișierului, dimensiunea și rezultatul, nu fișierul în sine.
  • Evenimente de conexiune. Conectat, deconectat și conectare eșuată, cu motivul și adresa brokerului sau a dispozitivului.
  • Parole ascunse. Antetele Authorization, cookie-urile, numele de utilizator, parolele și tokenurile din adrese ar fi mascate înainte de a fi scrise. Jurnalul ar rămâne în memoria Core-ului: nu ar fi trimis în cloud, nu ar face parte dintr-un backup și ar dispărea după o repornire.

Ce nu va fi posibil

  • Captura întregii rețele. Core-ul nu ar captura tot traficul de pe portul său de rețea și nu ar crea un fișier pentru Wireshark. O astfel de captură ar conține traficul tuturor dispozitivelor din casă, inclusiv parolele altor sisteme.
  • Tot traficul brokerului MQTT de pe Core, într-o primă versiune. Jurnalul ar conține ceea ce trimite și primește modulul Packet Parser însuși. Mesajele pe care alte dispozitive le schimbă prin brokerul de pe Core, fără ca vreun modul TapHome să fie abonat la ele, nu ar fi incluse.
  • Un istoric lung. Jurnalul ar păstra ultimele câteva sute de mesaje și ar scurta conținutul lung. Este un instrument de depanare, nu un jurnal permanent.
  • Mesajele de dinainte de pornire. Ce a sosit înainte de pornirea jurnalului, de exemplu imediat după repornirea Core-ului, nu ar fi inclus.
  • Alte integrări. Modbus, magistrala TapHome, Zigbee și alte integrări nu fac parte din această idee.

Cum se poate rezolva astăzi

  • Statisticile din setările de service. Deschideți setările de service ale modulului Packet Parser și comparați numărul de mesaje primite și trimise și, pentru MQTT, topicurile. Un topic la care nu vă așteptați arată că dispozitivul publică sub alt nume; un topic cu multe mesaje este un motiv pentru a restrânge filtrul de topic (consultați Analiza pachetelor).
  • Verificați mai întâi topicul în scriptul listener. Comparați RECEIVEDMSG.Topic înainte de a citi conținutul, astfel încât mesajele de care nu aveți nevoie să nu coste aproape nimic (consultați Scriptul listener).
  • Un client MQTT pe un calculator. Conectați un client MQTT (de exemplu MQTT Explorer) la același broker, care poate fi și MQTT Broker de pe Core, și abonați-vă la topicul dispozitivului sau la #. Clientul afișează fiecare mesaj cu ora și conținutul său.
  • Oglindirea portului pe un switch. Pentru HTTP, TCP și UDP, un switch administrabil poate copia traficul portului Core-ului pe un calculator cu Wireshark. Conținutul HTTPS rămâne criptat.

Cum ar putea arăta

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.

Pentru un modul HTTP, jurnalul ar asocia fiecare cerere cu răspunsul ei, ar afișa codul de stare și timpul de răspuns, ar marca erorile, de exemplu un timeout, și ar ascunde antetul Authorization. Imaginile sunt o schiță: ecranele finale pot arăta diferit.

Aflați mai multe

Ce protocol depanați cel mai des și ce ar trebui să vedeți în jurnal? Votați această idee și urmăriți-o pentru noutăți.

Asociate

Daikin Onecta în TapHome: controlul aparatelor de aer condiționat și al pompelor de căldură Daikin prin cloudul DaikinColectare interes Alarma Ajax în TapHome: armare și dezarmare și detectoare Ajax în smart rulesColectare interes Wi-Fi pentru Core: conectarea unității de control la rețeaua casei fără cablu LANColectare interes

Istoric status

  • 4 nov. 2026 Colectare interes Publicat

Comentarii 0

Alăturați-vă discuției

Autentificați-vă cu contul dvs. TapHome pentru a comenta. Echipa aprobă comentariile înainte ca acestea să apară.

Autentificare Creați un cont gratuit

Niciun comentariu momentan.

Ideile indică direcția, nu sunt angajamente. Nu publicăm date fixe; funcțiile lansate sunt anunțate în notele de lansare.