MDIR-O zyklische brightness Meldung setzt state auf motion

[Deudi]

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:

Code Auswählen Erweitern

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

[martinp876]

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

[Crawler]

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?)

Code Auswählen Erweitern

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

[martinp876]

Wenn STATE auf motion steht kommt motionCount

wenn motion erkannt wird, wird reading state, internal STATE und reading motionCount gesetzt

ändert sich nur nach setstate (Empfindlichkeit zu hoch?)

was Ändert sich nicht?

motion count zählt bei Bewegung von ? bis ? und fängt von vorne an

0 bis 255

Unterschied 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

[Deudi]

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

[Crawler]

war ein versuch

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

[martinp876]

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

[Deudi]

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

[Deudi]

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

Code Auswählen Erweitern


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:

Code Auswählen Erweitern


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

[martinp876]

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

[Deudi]

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:

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.

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

[martinp876]

Hallo Jürgen,

1) 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?

2) 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

[Deudi]

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.

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.

das macht auch keinen sinn - da ist eher etwas für dummy entities.

Das dämmert mir auch so langsam. 

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.

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.

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.

Die 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

[martinp876]

Hi

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

Ja, 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!

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.

exakt - wie oben beschrieben. Reading state wird NICHT angetastet - wie beschrieben.

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.

SW-technisch sicher nicht - es ist ein semantisches Problem. Diese Frage bitte an "den Kernal" stellen, also die Platform (Rudi).

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

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?

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

[Deudi]

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:

Code Auswählen Erweitern

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 

Gruß Jürgen