TapHome
Raccolta interesse Funzionalità

Registro dei messaggi per Packet Parser e MQTT: vedi cosa ha inviato e ricevuto un modulo

Un breve registro dei messaggi che un modulo Packet Parser invia e riceve, con ora, direzione, topic MQTT o indirizzo e contenuto, mostrato nelle impostazioni di servizio mentre risolvi un problema. Non serve uno sniffer di rete e contiene solo i messaggi del modulo, non quelli di tutta la rete.

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.

Perché e come lo useresti

Packet Parser collega dispositivi di terze parti al Core tramite HTTP, TCP, UDP, FTP e MQTT. Quando un valore non arriva, o arriva molto più spesso del dovuto, l’installatore ha bisogno di vedere i messaggi stessi: cosa è arrivato, su quale topic, con quale contenuto e cosa ha inviato il Core. Oggi le impostazioni di servizio di un modulo Packet Parser mostrano statistiche: quanti messaggi sono stati ricevuti e inviati negli ultimi 5 e 30 minuti, quanti byte sono stati ricevuti e, per MQTT, i messaggi per topic. Ti dicono che qualcosa arriva, non cosa sia né quale dispositivo l’abbia inviato.

Un caso tipico: un installatore osserva il broker MQTT e vede lo stato di una lampada ogni pochi secondi, a volte più volte al secondo, anche se dovrebbe essere scritto una volta al minuto. Lo invia il Core o un altro sistema? Se è il Core, quale dispositivo e quale script? Oggi serve uno sniffer di rete o un client MQTT su un computer accanto all’impianto. Un altro caso: una generazione più recente di un dispositivo pubblica su topic diversi da quelli che lo script listener si aspetta. Il valore resta vuoto e l’app non mostra alcun errore, perché non arriva mai nulla di corrispondente.

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.

Il registro mostrerebbe entrambi i casi a colpo d’occhio. In questa bozza, lo script di scrittura di una lampada invia lo stesso messaggio ogni secondo, e un messaggio su un altro topic è segnato come non elaborato, quindi nessun dispositivo lo legge.

OggiCon questa idea
Messaggi per topicSolo conteggiConteggi e contenuto
Contenuto di un messaggioStrumento separatoImpostazioni di servizio
Chi l’ha inviatoNon visibileDispositivo e script

Cosa sarà possibile

Stiamo valutando questa idea. Niente di quanto segue è ancora pianificato, e i dettagli potrebbero ancora cambiare.

  • Registro su richiesta. Avvieresti la registrazione nelle impostazioni di servizio di un modulo Packet Parser per un tempo limitato mentre risolvi un problema, e apriresti il registro in una finestra separata su un computer. La registrazione si fermerebbe da sola, e mentre è disattivata non viene registrato nulla.
  • Entrambe le direzioni. Ogni riga riporterebbe l’ora al millisecondo, la direzione (ricevuto o inviato), il topic MQTT o l’indirizzo e la porta, la dimensione e il contenuto, come testo o come byte.
  • Quale dispositivo l’ha usato. Per un messaggio ricevuto, il registro mostrerebbe quali dispositivi del modulo l’hanno elaborato, oppure che nessuno l’ha fatto: un topic che nessuno script listener legge. Per un messaggio inviato, mostrerebbe il dispositivo e lo script che l’ha inviato, per esempio uno script di scrittura con MQTTPUBLISH.
  • Ogni protocollo con i suoi termini. MQTT: topic e contenuto del messaggio. HTTP: metodo, percorso, codice di stato, tempo di risposta e un corpo abbreviato. TCP e UDP: i dati inviati con SENDDATA e i dati ricevuti. FTP: nome del file, dimensione e risultato, non il file stesso.
  • Eventi di connessione. Connesso, scollegato e connessione non riuscita, con il motivo e l’indirizzo del broker o del dispositivo.
  • Password nascoste. Intestazioni Authorization, cookie, nomi utente, password e token negli indirizzi verrebbero mascherati prima di essere scritti. Il registro resterebbe nella memoria del Core: non verrebbe inviato al cloud, non farebbe parte di un backup e sparirebbe dopo un riavvio.

Cosa non sarà possibile

  • Catturare tutta la rete. Il Core non catturerebbe tutto il traffico sulla sua porta di rete né produrrebbe un file per Wireshark. Una cattura del genere conterrebbe il traffico di ogni dispositivo della casa, comprese le password di altri sistemi.
  • Tutto il traffico del broker MQTT sul Core, in una prima versione. Il registro conterrebbe ciò che il modulo Packet Parser stesso invia e riceve. I messaggi che altri dispositivi si scambiano attraverso il broker sul Core, senza che alcun modulo TapHome vi sia iscritto, non ci sarebbero.
  • Una lunga cronologia. Il registro conserverebbe alcune centinaia di messaggi più recenti e accorcerebbe i contenuti lunghi. È uno strumento per la risoluzione dei problemi, non un log permanente.
  • Messaggi precedenti all’avvio. Ciò che è arrivato prima che avviassi la registrazione, per esempio subito dopo il riavvio del Core, non ci sarebbe.
  • Altre integrazioni. Modbus, il bus TapHome, Zigbee e altre integrazioni non fanno parte di questa idea.

Come risolverlo oggi

  • Statistiche nelle impostazioni di servizio. Apri le impostazioni di servizio del modulo Packet Parser e confronta i conteggi dei messaggi ricevuti e inviati e, per MQTT, i topic. Un topic che non ti aspettavi indica che il dispositivo pubblica con un altro nome; un topic con molti messaggi è un motivo per restringere il filtro di topic, vedi Analisi dei pacchetti.
  • Controlla prima il topic nello script listener. Confronta RECEIVEDMSG.Topic prima di leggere il contenuto, così i messaggi che non ti servono non costano quasi nulla, vedi Script listener.
  • Un client MQTT su un computer. Collega un client MQTT (per esempio MQTT Explorer) allo stesso broker, che può essere anche il Broker MQTT sul Core, e iscriviti al topic del dispositivo o a #. Mostra ogni messaggio con l’ora e il contenuto.
  • Una porta mirror su uno switch. Per HTTP, TCP e UDP, uno switch gestito può copiare il traffico della porta del Core su un computer con Wireshark. Il contenuto HTTPS resta cifrato.

Come potrebbe apparire

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.

Per un modulo HTTP, il registro abbinerebbe ogni richiesta alla sua risposta, mostrerebbe il codice di stato e il tempo di risposta, segnalerebbe errori come un timeout e nasconderebbe l’intestazione Authorization. Le immagini sono una bozza: le schermate finali potrebbero essere diverse.

Per saperne di più

Quale protocollo ti capita più spesso di dover diagnosticare, e cosa ti servirebbe vedere nel registro? Vota questa idea e seguila per ricevere aggiornamenti.

Correlati

Daikin Onecta in TapHome: controlla climatizzatori e pompe di calore Daikin tramite il cloud DaikinRaccolta interesse Allarme Ajax in TapHome: inserire e disinserire e usare i rilevatori Ajax nelle smart ruleRaccolta interesse Wi-Fi per il Core: collegare l'unità di controllo alla rete di casa senza cavo LANRaccolta interesse

Cronologia dello stato

  • 4 nov 2026 Raccolta interesse Pubblicato

Commenti 0

Partecipa alla discussione

Accedi con il tuo account TapHome per commentare. Il team approva i commenti prima che vengano pubblicati.

Accedi Crea un account gratuito

Ancora nessun commento.

Le idee descrivono la direzione, non sono impegni. Non pubblichiamo date; le funzionalità rilasciate vengono annunciate nelle note di rilascio.