Hi,
seit einigen Tagen läuft die Watchdog funktion nicht mehr sauber:
define ToilWatch watchdog wc.KT:open 00:02 wc.KT:closed set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike'; trigger ToilWatch
Der Status geht nach der Auslösung von 'defined' über auf 'next' und dann kommt auch die Aktion. Danach geht der Status auf 'triggered' aber es folgt keine weiter Aktion (Benachrichtigung per Pushmsg) mehr.
Früher hat das Problemlos funktioniert.
Hat einer eine Idee woran das jetzt liegen kann?
Sollte das nicht
trigger ToilWatch .
heissen? Und vermutlich ;; statt ; (es sei denn, man editiert das Ganze in FHEMWEB).
Watchdog habe ich seit 4 Monaten nicht angefasst.
Heißt auch so:
define ToilWatch watchdog wc.KT:open 00:02 wc.KT:closed set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike' ;; trigger ToilWatch .
Könnte die Ursache mit dem Wechsel des Fesnterkontakts von FS20 auf Homematic stehen?
Der Homematic ist jetzt auch direkt mit einem Heizungsventil gekoppelt.
Der Status geht jetzt auch nach dem einmaligen Ausführen der Aktion auf 'defined'.
Geht STATE auf triggered wie im ersten Post beschrieben, oder auf defined wie im dritten?
Triggered meint ausgeloest, und wertet keine Aktionen mehr aus. Mit defined ist der Watchdog wieder scharf.
Habs gerade mit einem dummy probiert, funktioniert einwandfrei:
fhem> define d dummy
fhem> define w watchdog d:open 00:00:05 d:closed {Log 1, "WD"};;trigger w .
fhem> inform timer
fhem> set d open
Nach 5 Sekunden erscheint "WD" im log, und STATE von w ist defined.
Und das kann man beliebig wiederholen.
ZitatKönnte die Ursache mit dem Wechsel des Fesnterkontakts von FS20 auf Homematic stehen?
Ich meine das einer von beiden closed sendet und der andere Closed - dito mit opened und Opened.
Auch hier - Gross- kleinschreibung beachten da FHEM case sensitiv ist.
Aber auch hier würde ein Blick in den EventMonitor reichen um das Rätsel zu lösen.
@Puschel: Vielen Dank für den Hinweis, hatte ich schon geändert.
@rudolfkoenig: Status geht auf defined wie im dritten Post beschrieben.
Eine einmalige Benachrichtigung findet ja auch statt. Nur sollte nach weiteren 2 Minuten wieder eine Benachrichtigung erfolgen, so lange bis das Fenster wieder geschlossen wurde. Das geht leider nicht mehr.
Fragt der Watchdog Regelmäßig den Status von 'wc.KT' ab oder reagiert er nur auf Änderungen?
Die wiederholte Ausfuehrung lief aber auch frueher auch nicht, das war nie Bestandteil von watchdog.
Man kann es natuerlich mit einem weiteren trigger simulieren.
Aber Watchdog müsste doch nach Ausführen der Aktion und Rückkehr in den Status defined wieder neu ausgeführt werden, wenn er den Status neu abfragt.
Wenn Watchdog allerdings nur auf eine Änderung des Status reagiert, würde natürlich keine neue Meldung kommen.
Sehe ich das so richtig?
Watchdog fragt nie ein Status ab, sondern reagiert nur auf Events.
Eigentlich weiss er nicht, welche Geraete er ueberwacht, achtet nur auf das Eintreffen bestimmter Strings via Event.
Diese zwei Varianten funktionieren bei mir beide:
Aus fhem.cfg:
define w_cellar_door_warning watchdog cellar_door:open 00:10 cellar_door:closed \
{myLog("Watchdog: Cellar Door open");;;; fhem("trigger w_cellar_door_warning .")}
define di_cellar_door_warning DOIF ([cellar_door] eq "open") ({myLog("Cellar Door open")})
attr di_cellar_door_warning do always
attr di_cellar_door_warning wait 600
cellar_door: EnOcean-STM-250
@flurin: Ich habe beide varianten ausprobiert und es kommt jeweils leider nur eine Meldung!
In den Logfiles haben ich dann den Unterschied der beiden Fensterkontakte gefunden. Wärend der alte FS20 alle 5 Minuten einen neuen Status-Event gesendet hat, senden der Homatic HM-SEC-SC-2 leider nur einen Event bei Änderung und danach nur einen alive-Event.
2015-04-07_15:22:56 wc.KT Activity: alive
2015-04-07_15:20:38 wc.KT Activity: alive
2015-04-07_15:05:22 wc.KT Activity: alive
2015-04-07_14:58:10 wc.KT Activity: alive
2015-04-07_14:46:43 wc.KT Activity: alive
2015-04-07_14:45:45 wc.KT trigger_cnt: 174
2015-04-07_14:45:45 wc.KT trigDst_1C67C1: noConfig
2015-04-07_14:45:45 wc.KT open
2015-04-07_14:45:45 wc.KT contact: open (to HMLAN1)
2015-04-07_14:45:45 wc.KT battery: ok
Vermutlich hat deshalb das ganze mit dem alten Fensterkontakt funktioniert und mit dem neuen (HM-SEC-SC-2) nicht mehr!
Hat eventuell jemand eine Idee wie ich das ganze dennoch zum laufen bekomme?
Ich möchte gerne so lange Meldungen bekommen, bis das Fenster wieder geschlossen wurde.
Zitat von: prime1009 am 07 April 2015, 17:36:36
@flurin: Ich habe beide varianten ausprobiert und es kommt jeweils leider nur eine Meldung!
In den Logfiles haben ich dann den Unterschied der beiden Fensterkontakte gefunden. Wärend der alte FS20 alle 5 Minuten einen neuen Status-Event gesendet hat, senden der Homatic HM-SEC-SC-2 leider nur einen Event bei Änderung und danach nur einen alive-Event.
2015-04-07_15:22:56 wc.KT Activity: alive
2015-04-07_15:20:38 wc.KT Activity: alive
2015-04-07_15:05:22 wc.KT Activity: alive
2015-04-07_14:58:10 wc.KT Activity: alive
2015-04-07_14:46:43 wc.KT Activity: alive
2015-04-07_14:45:45 wc.KT trigger_cnt: 174
2015-04-07_14:45:45 wc.KT trigDst_1C67C1: noConfig
2015-04-07_14:45:45 wc.KT open
2015-04-07_14:45:45 wc.KT contact: open (to HMLAN1)
2015-04-07_14:45:45 wc.KT battery: ok
Vermutlich hat deshalb das ganze mit dem alten Fensterkontakt funktioniert und mit dem neuen (HM-SEC-SC-2) nicht mehr!
Hat eventuell jemand eine Idee wie ich das ganze dennoch zum laufen bekomme?
Ich möchte gerne so lange Meldungen bekommen, bis das Fenster wieder geschlossen wurde.
versuchs mal sinngemäss so:
define di_cellar_door_warning DOIF ([cellar_door] eq "open" and ([cellar_door:Activity] eq "alive")
({myLog("Cellar Door open")})
attr di_cellar_door_warning do always
attr di_cellar_door_warning wait 600
wenn State auf "open" bleibt, müsste es funktionieren.
Edit: bei deinem Fall:
define ToilWatch DOIF ([wc.KT] eq "open" and [wc.KT:Aktivity] eq "alive")
(set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike')
attr ToilWatch do always
Ich würde es mal ohne attr wait testen.
Ich musste etwas anpassen, hat aber leider nichts gebracht. Es erfolgte keinerlei Auslösung mehr!
define ToilWatch DOIF ([wc.KT] eq "open" and [wc.KT:Activity] eq "alive")
{fhem("set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike'")}
Zitat von: prime1009 am 07 April 2015, 19:01:05
Ich musste etwas anpassen, hat aber leider nichts gebracht. Es erfolgte keinerlei Auslösung mehr!
define ToilWatch DOIF ([wc.KT] eq "open" and [wc.KT:Activity] eq "alive")
{fhem("set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike'")}
Beim DOIF brauchst du die (...) Klammer auch beim Befehl:
define ToilWatch DOIF ([wc.KT] eq "open" and [wc.KT:Activity] eq "alive")
({fhem("set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike'")})
und
attr ToilWatch do always
Mit
define ToilWatch DOIF ([wc.KT] eq "open" and [wc.KT:Activity] eq "alive") (set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike')
attr ToilWatch do always
attr ToilWatch wait 120
erfolgt die einmalige Auslösung aber leider keine Wiederholungen
Zitat von: prime1009 am 07 April 2015, 22:37:32
Mit
define ToilWatch DOIF ([wc.KT] eq "open" and [wc.KT:Activity] eq "alive") (set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike')
attr ToilWatch do always
attr ToilWatch wait 120
erfolgt die einmalige Auslösung aber leider keine Wiederholungen
Das ist schon mal was. Ein HM-SEC-SC-2 habe ich nicht aber ich würde die Readings untersuchen:
Entweder mit dem Event Monitor oder mit Log:
define ToilWatch_Test DOIF ([wc.KT:Activity])
({Log 3,"wc.KT state: ".Value("wc.KT")." - wc.KT:Activity: ".ReadingsVal("wc.KT","Activity","undef")})
attr ToilWatch_Test do always
Gemäss deinem Listing kommen die alive-Events unregelmässig, also einige Minuten warten.
Die Log-Einträge sind in fhem-2015-04.log
Ok, habe ich gemacht. Leider kein Eintrag im Log. Das Fenster wurde auch nicht geöffnet.
Wahrscheinlich sendet der HM-SEC-SC-2 nur bei einer Statusänderung (was ja aus Energiesparsicht auch sinnvoll ist).
Noch eine Idee ? :(
Zitat von: prime1009 am 09 April 2015, 10:24:58
Ok, habe ich gemacht. Leider kein Eintrag im Log. Das Fenster wurde auch nicht geöffnet.
Wahrscheinlich sendet der HM-SEC-SC-2 nur bei einer Statusänderung (was ja aus Energiesparsicht auch sinnvoll ist).
Noch eine Idee ? :(
überprüfe deine Einstellungen:
attr global verbose 3
ist
attr ToilWatch_Test do always
gesetzt?
Wenn das Fester offen ist, poste folgende Lists:
list ToilWatch_Test
list wc.KT bzw. deine device HM-SEC-SC-2
attr global verbose von 2 auf 3 geändert
attr ToilWatch_Test do always war gesetzt
list ToilWatch_Test
Internals:
DEF 24817D
HMLAN1_MSGCNT 2
HMLAN1_RAWMSG E24817D,0000,04F61FDA,FF,FFB6,64A24124817D1C67C101BEC8
HMLAN1_RSSI -74
HMLAN1_TIME 2015-04-09 15:05:42
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 2
NAME wc.KT
NR 606
STATE open
TYPE CUL_HM
lastMsg No:64 - t:41 s:24817D d:1C67C1 01BEC8
peerList EG_N_HM_CC_RT_DN_WindowRec,
protLastRcv 2015-04-09 15:05:42
protSnd 1 last_at:2015-04-09 15:05:42
protState CMDs_done
rssi_at_HMLAN1 avg:-74.5 min:-75 max:-74 lst:-74 cnt:2
Readings:
2015-04-09 14:49:09 Activity unknown
2015-03-29 15:14:18 CommandAccepted yes
2015-03-29 15:14:13 D-firmware 2.2
2015-03-29 15:14:13 D-serialNr KEQ0957122
2015-03-29 15:21:14 PairedTo 0x1C67C1
2015-03-29 15:14:20 R-EG_N_HM_CC_RT_DN_WindowRec-expectAES off
2015-03-29 15:14:20 R-EG_N_HM_CC_RT_DN_WindowRec-peerNeedsBurst on
2014-03-05 17:10:48 R-cyclicInfoMsg off
2015-03-29 14:37:15 R-eventDlyTime 0 s
2015-03-29 14:37:15 R-ledOnTime 0.5 s
2015-03-29 14:37:15 R-msgScPosA closed
2015-03-29 14:37:15 R-msgScPosB open
2015-03-29 14:52:02 R-pairCentral 0x1C67C1
2015-03-29 14:37:15 R-sabotageMsg on
2015-03-29 14:37:15 R-sign off
2014-03-05 17:10:48 R-transmDevTryMax 6
2014-03-05 17:10:50 R-transmitTryMax 6
2015-03-29 15:21:04 alive yes
2015-04-09 15:05:42 battery ok
2015-04-09 15:05:42 contact open (to HMLAN1)
2014-06-14 10:10:35 cover closed
2014-02-18 16:55:46 noReceiver src:24817D A610 0601C80E
2015-04-09 14:49:09 peerList EG_N_HM_CC_RT_DN_WindowRec,
2015-03-29 15:21:04 recentStateType info
2015-03-29 15:21:04 sabotageError off
2015-04-09 15:05:42 state open
2015-04-09 15:05:42 trigDst_1C67C1 noConfig
2015-04-09 15:05:42 trigger_cnt 190
Helper:
mId 00B1
rxType 12
Io:
newChn +24817D,00,01,00
nextSend 1428584742.79475
prefIO
rxt 2
vccu
p:
24817D
00
01
00
Mrssi:
mNo 64
Io:
HMLAN1 -72
Prt:
bErr 0
sProc 0
sleeping 1
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rpt:
IO HMLAN1
flg A
ts 1428584742.70726
ack:
HASH(0x384b428)
6480021C67C124817D0101C800
Rssi:
At_hmlan1:
avg -74.5
cnt 2
lst -74
max -74
min -75
Attributes:
IODev HMLAN1
actCycle 005:00
actStatus unknown
autoReadReg 4_reqStatus
devStateIcon Open:fts_window_1w_tilt
expert 2_full
firmware 2.2
fp_EG 100,100,1, Toilettenfenster
group Kontakte
model HM-SEC-SC-2
peerIDs 00000000,21BC7C03,
room Spezial
serialNr KEQ0957122
subType threeStateSensor
verbose 5
list wc.KT
Internals:
DEF ([wc.KT:Activity]) ({Log 3,"wc.KT state: ".Value("wc.KT")." - wc.KT:Activity: ".ReadingsVal("wc.KT","Activity","undef")})
NAME ToilWatch_Test
NR 633
NTFY_ORDER 50-ToilWatch_Test
STATE cmd_1
TYPE DOIF
Readings:
2015-04-09 15:05:42 cmd_event wc.KT
2015-04-09 15:05:42 cmd_nr 1
2015-04-09 15:05:42 e_wc.KT_Activity unknown
2015-04-09 15:05:42 state cmd_1
Condition:
0 ReadingValDoIf('wc.KT','Activity','')
Devices:
0 wc.KT
all wc.KT
Do:
0 {Log 3,"wc.KT state: ".Value("wc.KT")." - wc.KT:Activity: ".ReadingsVal("wc.KT","Activity","undef")}
Helper:
last_timer 0
sleeptimer -1
Internals:
Itimer:
Readings:
0 wc.KT:Activity
all wc.KT:Activity
State:
Trigger:
Attributes:
do always
room Spezial
Danke für die Hilfe
Aktivity: unknown!
Was steht in fhem-2015-04.log?
Schaue, ob wc.KT state: auf open bleibt, solange das Fester offen ist (auch nach ca. 20 min).
beim öffnen steht im Log:
2015.04.09 16:07:50 3: wc.KT state: open - wc.KT:Activity: alive
2015.04.09 16:07:49 3: Device wc.KT added to ActionDetector with 005:00 time
beim schließen steht im Log:
2015.04.09 17:40:17 3: wc.KT state: closed - wc.KT:Activity: alive
2015.04.09 17:40:17 5: CUL_HM wc.KT sent ACK:2
2015.04.09 17:40:17 5: CUL_HM wc.KT protEvent:CMDs_done
2015.04.09 17:40:17 5: CUL_HM wc.KT prep ACK for 01
2015.04.09 17:40:17 3: wc.KT state: closed - wc.KT:Activity: alive
dazwischen gibt es keine Logeinträge.
Der Status wird immer korrekt dargestellt.
Zitat von: prime1009 am 09 April 2015, 19:36:24
beim öffnen steht im Log:
2015.04.09 16:07:50 3: wc.KT state: open - wc.KT:Activity: alive
2015.04.09 16:07:49 3: Device wc.KT added to ActionDetector with 005:00 time
beim schließen steht im Log:
2015.04.09 17:40:17 3: wc.KT state: closed - wc.KT:Activity: alive
2015.04.09 17:40:17 5: CUL_HM wc.KT sent ACK:2
2015.04.09 17:40:17 5: CUL_HM wc.KT protEvent:CMDs_done
2015.04.09 17:40:17 5: CUL_HM wc.KT prep ACK for 01
2015.04.09 17:40:17 3: wc.KT state: closed - wc.KT:Activity: alive
dazwischen gibt es keine Logeinträge.
Der Status wird immer korrekt dargestellt.
OK, dann versuchen wir es mit einem "Trick".
define du_interval dummy
set du_interval 00:02
Mit dem Dummy wird das Intervall (2 Minuten) definiert.
define di_ToilWatch DOIF ([wc.KT:?open])
(trigger du_interval)
DOELSEIF ([+[du_interval]] and [wc.KT] eq "open")
(set pushmsg msg 'Toilette' 'Fenster offen !' ' ' 0 'bike', trigger du_interval)
attr di_ToilWatch do always
Funktioniert, Prima :) :) :) :) :) :)
Vielen Dank