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:
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
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
Schau auch die Events, die aus KB_Fens kommen: Eventmonitor aufmachen, und auf KB_Fens.* filtern.
Kein Event => kein Triggern des Watchdogs
Ich habe mir einen Test aufgebaut:
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 :'(
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
@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.
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)?
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 8)
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 .*
Zitat von: fr00sch am 06 Mai 2019, 12:02:35
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.
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.
Zitat von: fr00sch am 08 Mai 2019, 07:57:55
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.
Oder https://fhem.de/commandref_DE.html#DOIF_repeatcmd
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