HM-Sen-MDIR-O-2 flackert grün bei Bewegung

[Thorsten Pferdekaemper]

Hallo,
ich habe zwei HM-Sen-MDIR-O-2. Der eine flackert seit neustem grün, wenn ich daran vorbeilaufe. (Mit "flackern" meine ich ein schnelles Blinken.) Bisher konnte ich keine Fehlfunktion feststellen, würde aber trotzdem gerne wissen, was das bedeutet. In der Anleitung habe ich dazu nichts gefunden, außer dass das Teil beim Anlernen grün blinkt. Das Ding ist meiner Meinung nach korrekt angelernt:

Code Auswählen Erweitern


Internals:
   DEF        3266D4
   HMLAN1_MSGCNT 19576
   HMLAN1_RAWMSG E3266D4,0000,134E2E43,FF,FFB2,B884103266D423A3F406017500
   HMLAN1_RSSI -78
   HMLAN1_TIME 2015-10-21 09:15:39
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     19576
   NAME       eg_ds_BewegungHinten
   NR         168
   STATE      motion
   TYPE       CUL_HM
   lastMsg    No:B8 - t:10 s:3266D4 d:23A3F4 06017500
   protLastRcv 2015-10-21 09:15:39
   protResnd  56 last_at:2015-10-21 08:08:50
   protSnd    1340 last_at:2015-10-21 08:13:28
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-71.1 min:-101 max:-60 lst:-78 cnt:19576
   Readings:
     2015-10-09 16:34:01   Activity        alive
     2015-05-14 12:51:44   D-firmware      1.6
     2015-05-14 12:51:44   D-serialNr      LEQ0986924
     2015-10-21 08:13:27   PairedTo        0x23A3F4
     2015-05-14 12:51:40   R-brightFilter  7
     2015-05-14 12:51:40   R-captInInterval off
     2015-05-14 12:51:40   R-evtFltrNum    1
     2015-05-14 12:51:40   R-evtFltrPeriod 1 s
     2015-05-14 12:51:40   R-ledOnTime     0 s
     2015-05-14 12:51:40   R-minInterval   60
     2015-05-14 12:51:39   R-pairCentral   0x23A3F4
     2015-10-21 08:13:27   RegL_00:          02:01 0A:23 0B:A3 0C:F4 00:00
     2015-10-21 08:13:27   RegL_01:          01:12 02:72 08:00 22:00 00:00
     2015-10-21 09:15:39   battery         ok
     2015-10-21 09:15:39   brightness      117
     2015-10-21 09:15:39   cover           closed
     2015-10-21 08:13:26   motion          on (to HMLAN1)
     2015-10-21 08:13:26   motionCount     218_next:29s
     2015-10-21 05:12:31   powerOn         2015-10-21 05:12:31
     2015-10-21 09:15:39   recentStateType info
     2015-10-21 08:13:26   state           motion
     2015-10-21 08:13:26   trigDst_23A3F4  noConfig
     2015-10-21 08:13:26   trigger_cnt     218
   Helper:
     cSnd       0123A3F43266D40103
     mId        00C1
     peerIDsRaw ,00000000
     rxType     28
     Io:
       newCh      1
       newChn     +3266D4,00,01,1E
       nextSend   1445411739.55677
       prefIO
       rxt        2
       vccu
       p:
         3266D4
         00
         01
         1E
     Mrssi:
       mNo        B8
       Io:
         HMLAN1     -76
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_hmlan1:
         avg        -71.1013485901098
         cnt        19576
         lst        -78
         max        -60
         min        -101
     Shadowreg:
Attributes:
   IODev      HMLAN1
   actCycle   000:10
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_full
   firmware   1.6
   group      eg_Draussen
   icon       people_sensor
   model      HM-Sen-MDIR-O-2
   peerIDs    00000000,
   room       eg_Draussen
   serialNr   LEQ0986924
   subType    motionDetector

Ich hatte auch einmal ein "CMDs_Pending", das ist aber inzwischen verschwunden. Flackern tut's aber immer noch (beim Vorbeilaufen).
(Wobei ich mich auch frage, welche Kommandos an das Teil geschickt wurden. Ich war's nicht.)
Gruß,
   Thorsten

[frank]

ich würde mal die rawmessages sniffen, um zu sehen, was dabei passiert. wenn du mehrere hast, am besten zum vergleich einen "normalen" und den sonderbaren.

eventuell hat es mit dem manchmal (-101) sehr schlechten funk zu tun. set clear rssi löscht diese historie und du siehst nur noch die aktuellen daten.

Code Auswählen Erweitern

rssi_at_HMLAN1 avg:-71.1 min:-101 max:-60 lst:-78 cnt:19576

[Thorsten Pferdekaemper]

Hi,
hier sind die Rawmessages:

Code Auswählen Erweitern


2015.10.21 20:08:05.787 0: HMLAN_Parse: HMLAN1 R:E3268B2   stat:0000 t:15A39783 d:FF r:FFC0     m:F1 A641 3268B2 23A3F4 01813460
2015.10.21 20:08:05.884 0: HMLAN_Send:  HMLAN1 S:S8B962BF9 stat:  00 t:00000000 d:01 r:8B962BF9 m:F1 8002 23A3F4 3268B2 01013400
2015.10.21 20:08:06.210 0: HMLAN_Parse: HMLAN1 R:R8B962BF9 stat:0002 t:00000000 d:FF r:7FFF     m:F1 8002 23A3F4 3268B2 01013400
2015.10.21 20:08:11.003 0: HMLAN_Parse: HMLAN1 R:E3266D4   stat:0000 t:15A3ABE3 d:FF r:FFB5     m:CF A641 3266D4 23A3F4 01DF1460
2015.10.21 20:08:11.099 0: HMLAN_Send:  HMLAN1 S:S8B96405D stat:  00 t:00000000 d:01 r:8B96405D m:CF 8002 23A3F4 3266D4 01011400
2015.10.21 20:08:11.391 0: HMLAN_Parse: HMLAN1 R:R8B96405D stat:0002 t:00000000 d:FF r:7FFF     m:CF 8002 23A3F4 3266D4 01011400

3268B2 ist der normale, 3266D4 ist der mit dem grünen Flackern. Mir fällt da jetzt nichts auf.

Ich hab's jetzt nochmal ausprobiert und komischerweise ist das Geflacker jetzt weg. Sehr seltsam...

Gruß,
   Thorsten

[stromer-12]

Das flackern kommt auch, wenn man Register geändert hat und anschliessend der Melder eine Bewegung erkennt.

Gesendet von meinem GT-I9295

[frank]

wenn es bei dem log geflackert hat, ist es schon seltsam, da ich eine kommunikation erwartet hätte.

rein theoretisch könnte ja auch dein nachbar mit dem bewegungsmelder kommunizieren und bei ungünstigen einstellungen wäre es eventuell nicht im log erkennbar. attack meldungen/readings sind keine da?

[Thorsten Pferdekaemper]

Das flackern kommt auch, wenn man Register geändert hat und anschliessend der Melder eine Bewegung erkennt.

Tja, ich habe nichts geändert. Allerdings stand das Ding auf CMDs_Pending. Kann es sein, dass das CUL_HM-Modul selbständig irgendwas an das Gerät schickt?

wenn es bei dem log geflackert hat, ist es schon seltsam, da ich eine kommunikation erwartet hätte.

Tja, ich bin mir nicht wirklich sicher, ob es da noch geflackert hat. Wahrscheinlich eher nicht.

rein theoretisch könnte ja auch dein nachbar mit dem bewegungsmelder kommunizieren und bei ungünstigen einstellungen wäre es eventuell nicht im log erkennbar. attack meldungen/readings sind keine da?

Nein, ich habe keine solchen Readings gesehen. Bei meiner Nachbarschaft halte ich das auch für etwas unwahrscheinlich. ...aber nicht unmöglich. Allerdings müsste der Nachbar ja dann auch die HMId meines HMLAN kennen, oder? Dazu muss man schonmal den Traffic sniffen können.

Gruß,
   Thorsten

[frank]

Allerdings müsste der Nachbar ja dann auch die HMId meines HMLAN kennen, oder? Dazu muss man schonmal den Traffic sniffen können.

mit deiner hmid wahrscheinlich schon. mit F11234 oder 123ABC könnte das auch mal aus versehen passieren.

[Thorsten Pferdekaemper]

mit deiner hmid wahrscheinlich schon.

...außer einer von Euch wohnt auch hier irgendwo.

[Thorsten Pferdekaemper]

Hi,
ich habe die Frage so ähnlich auch im ELV-Forum gestellt. Dort hat man mir sinngemäß geantwortet, dass das Flackern bedeutet, dass von der Zentrale irgendwelche Daten übertragen werden. Das kann nur erfolgen, wenn man entweder den Anlernknopf drückt oder wenn das Gerät von sich aus sendet.
Jetzt frage ich mich wirklich, was die Zentrale (also FHEM) an das Gerät sendet, ohne dass ich irgendwas mache. Kann es sein, dass das FHEM-Modul so etwas macht?
Gruß,
   Thorsten

[martinp876]

Klar kann fhem senden. Und warum siehst du nicht nach?
Hminfo protevents
Hm sniffen im wiki

Wenn fhem die Daten hat von getconfig sollte Ruhe sein. Sollte es nicht klappen wird fhem wiederholen.in diesem Fall sniffen den Ablauf und poste

[Thorsten Pferdekaemper]

Klar kann fhem senden. Und warum siehst du nicht nach?

Weil der Spuk vorbei ist. Das ganze passiert momentan nicht und ich kann es auch nicht nachstellen.

Wenn fhem die Daten hat von getconfig sollte Ruhe sein.

Ich habe aber kein getconfig angestoßen und auch die letzten paar Monate an dem Teil nichts verändert. Weder an dem Teil selbst noch in FHEM. Im Logfile kann ich auch nichts von einem Stromausfall oder so sehen. Mich interessiert halt, was in FHEM "von sich aus" irgendwas ans Device sendet.
Für Homematic-Wired könnte ich das beantworten, aber nicht für Funk.
Gruß,
   Thorsten

[LuckyDay]

autoReadReg 4_reqStatus

vielleicht liegts auch daran

[Thorsten Pferdekaemper]

vielleicht liegts auch daran

Mmmm... Dann wundere ich mich, warum es nur den einen der beiden betroffen hat und warum ich ansonsten nichts im Logfile sehe. Eigentlich kann ja nur ein Stromausfall zum Re-Read geführt haben. Ich wüsste nicht, was sonst noch gewesen sein könnte. Den Reboot müsste man ja auch sonst im Log sehen.
Gruß,
  Thorsten

[LuckyDay]

'0' autoReadReg wird ignorert.
'1' wird automatisch in getConfig ausgeführt für das Device nach jedem reboot von FHEM.
'2' wie '1' plus nach Power on.
'3' wie '2' plus update wenn auf das Device geschreiben wird.
'4' wie '3' plus fordert Status an, wenn es nicht korrekt erscheint

das autoReadReg hat mir ein zu großes Eigenleben, ich hab das komplett abgeschalten, bei allen Device, vorallem , weil nach jedem reboot von Fhem alles angefordert wird

[martinp876]

, weil nach jedem reboot von Fhem alles angefordert wird

sollte nicht. Status ja, würde ich nie anders machen. Niemand weiss, was in der zwischenzeit passiert ist, daher ein Muss. 
Register nur, wenn sie fehlen. Hierzu auch archConfig und loadConfig beachten. Das deckt einiges ab - wobei das statesave auch schon etliches macht - leider aber beim Absturz versagt (versagen muss)