Watchdog reset

[auto-mate]

Hallo zusammen,

ich möchte gern eine Watchdog einsetzen, der automatisch startet.

 

Nach der Doku muß man doch dazu schreiben:

define <name> watchdog . <timespec> <regexp2> <command>

 

Wenn ich das so definiere, startet der Watchdog wirklich automatisch, leider kennt er aber nur zwei "finale" Zustände:

a) "defined" = wenn innerhalb von <timespec> die <regexp2> eingetroffen ist

b) "triggered" = wenn innerhalb von <timespec> die <regexp2> NICHT eingetroffen ist.

 

Kann man den Watchdog irgendwie zurücksetzen? (per Kommando?)

Gibt es eine Möglichkeit einen Watchdog zu definieren ähnlich wie bei

define <name> watchdog <regexp1> <timespec> SAME <command>, der aber auch ohne Vorbedingung automatisch startet???

 

Danke, beste Grüße, Jens

[Rudolf Koenig]

> define <name> watchdog . <timespec> <regexp2> <command>

> Kann man den Watchdog irgendwie zur�cksetzen? (per Kommando?)

trigger dev value

so dass dev:value auf regexp2 passt.

> Gibt es eine M�glichkeit einen Watchdog zu definieren �hnlich wie bei

> define <name> watchdog <regexp1> <timespec> SAME <command>, der aber auch
> ohne Vorbedingung automatisch startet???

???
Das habe ich nicht verstanden oder auch: das ist doch die erste Variante...

[auto-mate]

Hi, danke für die schnelle Antwort - hat aber leider nicht geholfen.

 

Es sieht für mich so aus, als wenn es 3 Zustände beim Watchdog geben soll:

1) State "defined": bedeutet: Es ist ein Watchdog definiert, der auf die Startbedingung wartet

2) State "Next...<time>": Der Watchdog läuft bis <time>, wenn er nicht zwischenzeitlich neu gestartet wird....

3) State "Triggered" Der watchdog ist "durchgelaufen, weil keine regexp2 empfangen wurde.

 

Im Fall 2 (also mit regexp1 = . ) startet der Watchdog genau 1 mal (sofort). Wenn innerhalb der <timespec> ein <regexp2> kommt, schaltet er bei mir auf "defined" und bleibt stehen.

Falls kein <regexp2> kommt, geht er auf "triggered".

Danach geht mit dem Watchdog nichts mehr.  - Weder ein "trigger" oder der empfang einer <regexp2> ändert etwas an dem Zustand.

 

Es wäre für mich zumindest sinnvoller, wenn er wieder auf "Next + timespec" gehen würde.

Ist das eventuell ein bug?

 

(Hintergrund: Die erste Variante (mit SAME) kommt leider nicht in Betracht, weil ich Zustände überwachen möchte, die sehr selten (also max 1mal am tag) gesetzt werden. wenn ich da erst mal einen tag warten muß, bis der watchdog überhaupt erst anfängt zu laufen ist das zu lang.)

 

Danke, beste Grüße, Jens

 

[Rudolf Koenig]

> Danach geht mit dem Watchdog nichts mehr. - Weder ein "trigger" oder der

> empfang einer <regexp2> �ndert etwas an dem Zustand.

"trigger w ." startet den watchdog wieder (. passt auf dem Regexp ^.$ :)

watchdog is fuer 2 Problemklassen gebaut:

- Ueberwachung eines HMS-FIT, der alle 10 Minuten ein Telegramm schickt, es sei
denn die Sicherung hat ausgeloest, dann ist es "tot".

define w watchdog . 00:11 hmsfit:.* "send_sms.sh fit hat ausgeloest"

- Ueberwachen eines Fensters, bei dem ein Kontakt erst auf open dann auf closed
geht, und der nicht laenger als 10 Minuten offen sein darf.

define w watchdog contact:open 00:10 contact:closed "send_sms.sh fenster offen"

In beiden Faellen passiert das was ich erwarte.

[auto-mate]

Hallo Rudi - klingt alles plausibel (und isnbesondere das mit dem "." war mir vorher nicht klar - trotzdem bekomme ich es nicht zum Laufen.

Ich habe testweise einen Handsender genommen: (FS20 S8)

 

define HandSender_btn1 FS20 358d 00

dann habe ich 4 notify definiert, den ich für einen anderen Zweck brauche.

define HandSender_btn1_dimup notify HandSender_btn1.dimup { system  ...}

... und dasselbel nochmal abgewandelt für .dimdown, .on und .off

 

dann will ich den Watchdog haben:

define wd_Sender1 watchdog HandSender_btn1.on 00:01:00 HandSender_btn1.off "/bin/echo 'Watchdog Sender1' >>/opt/fhem/log/error.log"

 

das tut, was es soll - mit "on" läuft der Watchdog los, mit ".off" kann man ihn wieder anhalten.

mit "trigger HandSender_btn1 on" kann ich auch starten und mit "trigger HandSender_btn1 off" stoppen.

 

ein "trigger wd_Sender1 HandSender_btn1.on" oder "trigger wd_Sender HandSender_btn1.off" tun leider überhaupt nichts.

Irgendwie kommt das "trigger"-Kommando nicht beim watchdog(!) an.

Es gibt keine Fehermeldung - aber es passiert auch nichts.

Das selbe ist, wenn ich die Startbedingug als "." definiere:

define wd_Sender1 watchdog . 00:01:00 HandSender_btn1.off "/bin/echo 'Watchdog Sender1' >>/opt/fhem/log/error.log"

 

wenn ich ein "trigger wd_Sender1 ." schicke. passiert gar nichts.

 

liegt's an mir?

Ich habe mit updatefhem die neueste Version drauf, ich habe watchdog generell probiert, ich habe "trigger" mit FS20-befehlen erfolgreich probiert.

Es klappt nur nicht beim watchdog :-(

 

beste Grüße, jens

 

[auto-mate]

Achja:

und wenn es so ist, wie Du schreibst, daß

 

define w watchdog . 00:11 hmsfit:.* "send_sms.sh fit hat ausgeloest"

 

zur Überwachung des regelmäigen empfangs der hms-fit meldungen dient, dann üßte man doch während des ordnungsgemäßen Empfangs ständig ein "NEXT  <Uhrzeit+11min>" angezeigt bekommen...?

 

Bei mir springt aber der Status bei Empfang eines  passenden Paktes statt auf "NEXT" auf "defined". Das klingt jedenfalls nicht so, als wenn es so sein soll.

 

Jens, ratlos

[Rudolf Koenig]

> wenn ich ein "trigger wd_Sender1 ." schicke. passiert gar nichts.

Hmmm. Ich bin in meine eigene Falle geraten. Das Regexp muss auf devname oder
devname:event passen (genau wie bei einem notify). Da ich zum testen mein
watchdog w genannt habe, passt . auf w (devname), und nicht auf dem . in
event, wie ich es vorhin geschrieben habe. In deinem Fall passt aber . weder
auf "wd_Sender1", noch auf "wd_Sender1:."

Ich habe 91_watchdog.pm erweitert (und eingecheckt), damit ein watchdog mit
"trigger <watchdogname> ." wieder initialisiert werden kann, wenn es abgelaufen
ist.

[Rudolf Koenig]

> Das klingt jedenfalls nicht so, als wenn es so sein soll.

Stimmt, ich hoffe ich habe es gefixed und eingecheckt.

[auto-mate]

Hallo Rudi, vielen Dank, Super!!

Ich hatte schon etwas an mir gezweifelt....aber ich bin ja froh, daß ich beharrlich geblieben bin :-)

Eine letzte Bitte / bzw. Diskussion:

Bei der Variante:

define <name> watchdog <regexp1> <timespec> <regexp2> <command>

Glaubst Du daß es Sinn macht, wenn man bei wiederholtem Empfang eines  <regexp1>,den  timer verlängert?

Im Moment wird er nur einmal gestartet und läuft dann bis zum trigger (falls regexp2 nicht kommt) oder geht auf "defined", wenn <regexp2> kommt.

Ich fände es geschickt, wenn bei neuem <regexp1> der watchdog wieder auf now+<timespec> "aufgezogen" wird.

Das sollte ja auch keinen Wierspruch zu Deinem use-case mit dem fenster sein - schließlich kmmt da der <regexp1> nur einmal.

 

Vielen Dank nochmal, Beste Grüße, Jens

 

 

 

[Rudolf Koenig]

> Ich f�nde es geschickt, wenn bei neuem <regexp1> der watchdog wieder auf
> now+<timespec> "aufgezogen" wird.

Ich finde das passiert. Da ich Dich nicht folgen kann, hier ein Beispiel:

fhem> define w2 watchdog w2:open 00:00:10 w2:close { Log 1, "w2 trigger" }
fhem> list w2
STATE defined
fhem> tri w2 open
fhem> list w2
STATE Next: 06:51:23
... (Trigger abwarten)
fhem> list w2
STATE triggered
fhem> tri w2 open
fhem> list w2
STATE Next: 06:54:27

Falls regexp "." ist, dann wird es nicht neu gestartet.

[auto-mate]

Hallo Rudi,

ein Bild sagt vielleicht mehr... :-)

ich habe mal die Watchdogvarianten nach bestem Wissen in eine Art Zusatandsdiagramm gepackt.

Was ich meinte ist der Punkt, den ich mit (A) markiert habe. Im Unterschied zu den anderen Varianten kann in der vollständigen definition der Timer nicht mit <regexp1> verlängert werden. Ich würde vorschlagen, den auch verlängerbar zu machen.

Danke, Beste Grüße, Jens.

 

 

[Rudolf Koenig]

Hallo Jens

Eine wunderschoene Grafik. Womit baut man sowas? Kannst Du bitte auch alle
anderen Befehle so schoen "bebildern"? Commandref.html muss bunter werden :)

Dein bemaengeltes Szenario (Fenster offen / zu) hat bisher die Verlaengerung
mittels "zweiten "Fenster offen" nicht benoetigt. Und "trigger watchdogname ."
war nur fuers Neustarten des "." Triggers gedacht.

Da dein Wunsch um Verlaengerung in diesem Szenario nicht stoert, habe ich es
zugelassen und eingecheckt. Als Seiteneffekt verlaengert
"trigger watchdogname ." den watchdog.

Jetzt kommt hoffentlich keiner mit einem anderen Szenario, bei dem das
Verlaengern nicht gewuenscht ist...

Gruss,
Rudi

[auto-mate]

Hallo Rudi - ich wollte das ja nicht bemängeln - war ja nur ein Vorschlag bzgl. Konsistenz

Aber danke für's implementieren!

Bzgl.Bilder malen: Mache ich mit dem mächtigsten Entwicklerwerkzeug genannt "Powerpoint".

Wenn es was hilft, kann ich die Grafiken gern nochmal updaten und schicken. HastDu irgendwelche sinnvollen Höhen / Breiten die eingehalten werden sollten?

Danke, beste GRüße, jens

[cge]

Hallo zusammen,

> - Ueberwachen eines Fensters, bei dem ein Kontakt erst auf open dann auf closed
>   geht, und der nicht laenger als 10 Minuten offen sein darf.
>

>   define wwatchdogcontact:open 00:10 contact:closed "send_sms.sh fenster offen"

ich befürchte ich habe bei mir einen Fall, bei dem das neu Aufziehen
zu einem Problem führt. Ich habe einen FHT80 TF-2 Fensterkontakt, der
in regelmäßigen Abständen open oder closed sendet. Wenn das Fenster
(oder bei mir das Garagentor) länger als 15min offen steht soll eine
Mail kommen. Mit dem Watchdog kommt sie nie, da ja regelmäßig ein open
gesendet wird und damit der watchdog immer wieder aufgezogen wird.
Ideal wäre, wenn man dem watchdog über einen Parameter das Verhalten
bei erneutem Eintreffen der regex mitgeben könnte (neu afziehen vs.
weiterlaufen).

Meinen Fall habe ich mit folgendem Konstrukt umgesetzt. Beim ersten
Wechsel von closed nach open wird ein Notify angelegt, das nach
15Minuten nochmal prüft, ob das Tor noch offen ist. Wenn es in der
Zwischenzeit geschlossen wird, wird das Notify gelöscht:

define Garagentor_geoeffnet_N notify Garagentor.*Open { \
if (OldValue("Garagentor") =~ /Closed/) { \
fhem("define Garagentor_A at +00:15:00 trigger
Pruefe_Garagentor_zu_N");;\
} \
}

define Garagentor_geschlossen_N notify Garagentor.*Closed { \
if (OldValue("Garagentor") =~ /Open/) { \
if (($defs{Garagentor_A})) {\
fhem("delete Garagentor_A");;\
}\
}\
}

define Pruefe_Garagentor_zu_N notify Pruefe_Garagentor_zu_N { \
if (Value("Garagentor") =~ /Open/) { \
Log 1, '...Mailversand, da Garagentor noch offen';;\
fb_mail("Garagentor ist noch offen!");;\
}\
}

Viele Grüße,
Carsten

[Rudolf Koenig]

> Ideal w�re, wenn man dem watchdog �ber einen Parameter das Verhalten
> bei erneutem Eintreffen der regex mitgeben k�nnte (neu afziehen vs.
> weiterlaufen).

Danke fuer den Hinweis. Hab ein regexp1WontReactivate Attribut eingefuehrt und
eingecheckt, bitte testen. Hab auch den commandref Eintrag etwas erweitert.

[Thomas Herrmann]

Immer wenn die kalte Jahreszeit vor der T�r steht, aktiviere ich meinen
Fensterwatchdog, so auch gestern. Dazu setze ich Fensterwatchdog auf
aktiv, und das hat auch bisher funktioniert:

define WC_FensterWatchdog watchdog WC_Fenstersensor:Window:.Open 00:15
WC_Fenstersensor:Window:.Closed { fhem("define WC_tmp at +*{2}00:00:15
set Kueche_Statue toggle") if ($value{Fensterwatchdog} eq "aktiv") }

Leider hat der Watchdog bei meinen ersten Tests nie ausgel�st. Dann habe
ich (um besser testen zu k�nnen), die Zeit von 15 Minuten auf 2
runtegesetzt - dann hat es manchmal funktioniert, manchmal nicht. Ich
war schon am verzweifeln, da habe ich die Doku gelesen, und folgenden
Eintrag hinzugef�gt:

attr WC_FensterWatchdog regexp1WontReactivate

Funktioniert aber immer noch nicht; der Watchdog wird nicht ausgef�hrt.
Was mache ich falsch?

Hinweis: WC_Fenstersensor ist ein FHTTK, der sendet ca. alle 4 Minuten
wenn sich nichts �ndert und alle 60 Sekunden wenn sich gerade etwas
ge�ndert hat.

Viele liebe Gr��e,
Thomas

[Rudolf Koenig]

> Funktioniert aber immer noch nicht; der Watchdog wird nicht ausgef�hrt.

Ich hab jetzt das watchdog Thema nochmal angenommen, eine Weile getestet,
gefixed, nochmal getestet, und ich meine, dass es jetzt mit der bisherigen
Semantik funktionieren sollte. Eingecheckt in SVN und fhemupload ausgefuehrt.

[Willi]

Hallo Rudi,

da ich meine Fenster auch überwachen wollte habe ich mit einem
Testschalter (DS10a an RFXCOM) folgendes probiert:

define watch_win_17a1 watchdog RFXX10REC_17a1:Open 00:00:10
RFXX10REC_17a1:Closed { Log 1, "Alarm: Windows 17a1 geoeffnet "}

Mit dem alten 91_watchdog.pm (Revision 1009 aus 2010 ohne
regexp1WontReactivate) funktioniert alles wie gewünscht. Wird der
Kontakt mehr als 10 Sekunden geöffnet, erhalte ich die entsprechende
Log-Meldung.

Dieser Test funktioniert auch mit der geringen Testzeit in Sekunden,
da der DS10a-Fensterkontakt die Meldung unmittelbar sendet.

Wenn ich die neue Version 91_watchdog.pm aus SVN probiere, klappt auch
das erste Überschreiten der Öffnung für mehr als 10 Sekunden und ich
erhalte die entsprechende Log-Meldung. STATE wechselt daei von defined
-> NEXT -> triggered.

Wenn allerdings der Fensterkontakt danach wieder geschlossen wird und
geöffnet wird, bleibt STATE bei triggered und geht nicht mehr zu NEXT.
Damit wird die zweite Öffung nicht mehr ausgelöst.

Das gleiche passiert auch, wenn ich das Attribut regexp1WontReactivate
definiere.

Ich habe für den Test nur 91_watchdog.pm ausgetauscht. Ist das evtl.
der Fehler und ich muss komplett updaten? Oder gibt es noch einen
Fehler bei 91_watchdog.pm?

MfG Willi

[Rudolf Koenig]

> Damit wird die zweite �ffung nicht mehr ausgel�st.

Das ist eigentlich so wie gewollt, ich will ja auch nur eine Nachricht kriegen.
Alternativ muss man den Trigger mit "trigger NAME ." wieder aktivieren.

[Willi]

Also "works as designed!" ;-)

Bei einem manuellen (also in der Koammandozeile)
trigger watch_win_17a1 .
funktioniert das auch wie erwartet.

Ich habe darauf hin versucht den trigger in den Watchdog einzubauen:

define watch_win_17a1 watchdog RFXX10REC_17a1:Open 00:00:10

RFXX10REC_17a1:Closed { Log 1, "Alarm: Windows 17a1 geoeffnet ";;fhem
"trigger watch_win_17a1 ."}

Das funktioniert aber nicht.

Mit

define watch_win_17a1 watchdog RFXX10REC_17a1:Open 00:00:10

RFXX10REC_17a1:Closed { Log 1, "Alarm: Windows 17a1 geoeffnet ";;fhem
"define a5 at +00:00:02 trigger watch_win_17a1 ."}

habe ich es dann hinbekommen. Ist das auch so gewollt?

[Willi]

Da ich es beim vorherigen Posting vergessen habe:

Danke Rudi, dass Du 91_watchdog.pm überarbeitest hast.

regexp1WontReactivate scheint auch in meinem Fall ein wichtiges
Feature zu sein.

[Rudolf Koenig]

> Ist das auch so gewollt?

Nich wirklich. Hab die Rekursion-Vermeidende INWATCHDOG enfernt, weil ich den
Eindruck habe, dass Rekursion mittels watchdog doch nicht so einfach zu bauen
ist, wie mit notify. Da vermeidet INTRIGGER die Rekursion.

[Thomas Herrmann]

On 11/20/2011 07:33 PM, Rudolf Koenig wrote:
> Ich hab jetzt das watchdog Thema nochmal angenommen, eine Weile getestet,
> gefixed, nochmal getestet, und ich meine, dass es jetzt mit der bisherigen
> Semantik funktionieren sollte. Eingecheckt in SVN und fhemupload ausgefuehrt.

Bin leider erst jetzt dazu gekommen, es zu testen. Es sieht aber so aus,
als wenn jetzt alles so funktioniert, wie es in der Doku beschrieben steht.

Danke f�r die schnelle Hilfe
Thomas