MQTT2_CLIENT / MQTT2_SERVER: Show MQTT traffic

[rudolfkoenig]

Ich habe die beiden Module erweitert, damit in der FHEMWEB Detailansicht das MQTT Verkehr direkt dargestellt werden kann, ohne den Umweg ueber rawEvents & EventMonitor.

Da die Implementation doch komplizierter wurde als erwartet, bin ich nicht sicher, dass ich nicht irgendwo Nebeneffekte eingebaut habe.
Anfassen musste ich ausser den beiden Modulen console.js und 01_FHEMWEB.pm, Letzteres nur leicht.

[Otto123]

ich weiß nicht ob es ein Nebeneffekt ist - aber: der clearretain setter gibt bei mir einen Hash Wert zurück und bewirkt nichts. Eine Zwischenversion - also mit clearretain und ohne Show MQTT hatte ich nicht im Einsatz.

Das Show MQTT Traffic sieht gut aus - danke!

[rudolfkoenig]

ich weiß nicht ob es ein Nebeneffekt ist - aber: der clearretain setter gibt bei mir einen Hash Wert zurück und bewirkt nichts.

Das war kein Nebeneffekt, es war schon "immer" so.
Danke fuer den Hinweis, habs gefixt.

[Otto123]

Hallo Rudi,

der neue Effekt von clearretain: er gibt nichts mehr zurück - aber es tut immer noch nichts?

Gruß Otto

[rudolfkoenig]

Danke fuer den Hinweis, habs gefixt.

[Reinhard.M]

Hallo Rudi,
ich beobachte seit einiger Zeit einen Effekt der eventuell mit der Änderung zusammenhängen könnte.
Ich habe ca. 30 Geräte über MQTT2 in FHEM eingebunden. Ich verwende MQTT2_SERVER, alles läuft perfekt. Sporadisch (sagen wir, alle paar Tage) bekommen aber meine Devices keine Verbindung mehr zum Broker. Das kann ich in der Weboberfläche der Devices sehen die alle auf Tasmota laufen. Die Einschränkungen reichen von mehreren Sekunden Verzögerung bis komplette Fehlfunktion (Device reagiert nicht). Das kann mehrere Stunden andauern. Dann ist dieses Verhalten genau so plötzlich wieder verschwunden wie es aufgetaucht ist und alles funktioniert problemlos. Bislang habe ich keine Systematik mit anderen Vorgängen auf meinem Raspi feststellen können, alles läuft vor, während und nach der Störung identisch.
Ich weiß nicht mehr wann ich es zum ersten Mal beobachtet habe, es ist aber noch nicht so lange her und kann zeitlich durchaus mit der Änderung von dir zusammenhängen. Hättest du eine Idee für mich wie ich im Fehlerfall vorgehe um brauchbare Logdaten hierfür zu erhalten? Z.B. welches Device mit welchem verbose Level.

Gruß Reinhard

[TomLee]

Wird es irgendwann mal die Möglichkeit geben den Verkehr in dem "Fenster" Show MQTT Traffic zu filtern, wie im Event-Monitor oder ist das was ganz anderes und nicht vergleichbar/umsetzbar ?

[rudolfkoenig]

ich beobachte seit einiger Zeit einen Effekt der eventuell mit der Änderung zusammenhängen könnte.

Anhand der Problembeschreibung halte ich FHEM als Verursacher fuer unwahrscheinlich, und diese Aenderung noch viel weniger.
Aber man lernt ja nie aus.

Im Problemfall wuerde ich:
- mit "mosquitto_pub -h <FHEMHOST> -i TESTDEV -t Hello -m World" schauen, ob eine Verbindung zum MQTT2_SERVER moeglich ist. Wenn ja, dann wird ein neues MQTT2_DEVICE mit dem Namen ..._TESTDEV angelegt.
- "attr global verbose 5" setzen, und im Log nach Merkwuerdigkeiten suchen (lassen).
- pruefen, ob ein FHEM-Restart das Problem behebt.
Ist FHEMWEB in dieser Zeit erreichbar?

Wird es irgendwann mal die Möglichkeit geben den Verkehr in dem "Fenster" Show MQTT Traffic zu filtern, wie im Event-Monitor oder ist das was ganz anderes und nicht vergleichbar/umsetzbar ?

Der Code verwendet nicht die gleiche Funktion, wie das Event-Monitor, d.h. ich muesste es erneut implementieren.
Wenn noch jemand den Wunsch danach aeussert, werde ich es einbauen.

[TomLee]

Ich brauchs mittlerweile nicht mehr und wenn es auch noch (mehr) Arbeit macht auch nicht darauf pochen, bin aber der Meinung das Feature würde FHEM gut "stehen" und bei einem MQTT-Neuling/Anwender mit keinem Bezug zu MQTT zum schnelleren Verständnis beitragen (mir hätte es damals geholfen) und auch die ein oder andere Frage würde sich automatisch erübrigen, das es für die (beruflichen) Entwickler unnötig ist steht ausser Frage.

(Wenns irgendwann mal kommt -> ein Button zum erstellen einer Textdatei (mit den geloggten Daten) zum hier anhängen bei Fragen fänd ich auch gut <-    ich weiß für "Entwickler" unnötig )

[xenos1984]

Ich würde mich dem anschließen, dass eine Funktion, den MQTT-Traffic gefiltert anzuzeigen, hilfreich wäre (wenn auch nicht unbedingt von mir momentan gebraucht). Vielleicht wäre es in der Form sinnvoll, dass man als "Filter" eine Topic-Wildcard (also ein Topic mit ggf. + und #) eingeben könnte und dann nur Nachrichten bekommt, die zu dem Topic passen. Oder das Format topic:message bzw. cid:topic:message, das in der gleichen Form in readingList von MQTT2_DEVICE benutzt wird. So sieht man genau den Traffic, auf den ein Reading reagiert.

[Beta-User]

Hmm, also...

Habe im Moment keine explizite Meinung dazu, als Gewohnheitstier schaue ich sowieso "von außen" (mit Linux-Kommandozeilen-Tools) auf den jeweiligen MQTT-Server, weswegen ich auch mit "rawEvents" nicht die große Erfahrung gesammelt habe. Falls das letztere eigentlich alle Features bietet, um den ein- und ausgehenden Verkehr anzuzeigen, ist es m.E. unnötige Doppelarbeit, und die User, die nicht sowieso wissen, wie es geht, muss man dann eh' coachen.

Andererseits hat der Ansatz "ein Tool an zentraler Stelle" auch was für sich (wenn es einfach zu benutzen ist).
Tendenziell würde ich auch die "MQTT-like" Notation bevorzugen, wenn es als MQTT-Tool zu interpretieren sein soll.

Bedarf für das Sichtbarmachen vom Traffic an sich ist jedenfalls gegeben (v.a., weil eine bei vielen beliebte Handy-App wohl nicht mehr kostenlos angeboten/aktualisiert wird, und man diesen Nutzerkreis nicht wirklich gut auf die Kommandozeile verweisen kann...), von daher nochmal ein ausdrückliches Danke für das Tool an sich!

[xenos1984]

Ich benutze normalerweise auch die Kommandozeile, insbesondere mosquitto_sub, um den Verkehr anzuzeigen - damit hat man dann automatisch die Möglichkeit, nach Topic zu filtern.

Was bei der Kommandozeilen-Methode bzw. konkret bei mosquitto_sub aber wohl nicht geht ist die Client-ID des Absenders einer Nachricht anzuzeigen oder danach zu filtern - was im MQTT2_SERVER aber vermutlich gehen sollte.

Unabhängig von der Filter-Frage: Wäre es möglich (und sinnvoll), unter "Show MQTT traffic" die Client-ID mit anzuzeigen?

[rudolfkoenig]

Ich habe die Traffic-Anzeige etwas erweitert:
- MQTT2_SERVER zeigt statt RCVD die clientID an
- es gibt eine Reset-Moeglichkeit, analog zum Event-Monitor
- es gibt einen Filter, der den Inhalt der ganzen Zeile als Regexp filtert.
- wenn das Message ein JSON ist, dann kann man die Daten mit draufklicken formatiert anzeigen.

[xenos1984]

Edit: Kommando zurück, alles funktioniert wie gewünscht. Ich musste nur das JavaScript mit Strg+F5 neu laden. Super!

Ich habe gerade ein Update gemacht (FHEM komplett), allerdings komme ich noch nicht ganz mit den neuen Funktionen klar:

- MQTT2_SERVER zeigt statt RCVD die clientID an

Sieht gut aus. Allerdings meine ich, dass vorher nach jeder Nachricht ein Zeilenumbruch war, der jetzt nicht mehr da ist - ersteres fand ich übersichtlicher.

- es gibt eine Reset-Moeglichkeit, analog zum Event-Monitor
- es gibt einen Filter, der den Inhalt der ganzen Zeile als Regexp filtert.

Wo sich die versteckt haben, konnte ich noch nicht herausfinden...

- wenn das Message ein JSON ist, dann kann man die Daten mit draufklicken formatiert anzeigen.

Kann es sein, dass man das Encoding anders einstellen muss als den "alten" Standardwert (ich erinnere mich da an eine lange Diskussion rund um Unicode). Bei mir sieht das Ergebnis etwas unschön aus und klicken lässt sich nichts. Vorher sah das JSON normal aus. Die Daten werden im Beispiel von mosquitto_pub gesendet, aber mit JSON von einem Arduino mit PubSubClient sieht es genau so aus.

Code: [Auswählen]

["","status/meter/water/cold","{\u0022media\u0022:\u0022cold water\u0022,\u0022meter\u0022:\u0022multical21\u0022,\u0022name\u0022:\u0022cold\u0022,\u0022id\u0022:\u002276522329\u0022,\u0022total_m3\u0022:19.463,\u0022target_m3\u0022:19.238,\u0022max_flow_m3h\u0022:0,\u0022flow_temperature_c\u0022:127,\u0022external_temperature_c\u0022:127,\u0022current_status\u0022:\u0022\u0022,\u0022time_dry\u0022:\u0022\u0022,\u0022time_reversed\u0022:\u0022\u0022,\u0022time_leaking\u0022:\u0022\u0022,\u0022time_bursting\u0022:\u0022\u0022,\u0022timestamp\u0022:\u00222022-05-18T06:22:29Z\u0022,\u0022device\u0022:\u0022rtl433[]\u0022,\u0022rssi_dbm\u0022:999}"]