Hauptmenü

Watchdog reset

Begonnen von Guest, 19 September 2011, 01:27:35

Vorheriges Thema - Nächstes Thema

Guest

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

rudolfkoenig

                                                   

> 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

Guest

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

rudolfkoenig

                                                   

> 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

Guest

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

Guest

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

rudolfkoenig

                                                   

> 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

rudolfkoenig

                                                   

> 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

Guest

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

rudolfkoenig

                                                   

> 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

Guest

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.
 

<https://lh6.googleusercontent.com/-wxClq9Re8mY/Tn0uIgYS6uI/AAAAAAAAAAo/SwL1VLFyxXo/fhem-watchdog-states.jpg>
 

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

rudolfkoenig

                                                   

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

Guest

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

Guest

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

rudolfkoenig

                                                   

> 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