Hallo Martin,
ich spreche dich mal direkt an, da ich denke, dass du allein die Frage beantworten kannst. Antworten sind natürlich von allen willkommen.
Ich habe drei Bewegungsmelder HM-Sen-MDIR-O. Auf einer Statusseite möchte ich sehen, ob diese kürzlich eine Bewegung erkannt haben. Dazu habe ich einen Wachhund eingerichtet, der 40 Sekunden nach der letzten erkannten Bewegung den State auf "nomotion" setzt:
BM_Zufahrt:motion 00:00:40 SAME setstate BM_Zufahrt nomotion;trigger BM_Zufahrt nomotion;trigger Reset_BM_Zufahrt .
Der Köter funktioniert auch prächtig. In Verbindung mit zwei verschiedenen devStateIcons kann ich dann sehen was draussen los ist. Nun habe ich festgestellt, dass nach einiger Zeit der State wieder auf Motion steht, obwohl keine Bewegung gemeldet wurde. Der Grund ist auch leicht auszumachen. Wenn die zyklische Meldung vom BM kommt mit den Werten für Brightness, Cover, Battery wird der State wieder auf "motion" gesetzt.
Gibt es dafür eine (Software-)technische Notwendigkeit, oder könnte man das in einem zukünftigen Update abstellen? Eigentlich sollte der State doch nur auf "motion" gesetzt werden, wenn der BM auch wirklich Bewegung erkannt hat.
Viele Grüße
Deudi
mit der Bedeutung von Motion hast du recht.
Den Ablauf verstehe ich aber nicht - und da ich keinen mdir habe "sehe" ich es nicht.
Es gibt
state:motion
motion:on target
motionCount:Zähler
wie verhalten sie diese?
Motion wird ausschliesslich bei einem Trigger gesetzt - also nicht bei einer statusmessage. Somit ist das Verhalten nicht klar.
Kannst du einen Log machen - rohmessages (nur die ID des/der MDIR eingeben) und den Mdir auf verbose 5 setzen.
Und dann laufen lassen, bis dein Problem eintritt - so 24h?
Gruss Martin
Hi,
Erstmal die Frage eines Anfängers Logfile richtig eingerichtet?
define FileLog_IR.Melder FileLog ./log/IR.Melder.-%Y.log IR.Melder.Haustuer
attr FileLog_IR.Melder verbose 5
Brightness setzt kein motion
state:motion wird gesetzt bei bewegung
Wenn STATE auf motion steht kommt motionCount
ändert sich nur nach setstate (Empfindlichkeit zu hoch?)
motion count zählt bei Bewegung von ? bis ? und fängt von vorne an
Unterschied von internal state und Reading STATE? (Fritzbox zu langsam?)
2014-05-06_22:27:59 IR.Melder.Haustuer brightness: 42
2014-05-06_22:28:04 IR.Melder.Haustuer motionCount: 59_next:8-240
2014-05-06_22:32:23 IR.Melder.Haustuer brightness: 35
2014-05-06_22:38:05 IR.Melder.Haustuer motionCount: 60_next:8-240
2014-05-06_22:43:11 IR.Melder.Haustuer motionCount: 61_next:8-240
----------------------
#get config
# 2014-05-06_22:43:12 IR.Melder.Haustuer R-pairCentral: 0x272E50
# 2014-05-06_22:43:12 IR.Melder.Haustuer R-brightFilter: 7
# 2014-05-06_22:43:12 IR.Melder.Haustuer R-captInInterval: off
# 2014-05-06_22:43:12 IR.Melder.Haustuer R-evtFltrPeriod: 1 s
# 2014-05-06_22:43:12 IR.Melder.Haustuer R-minInterval: 240
# 2014-05-06_22:43:12 IR.Melder.Haustuer R-evtFltrNum: 2
# 2014-05-06_22:43:12 IR.Melder.Haustuer R-ledOnTime: 0 s
2014-05-06_23:15:02 IR.Melder.Haustuer motionCount: 62_next:8-240
2014-05-06_23:21:27 IR.Melder.Haustuer brightness: 36
2014-05-06_23:21:32 IR.Melder.Haustuer motionCount: 63_next:8-240
2014-05-06_23:26:33 IR.Melder.Haustuer motionCount: 64_next:8-240
----------------------
#Neustart regset R-evtFltrNum: 4 R-evtFltrPeriod: 2 s R-minInterval: 120 dyn
2014-05-06_23:57:06 IR.Melder.Haustuer motionCount: 65_next:0-0x0
2014-05-06_23:57:06 IR.Melder.Haustuer brightness: 35
2014-05-06_23:57:08 IR.Melder.Haustuer motionCount: 66_next:7-120
2014-05-06_23:57:08 IR.Melder.Haustuer motionCount: 67_next:7-120
----------------------
#clear readings get config
# 2014-05-07_00:06:09 IR.Melder.Haustuer Activity: unknown
2014-05-07_00:07:57 IR.Melder.Haustuer motion
2014-05-07_00:07:57 IR.Melder.Haustuer motion: on (to HMLAN1)
2014-05-07_00:07:57 IR.Melder.Haustuer motionCount: 68_next:7-120
# 2014-05-07_00:07:57 IR.Melder.Haustuer brightness: 35
# 2014-05-07_00:07:58 IR.Melder.Haustuer R-pairCentral: 0x272E50
# 2014-05-07_00:07:59 IR.Melder.Haustuer R-brightFilter: 7
# 2014-05-07_00:07:59 IR.Melder.Haustuer R-captInInterval: on
# 2014-05-07_00:07:59 IR.Melder.Haustuer R-evtFltrPeriod: 2 s
# 2014-05-07_00:07:59 IR.Melder.Haustuer R-minInterval: 120
# 2014-05-07_00:07:59 IR.Melder.Haustuer R-evtFltrNum: 4
# 2014-05-07_00:07:59 IR.Melder.Haustuer R-ledOnTime: 0 s
# 2014-05-07_00:08:09 IR.Melder.Haustuer Activity: alive
2014-05-07_00:09:17 IR.Melder.Haustuer motionCount: 68_next:0-0x0
2014-05-07_00:10:01 IR.Melder.Haustuer motionCount: 69_next:7-120
2014-05-07_00:14:19 IR.Melder.Haustuer cover: closed
2014-05-07_00:14:19 IR.Melder.Haustuer battery: ok
----------------------
# 2014-05-07_00:18:00 setstate nomotion
2014-05-07_00:26:18 IR.Melder.Haustuer brightness: 48
----------------------
#2014-05-07_00:26:18 state steht auf motion
# 2014-05-07_00:27:00 setstate nomotion
#2014-05-07_00:35:00 state steht auf motion
# 2014-05-07_00:36:00 setstate nomotion
#2014-05-07_00:36:00 state steht auf motion
# 2014-05-07_00:37:00 setstate off; clear readings
2014-05-07_00:40:34 IR.Melder.Haustuer brightness: 48
2014-05-07_00:40:34 IR.Melder.Haustuer cover: closed
2014-05-07_00:40:34 IR.Melder.Haustuer battery: ok
2014-05-07_00:40:40 IR.Melder.Haustuer Activity: alive
#2014-05-07_00:41:00 state steht auf off
2014-05-07_00:52:44 IR.Melder.Haustuer motion
2014-05-07_00:52:44 IR.Melder.Haustuer motion: on (to HMLAN1)
2014-05-07_00:52:44 IR.Melder.Haustuer motionCount: 70_next:7-120
2014-05-07_00:54:49 IR.Melder.Haustuer motionCount: 71_next:7-120
2014-05-07_00:56:59 IR.Melder.Haustuer brightness: 8
2014-05-07_00:56:59 IR.Melder.Haustuer brightness: 8
2014-05-07_05:35:14 IR.Melder.Haustuer brightness: 9
2014-05-07_05:41:02 IR.Melder.Haustuer brightness: 10
2014-05-07_05:46:21 IR.Melder.Haustuer brightness: 14
2014-05-07_05:55:29 IR.Melder.Haustuer brightness: 21
2014-05-07_06:01:31 IR.Melder.Haustuer brightness: 35
2014-05-07_06:07:03 IR.Melder.Haustuer brightness: 51
2014-05-07_06:12:05 IR.Melder.Haustuer brightness: 65
2014-05-07_06:22:53 IR.Melder.Haustuer brightness: 78
2014-05-07_06:28:38 IR.Melder.Haustuer brightness: 91
2014-05-07_06:33:53 IR.Melder.Haustuer brightness: 99
2014-05-07_06:38:38 IR.Melder.Haustuer brightness: 103
2014-05-07_06:42:53 IR.Melder.Haustuer brightness: 105
2014-05-07_07:03:46 IR.Melder.Haustuer brightness: 107
2014-05-07_07:09:58 IR.Melder.Haustuer brightness: 108
2014-05-07_07:15:39 IR.Melder.Haustuer brightness: 110
2014-05-07_07:20:50 IR.Melder.Haustuer brightness: 115
2014-05-07_07:29:44 IR.Melder.Haustuer brightness: 120
2014-05-07_07:35:38 IR.Melder.Haustuer brightness: 122
2014-05-07_07:41:02 IR.Melder.Haustuer brightness: 132
2014-05-07_07:45:57 IR.Melder.Haustuer brightness: 135
2014-05-07_07:56:29 IR.Melder.Haustuer brightness: 144
2014-05-07_08:07:14 IR.Melder.Haustuer brightness: 148
2014-05-07_08:11:52 IR.Melder.Haustuer brightness: 140
2014-05-07_08:18:13 IR.Melder.Haustuer brightness: 135
2014-05-07_08:24:03 IR.Melder.Haustuer brightness: 134
2014-05-07_08:29:24 IR.Melder.Haustuer brightness: 133
2014-05-07_08:29:27 IR.Melder.Haustuer motionCount: 72_next:7-120
2014-05-07_08:29:27 IR.Melder.Haustuer brightness: 124
ZitatWenn STATE auf motion steht kommt motionCount
wenn motion erkannt wird, wird reading state, internal STATE und reading motionCount gesetzt
Zitatändert sich nur nach setstate (Empfindlichkeit zu hoch?)
was Ändert sich nicht?
Zitat
motion count zählt bei Bewegung von ? bis ? und fängt von vorne an
0 bis 255
ZitatUnterschied von internal state und Reading STATE? (Fritzbox zu langsam?)
wenn du STATE mit setstate auf nomotion änderst wird das Reading nicht geändert. Das machst du von hand - also musst du es auch selbst kontrollieren
Zitat von: martinp876 am 19 April 2014, 09:14:33
Kannst du einen Log machen - rohmessages (nur die ID des/der MDIR eingeben) und den Mdir auf verbose 5 setzen.
Und dann laufen lassen, bis dein Problem eintritt - so 24h?
@ Martin,
sorry bin noch nicht zum Aufzeichnen gekommen. Vielleicht schaffe ich es heute Abend. Ich brauche nur 40 Sekunden aufzeichnen, dann habe ich das "Problem".
@ Crawler
Ich bin verwirrt - und Martin glaube ich auch. Was wolltest du uns mitteilen? Ist dein Post eine Frage, wolltest du helfen? Ich hab's nicht verstanden...
Grüße Deudi
war ein versuch :D
das einzige was ich sagen wollte bei mir stellt sich state:motion nicht zurück ???
und brightness setzt bei mir kein motion....
sorry fürs aus dem Kontext reißen ich werde wohl lieber mal ins Anfängerforum wechseln :D
Hi Deudi,
erst einmal bin ich an den messages interessiert um festzustellen, warum state geändert wird, 40sec nach dem trigger.
Zum 2. glaube ich erkannt zu haben, was nextTr bedeutet. Liegen ich richtig zeigt es an, wann der nächste trigger kommen soll. Wenn dieser Wert nicht mehr gesetzt ist, könnte es also bedeuten, dass keine "motion" mehr da ist. Das müsstest du testen:
zum testen könnte es hilfreich sein, minInterval auf "15" zu setzen - da sollte es schneller gehen.
Bitte alle Register, wie sie beim Test waren liefern (insbesonder captInInterval).
1) einmal motion, dann ruhe
2) motion immer wieder, so dass Folgetrigger kontinuierlich kommen (min 2 oder 3)
3) minInterval ändern und "motion machen" => ändert sich nextTrigger?
Gruss Martin
Hallo Martin,
sorry das mit den 40 Sekunden stimmt nicht. Ich muss den Zeitraum zwischen zwei Statusmeldungen aufzeichnen (nicht motion, sondern die zyklischen alle paar Minuten mit battery, cover, brightness).
captInInterval auf "on" und minInterval auf "15" sind meine Einstellungen, der Rest ist default.
Wie schon anfangs geschrieben setzt die Keep-Alive Meldung den vom Watchdog "von Hand" gesetzten Status "nomotion" zurück auf "motion". Ich hatte gehofft, dass du durch die "Technik des genauen Hinsehens" dazu im Code was findest. Log kommt heute Abend.
Grüße Jürgen
Hallo Martin,
hier kommen die Rohdaten. Nochmal zur Erklärung was ich eigentlich machen will: Im angehängten Bild siehst du drei Bewegungsmelder, wovon die ersten beiden unlängst eine Bewegung erkannt haben. Daher das entsprechende Symbol. BM_Zufahrt wurde vom Watchdog 40 Sekunden nach der letzten Bewegung auf state "nomotion" gesetzt und dafür ist das Bild ein leeres. Im Normalfall zeigen alle drei BM kein Bild und somit ist da auch nix los. Nur wenn das Symbol angezeigt wird, ist da kürzlich jemand - oder etwas - vorbeigekommen.
Vielleicht kann man das auch anders lösen. Jedenfalls ist das ganze nicht wirklich heilsentscheidend sondern nur eine Spielerei. Daher stecke da nicht zu viel Arbeit rein. Ich hatte nur ursprünglich gedacht, dass mein Watchdog nicht funktioniert und daher habe ich tiefer reingeschaut.
Ich habe folgendes geloggt.
1. Eine zyklische Statusmeldung (nenne ich mal Keep-Alive)
2. 3x Bewegung
3. Watchdog bellt nach 40 Sekunden
4. Eine zyklische Statusmeldung
Deine Forschungsarbeiten bzgl. "nextTr" habe ich jetzt nicht explizit berücksichtigt. Falls du da Daten brauchst, logge ich dir gerne zu einem späteren Zeitpunkt noch was du im letzten Post gefordert hattest.
Ich glaube auch schon anhand der Daten etwas verstanden zu haben. Mein Watchdog setstate setzt den STATE in den Internals auf "nomotion". Der state in den Readings bleibt auf "motion". Wenn die Keep-Alive nach dem Watchdog kommt, werden die Werte aus den Readings in die Internals geschrieben und somit geht STATE wieder auf "motion". Ob das korrekt ist, musst du beurteilen.
Noch eine Info zu den Logs: Ich habe 3 HMLAN 0-2. Alle BM sind mit dem HMLAN1 (444958) gepairt und IODev ist entsprechend gesetzt. Die Keep-Alive gehen auch an diesen HMLAN. Die Motion Meldungen gehen aber immer an broadcast. Verstehe ich nicht wirklich. Beim BM_Fahrraeder gehen auch Motion Meldungen an HMLAN1. Der BM_Fahrraeder hat Fw 1.6, die anderen 1.5. Irgendwas ist da anders. Es gibt ja auch noch den Post mit der "Dauermotion".
Also hier 3x "list BM_Zufahrt"
- Vor dem Watchdog
- Nach dem Watchdog
- Nach der zweiten Keep-Alive
Internals:
DEF 1A67B1
HMLAN0_MSGCNT 9289
HMLAN0_RAWMSG E1A67B1,0000,AF72E2A6,FF,FFB2,5E84101A67B14449580601D100
HMLAN0_RSSI -78
HMLAN0_TIME 2014-05-07 19:23:13
HMLAN1_MSGCNT 9266
HMLAN1_RAWMSG E1A67B1,0000,11549CB6,FF,FFA1,5E84101A67B14449580601D100
HMLAN1_RSSI -95
HMLAN1_TIME 2014-05-07 19:23:13
HMLAN2_MSGCNT 9277
HMLAN2_RAWMSG E1A67B1,0000,AF72A413,FF,FFAF,5E84101A67B14449580601D100
HMLAN2_RSSI -81
HMLAN2_TIME 2014-05-07 19:23:13
IODev HMLAN1
LASTInputDev HMLAN0
MSGCNT 27832
NAME BM_Zufahrt
NR 58
STATE motion
TYPE CUL_HM
lastMsg No:5E - t:10 s:1A67B1 d:444958 0601D100
protLastRcv 2014-05-07 19:23:13
rssi_at_HMLAN0 avg:-79.44 min:-93 max:-75 lst:-78 cnt:9289
rssi_at_HMLAN1 avg:-76.11 min:-103 max:-65 lst:-95 cnt:9266
rssi_at_HMLAN2 avg:-81.7 min:-103 max:-74 lst:-81 cnt:9277
Readings:
2014-04-06 16:16:36 Activity alive
2014-02-07 18:35:10 Activity: alive
2014-02-07 21:02:18 D-firmware 1.5
2014-02-07 21:02:18 D-serialNr JEQ0128025
2014-05-07 19:23:13 battery ok
2014-05-07 19:23:13 brightness 209
2014-05-07 19:23:13 cover closed
2014-05-07 19:14:58 motion on (to broadcast)
2014-05-07 19:14:58 motionCount 108_next:4-15
2014-02-05 18:35:46 noReceiver src:1A67B1 (8441) 012C2C
2014-05-07 19:23:13 recentStateType info
2014-05-07 19:14:58 state motion
Helper:
mId 005D
rxType 28
Io:
newChn +1A67B1,02,01,1E
nextSend 1399483393.73417
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan0:
avg -79.4450425234147
cnt 9289
lst -78
max -75
min -93
At_hmlan1:
avg -76.1145046406214
cnt 9266
lst -95
max -65
min -103
At_hmlan2:
avg -81.7010887140238
cnt 9277
lst -81
max -74
min -103
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
devStateIcon motion:people_sensor .*:rc_BLANK
expert 2_full
firmware 1.5
model HM-Sen-MDIR-O
peerIDs 00000000,
room Sensoren
serialNr JEQ0128025
subType motionDetector
--------------------------------------------------
Internals:
DEF 1A67B1
HMLAN0_MSGCNT 9293
HMLAN0_RAWMSG E1A67B1,0000,AF7BD0F1,FF,FFB2,6284411A67B1000000016FD141
HMLAN0_RSSI -78
HMLAN0_TIME 2014-05-07 19:32:58
HMLAN1_MSGCNT 9270
HMLAN1_RAWMSG E1A67B1,0000,115D8AFC,FF,FFB2,6284411A67B1000000016FD141
HMLAN1_RSSI -78
HMLAN1_TIME 2014-05-07 19:32:58
HMLAN2_MSGCNT 9281
HMLAN2_RAWMSG E1A67B1,0000,AF7B925B,FF,FFB1,6284411A67B1000000016FD141
HMLAN2_RSSI -79
HMLAN2_TIME 2014-05-07 19:32:58
IODev HMLAN1
LASTInputDev HMLAN0
MSGCNT 27844
NAME BM_Zufahrt
NR 58
STATE nomotion
TYPE CUL_HM
lastMsg No:62 - t:41 s:1A67B1 d:000000 016FD141
protLastRcv 2014-05-07 19:32:58
rssi_at_HMLAN0 avg:-79.44 min:-93 max:-75 lst:-78 cnt:9293
rssi_at_HMLAN1 avg:-76.11 min:-103 max:-65 lst:-78 cnt:9270
rssi_at_HMLAN2 avg:-81.7 min:-103 max:-74 lst:-79 cnt:9281
Readings:
2014-04-06 16:16:36 Activity alive
2014-02-07 18:35:10 Activity: alive
2014-02-07 21:02:18 D-firmware 1.5
2014-02-07 21:02:18 D-serialNr JEQ0128025
2014-05-07 19:29:49 battery ok
2014-05-07 19:32:58 brightness 209
2014-05-07 19:29:49 cover closed
2014-05-07 19:32:58 motion on (to broadcast)
2014-05-07 19:32:58 motionCount 111_next:4-15
2014-02-05 18:35:46 noReceiver src:1A67B1 (8441) 012C2C
2014-05-07 19:29:49 recentStateType info
2014-05-07 19:32:58 state motion
Helper:
mId 005D
rxType 28
Io:
newChn +1A67B1,02,01,1E
nextSend 1399483978.93687
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan0:
avg -79.4443129237059
cnt 9293
lst -78
max -75
min -93
At_hmlan1:
avg -76.1176914778854
cnt 9270
lst -78
max -65
min -103
At_hmlan2:
avg -81.7008943001831
cnt 9281
lst -79
max -74
min -103
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
devStateIcon motion:people_sensor .*:rc_BLANK
expert 2_full
firmware 1.5
model HM-Sen-MDIR-O
peerIDs 00000000,
room Sensoren
serialNr JEQ0128025
subType motionDetector
--------------------------------------------------
Internals:
DEF 1A67B1
HMLAN0_MSGCNT 9294
HMLAN0_RAWMSG E1A67B1,0000,AF7E78FA,FF,FFB2,6384101A67B14449580601D100
HMLAN0_RSSI -78
HMLAN0_TIME 2014-05-07 19:35:52
HMLAN1_MSGCNT 9271
HMLAN1_RAWMSG E1A67B1,0000,11603306,FF,FFB2,6384101A67B14449580601D100
HMLAN1_RSSI -78
HMLAN1_TIME 2014-05-07 19:35:52
HMLAN2_MSGCNT 9282
HMLAN2_RAWMSG E1A67B1,0000,AF7E3A63,FF,FFB3,6384101A67B14449580601D100
HMLAN2_RSSI -77
HMLAN2_TIME 2014-05-07 19:35:52
IODev HMLAN1
LASTInputDev HMLAN1
MSGCNT 27847
NAME BM_Zufahrt
NR 58
STATE motion
TYPE CUL_HM
lastMsg No:63 - t:10 s:1A67B1 d:444958 0601D100
protLastRcv 2014-05-07 19:35:52
rssi_at_HMLAN0 avg:-79.44 min:-93 max:-75 lst:-78 cnt:9294
rssi_at_HMLAN1 avg:-76.11 min:-103 max:-65 lst:-78 cnt:9271
rssi_at_HMLAN2 avg:-81.7 min:-103 max:-74 lst:-77 cnt:9282
Readings:
2014-04-06 16:16:36 Activity alive
2014-02-07 18:35:10 Activity: alive
2014-02-07 21:02:18 D-firmware 1.5
2014-02-07 21:02:18 D-serialNr JEQ0128025
2014-05-07 19:35:52 battery ok
2014-05-07 19:35:52 brightness 209
2014-05-07 19:35:52 cover closed
2014-05-07 19:32:58 motion on (to broadcast)
2014-05-07 19:32:58 motionCount 111_next:4-15
2014-02-05 18:35:46 noReceiver src:1A67B1 (8441) 012C2C
2014-05-07 19:35:52 recentStateType info
2014-05-07 19:32:58 state motion
Helper:
mId 005D
rxType 28
Io:
newChn +1A67B1,02,01,1E
nextSend 1399484153.0015
Prt:
bErr 0
sProc 0
Rspwait:
Q:
qReqConf 00
qReqStat
Role:
chn 1
dev 1
Rssi:
At_hmlan0:
avg -79.4441575209812
cnt 9294
lst -78
max -75
min -93
At_hmlan1:
avg -76.1178945097614
cnt 9271
lst -78
max -65
min -103
At_hmlan2:
avg -81.7003878474466
cnt 9282
lst -77
max -74
min -103
Shadowreg:
Attributes:
IODev HMLAN1
actCycle 000:10
actStatus alive
autoReadReg 4_reqStatus
devStateIcon motion:people_sensor .*:rc_BLANK
expert 2_full
firmware 1.5
model HM-Sen-MDIR-O
peerIDs 00000000,
room Sensoren
serialNr JEQ0128025
subType motionDetector
Und die Logs, je einmal aus dem Event Monitor und danach die RAW Daten:
### Keep-Alive 1 ###
2014-05-07 19:29:49.267 CUL_HM BM_Zufahrt brightness: 209
2014-05-07 19:29:49.267 CUL_HM BM_Zufahrt cover: closed
2014-05-07 19:29:49.267 CUL_HM BM_Zufahrt battery: ok
# RAW
2014.05.07 19:29:49.221 5: HMLAN/RAW: /E1A67B1,0000,AF78AD8B,FF,FFAF,5F84101A67B14449580601D100
2014.05.07 19:29:49.222 5: HMLAN_Parse: HMLAN2 R:E1A67B1 stat:0000 t:AF78AD8B d:FF r:FFAF m:5F 8410 1A67B1 444958 0601D100
2014.05.07 19:29:49.223 5: HMLAN2 dispatch A0D5F84101A67B14449580601D100::-81:HMLAN2
2014.05.07 19:29:49.229 5: Triggering BM_Zufahrt (3 changes)
2014.05.07 19:29:49.229 5: Notify loop for BM_Zufahrt brightness: 209
2014.05.07 19:29:49.231 5: Triggering Battery_Check
2014.05.07 19:29:49.232 4: Battery_Check exec {
if ("battery: ok" !~ m/ok/ && Value("Batterie_eMail") eq "ein") {
fhem("set Batterie_eMail aus");;
Log 3, "BM_Zufahrt: Batteriewarnung battery: ok";;
Nachricht(1,0,"FHEM Batteriewarnung","BM_Zufahrt battery: ok");;
}
}
2014.05.07 19:29:49.233 5: Cmd: >{
if ("battery: ok" !~ m/ok/ && Value("Batterie_eMail") eq "ein") {
fhem("set Batterie_eMail aus");
Log 3, "BM_Zufahrt: Batteriewarnung battery: ok";
Nachricht(1,0,"FHEM Batteriewarnung","BM_Zufahrt battery: ok");
}
}<
2014.05.07 19:29:49.276 5: HMLAN/RAW: /E1A67B1,0000,115AA62F,FF,FFA3,5F84101A67B14449580601D100
2014.05.07 19:29:49.277 0: HMLAN_Parse: HMLAN1 R:E1A67B1 stat:0000 t:115AA62F d:FF r:FFA3 m:5F 8410 1A67B1 444958 0601D100
2014.05.07 19:29:49.278 5: HMLAN1 dispatch A0D5F84101A67B14449580601D100::-93:HMLAN1
2014.05.07 19:29:49.280 4: CUL_HM BM_Zufahrt dupe: dont process
2014.05.07 19:29:49.282 5: HMLAN/RAW: /E1A67B1,0000,AF78EC21,FF,FFB2,5F84101A67B14449580601D100
2014.05.07 19:29:49.282 5: HMLAN_Parse: HMLAN0 R:E1A67B1 stat:0000 t:AF78EC21 d:FF r:FFB2 m:5F 8410 1A67B1 444958 0601D100
2014.05.07 19:29:49.283 5: HMLAN0 dispatch A0D5F84101A67B14449580601D100::-78:HMLAN0
2014.05.07 19:29:49.285 4: CUL_HM BM_Zufahrt dupe: dont process
### Motion 1 ###
2014-05-07 19:32:24.976 CUL_HM BM_Zufahrt motion
2014-05-07 19:32:24.976 CUL_HM BM_Zufahrt motion: on (to broadcast)
2014-05-07 19:32:24.976 CUL_HM BM_Zufahrt motionCount: 109_next:4-15
2014-05-07 19:32:24.976 CUL_HM BM_Zufahrt brightness: 209
# RAW
2014.05.07 19:32:24.930 5: HMLAN/RAW: /E1A67B1,0000,115D0682,FF,FFAE,6084411A67B1000000016DD140
2014.05.07 19:32:24.932 0: HMLAN_Parse: HMLAN1 R:E1A67B1 stat:0000 t:115D0682 d:FF r:FFAE m:60 8441 1A67B1 000000 016DD140
2014.05.07 19:32:24.933 5: HMLAN1 dispatch A0D6084411A67B1000000016DD140::-82:HMLAN1
2014.05.07 19:32:24.938 5: Triggering BM_Zufahrt (4 changes)
2014.05.07 19:32:24.938 5: Notify loop for BM_Zufahrt motion
2014.05.07 19:32:24.940 5: Triggering Bewegung_Zufahrt
2014.05.07 19:32:24.941 4: Bewegung_Zufahrt exec {
if (Value("BM_aktiv") eq "ein" && Value("BM_Zufahrt_aktiv") eq "ein") {
fhem "set Licht_Zufahrt on-for-timer 120";;
}
}
2014.05.07 19:32:24.942 5: Cmd: >{
if (Value("BM_aktiv") eq "ein" && Value("BM_Zufahrt_aktiv") eq "ein") {
fhem "set Licht_Zufahrt on-for-timer 120";
}
}<
2014.05.07 19:32:24.985 5: HMLAN/RAW: /E1A67B1,0000,AF7B0DE0,FF,FFAC,6084411A67B1000000016DD140
2014.05.07 19:32:24.986 5: HMLAN_Parse: HMLAN2 R:E1A67B1 stat:0000 t:AF7B0DE0 d:FF r:FFAC m:60 8441 1A67B1 000000 016DD140
2014.05.07 19:32:24.987 5: HMLAN2 dispatch A0D6084411A67B1000000016DD140::-84:HMLAN2
2014.05.07 19:32:24.989 4: CUL_HM BM_Zufahrt dupe: dont process
2014.05.07 19:32:24.991 5: HMLAN/RAW: /E1A67B1,0000,AF7B4C77,FF,FFB3,6084411A67B1000000016DD140
2014.05.07 19:32:24.991 5: HMLAN_Parse: HMLAN0 R:E1A67B1 stat:0000 t:AF7B4C77 d:FF r:FFB3 m:60 8441 1A67B1 000000 016DD140
2014.05.07 19:32:24.992 5: HMLAN0 dispatch A0D6084411A67B1000000016DD140::-77:HMLAN0
2014.05.07 19:32:24.994 4: CUL_HM BM_Zufahrt dupe: dont process
### Motion 2 ###
2014-05-07 19:32:41.698 CUL_HM BM_Zufahrt motion
2014-05-07 19:32:41.698 CUL_HM BM_Zufahrt motion: on (to broadcast)
2014-05-07 19:32:41.698 CUL_HM BM_Zufahrt motionCount: 110_next:4-15
2014-05-07 19:32:41.698 CUL_HM BM_Zufahrt brightness: 209
# RAW
2014.05.07 19:32:41.653 5: HMLAN/RAW: /E1A67B1,0000,115D47D7,FF,FFAF,6184411A67B1000000016ED140
2014.05.07 19:32:41.654 0: HMLAN_Parse: HMLAN1 R:E1A67B1 stat:0000 t:115D47D7 d:FF r:FFAF m:61 8441 1A67B1 000000 016ED140
2014.05.07 19:32:41.655 5: HMLAN1 dispatch A0D6184411A67B1000000016ED140::-81:HMLAN1
2014.05.07 19:32:41.659 5: Triggering BM_Zufahrt (4 changes)
2014.05.07 19:32:41.660 5: Notify loop for BM_Zufahrt motion
2014.05.07 19:32:41.662 5: Triggering Bewegung_Zufahrt
2014.05.07 19:32:41.663 4: Bewegung_Zufahrt exec {
if (Value("BM_aktiv") eq "ein" && Value("BM_Zufahrt_aktiv") eq "ein") {
fhem "set Licht_Zufahrt on-for-timer 120";;
}
}
2014.05.07 19:32:41.663 5: Cmd: >{
if (Value("BM_aktiv") eq "ein" && Value("BM_Zufahrt_aktiv") eq "ein") {
fhem "set Licht_Zufahrt on-for-timer 120";
}
}<
2014.05.07 19:32:41.707 5: HMLAN/RAW: /E1A67B1,0000,AF7B4F36,FF,FFAF,6184411A67B1000000016ED140
2014.05.07 19:32:41.707 5: HMLAN_Parse: HMLAN2 R:E1A67B1 stat:0000 t:AF7B4F36 d:FF r:FFAF m:61 8441 1A67B1 000000 016ED140
2014.05.07 19:32:41.708 5: HMLAN2 dispatch A0D6184411A67B1000000016ED140::-81:HMLAN2
2014.05.07 19:32:41.710 4: CUL_HM BM_Zufahrt dupe: dont process
2014.05.07 19:32:41.712 5: HMLAN/RAW: /E1A67B1,0000,AF7B8DCC,FF,FFB2,6184411A67B1000000016ED140
2014.05.07 19:32:41.713 5: HMLAN_Parse: HMLAN0 R:E1A67B1 stat:0000 t:AF7B8DCC d:FF r:FFB2 m:61 8441 1A67B1 000000 016ED140
2014.05.07 19:32:41.714 5: HMLAN0 dispatch A0D6184411A67B1000000016ED140::-78:HMLAN0
2014.05.07 19:32:41.716 4: CUL_HM BM_Zufahrt dupe: dont process
### Motion 3 ###
2014-05-07 19:32:58.884 CUL_HM BM_Zufahrt motion
2014-05-07 19:32:58.884 CUL_HM BM_Zufahrt motion: on (to broadcast)
2014-05-07 19:32:58.884 CUL_HM BM_Zufahrt motionCount: 111_next:4-15
2014-05-07 19:32:58.884 CUL_HM BM_Zufahrt brightness: 209
# RAW
2014.05.07 19:32:58.839 5: HMLAN/RAW: /E1A67B1,0000,115D8AFC,FF,FFB2,6284411A67B1000000016FD141
2014.05.07 19:32:58.840 0: HMLAN_Parse: HMLAN1 R:E1A67B1 stat:0000 t:115D8AFC d:FF r:FFB2 m:62 8441 1A67B1 000000 016FD141
2014.05.07 19:32:58.841 5: HMLAN1 dispatch A0D6284411A67B1000000016FD141::-78:HMLAN1
2014.05.07 19:32:58.846 5: Triggering BM_Zufahrt (4 changes)
2014.05.07 19:32:58.846 5: Notify loop for BM_Zufahrt motion
2014.05.07 19:32:58.848 5: Triggering Bewegung_Zufahrt
2014.05.07 19:32:58.849 4: Bewegung_Zufahrt exec {
if (Value("BM_aktiv") eq "ein" && Value("BM_Zufahrt_aktiv") eq "ein") {
fhem "set Licht_Zufahrt on-for-timer 120";;
}
}
2014.05.07 19:32:58.850 5: Cmd: >{
if (Value("BM_aktiv") eq "ein" && Value("BM_Zufahrt_aktiv") eq "ein") {
fhem "set Licht_Zufahrt on-for-timer 120";
}
}<
2014.05.07 19:32:58.892 5: HMLAN/RAW: /E1A67B1,0000,AF7B925B,FF,FFB1,6284411A67B1000000016FD141
2014.05.07 19:32:58.893 5: HMLAN_Parse: HMLAN2 R:E1A67B1 stat:0000 t:AF7B925B d:FF r:FFB1 m:62 8441 1A67B1 000000 016FD141
2014.05.07 19:32:58.894 5: HMLAN2 dispatch A0D6284411A67B1000000016FD141::-79:HMLAN2
2014.05.07 19:32:58.896 4: CUL_HM BM_Zufahrt dupe: dont process
2014.05.07 19:32:58.898 5: HMLAN/RAW: /E1A67B1,0000,AF7BD0F1,FF,FFB2,6284411A67B1000000016FD141
2014.05.07 19:32:58.899 5: HMLAN_Parse: HMLAN0 R:E1A67B1 stat:0000 t:AF7BD0F1 d:FF r:FFB2 m:62 8441 1A67B1 000000 016FD141
2014.05.07 19:32:58.900 5: HMLAN0 dispatch A0D6284411A67B1000000016FD141::-78:HMLAN0
2014.05.07 19:32:58.902 4: CUL_HM BM_Zufahrt dupe: dont process
### Watchdog ###
2014.05.07 19:33:38.876 3: Watchdog Reset_BM_Zufahrt triggered
2014.05.07 19:33:38.877 5: Cmd: >setstate BM_Zufahrt nomotion<
2014.05.07 19:33:38.878 5: Cmd: >trigger BM_Zufahrt nomotion<
2014.05.07 19:33:38.879 5: Triggering BM_Zufahrt (1 changes)
2014.05.07 19:33:38.879 5: Notify loop for BM_Zufahrt nomotion
2014.05.07 19:33:38.896 5: Cmd: >trigger Reset_BM_Zufahrt .<
2014.05.07 19:33:38.896 5: Triggering Reset_BM_Zufahrt (1 changes)
2014.05.07 19:33:38.897 5: Notify loop for Reset_BM_Zufahrt .
### Keep-Alive 2 ###
2014.05.07 19:35:52.903 5: HMLAN/RAW: /E1A67B1,0000,AF7E3A63,FF,FFB3,6384101A67B14449580601D100
2014.05.07 19:35:52.904 5: HMLAN_Parse: HMLAN2 R:E1A67B1 stat:0000 t:AF7E3A63 d:FF r:FFB3 m:63 8410 1A67B1 444958 0601D100
2014.05.07 19:35:52.905 5: HMLAN2 dispatch A0D6384101A67B14449580601D100::-77:HMLAN2
2014.05.07 19:35:52.910 5: Triggering BM_Zufahrt (3 changes)
2014.05.07 19:35:52.910 5: Notify loop for BM_Zufahrt brightness: 209
2014.05.07 19:35:52.912 5: Triggering Battery_Check
2014.05.07 19:35:52.913 4: Battery_Check exec {
if ("battery: ok" !~ m/ok/ && Value("Batterie_eMail") eq "ein") {
fhem("set Batterie_eMail aus");;
Log 3, "BM_Zufahrt: Batteriewarnung battery: ok";;
Nachricht(1,0,"FHEM Batteriewarnung","BM_Zufahrt battery: ok");;
}
}
2014.05.07 19:35:52.914 5: Cmd: >{
if ("battery: ok" !~ m/ok/ && Value("Batterie_eMail") eq "ein") {
fhem("set Batterie_eMail aus");
Log 3, "BM_Zufahrt: Batteriewarnung battery: ok";
Nachricht(1,0,"FHEM Batteriewarnung","BM_Zufahrt battery: ok");
}
}<
2014.05.07 19:35:52.956 5: HMLAN/RAW: /E1A67B1,0000,AF7E78FA,FF,FFB2,6384101A67B14449580601D100
2014.05.07 19:35:52.957 5: HMLAN_Parse: HMLAN0 R:E1A67B1 stat:0000 t:AF7E78FA d:FF r:FFB2 m:63 8410 1A67B1 444958 0601D100
2014.05.07 19:35:52.958 5: HMLAN0 dispatch A0D6384101A67B14449580601D100::-78:HMLAN0
2014.05.07 19:35:52.960 4: CUL_HM BM_Zufahrt dupe: dont process
2014.05.07 19:35:52.963 5: HMLAN/RAW: /E1A67B1,0000,11603306,FF,FFB2,6384101A67B14449580601D100
2014.05.07 19:35:52.963 0: HMLAN_Parse: HMLAN1 R:E1A67B1 stat:0000 t:11603306 d:FF r:FFB2 m:63 8410 1A67B1 444958 0601D100
2014.05.07 19:35:52.964 5: HMLAN1 dispatch A0D6384101A67B14449580601D100::-78:HMLAN1
2014.05.07 19:35:52.966 4: CUL_HM BM_Zufahrt dupe: dont process
### End
Viele Grüße
Jürgen
Hallo Jürgen,
zum einen sind mir deine Notifies unklar. Ein ziel von mir ist hier immer die optimierung - anzahl der notifies sowie performance. Das scheint mir nicht optimal zu sein.
1) der Batteriecheck wird schon bei einer statusmeldung mehrfach ausgeführt
=> die regexp des notify sollte bereits die Abfrage nach dem "ok" enthalten.
2) du solltest event-on-change-reading nutzen - dann sollte Batterie_eMail hinfällig werden - du wirst bei jeder Änderung informiert, aber nicht wenn es gleich bleibt - als nur einmal pro batterieproblem
3) HMInfo sammelt verschiedene Alarme, auch batteriealarme - für alle komponenten. Vielleicht eine Alternative?
Ähnlich - aber nicht gleich - ist das notify für die treppenhausschaltung zu sehen. Wenn du dies auf motionCount triggern lässt ist es sogar gleich.
Vielleicht postest du einmal die notifies
Was mir zu next_Tr fehlt wären längere logs. Nach den Motion und dem trigger sind die rohmessages der 3 ios zu sehen - interessant sind für mich die messages der nächsten 5min. Falls du hier noch ein paar aufnahmen machen kannst - insbesondere wenn du mehrfach triggerst.
Die Option den BM mit dem licht direkt zu peeren hat dir nicht gefallen?
Gruss Martin
Hallo Martin,
danke für deine Anmerkungen. Dazu äußere ich mich gerne später auch noch.
Können wir zunächst mein eigentliches Problem lösen? Siehe Titel des Themas und:ZitatIch glaube auch schon anhand der Daten etwas verstanden zu haben. Mein Watchdog setstate setzt den STATE in den Internals auf "nomotion". Der state in den Readings bleibt auf "motion". Wenn die Keep-Alive nach dem Watchdog kommt, werden die Werte aus den Readings in die Internals geschrieben und somit geht STATE wieder auf "motion". Ob das korrekt ist, musst du beurteilen.
Erkenntnis:
1) Wenn etwas empfangen wird, werden
alle Readings in die Internals übernommen - auch wenn es zu einem Reading gar kein Update gab (hier "state").
2) Ein setstate alleine ist für den Bewegungsmelder ziemlich unnütz, da der Wert nicht "lange lebt".
Bedeutet für mich:
Es nützt mir also nichts mit setstate den Internals STATE auf "nomotion" zu setzten, da es später vom Reading state wieder überschrieben wird. Ich muss also zusätzlich zu setstate auch noch setreading ausführen. Dann sollte es gehen!?
Gruß Jürgen
Hallo Jürgen,
Zitat1) Wenn etwas empfangen wird, werden alle Readings in die Internals übernommen - auch wenn es zu einem Reading gar kein Update gab (hier "state").
wie bitte?
Readings werden bei mir NIE nach internals übernommen.
reading state und internal STATE ist ein sonderfall.
was meinst du hier? kannst du ein Beispiel nennen?
Zitat2) Ein setstate alleine ist für den Bewegungsmelder ziemlich unnütz, da der Wert nicht "lange lebt".
das macht auch keinen sinn - da ist eher etwas für dummy entities.
Du könntest mit dem Attribut stateFormat arbeiten - das wäre der weg.
du kannst hier gerne weiter basteln - aber sollten wir nicht erst das eigentliche verhalten Untersuchen? Wenn du entsprechende Daten zu next_Tr lieferst kann das ganze evtl in fhem erledigt werden.
Und deine notifies kannst du natürlich so aufwendig lassen, wie du willst.
Gruss Martin
Zitat von: martinp876 am 09 Mai 2014, 16:08:07
Readings werden bei mir NIE nach internals übernommen.
reading state und internal STATE ist ein sonderfall.
Naja, der zweite Satz relativiert den ersten ja schon wieder.
Zitat
was meinst du hier? kannst du ein Beispiel nennen?
Ja, nämlich genau die Sache mit STATE und state. Schau mal das "list BM_Zufahrt" an. Im zweiten Datensatz steht STATE auf "nomotion". Im dritten steht es wieder auf "motion", obwohl die letzte Meldung gar kein Motion enthält.
In deiner ersten Antwort hier hast du mir geschrieben:
Motion wird ausschliesslich bei einem Trigger gesetzt - also nicht bei einer statusmessage. Somit ist das Verhalten nicht klar.Das stimmt ja nun so nicht, da eine Statusmeldung sehr wohl Motion setzt, nur halt in den Internals und nicht in den Readings.
Zitat
das macht auch keinen sinn - da ist eher etwas für dummy entities.
Das dämmert mir auch so langsam. ???
Zitat
Du könntest mit dem Attribut stateFormat arbeiten - das wäre der weg.
Ok, das "If not set, its value is taken from the state reading" erklärt es nun auch warum state (Reading) in STATE (Internals) wandert. Dann schaue ich mir das mal an.
Zitat
du kannst hier gerne weiter basteln - aber sollten wir nicht erst das eigentliche verhalten Untersuchen? Wenn du entsprechende Daten zu next_Tr lieferst kann das ganze evtl in fhem erledigt werden.
Ich will hier nichts sinnlos basteln ::)
Ich versuche nur seit x Posts lediglich eine Antwort auf die Frage "Warum ändert sich der STATE bei Empfang der zyklischen Keep-Alive Meldung" zu erhalten und ich habe bzw. hatte das Gefühl, dass wir hier nur aneinander vorbei reden.
Gibt es einen (softwaretechnischen) Grund den Inhalt von state (Reading) in STATE (Internals) zu übertragen? Wenn ja, welchen? Ich will es doch nur mal verstehen.
Verstehe mich nicht falsch. Ich ziehe meinen Hut vor deiner Arbeit hier!
Ich mache dir, da du keine MDIR-O hast, auch gerne noch alle möglichen Logs davon. Vielleicht kann man dann - wie du schreibst - das direkt in fhem lösen. Es ist ja auch für viele Anfänger ungewohnt, dass der BM nur einen einzigen State besitzt.
Zitat
Und deine notifies kannst du natürlich so aufwendig lassen, wie du willst.
Nee, für Verbesserungen bin ich immer zu haben, aber lass uns doch mal eine Sache nach der anderen klären.
8)
ZitatDie Option den BM mit dem licht direkt zu peeren hat dir nicht gefallen?
Nein, da ich nicht die brightness Werte verwenden möchte, sondern mir mittels sunset/rise eine Variable setzte, die mir sagt, ob es hinreichend dunkel ist. Ich mache lieber alles über die Zentrale. FHEM ist bei mir auf der 7390 einmal abgestürzt und auf dem Cubietruck noch nie.
So, noch was zum Thema "next_Tr". Schau dir mal mein Log und das Log von Crawler an:
Bei mir, minInterval 15 kommt: motionCount: xxx_next:4-15
Bei ihm, minInterval 120 kommt: motionCount: xxx_next:7-120
Bei ihm, minInterval 240 kommt: motionCount: xxx_next:8-240
Hilft dir das weiter oder brauchst du von mir noch Logs mit unterschiedlichen minInterval?
Gruß Jürgen
Hi
ZitatNaja, der zweite Satz relativiert den ersten ja schon wieder.
state ist die einzige Ausnahme - das wird von der "kernal-SW" gemacht. Alle anderen bleiben, wo sie sind.
ZitatJa, nämlich genau die Sache mit STATE und state.
wie gesagt - kernal. Die treiben sonderspielchen mit STATE. Prüfe einmal, ob der Zeitstempel von reading-state auch geändert ist. Wenn nicht kopiert das der kernal einfach bei jedem trigger. Dann ist es eben so.
CUL_HM sollte das Reading STATE
nicht anfassen -beim status.
Du kannst es aber ändern, wenn du das Attribut stateFormat nutzt. Dann gehört es dir - wird aber auch bei jedem Trigger angewendet!
ZitatOk, das "If not set, its value is taken from the state reading" erklärt es nun auch warum state (Reading) in STATE (Internals) wandert. Dann schaue ich mir das mal an.
exakt - wie oben beschrieben. Reading state wird NICHT angetastet - wie beschrieben.
ZitatGibt es einen (softwaretechnischen) Grund den Inhalt von state (Reading) in STATE (Internals) zu übertragen? Wenn ja, welchen? Ich will es doch nur mal verstehen.
SW-technisch sicher nicht - es ist ein semantisches Problem. Diese Frage bitte an "den Kernal" stellen, also die Platform (Rudi).
ZitatVerstehe mich nicht falsch. Ich ziehe meinen Hut vor deiner Arbeit hier!
kein Problem. STATE ist nicht ganz problemlos - schon einmal dass man nur schwer ein notify darauf setzen kann.
ZitatSo, noch was zum Thema "next_Tr". Schau dir mal mein Log und das Log von Crawler an:
Bei mir, minInterval 15 kommt: motionCount: xxx_next:4-15
Bei ihm, minInterval 120 kommt: motionCount: xxx_next:7-120
Bei ihm, minInterval 240 kommt: motionCount: xxx_next:8-240
Hilft dir das weiter oder brauchst du von mir noch Logs mit unterschiedlichen minInterval?
super - wie erwartet. Jetzt ist nur die Frage, wann die "next" kommen.
Zum Hintergrund:
Wenn ich richtig liege (und wie du siehst) kommt die eingestellt Filterzeit (kodiert) in der triggermessage an. Es ist dann mit dem Nächsten Trigger in er angegebenen Zeit zu rechnen. Der kommt in jedem Fall - wie ich gesehen habe. Aber wenn keine Motion mehr "vorhanden" ist, kommt bei next eine '0'.
So dies korrekt ist, kann ich dies nutzen um ein "no-motion" zu setzen.
Ich hätte dies gerne in rohmessages gesehen. Also min 2 aufnahmen:
I) 1 motion => es sollten 2 trigger-meldungen kommen
II) 2 oder mehr motion - innerhalb der filter-periode es sollten min 3 triggermeldungen kommen.
Bitte immer warten bis die Filterperiode abgelaufen ist. Die letzte message ist sehr wichtig! (daher besser mit 15sec testen - geht schneller)
Gruss Martin
Zitat von: martinp876 am 09 Mai 2014, 19:19:42
Zum Hintergrund:
Wenn ich richtig liege (und wie du siehst) kommt die eingestellt Filterzeit (kodiert) in der triggermessage an. Es ist dann mit dem Nächsten Trigger in er angegebenen Zeit zu rechnen. Der kommt in jedem Fall - wie ich gesehen habe. Aber wenn keine Motion mehr "vorhanden" ist, kommt bei next eine '0'.
So dies korrekt ist, kann ich dies nutzen um ein "no-motion" zu setzen.
Hallo Martin!
1.) Was ich dir ohne Rohdaten schon sagen kann ist, dass nach einer Motion Meldung:
2014-05-14_15:02:53 BM_Zufahrt motion
2014-05-14_15:02:53 BM_Zufahrt motion: on (to broadcast)
2014-05-14_15:02:53 BM_Zufahrt motionCount: 135_next:4-15
2014-05-14_15:02:53 BM_Zufahrt brightness: 224
kein Eintrag mit next 0 wie etwa:
2014-05-14_15:02:53 BM_Zufahrt motionCount: 135_next:0
oder so ähnlich im Log steht.
Nach der letzten Motion Meldung kommt einfach nix mehr und dann kommt einfach irgendwann wieder eine zyklische Statusmeldung. Rohdaten kann ich dir aber wie gewünscht am Wochenende mal ziehen. Vielleicht steht da noch mehr drin.
2.) Ich habe meine Events wie von dir vorgeschlagen stark ausgedünnt und dazu diverse "event-on-change/update-reading" verwendet.
3.) Den anfangs erwähnten Watchdog habe ich mit den hier gewonnenen Erkenntnissen wie folgt abgeändert:
define Reset_BM_Zufahrt watchdog BM_Zufahrt:motion 00:00:40 SAME setreading BM_Zufahrt state nomotion;setstate BM_Zufahrt nomotion;trigger Reset_BM_Zufahrt .Damit funktioniert meine Anzeige einer Bewegung wie gewünscht und ich bin happy 8)
Gruß Jürgen
Hallo Leute,
sorry für die vielleicht blöde Frage, aber ich kapier den WatchDog der hier und auch in weiteren Beiträgen erwähnt wird nicht.
Ihr schreibt immer:
define Reset_BM_Zufahrt watchdog BM_Zufahrt:motion 00:00:40 SAME setreading BM_Zufahrt state nomotion;setstate BM_Zufahrt nomotion;trigger Reset_BM_Zufahrt .
Für mich vorgelesen sagt das...
"Definiere einen WhatchDog namens "Reset_BM_Zufahrt" und bei "motion" mach nach 40 Sekunden ein FHEMCMD>setreading BM_Zufahrt (also den BM reading status) nomotion und weiter noch ein FHEMCMD>setstate BM-Zufahrt auf nomotion"
Soweit so gut, und jetzt kommt der Teil den ich nicht verstehe....
trigger den Watchdog erneut! mit FHEMCMD>trigger Reset_BM_Zufahrt
Wieso wird hier im ausführenden Teil des WatchDog der WatchDog getriggert um das in einer Schleife andauernd zu triggern?
Ich dachte ein WatchDog ist der Aufpasser der auf den Status schaut und muss nicht andauernd ala "Totmanschalter" stati setzen?
Bitte erklärt es mir, denn ich habe seit ner Stunde auch einen "HM-Sen-MDIR-O", habe im Wiki einen verkürzten watchDog gefunden, und beim Testen stellte ich eine andauernde Inkonsitenz und Unzuverlässigkeit des WatchDog fest, was mich dann an meinem Verständnis zweifeln lässt, und weswegen ich hier nun frage.
Danke Euch!
der Merlin
Zitattrigger den Watchdog erneut! mit FHEMCMD>trigger Reset_BM_Zufahrt
das wichtige dabei ist der niedliche, kleine punkt (dot) am ende. das setzt den status vom watchdog eine stufe höher. also in diesem fall von triggered nach defined, damit der nächste motion den watchdog dann wieder auf activated setzen kann.
schau mal in die commandref bei watchdog
Nach der Testorgie, die ich hinter mir habe (siehe vegangene Posts) würde ich behaupten, dass der watchdog im Wiki falsch bzw. unvollständig ist. Nimm den von mir (mit "." am Ende!), der funzt. Die 40 Sekunden musst du natürlich an deine Einstellungen anpassen, z.B. minInterval+x.
Puh!
so ein kleiner niedlicher Punkt...
Wie ich sowas mag. :-)
Das wars scheinbar auch bei mir.
Hab es mal so gesetzt und mit dem Punkt, und nun scheint es glaube ich tatsächlich zu funktionieren.
Siche rbin ich noch nicht, weil ich das gerade remote geändert habe aber keine echte Bewegung auslösen kann.
Ich kann nur per setReading das versuchen zu triggern.
Aber lieber wäre mir der echte Wet-Ware test.