Problem mit watchdog

Begonnen von tomspatz, 26 Januar 2016, 07:55:33

Vorheriges Thema - Nächstes Thema

tomspatz

Moin zusammen.
Dieser Hund läuft einwandfrei, ABER er löst nur einmal aus. So wie ich es verstehe musste er doch wenn einmal ausgelöst sofort wieder "scharf" sein und immer wieder auslösen bis das Ereignis vorbei ist.
Wo ist denn da mein Fehler?
Der Code ist direkt aus der fhem.cfg. Die kurze Zeit ist natürlich nur zum testen.

define FensterBueroUeberwachung watchdog FensterBuero:offen 00:01:00 FensterBuero:geschlossen set PushBenachrichtigungTom msg 'fhem' 'Fenster im Büro ist offen !';; trigger FensterBueroUeberwachung .

Vielen dank

marco-f

Ich bin auch nur nach einer Anleitung vorgegangen. Bei mir sieht es wie folgt aus:
define BadfensterWatch watchdog Bad.Fenster:open|Bad.Fenster:tilted 00:10 Bad.Fenster:closed set gcm send Achtung|Bad|Fenster offen;; setstate BadfensterWatch defined
Durch das setstate ... defined wird der Watchdog zurückgesetzt und löst dann bei erneutem Ereignis wieder aus.

Otto123

Hinweis zur Diskussion des Entwicklers  8)
Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

Benni

Und in der offiziellen Doku steht auch nichts von setstate,
dafür steht unter Hinweise im 4. Punkt, wie es zu funktionieren hat.
Und ja, der Punkt (.)  dort ist entscheidend. ;)

tomspatz

OK

vielleicht könnte mal der Modulentwickler etwas dazu sagen.
Ich denke das mein Ansatz nämlich verkehrt ist.
Der watchdog kann NICHT immer wieder feuern.
Er wird über regex1 gestartet, wartet auf ggf. regex2 innerhalb einer bestimmten Zeit, sonst FEUER.
Hat er aber abgefeuert wird er nur wieder mit regex1 aktiv.

Hoffe das es so richtig ist.
LG
Tom

Benni

Zitat von: tomspatz am 27 Januar 2016, 18:30:19
Hoffe das es so richtig ist.
Nö! Ist es nicht!

Der Watchdog muss nach Auslösung explizit dazu aufgefordert werden wieder auf regex1 zu lauern.
Dazu muss er mit einem Punkt ge-triggert werden.

Dazu muss auch der Modulautor nichts mehr sagen, denn das hat er in der commandref so Beschrieben und sogar in einem Beispiel dargestellt.

tomspatz

Moin Benni

was stimmt denn dann zum Teu....l damit nicht?? grrrrrrr
Ich habe den jetzt schon Stunden dran verbracht.
Die Syntax ist richtig, der watchdog steht auf defined. Fenster auf, im state wird Next: 07:57:15 angezeigt (aktuell heute morgen) das ist dann auch der Zeitpunkt wo er auslöst wenn Fenster offen bleibt.
Fenster vorher wieder zu sofort defined im state.
Nach der Zeit löst er aus und dann steht er wieder im state auf defined.
Wobei der Punkt am Ende ja doch da ist.

konfus.

LG
Tom

Benni

Zitat von: tomspatz am 28 Januar 2016, 08:02:33
Nach der Zeit löst er aus und dann steht er wieder im state auf defined.

Ja genau!
Und was erwartest du eigentlich?

tomspatz

das er solange das Fenster offen ist alle "eingestellte" Zeit feuert.

Benni

Das dachte ich mir  ;D
Allerdings kann der Watchdog das nicht!

Es ginge eventuell, wenn du im Auslöseteil deines Watchdog erst den Watchdog mit trigger-Punkt wieder scharf schaltest und dann direkt nochmal das regex1-Ereignis per trigger (auf den Fensterkontakt) auslöst. Eventuell braucht es aber zwischen dem Scharfschalten und der erneuten Auslösung noch eine zeitl. Verzögerung.

Schau dir doch mal das hier an: http://forum.fhem.de/index.php/topic,36504.0.html

Und wenn du das versuchen möchtest dann bitte das Beispiel am erst einmal komplett 1:1 durcharbeiten und versuchen zu verstehen. ;)

Otto123

Du dachtest eher an einen richtigen Wachhund. Das hättest Du aber auch mal so genau sagen können, dass das Dein Problem ist.

Es gibt mit DOIF einen Lösungsansatz mit wait und repeatcmd, kannst Du Dir ja mal in der commandref anschauen.

Auch wenn DOIF stark polarisiert   :-X  ;)

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

tomspatz

@Qtto123
SORRY aber:
ZitatDas hättest Du aber auch mal so genau sagen können, dass das Dein Problem ist.

Habe ich hier:
ZitatSo wie ich es verstehe musste er doch wenn einmal ausgelöst sofort wieder "scharf" sein und immer wieder auslösen bis das Ereignis vorbei ist.
ZitatIch denke das mein Ansatz nämlich verkehrt ist.
Der watchdog kann NICHT immer wieder feuern.

Bennies Beispiel habe ich auch schon gesehen. Schien mir für einen Anfänger kompliziert.
Muss ich mal mit Zeit dran.

Auf jedem Falle ist es Fakt das der watchdog das so nicht kann.
Schade um die Zeit.

Otto123

War eher spaßig gemeint, klar hast Du es so geschrieben aber zumindest ich habe es nicht verstanden. Weil mir klar war, dass ein watchdog so nicht ist, der beißt nur einmal zu.

Wie gesagt der Ansatz mit DOIF ist simpel, Da ist ein konkretes Beispiel mit wait und kurz darunter steht repeatcmd...

Gruß Otto
Viele Grüße aus Leipzig  ⇉  nächster Stammtisch an der Lindennaundorfer Mühle
RaspberryPi B B+ B2 B3 B3+ ZeroW,HMLAN,HMUART,Homematic,Fritz!Box 7590,WRT3200ACS-OpenWrt,Sonos,VU+,Arduino nano,ESP8266,MQTT,Zigbee,deconz

t.huber

Ich hab auch einen ganzen Abend mit der Thematik Watchdog herumgesch.....
Egal was ich gemacht habe entweder waren falsche States geschrieben oder der Watchdog hat sich einfach nicht zurückgesetzt und war "triggered"
Ich hab alles mögliche versucht wie es in div. Anleitungen, HowTo's und CommandReferenzen steht.
Ich versuchte einen Bewegungmelder "einfach" wieder zurückzusetzten. So wie es "einfach" in mehreren Anleitungen steht.

In wirklich vielen Anleitungen steht (sinngemäß) zurücksetzten mit
define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion;; setstate wd defined

oder gemäß CommandRef
define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion;; trigger wd .

Aber das hat alles nicht zum Erfolg geführt.

Aber erst durch das entfernen des 2. Semikolon hat es bei mir funktioniert.
define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion; trigger wd .

Ich weiß dank "Erste Schritte in Fhem" daß ein Semikolon bedeutet daß der Befehl sofort bei Eingabe der Zeile bzw. dem Aufruf ausgeführt wird.
2 Semikolons würde bedeuten dass sofort getriggert wird und dann nach Erfüllung von "00:00:10 SAME" der State auf "nomotion" geändert wird.

Soweit meine (wahrscheinlich falsche) Logik.
Aber dann versteh ich noch weniger warum es mit nur einem Semikolon geht.  :o
Würde eine sofortige Auslösung des Triggers keine Endlosschleife verursachen ?

(In dem obigen Beispiel hab ich die Zeit absichtlich zum Testen auf 10 Sekunden gestellt; Der Bewegungsmelder kann frühestens nach 15 Sekunden wieder ein ..:motion bringen; also löst der Watchdog immer nach 10 Sekunden aus)

Benni

#14
Zitat von: t.huber am 31 Januar 2016, 00:41:55
oder gemäß CommandRef
define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion;; trigger wd .

Aber das hat alles nicht zum Erfolg geführt.

Aber erst durch das entfernen des 2. Semikolon hat es bei mir funktioniert.
define wd watchdog Bewegungsmelder:motion 00:00:10 SAME setreading Bewegungsmelder state nomotion; trigger wd .

Ich weiß dank "Erste Schritte in Fhem" daß ein Semikolon bedeutet daß der Befehl sofort bei Eingabe der Zeile bzw. dem Aufruf ausgeführt wird.
2 Semikolons würde bedeuten dass sofort getriggert wird und dann nach Erfüllung von "00:00:10 SAME" der State auf "nomotion" geändert wird.

Soweit meine (wahrscheinlich falsche) Logik.

Die Logik ist folgende:

Wenn der Befehl in der Befehlszeile im im WebIf (FHEMWEB) oder im telnet direkt eingegeben wird, so muss um die Befehle im Ausführungsteil des watchdog zu trennen ein doppeltes Semikolon eingegeben werden, da sonst der 2. Befehl nicht an den Ausführungsteil des watchdog angefügt wird, sonder direkt nach dem define sofort als Befehl ausgeführt wird.

Also 1 Semikolon würde in dem o.g. Beispiel erst den define des watchdog vornehmen und in dessen Ausführungsteil als Befehl das setreading aufhnehmen und nach dem define würde sofort versucht den watchdog mit Punkt zu triggern.

Mit 2 Semikolons wird der watchdog definiert und in den Ausführungsteil des watchdog werden dann die beiden Einzelbefehle setreading und trigger aufgenommen, so dass diese beide ausgeführt werden, wenn der watchdog anschlägt.

Das ist hier aber auch so beschrieben.