Watchdog hat aufgehört zu funktionieren

[fr00sch]

Hallo zusammen,

ich brauche mindestens 1 zweites Paar Augen, irgendwas funktioniert bei meinem watchdog nicht mehr wie es soll: Eigentlich möchte ich nach dem ersten Öffnen alle 15 Minuten eine Erinnerung an das Fenster:

Code Auswählen Erweitern


Internals:
   CMD        set telegramBot msg Das Fenster im kleinen Bad ist noch offen!;
   DEF        KB_Fens:open.* 00:15:00 KB_Fens:closed.* set telegramBot msg Das Fenster im kleinen Bad ist noch offen!;
   FUUID      5c4778a4-f33f-daea-945c-e2676736ae6c4b54
   NAME       KB_Fenster_opened
   NOTIFYDEV  KB_Fenster_opened,KB_Fens
   NR         487
   NTFY_ORDER 50-KB_Fenster_opened
   RE1        KB_Fens:open.*
   RE2        KB_Fens:closed.*
   STATE      defined
   TO         900
   TYPE       watchdog
   READINGS:
     2019-05-05 10:05:52   Activated       activated
     2019-05-05 10:20:52   Reset           reset
     2019-05-05 10:20:52   Triggered       triggered
     2019-04-27 18:08:44   state           defined
Attributes:
   DbLogExclude .*
   autoRestart 1
   group      Fenster
   room       01_Kleines_Bad

Internals:
   DEF        578D38
   FUUID      5c4778a4-f33f-daea-4e23-8ff15fea6f864ed1
   HMLANGW_MSGCNT 1
   HMLANGW_RAWMSG 05000035698610578D380000000601C800
   HMLANGW_RSSI -53
   HMLANGW_TIME 2019-05-05 10:05:52
   IODev      HMLANGW
   LASTInputDev myHmUART
   MSGCNT     2
   NAME       KB_Fens
   NOTIFYDEV  global
   NR         496
   NTFY_ORDER 50-KB_Fens
   STATE      open
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:69 - t:10 s:578D38 d:000000 0601C800
   myHmUART_MSGCNT 1
   myHmUART_RAWMSG 0500003C698610578D380000000601C800
   myHmUART_RSSI -60
   myHmUART_TIME 2019-05-05 10:05:53
   peerList   KB_TReg_WindowRec,
   protCmdPend 3 CMDs pending
   protLastRcv 2019-05-05 10:05:52
   protRcv    1 last_at:2019-05-05 10:05:52
   protResnd  1 last_at:2019-05-05 10:05:57
   protSnd    1 last_at:2019-05-05 10:05:52
   protState  CMDs_pending
   rssi_at_HMLANGW cnt:1 min:-53 max:-53 avg:-53 lst:-53
   rssi_at_myHmUART cnt:1 min:-60 max:-60 avg:-60 lst:-60
   Helper:
     DBLOG:
       battery:
         logdb:
           TIME       1557043552.96437
           VALUE      ok
       state:
         logdb:
           TIME       1557043552.96437
           VALUE      open
   READINGS:
     2019-05-05 09:56:42   Activity        alive
     2019-05-02 15:33:30   CommandAccepted no
     2018-12-01 09:48:12   D-firmware      1.0
     2018-12-01 09:48:12   D-serialNr      OEQ0394211
     2018-12-02 16:17:06   PairedTo        0x000000
     2018-12-02 16:17:08   R-KB_TReg_WindowRec-expectAES off
     2018-12-02 16:17:08   R-KB_TReg_WindowRec-peerNeedsBurst on
     2018-12-02 16:17:06   R-cyclicInfoMsg on
     2018-12-02 16:17:07   R-eventDlyTime  0 s
     2018-12-02 16:17:06   R-pairCentral   0x000000
     2018-12-02 16:17:06   R-sabotageMsg   on
     2018-12-02 16:17:07   R-sign          on
     2018-12-01 09:48:18   aesKeyNbr       00
     2019-05-05 10:05:52   alive           yes
     2019-05-05 10:05:52   battery         ok
     2019-05-05 10:05:52   contact         open (to broadcast)
     2019-05-05 09:56:50   peerList        KB_TReg_WindowRec,
     2018-12-22 13:01:53   powerOn         2018-12-22 13:01:53
     2019-05-05 10:05:52   recentStateType info
     2018-12-01 09:48:18   sabotageAttackId_ErrIoId_53597E cnt:4
     2019-05-05 10:05:52   sabotageError   off
     2019-05-05 10:05:52   state           open
     2018-12-01 10:02:56   trigDst_HM_53597E noConfig
     2018-12-02 16:17:06   trigDst_KB_TReg noConfig
     2019-05-05 09:30:07   trigger_cnt     171
   cmdStack:
     ++A001123456578D3800040000000000
     ++A001123456578D3801040000000001
     ++A001123456578D380103
   helper:
     HM_CMDNR   106
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +578D38,02,00,00
       nextSend   1557043553.11899
       prefIO     
       rxt        2
       vccu       
       p:
         578D38
         00
         00
         00
     mRssi:
       mNo        69
       io:
         HMLANGW:
           -47
           -47
         myHmUART:
           -60
           -60
     prt:
       bErr       0
       sProc      2
       wuReSent   2
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HMLANGW:
         avg        -53
         cnt        1
         lst        -53
         max        -53
         min        -53
       at_myHmUART:
         avg        -60
         cnt        1
         lst        -60
         max        -60
         min        -60
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude Activity,CommandAccepted,D-firmware,D-serialNr,RegL_00.,aesKeyNbr,alive,contact,PowerOn,recentStateType,sabotageAttackId_ErrIoId_53597E,sabotageError,trigDst_HM_53597E,trigger_cnt
   IODev      HMLANGW
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      Fenster
   model      HM-SEC-SCO
   peerIDs    00000000,53597E03,
   room       01_Kleines_Bad
   serialNr   OEQ0394211
   subType    threeStateSensor


Früher war es so, dass ich - sobald das Fenster offen war - alle 15 Minuten eine Erinnerung bekomme habe.
Irgendwann ist das aber verschwunden, ich habe nicht wirklich an diesen Geräten gearbeitet in der Zeit.
Ich habe auch schon mit dem attr autoRestart getestet, aber das hat auch nichts gebracht.

Habe ich irgendwo einen Denkfehler oder Tomaten auf den Augen?
Ich probiere schon ein paar Tage, aber ich komme nicht dahinter, sonst würde ich hier nicht mit einer solchen Kleinigkeit ankommen.

Vielen Dank schonmal!

Gruß fr00sch

[heinzfo]

Schau Dir mal die Whatchdog  Commandref vs. trigger und dem . an.
Aber frage mich nicht ob ich das richtig verstanden habe

PS: attr autoRestart und regexp1WontReactivate stehen bei mir auf 0

[amenomade]

Schau auch die Events, die aus KB_Fens kommen: Eventmonitor aufmachen, und auf KB_Fens.* filtern.
Kein Event => kein Triggern des Watchdogs

[fr00sch]

Ich habe mir einen Test aufgebaut:

Code Auswählen Erweitern


nternals:
   CMD        set telegramBot msg 2Das Fenster im Gaestebad ist noch offen!;; trigger GaeB_Fenster_opened2 .
   DEF        test:open.* 00:00:10 test:closed.* set telegramBot msg 2Das Fenster im Gaestebad ist noch offen!;; trigger GaeB_Fenster_opened2 .
   FUUID      xxxx
   NAME       GaeB_Fenster_opened2
   NOTIFYDEV  test,GaeB_Fenster_opened2
   NR         633
   NTFY_ORDER 50-GaeB_Fenster_opened2
   RE1        test:open.*
   RE2        test:closed.*
   STATE      defined
   TO         10
   TYPE       watchdog
   READINGS:
     2019-05-06 09:00:37   Activated       activated
     2019-05-06 09:00:47   Reset           reset
     2019-05-06 09:00:47   Triggered       triggered
     2019-05-05 10:15:09   state           defined
Attributes:
   DbLogExclude .*
   autoRestart 0
   regexp1WontReactivate 0

Internals:
   FUUID      5cce9454-f33f-daea-a9f9-edb7d3bcce0102e2
   NAME       test
   NR         634
   STATE      open
   TYPE       dummy
   READINGS:
     2019-05-06 08:59:01   state           open
Attributes:
   DbLogExclude .*
   setList    open closed


Wenn ich den watchdog manuell trigger über: "trigger GaeB_Fenster_opened2 ." funktioniert der watchdog einmal, genauso verhält es sich, wenn ich "set test open" als Befehl absetze.

@heinzfo: Die beiden attr sind bei mir ebenfalls auf 0 jetzt und es hat sich leider nichts geändert. Auch wenn ich mit autoRestart bei dem Test-Modul arbeite, hat es leider keinen positiven Effekt.

@amenomade: Der watchdog wird ja einmal ausgeführt, nur das retriggern funktioniert sich aus sich selbst heraus 

[amenomade]

Warum sollte der Watchdog mehrmals funktionieren, wenn er nur einmal (es sei durch set test open oder durch trigger Befehl) getriggert worden ist?
In deinem "list" steht er auf "defined" = "bereit, warte auf triggern". Scheint ganz normal zu sein

[fr00sch]

@amenomade:

So hat es früher funktioniert:
12:00 Uhr: Fenster auf
12:15 Uhr: Erinnerung an das Fenster
12:30 Uhr: Erinnerung an das Fenster
12:45 Uhr: Erinnerung an das Fenster
13:00 Uhr: Erinnerung an das Fenster
13:05 Uhr: Fenster zu
danach nichts mehr
<-- diese Funktion dachte ich sei durch das triggern am Ende möglich:
test:open.* 00:00:10 test:closed.* set telegramBot msg 2Das Fenster im Gaestebad ist noch offen!;; trigger GaeB_Fenster_opened2 .

und ohne das ich etwas geändert habe am Code (ich habe es nochmal kontrolliert und sogar die watchdog.pm neu geladen), passiert jetzt nur noch folgendes:
12:00 Uhr: Fenster auf
12:15 Uhr: Erinnerung an das Fenster
13:05 Uhr: Fenster zu

War das erste Szenario nur Zufall also habe ich die Funktion des Watchdogs Missverstanden? Ich dachte ich könnte sozusagen Retriggern oder anders ausgedrückt:
"Erinnere mich solange an offene Fenster bis ich es wieder geschlossen habe."

Ich hoffe mein Wunsch ist damit etwas klarer geworden.

[amenomade]

Nein, Zufall ist es sicher nicht, aber ich tippe immer noch auf Events von deinem KB_Fens: meine Vermutung ist, dass das Fenster früher regelmässig (1/4 St) erneut ein "open" geschickt hat , und jetzt es nur noch einmal macht.

Ein Watchdof funktioniert so:
Event1 => Timer läuft
Timer erreicht ohne Event2 => Befehl. Wenn Befehl "triggern" enthält, oder Attribut autoRestart gesetzt, dann wieder scharfschalten.

Der Vorgang läuft nur einmal pro Ereignis Event1. Wenn jede 1/4 Stunde Event1 kommt, dann läuft der Vorgang jede 1/4 Stunde. Sonst nicht. Du kannst mit deinem Test-dummy probieren: mach alle 20 Sekunden ein "set test open" und du wirst alle 20 Sekunden eine Nachricht bekommen.

Deswegen wiederum Richtung KB_Fens schauen. Hast Du ein "list" davon? Hast Du die Events im Eventmonitor geschaut? Hast Du bei KB_Fens etwas geändert (z.B. attr event-on-change-reading gesetzt oder irgendwelches Register geändert)?

[fr00sch]

Erstmal danke, ich glaube jetzt habe ich den watchdog erst richtig verstanden.
Das mit den Events kann nicht wirklich sein, denn - meiner Erinnerung nach - hatte ich anfangs die Intervalle bei 10 Sekunden, um es testen zu können. 

Die "list" von KB_Fens habe ich meinem ersten Post abgegeben. Der Event-Monitor hat mir gestern angezeigt: nur bei mechanischem Öffnen und schließen gibt es wirklich einen Event im System.
Ich habe mein Backup von vor 3 Wochen kontrolliert und der Code im fhem.cfg ist identisch zu damals. Eventuell hat sich irgendwas in einer relevanten .pm geändert. Soweit blicke ich da aber nicht durch.

Jetzt habe ich was gemacht wofür ich hier vielleicht gescholten werde  aber so funktioniert es, solange das test "open" ist kriege ich eine Erinnerung 

Code Auswählen Erweitern


Internals:
   CMD        set telegramBot msg 2Das Fenster im Gaestebad ist noch offen!; trigger GaeB_Fenster_opened2 .; trigger GaeB_Fenster_opened2 .
   DEF        test:open.* 00:00:10 test:closed.* set telegramBot msg 2Das Fenster im Gaestebad ist noch offen!; trigger GaeB_Fenster_opened2 .; trigger GaeB_Fenster_opened2 .
   FUUID      5ccdc48b-f33f-daea-14d3-cf30950c9f74c4cb
   NAME       GaeB_Fenster_opened2
   NOTIFYDEV  GaeB_Fenster_opened2,test
   NR         633
   NTFY_ORDER 50-GaeB_Fenster_opened2
   RE1        test:open.*
   RE2        test:closed.*
   STATE      Next: 12:03:10
   TO         600
   TYPE       watchdog
   READINGS:
     2019-05-06 11:53:10   Activated       activated
     2019-05-06 11:53:10   Reset           reset
     2019-05-06 11:53:10   Triggered       triggered
     2019-05-05 10:15:09   state           defined
Attributes:
   DbLogExclude .*


[amenomade]

Die "list" von KB_Fens habe ich meinem ersten Post abgegeben.

Das war nicht vom KB_Fens Sensor, sondern von KB_Fenster_opened watchdog

Es kann sein, dass durch trigger im Befehl + autoRestart Attribut etwas ähnliches wie dein doppeltes trigger erreicht wurde. Das war aber m.M.n. reiner Zufall. Das watchdog Modul hat sich seit Juli 2018 nicht geändert.

[fr00sch]

Code Auswählen Erweitern


Internals:
   DEF        578D38
   FUUID      5c4778a4-f33f-daea-4e23-8ff15fea6f864ed1
   HMLANGW_MSGCNT 4
   HMLANGW_RAWMSG 050000321E8610578D3800000006010000
   HMLANGW_RSSI -50
   HMLANGW_TIME 2019-05-06 11:44:03
   IODev      HMLANGW
   LASTInputDev myHmUART
   MSGCNT     56
   NAME       KB_Fens
   NOTIFYDEV  global
   NR         496
   NTFY_ORDER 50-KB_Fens
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:4D - t:10 s:578D38 d:000000 06010000
   myHmUART_MSGCNT 52
   myHmUART_RAWMSG 0500003F4D8610578D3800000006010000
   myHmUART_RSSI -63
   myHmUART_TIME 2019-05-08 07:32:07
   peerList   KB_TReg_WindowRec,
   protCmdDel 4
   protLastRcv 2019-05-08 07:32:07
   protNack   2 last_at:2019-05-06 10:48:07
   protRcv    52 last_at:2019-05-08 07:32:07
   protResnd  1 last_at:2019-05-06 09:53:45
   protSnd    2 last_at:2019-05-06 10:48:06
   protState  CMDs_done_Errors:1
   rssi_at_HMLANGW cnt:4 min:-51 max:-50 avg:-50.5 lst:-50
   rssi_at_myHmUART cnt:52 min:-63 max:-58 avg:-59.92 lst:-63
   Helper:
     DBLOG:
       battery:
         logdb:
           TIME       1557293527.80772
           VALUE      ok
       state:
         logdb:
           TIME       1557293527.80772
           VALUE      closed
   READINGS:
     2019-05-06 09:07:01   Activity        alive
     2019-05-06 10:48:07   CommandAccepted no
     2018-12-01 09:48:12   D-firmware      1.0
     2018-12-01 09:48:12   D-serialNr      OEQ0394211
     2018-12-02 16:17:06   PairedTo        0x000000
     2018-12-02 16:17:08   R-KB_TReg_WindowRec-expectAES off
     2018-12-02 16:17:08   R-KB_TReg_WindowRec-peerNeedsBurst on
     2018-12-02 16:17:06   R-cyclicInfoMsg on
     2018-12-02 16:17:07   R-eventDlyTime  0 s
     2018-12-02 16:17:06   R-pairCentral   0x000000
     2018-12-02 16:17:06   R-sabotageMsg   on
     2018-12-02 16:17:07   R-sign          on
     2018-12-01 09:48:18   aesKeyNbr       00
     2019-05-08 07:32:07   alive           yes
     2019-05-08 07:32:07   battery         ok
     2019-05-08 07:32:07   contact         closed (to broadcast)
     2019-05-06 09:07:11   peerList        KB_TReg_WindowRec,
     2018-12-22 13:01:53   powerOn         2018-12-22 13:01:53
     2019-05-08 07:32:07   recentStateType info
     2018-12-01 09:48:18   sabotageAttackId_ErrIoId_53597E cnt:4
     2019-05-08 07:32:07   sabotageError   off
     2019-05-08 07:32:07   state           closed
     2018-12-01 10:02:56   trigDst_HM_53597E noConfig
     2018-12-02 16:17:06   trigDst_KB_TReg noConfig
     2019-05-05 18:17:15   trigger_cnt     172
   helper:
     HM_CMDNR   77
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +578D38,00,00,00
       nextSend   1557293527.86975
       prefIO     
       rxt        2
       vccu       
       p:
         578D38
         00
         00
         00
     mRssi:
       mNo        4D
       io:
         HMLANGW:
         myHmUART:
           -63
           -63
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HMLANGW:
         avg        -50.5
         cnt        4
         lst        -50
         max        -50
         min        -51
       at_myHmUART:
         avg        -59.9230769230769
         cnt        52
         lst        -63
         max        -58
         min        -63
     shadowReg:
     tmpl:
Attributes:
   DbLogExclude Activity,CommandAccepted,D-.*,PairedTo,R-.*,RegL_00.,aesKeyNbr,alive,contact,PowerOn,recentStateType,sabotage.*,trigDst_.*,trigger_cnt
   IODev      HMLANGW
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   group      Fenster
   model      HM-SEC-SCO
   peerIDs    00000000,53597E03,
   room       01_Kleines_Bad
   serialNr   OEQ0394211
   subType    threeStateSensor


Ok, wenn sich da nichts geändert hat, bin ich auch mit meinen Theorien am Ende :-/

Mein Ansatz mit "trigger .... trigger .... " war nicht sehr erfolgreich, es gibt noch einen letzten Auslöser, obwohl das Fenster geschlossen wurde schon.
Ich werde mir ein neues Konzept überlegen.

Dank dir erstmal soweit, ich bin in sofern schlauer, dass ich nicht irgendeinen dummen Fehler eingebaut habe.

[Benni]

Ich werde mir ein neues Konzept überlegen.

Kannst dir ja mal das da anschauen  :

https://forum.fhem.de/index.php/topic,36504.0.html

Gruß Benni.

[amenomade]

Oder https://fhem.de/commandref_DE.html#DOIF_repeatcmd

Code Auswählen Erweitern

define KB_Fenster_opened DOIF ([KB_Fens] eq "open")(set telegramBot msg 2Das Fenster im Gaestebad ist noch offen!)
attr KB_Fenster_opened repeatcmd 900