MQTT2 üerwachen mit Watchdog

Begonnen von mikka1, 10 Februar 2019, 15:17:28

Vorheriges Thema - Nächstes Thema

mikka1

Guten Tag

Ich habe verschiedene Tasmotaschalter in FHEM eingebunden die ich teilweise auch zum schalten verwende. Leider kommt es immer wieder vor, das, aus welchen Gründen auch immer, der Schaltvorgang nicht ausgeführt wird.
Meine Idee ist nun, die mit einem Watchdog zu überwachen. Ich habe bereits verschiedene Beiträge gelesen, leider will es immer noch nicht so wie ich. Meiner Ansicht nach hängt es an der Erfassung des Gerätestatus, ON oder OFF.

Meine  raw def
defmod Ecklampe_WZ_ein watchdog 14:35:00 00:00:10 MQTT2_Ecklampe_WZ:on.* set /SonOff/Wohnzimmer/sonoff_Ecklampe_WZ/cmnd/POWER ON;; trigger Ecklampe_WZ_ein .

setstate Ecklampe_WZ_ein defined

Irgendwas in der regexp2 passt da noch nicht, komme aber gerade nicht weiter, weshalb hoffe, dass mir hier jemand auf die Sprünge helfen kann.
Besten Dank bereits im voraus.

Grüess
Stephan

KölnSolar

Zitatdefmod Ecklampe_WZ_ein watchdog 14:35:00 00:00:10 MQTT2_Ecklampe_WZ:on.* ....
Ich würd sagen in regexp1: 14:35:00 ?  :-\ ???
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

rudolfkoenig

Zitatdefmod Ecklampe_WZ_ein watchdog 14:35:00 00:00:10 MQTT2_Ecklampe_WZ:on.* set /SonOff/Wohnzimmer/sonoff_Ecklampe_WZ/cmnd/POWER ON;; trigger Ecklampe_WZ_ein .
Laut usage sollte es so ausschauen: "define <name> watchdog <re1> <timeout> <re2> <command>"
Die zitierte Definition passt mAn nicht.

mikka1

#3
Danke für eure Antworten.

Meine Idee:
defmod Ecklampe_WZ_ein watchdog <re1>(Uhrzeit, ab wann der Status überwacht wird,14:35:00 / nur zum testen) <timespec> alle 10 Sek überprüfen <re2> Status des Schalters,  wenn nicht On, dann <command> (set /SonOff/Wohnzimmer/sonoff_Ecklampe_WZ/cmnd/POWER ON)

Mach ich jetzt da einen Denkfehler

rudolfkoenig

ZitatMach ich jetzt da einen Denkfehler
Ja.
FHEM-Module funktioniern leider nach dem Muster, wie der Modulautor das entworfen hat, und nicht, wie man es als Anwender gerne haette.
Bitte die Doku nochmal genau lesen.

mikka1

Ok, Danke. Dann mache ich mich dort noch einmal dahinter.

Deudi

Ich habe für automatisch ausgeführte Schaltvorgänge eine kleine Perl-Routine geschrieben, die den Schaltbefehl wegschickt, 20 Sekunden später nachschaut, ob es auch geklappt hat und ggf. nacharbeitet. Bei Interesse kann ich heute Abend mal den Code posten.
Gigabyte Brix, Ubuntu 16.04.3 LTS, Homematic, Z-Wave, EnOcean, Shelly@MQTT, SIGNALduino, JeeLink DAVIS-Sketch

mikka1

Das wäre toll, weil bis jetzt bin ich noch nicht wirklich dahinter gekommen, wie ich dies mit dem Watchdog hinkriege.
Besten Dank.

Beta-User

Anmerkungen:
Zum einen arbeitet watchdog EVENT-basiert, nicht zustandsorientiert. Du solltest dir also mal ansehen, welche Events bezüglich des fraglichen Devices kommen ;) .

Zum anderen ist es m.E. wenig sinnvoll, Schwächen in der Infrastruktur auf diese Weise zu "übertünchen". Wenn das Teil also in der Realität unzuverlässig schaltet, sorge für eine zuverlässigere Funkverbindung... Bestenfalls: sorge dafür, dass du von Problemen erfährst. Dafür gibt es aber auch andere Wege, z.B. eine Readingsgroup, die alle Devices anzeigt, die auf NACK (hm), "set xy" (MQTT2, ggf. mit setStateEvent) usw. stehen.
Speziell bei MQTT kann man ergänzend die MQTT-spezifischen Optionen nutzen ("retain", "qos"), um auf Verbindungsprobleme zu reagieren ;) .
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

mikka1

Das Problem ist, dass vor allem die sonoff basic ein Problem mit der Erreichbarkeit zu haben scheinen. Ich probiere jetzt mal aus, ob es etwas mit dem Sleep Status zu tun hat.
Die Verbindung ins WLAN ist, wenn sie denn ist, gut. Die Geräte sind teilweise im selben Raum oder maximal durch eine Decke getrennt.
Da das entsprechende Gerät nur bedingt erreichbar ist, kommt leider nicht viel rum...

Wie oben gesagt, wenn die Verbindung steht, ist sie gut, aber die Geräte sind zwischendurch nicht erreichbar, darum auch mein Ansatz, per Watchdog über einen bestimmten Zeitraum die Meldungen, wenn sie denn kommen, auf den korrekten Schaltzustand zu überprüfen und ansonsten ein entsprechendes cmd abzusetzen.

Das mit den mit den MQTT spezifischen Optionen muss ich mit noch einmal näher anschauen... ;-)

Besten Dank

Beta-User

Zitat von: mikka1 am 13 Februar 2019, 13:54:09
Das mit den mit den MQTT spezifischen Optionen muss ich mit noch einmal näher anschauen... ;-)
Fang' damit mal an, wenn du die ESP's unbedingt schlafen legen mußt ;D .

Die Probleme können btw. auch daher kommen, dass zu viele WLAN-Geräte an einer Fritzbox hängen; die mag das erfahrungsgemäß nicht... (ein Grund, warum ich einen großen Bogen um WLAN-Geräte in der HA mache, und z.B. MySensors deutlich bevorzuge).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

MarkusN

Zitat von: Beta-User am 12 Februar 2019, 08:18:53
Speziell bei MQTT kann man ergänzend die MQTT-spezifischen Optionen nutzen ("retain", "qos"), um auf Verbindungsprobleme zu reagieren ;) .

Dem kann ich nur zustimmen. Retain wird wahrscheinlich deine Probleme lösen.
Sollte dein Tasmota Device zum Zeitpunkt des Schaltvorgangs nicht erreichbar sein, wird es bei gesetztem retain flag den Schaltvorgang nachholen sobald es wieder eine Verbindung zum MQTT Server hat.
Der Nachteil hierbei ist dass ein Schaltvorgang der nicht via MQTT stattgefunden hat u.U. durch genau dieses feature übersteuert wird.