MQTT2_Client/DevIO überwachen

[PatrickR]

Guten Abend zusammen,

ich setze für nahezu sämtliche meiner IO-Geräte bzw. externe Verbindungen DOIFs ein, die bei Abweichung des Sollzustands eine Alarmmeldung versenden, z. B. im Fall von MQTT:

Code Auswählen Erweitern


defmod D_S_MQTTBroker DOIF ([MQTTBroker] ne "opened - active") ({\
fhem(sprintf('set Pushover_pr msg title="%s" message="Gerät: %s\nStatus: %s\nZeitstempel: %s" sound="falling" priority=0',\
"$SELF",\
"$DEVICE",\
"[$DEVICE]",\
ReadingsTimestamp("$DEVICE", "state", "")\
));; \
}) DOELSE (\
)

Nun möchte ich schrittweise auf MQTT2 umstellen. Hier stößt mein obiger Ansatz leider an seine Grenzen, da weder STATE noch das state-Reading Events feuern - Lediglich die von DevIO generierten CONNECTED/DISCONNECTED-Events, wobei CONNECTED wiederum gemäß Doku bei der initialen Verbindung nicht generiert wird. Ebenso erhalte ich kein DISCONNECTED-Event wenn der initiale Connect fehlschlägt.

Besteht die Möglichkeit, die entsprechenden Events zu generieren? Ich würde nur ungern den Status pollen.

Patrick

[rudolfkoenig]

Fuer diese Aufgabe wurde in MQTT das LWT vorgesehen.

[PatrickR]

Hallo Rudi!

Fuer diese Aufgabe wurde in MQTT das LWT vorgesehen.

Könntest Du das näher ausführen? Konkret: Wie kann ich das LWT vom Broker abholen, um darauf in FHEM zu reagieren wenn die Verbindung nicht steht?

Patrick

[Beta-User]

Es geht m.E. beim "last will" (wie bei eigentlich allen MQTT-Themen) nicht darum, dass man irgendwas vom Broker abholen müßte, sondern darum, dass der Broker Abonnenten aktiv informiert, wenn irgendwas relevantes passiert, im Falle von LWT also die vorher festgelegte Message an alle verschickt wird.

Siehe z.B. http://www.steves-internet-guide.com/mqtt-last-will-example/ (Suchmaschine: mqtt last will)

Darauf kannst du mit jedem Event-Handler reagieren...

EDIT: Oder geht es darum, dass der MQTT2_Server oder .*_CLIENT offline ist? Da müßte es aber auch eine Statusmeldung geben, auf die man einen Eventhandler ansetzen kann...

[PatrickR]

Es geht m.E. beim "last will" (wie bei eigentlich allen MQTT-Themen) nicht darum, dass man irgendwas vom Broker abholen müßte, sondern darum, dass der Broker Abonnenten aktiv informiert, wenn irgendwas relevantes passiert, im Falle von LWT also die vorher festgelegte Message an alle verschickt wird.
[...]

Richtig, und deshalb löst es auch mein Problem nicht wenn der Broker Bescheid weiß, nicht aber FHEM.

Darauf kannst du mit jedem Event-Handler reagieren...

Zumindest nicht in FHEM, wenn das Ereignis in exakt den Fällen eintritt, in denen der Broker nicht erreicht wird und FHEM es somit nicht erfährt.

EDIT: Oder geht es darum, dass der MQTT2_Server oder .*_CLIENT offline ist? Da müßte es aber auch eine Statusmeldung geben, auf die man einen Eventhandler ansetzen kann...

Genau um den Fall MQTT2_Client ist disconnected geht es (siehe das Startposting). Leider gibt es auch nach intensiven Recherchen kein Event, auf das ich reagieren kann, was ich ärgerlich finde.

[sash.sc]

Hallo zusammen.

Habe da mal eine Frage.
Ich habe von gosund die funk mess Steckdosen Sp1 mit tasmota.
Wenn die Dosen offline sind, werden die Messwerte nicht auf 0 zurück gesetzt. Es bleibt der letzte Messwert bestehen, obwohl die Dose offline ist.

Ist das normal? Würde es logischer finden
Das die Werte dann auf Null gesetzt werden.

Gruß Sascha

Gesendet von meinem E6653 mit Tapatalk

[PatrickR]

Habe da mal eine Frage.

Kannst Du die Frage bitte in einen neuen Thread packen? Der hier verwässert schon genug.

[Beta-User]

Genau um den Fall MQTT2_Client ist disconnected geht es (siehe das Startposting). Leider gibt es auch nach intensiven Recherchen kein Event, auf das ich reagieren kann, was ich ärgerlich finde.

Danke für die Klarstellung, deine Antwort an Rudi hatte dann irgendwie in eine andere Richtung gewiesen, erst nachher hatte ich dann deinen Ausgangspost nochmal kritisch angesehen, daher dann der Edit.

Was das disconnect angeht: Ich hatte entsprechende Events iVm.einem MQTT2_CLIENT schon gesehen (im Event-Monitor), da aber ausgelöst durch irgendwas anderes und auch gleich wieder mit anschließendem connect. "Irgendwie" müßte da also eine entsprechende Funktionalität im CLIENT da sein.
Anmerkung @Rudi: Irgendwie wäre es schöner, der state des IO's wäre aussagekräftiger. "Initialized" mit Aktualisierungsdatum = Startdatum ist selbst bei nicht festgestellten Problemen irgendwie ziemlich statisch, und weitere Readings oder Internals, aus denen man viel ablesen könnte, gibt es auch nicht. (Kosmetik, aber trotzdem...)

Einen Verbindungsabbruch (durch stoppen des Brokers) hattest du vermutlich schon versucht, oder? Es gibt am Client auch ein Attribut "keepaliveFactor". Ob das irgendwas mit dem von dir gewünschten Event zu tun hat, kann ich im Moment aber nicht sagen.

[rudolfkoenig]

Richtig, und deshalb löst es auch mein Problem nicht wenn der Broker Bescheid weiß, nicht aber FHEM.

Per Voreinstellung holt MQTT2_CLIENT alle topics ab, damit kriegt es auch alle LWTs mit.
Wenn kein LWT hinterlegt ist, dann gibt es als MQTT Client keine Moeglichkeit, einen Verbindungsabbruch festzustellen.

Wenn einer der MQTT2_DEVICE Instanzen das LWT im readingList konfiguriert hat, dann gibt es auch ein passendes Event.
Mit autocreate passt MQTT2_SERVER readingList "richtig" an, MQTT2_CLIENT tut das evtl. mit dem falschen Device.
Ohne autocreate muss man selbst fuer die Anpassung sorgen.

Anmerkung @Rudi: Irgendwie wäre es schöner, der state des IO's wäre aussagekräftiger.

Gerade mit einem MQTT2_CLIENT geprueft:
- Wenn Verbindung zu mosquitto besteht, ist STATE "opened"
- sonst ist STATE "disconnected".
Dieser Wert kommt aus dem state Reading, dessen Zeitstempel enthaelt beim open den Zeitpunkt des Verbindungsaufbaus, bei disconnect den letzten Verbindungsversuch (alle 5 sek).

Das ist jetzt nicht super huebsch (kommt direkt aus DevIo), ist aber mAn auch nicht irrefuehrend.
Uebersehe ich etwas?

[PatrickR]

Hallo Rudi!

Per Voreinstellung holt MQTT2_CLIENT alle topics ab, damit kriegt es auch alle LWTs mit.
Wenn kein LWT hinterlegt ist, dann gibt es als MQTT Client keine Moeglichkeit, einen Verbindungsabbruch festzustellen.
[...]

Jetzt sehe ich endlich, wo wir aneinander vorbei reden.

Ich möchte nicht den Disconnect eines (externen) MQTT-Geräts feststellen, sondern den Disconnnect der MQTT-Verbindung von FHEM zum Broker. Dafür wiederum benötige ich Events, wenn state/STATE des MQTT_CLIENT2-Devices wechseln.

DevIO.pm aktualisiert aber state/STATE ohne Event und ich kann die Änderung somit auch nicht mittels DOIF oder notify "fangen". Im Event-Monitor tauchen auch nur die DevIO-Events (CONNECTED/DISCONNECTED) auf, die aber ein zuverlässigen Tracken des Zustands nicht erlauben, da sie (absichtlich) nicht immer auftreten (Näheres siehe oben). Das alte MQTT-Modul erzeugt z. B. beim Aktualisieren von STATE Events, daher war meine Frage, warum man es bei MQTT2 nicht ebenso macht. Workarounds wie periodisches Pollen des Readings würde ich gerne vermeiden.

Um es plastisch zu machen:
Würde man in DevIO.pm, sub DevIo_setStates($$) die Zeile

Code Auswählen Erweitern


setReadingsVal($hash, "state", $val, TimeNow());

durch

Code Auswählen Erweitern


readingsSingleUpdate($hash, "state", $val, 1);

ersetzen, würde das Update des state-Readings triggern und mir wäre geholfen. Das müsste man noch testen (bin gerade nicht zu Hause) und für STATE zuende denken.

Patrick

/Edit: @Beta-User: Nun sind wir auch auf einer Wellenlänge. Meine Antwort an Rudi war nur der verzweifelte Versuch, ein Szenario zu bauen, bei dem LWT zu meinem Problem passt.

[rudolfkoenig]

Ok, jetzt verstehe ich, sorry fuer die falsche Faehrte.
Der Gedanke, dass eine zentrale Komponente schon beim Start nicht verfuegbar ist, kam mir gar nicht.
Mit MQTT2_SERVER gibts dieses Problem nicht

Dein Vorschlag ist nicht komplett: man muesste die DoTrigger Zeilen entfernen.
Weiterhin wird erst Status auf opened gesetzt, dann die modulspezifische Geraete-Initializierung aufgerufen, und zum Schluss das CONNECTED Event generiert. Sowohl status erst nach der Initialisierung auf opened zu setzen, wie auch andersherum das CONNECTED Event davor zu senden verursacht Probleme.

Ich habe jetzt zwei Zeilen in DevIo.pm geaendert, dadurch wird ein CONNECTED / DISCONNECTED Event auch beim ersten Oeffnen erzeugt, allerdings DISCONNECTED nur fuer TCP/IP. Bin auf die Nebeneffekte gespannt.

[PatrickR]

Hallo Rudi!

Mit MQTT2_SERVER gibts dieses Problem nicht

Genauso wie viele andere, z. B. das Problem mit den vielen sinnvollen Features wie ACLs

Dein Vorschlag ist nicht komplett: man muesste die DoTrigger Zeilen entfernen.
Weiterhin wird erst Status auf opened gesetzt, dann die modulspezifische Geraete-Initializierung aufgerufen, und zum Schluss das CONNECTED Event generiert. Sowohl status erst nach der Initialisierung auf opened zu setzen, wie auch andersherum das CONNECTED Event davor zu senden verursacht Probleme.

Ach herje. Prinzipiell wäre es natürlich schön, wenn es ein Reading gäbe, das zuverlässig den Status des Moduls anzeigt und Events wirft. Ob DevIO das jetzt übernimmt oder die MQTT-Module ist dann Geschmackssache.

Ich habe jetzt zwei Zeilen in DevIo.pm geaendert, dadurch wird ein CONNECTED / DISCONNECTED Event auch beim ersten Oeffnen erzeugt, allerdings DISCONNECTED nur fuer TCP/IP. Bin auf die Nebeneffekte gespannt.

Habe gerade mal eine Reihe von Fällen getestet. Sieht gut aus. Danke!

Patrick