FHEM Forum

Originally posted by: <email address deleted>

Hallo zusammen,
ich möchte gern eine Watchdog einsetzen, der automatisch startet.
 
Nach der Doku muß man doch dazu schreiben:
define watchdog .
 
Wenn ich das so definiere, startet der Watchdog wirklich automatisch, leider
kennt er aber nur zwei "finale" Zustände:
a) "defined" = wenn innerhalb von die eingetroffen ist
b) "triggered" = wenn innerhalb von die 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 watchdog SAME , der aber auch
ohne Vorbedingung automatisch startet???
 
Danke, beste Grüße, Jens

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> define watchdog .
> 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 watchdog SAME , der aber auch
> ohne Vorbedingung automatisch startet???

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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...": Der Watchdog läuft bis , 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 ein kommt, schaltet er bei mir auf
"defined" und bleibt stehen.
Falls kein kommt, geht er auf "triggered".
Danach geht mit dem Watchdog nichts mehr.  - Weder ein "trigger" oder der
empfang einer ä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
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> Danach geht mit dem Watchdog nichts mehr.  - Weder ein "trigger" oder der
> empfang einer ä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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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  
" 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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> 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 ." wieder initialisiert werden kann, wenn es abgelaufen
ist.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

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

Stimmt, ich hoffe ich habe es gefixed und eingecheckt.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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 watchdog

Glaubst Du daß es Sinn macht, wenn man bei wiederholtem Empfang eines
 ,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 kommt.
Ich fände es geschickt, wenn bei neuem der watchdog wieder auf
now+ "aufgezogen" wird.
Das sollte ja auch keinen Wierspruch zu Deinem use-case mit dem fenster sein
- schließlich kmmt da der nur einmal.
 
Vielen Dank nochmal, Beste Grüße, Jens
 
 
 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> Ich fände es geschickt, wenn bei neuem der watchdog wieder auf
> now+ "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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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 verlängert werden. Ich würde vorschlagen, den auch
verlängerbar zu machen.
Danke, Beste Grüße, Jens.
 


 

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

On 11/13/2011 01:09 PM, Rudolf Koenig wrote:
>> 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.

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

On 20 Nov., 19:33, Rudolf Koenig wrote:
> > 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.

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

On 20 Nov., 22:49, Rudolf Koenig wrote:
> > 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.

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?

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

                                                   

> 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.

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com

Originally posted by: <email address deleted>

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

--
To unsubscribe from this group, send email to
fhem-users+unsubscribe@googlegroups.com