HM-Sen-MDIR-WM55 keine motion Meldung

[smitie]

Hallo,

ich habe das Problem, dass ich bei erfolgter Bewegung am HM-Sen-MDIR-WM55 keine motion Meldungen bekomme.
Drücke ich ein der beiden Tasten am Gerät, bekomme ich einmalig eine motion-Meldung angezeigt.
Das Meldeintervall habe ich lt. Anleitung aus dem wiki auf 60s verrringert.
Kann mir jemand einen Hinweis geben, was hier nicht stimmt?
Danke!

Gruß Rudi

List motion:

Code Auswählen Erweitern

Internals:
   DEF        57CA9203
   NAME       BM_Keller_Abgang_Motion
   NOTIFYDEV  global
   NR         137
   STATE      noMotion
   TYPE       CUL_HM
   chanNo     03
   device     BM_Keller_Abgang
   READINGS:
     2017-11-18 10:17:57   R-brightFilter  7
     2017-11-18 10:17:57   R-captInInterval off
     2017-11-17 19:59:18   R-evtFltrNum    1
     2017-11-17 19:59:18   R-evtFltrPeriod 1 s
     2017-11-18 10:17:57   R-minInterval   60
     2017-11-17 19:59:18   R-sign          off
     2017-11-18 10:29:03   RegL_01.          01:12 02:72 08:00 22:00 30:03 00:00
     2017-11-18 10:32:57   brightness      125
     2017-11-18 10:33:59   motion          off
     2017-11-18 10:32:57   motionCount     5_next:60s
     2017-11-18 10:33:59   motionDuration  62
     2017-11-18 10:33:59   state           noMotion
     2017-11-18 10:32:57   trigDst_D22929  noConfig
     2017-11-18 10:32:57   trigger_cnt     5
   helper:
     peerIDsRaw ,00000000
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     role:
       chn        1
     shadowReg:
Attributes:
   model      HM-Sen-MDIR-WM55
   peerIDs    00000000,
   room       Keller

List HM-Sen-MDIR-WM55:

Code Auswählen Erweitern

Internals:
   CUL_HM_MSGCNT 94
   CUL_HM_RAWMSG A0D00A61057CA92D2292906009800::-89:CUL_HM
   CUL_HM_RSSI -89
   CUL_HM_TIME 2017-11-18 10:44:29
   DEF        57CA92
   IODev      CUL_HM
   LASTInputDev CUL_HM
   MSGCNT     94
   NAME       BM_Keller_Abgang
   NOTIFYDEV  global
   NR         125
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 BM_Keller_Abgang_Btn_01
   channel_02 BM_Keller_Abgang_Btn_02
   channel_03 BM_Keller_Abgang_Motion
   lastMsg    No:00 - t:10 s:57CA92 d:D22929 06009800
   protLastRcv 2017-11-18 10:44:29
   protSnd    120 last_at:2017-11-18 10:44:29
   protState  CMDs_done
   rssi_at_CUL_HM lst:-89 avg:-82.87 cnt:94 min:-103 max:-75.5
   READINGS:
     2017-11-18 10:17:57   CommandAccepted yes
     2017-11-18 10:29:03   D-firmware      1.2
     2017-11-18 10:29:03   D-serialNr      OEQ0537878
     2017-11-18 10:15:20   PairedTo        0xD22929
     2017-11-18 10:15:20   R-pairCentral   0xD22929
     2017-11-18 10:15:20   RegL_00.          02:01 0A:D2 0B:29 0C:29 14:03 18:00 00:00
     2017-11-18 10:44:29   battery         ok
     2017-11-18 10:44:29   brightness      152
     2017-11-18 10:44:29   cover           closed
     2017-11-17 20:14:49   motion          off
     2017-11-14 20:52:31   motionCount     1_next:240s
     2017-11-14 20:56:33   motionDuration  242
     2017-11-18 10:44:29   powerOn         2017-11-18 10:44:29
     2017-11-18 10:44:29   recentStateType info
     2017-11-18 10:44:29   state           CMDs_done
     2017-11-14 20:52:31   trigger_cnt     1
   helper:
     HM_CMDNR   0
     PONtest    0
     cSnd       01D2292957CA9203040000000001,01D2292957CA920303
     mId        00DB
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +57CA92,00,00,00
       nextSend   1510998269.47184
       prefIO
       rxt        2
       vccu
       p:
         57CA92
         00
         00
         00
     mRssi:
       mNo        00
       io:
         CUL_HM     -87
     prt:
       bErr       0
       sProc      0
       sleeping   1
       try        1
       rspWait:
     q:
       qReqConf   00
       qReqStat
     role:
       dev        1
     rpt:
       IO         CUL_HM
       flg        A
       ts         1510998269.48967
       ack:
         HASH(0x312f728)
         008002D2292957CA9201019800
     rssi:
       at_CUL_HM:
         avg        -82.8723404255319
         cnt        94
         lst        -89
         max        -75.5
         min        -103
     shadowReg:
Attributes:
   IODev      CUL_HM
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   model      HM-Sen-MDIR-WM55
   room       Keller
   serialNr   OEQ0537878
   subType    motionAndBtn
   webCmd     getConfig:clear msgEvents 

Logfile:

Code Auswählen Erweitern

2017-11-18_10:44:29 BM_Keller_Abgang battery: ok
2017-11-18_10:44:29 BM_Keller_Abgang brightness: 152
2017-11-18_10:44:29 BM_Keller_Abgang cover: closed
2017-11-18_10:44:29 BM_Keller_Abgang powerOn: 2017-11-18 10:44:29
2017-11-18_10:44:29 BM_Keller_Abgang CMDs_done

[Loki]

Ich habe genau das gleich Problem!

Kann es sein, dass auch die "Initialerkennung" nur nach dem Ablauf des Intervalls gesendet wird?
Das würde aber nicht meiner Vorstellung eines Bewegungsmelders entsprechen.

Müssen noch zusätzliche Register gesetzt werden, damit die zumindest die erste Motion-Meldung sofort zurückgemeldet wird?

[Pfriemler]

"minIntervall" definiert eine Mindestpause nach einer gesendeten (!) Bewegungserkennung, im ersten Beispiel 60 Sekunden, default 240 Sekunden = 4 Minuten. Liegt die letzte Funkaussendung länger zurück, sollte sofort gesendet werden - es sind keine weiteren Register nötig (zumindest nicht ab Werk). In der Regel wird man bei einer manuellen Betätigung auch den Bewegungsmelder auslösen, so dass auch hier die Wartezeit ansteht.
"captInInterval" definiert das Verhalten der Bewegungserkennung in der Wartezeit. Steht es auf "off", so werden erst erneute Bewegungen nach Ablauf der Wartezeit gesendet. Bei "on" wird nach Ablauf der Wartezeit eine zwischenzeitlich erkannte Bewegung sofort "nachgereicht", auch wenn diese bereits länger zurückliegt. Das kann für sehr seltsames Verhalten sorgen, wenn nur Reaktionen auf unmittelbare Bewegung angedacht sind. Ein nach Verlassen des Bewegungsbereichs manuell ausgeschaltete Lampe könnte etwa ohne sichtbare Bewegung wieder einschalten usw.

Zur Diagnose empfehle ich die ledOnTime auf 0.1-0.3 Sekunden zu setzen, so erzeugt jede erkannte und gesendete (!) Bewegung lokal einen kurzen Blitzer. In der Wartepause erkannte Bewegungen werden nicht optisch gemeldet.

[betateilchen]

Drücke ich ein der beiden Tasten am Gerät, bekomme ich einmalig eine motion-Meldung angezeigt.

Das ist völlig unlogisch. Die beiden Taster am Gerät haben nichts mit dem Bewegungsmelder an sich zu tun und erzeugen keine motion Meldung.

Code Auswählen Erweitern


2018-07-13 12:15:57 CUL_HM wz_PIR1 CMDs_done
2018-07-13 12:15:57 CUL_HM wz_PIR1_Btn_02 Short 1_129 (to hmvccu)
2018-07-13 12:15:57 CUL_HM wz_PIR1_Btn_02 trigger: Short_129
2018-07-13 12:15:57 CUL_HM wz_PIR1_Btn_02 trigger_cnt: 129


Ich glaube, hier liegt ein grundsätzliches Verständnisproblem vor und ich versuche anhand des eingangs geposteten Problems mal zu erklären, auch wenn das schon ein bisschen her ist.

Man muss unterscheiden, wo man den motion event sucht. In dem Auszug aus dem Logfile oben sehen wir events aus dem Homematic device BM_Keller_Abgang.

Code Auswählen Erweitern


2017-11-18_10:44:29 BM_Keller_Abgang battery: ok


Dort wird der motion event nie auftreten. Einen event "motion" bzw. "noMotion" gibt es ausschließlich im Channel 03, im Beispiel also im FHEM device BM_Keller_Abgang_Motion.

Dass dort die events korrekt erzeugt werden, sieht man im Beispiel an den readings "motion" und "state"

Code Auswählen Erweitern


     2017-11-18 10:33:59   motion          off
     2017-11-18 10:33:59   state           noMotion



Also: Die events motion und noMotion immer an der richtigen Stelle suchen. Insbesondere darauf achten, wenn man auf diese events ein notify triggern möchte.

Dass im Homematic device selbst auch noch ein reading "motion" auftaucht, ist ein unschönes Verhalten und tritt nur ein einziges Mal beim Anlegen des Gerätes in FHEM auf. Dieses reading wird nie wieder aktualisiert und man kann es getrost dort rauslöschen, um die Verwirrung zu vermeiden.

[Pfriemler]

Das ist völlig unlogisch. Die beiden Taster am Gerät haben nichts mit dem Bewegungsmelder an sich zu tun und erzeugen keine motion Meldung.

Prinzipiell schon, aber die Hand in der Nähe des Tasters erzeugt ebenfalls motion, was man im Event-Monitor u.U. sehen kann (wenn die Bedingungen zur Funkaussendung erfüllt sind).