TapHome
Badanie zainteresowania Funkcja

Dziennik wiadomości dla Packet Parser i MQTT: zobacz, co moduł wysłał i odebrał

Krótki zapis wiadomości, które moduł Packet Parser wysyła i odbiera, z czasem, kierunkiem, tematem MQTT lub adresem i treścią, widoczny w jego ustawieniach serwisowych podczas diagnozowania problemów. Bez sniffera sieciowego i tylko własne wiadomości modułu, nie cała sieć.

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.

Dlaczego i jak to wykorzystasz

Packet Parser łączy urządzenia innych producentów z Core przez HTTP, TCP, UDP, FTP i MQTT. Gdy wartość nie dociera albo dociera znacznie częściej, niż powinna, instalator musi zobaczyć same wiadomości: co przyszło, w jakim temacie, z jaką treścią i co wysłał Core. Dziś ustawienia serwisowe modułu Packet Parser pokazują statystyki: ile wiadomości odebrano i wysłano w ciągu ostatnich 5 i 30 minut, ile bajtów odebrano, a dla MQTT liczbę wiadomości w każdym temacie. Mówią Ci, że coś przychodzi, ale nie co to jest ani które urządzenie to wysłało.

Typowy przypadek: instalator obserwuje broker MQTT i widzi stan jednej lampy co kilka sekund, czasem kilka razy na sekundę, choć powinien być zapisywany raz na minutę. Czy wysyła go Core, czy inny system? Jeśli Core, to które urządzenie i który skrypt? Dziś potrzeba do tego sniffera sieciowego albo klienta MQTT na komputerze obok instalacji. Inny przypadek: nowsza generacja urządzenia publikuje w innych tematach, niż oczekuje skrypt listener. Wartość pozostaje pusta, a aplikacja nie pokazuje błędu, bo nigdy nie przychodzi nic pasującego.

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.

Zapis pokazałby oba przypadki na pierwszy rzut oka. W tym szkicu skrypt zapisu lampy co sekundę wysyła tę samą wiadomość, a wiadomość w innym temacie jest oznaczona jako nieprzetworzona, więc żadne urządzenie jej nie odczytuje.

DziśZ tym pomysłem
Wiadomości według tematówTylko licznikiLiczniki i treść
Treść wiadomościOsobne narzędzieUstawienia serwisowe
Kto ją wysłałNiewidoczneUrządzenie i skrypt

Co będzie możliwe

Oceniamy ten pomysł. Nic z poniższego nie jest jeszcze zaplanowane, a szczegóły mogą się jeszcze zmienić.

  • Zapis na żądanie. Zapis można by uruchomić w ustawieniach serwisowych modułu Packet Parser na ograniczony czas podczas diagnozowania problemu i otworzyć w osobnym oknie na komputerze. Zatrzymałby się sam, a gdy jest wyłączony, nic nie jest zapisywane.
  • Oba kierunki. Każdy wiersz zawierałby czas z dokładnością do milisekundy, kierunek (odebrana lub wysłana), temat MQTT albo adres i port, rozmiar oraz treść, jako tekst lub jako bajty.
  • Które urządzenie z niej skorzystało. Dla odebranej wiadomości zapis pokazałby, które urządzenia modułu ją przetworzyły, albo że nie przetworzyło jej żadne: temat, którego nie odczytuje żaden skrypt listener. Dla wysłanej wiadomości pokazałby urządzenie i skrypt, który ją wysłał, na przykład skrypt zapisu z MQTTPUBLISH.
  • Każdy protokół na swój sposób. MQTT: temat i treść wiadomości. HTTP: metoda, ścieżka, kod statusu, czas odpowiedzi i skrócona treść. TCP i UDP: dane wysłane przez SENDDATA i dane odebrane. FTP: nazwa pliku, rozmiar i wynik, a nie sam plik.
  • Zdarzenia połączenia. Połączenie, rozłączenie i nieudana próba połączenia, z przyczyną i adresem brokera lub urządzenia.
  • Ukryte hasła. Nagłówki Authorization, pliki cookie, nazwy użytkowników, hasła i tokeny w adresach byłyby maskowane przed zapisaniem. Zapis pozostawałby w pamięci Core: nie byłby wysyłany do chmury, nie byłby częścią kopii zapasowej i znikałby po ponownym uruchomieniu.

Co nie będzie możliwe

  • Przechwytywanie całej sieci. Core nie przechwytywałby całego ruchu na swoim porcie sieciowym ani nie tworzyłby pliku dla programu Wireshark. Taki zrzut zawierałby ruch wszystkich urządzeń w domu, w tym hasła innych systemów.
  • Cały ruch brokera MQTT na Core, w pierwszej wersji. Zapis zawierałby to, co sam moduł Packet Parser wysyła i odbiera. Wiadomości, które inne urządzenia wymieniają przez broker na Core i których nie subskrybuje żaden moduł TapHome, nie trafiłyby do niego.
  • Długa historia. Zapis przechowywałby kilkaset ostatnich wiadomości i skracał długą treść. To narzędzie do diagnozowania problemów, a nie stały dziennik.
  • Wiadomości sprzed uruchomienia. To, co przyszło przed uruchomieniem zapisu, na przykład tuż po ponownym uruchomieniu Core, nie znalazłoby się w nim.
  • Inne integracje. Modbus, magistrala TapHome, Zigbee i inne integracje nie są częścią tego pomysłu.

Jak to rozwiązać dzisiaj

  • Statystyki w ustawieniach serwisowych. Otwórz ustawienia serwisowe modułu Packet Parser i porównaj liczby odebranych i wysłanych wiadomości, a dla MQTT tematy. Nieoczekiwany temat pokazuje, że urządzenie publikuje pod inną nazwą; temat z wieloma wiadomościami to powód, by zawęzić filtr tematu, zobacz sekcję Analiza pakietów.
  • Najpierw sprawdź temat w skrypcie listener. Porównaj RECEIVEDMSG.Topic, zanim odczytasz treść, aby niepotrzebne wiadomości prawie nic nie kosztowały, zobacz sekcję Skrypt listener.
  • Klient MQTT na komputerze. Połącz klienta MQTT (na przykład MQTT Explorer) z tym samym brokerem, także z brokerem MQTT na Core, i zasubskrybuj temat urządzenia albo #. Pokazuje on każdą wiadomość z jej czasem i treścią.
  • Port lustrzany na przełączniku. W przypadku HTTP, TCP i UDP zarządzalny przełącznik może kopiować ruch z portu Core na komputer z programem Wireshark. Treść HTTPS pozostaje zaszyfrowana.

Jak mogłoby to wyglądać

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.

W module HTTP zapis łączyłby każde żądanie z jego odpowiedzią, pokazywałby kod statusu i czas odpowiedzi, oznaczałby błędy, takie jak przekroczenie limitu czasu, i ukrywałby nagłówek Authorization. Obrazy są szkicem: ostateczne ekrany mogą wyglądać inaczej.

Dowiedz się więcej

Który protokół diagnozujesz najczęściej i co musiałbyś widzieć w zapisie? Zagłosuj na ten pomysł i obserwuj go, by śledzić nowości.

Powiązane

Daikin Onecta w TapHome: sterowanie klimatyzatorami i pompami ciepła Daikin przez chmurę DaikinBadanie zainteresowania Alarm Ajax w TapHome: uzbrajanie i rozbrajanie oraz czujki Ajax w smart rulesBadanie zainteresowania Wi-Fi dla Core: połączenie jednostki sterującej z siecią domową bez kabla LANBadanie zainteresowania

Historia statusu

  • 4 lis 2026 Badanie zainteresowania Opublikowano

Komentarze 0

Dołącz do dyskusji

Zaloguj się na swoje konto TapHome, aby skomentować. Zespół zatwierdza komentarze przed ich wyświetleniem.

Zaloguj się Załóż darmowe konto

Jeszcze nie ma komentarzy.

Pomysły wskazują kierunek rozwoju, nie zobowiązania. Nie publikujemy dat; wydane funkcje są ogłaszane w informacjach o wydaniu.