Problem mit Bewegungsmelder HM-SEC-MDIR-2 [gelöst]

Begonnen von SHOFHEM, 10 April 2021, 19:33:08

Vorheriges Thema - Nächstes Thema

SHOFHEM

Hallo Gemeide,

ich betreibe einen Bewegungsmelder HM-SEC-MDIR-2 als Teil meiner Alarmanlage, ich habe das Register minInterval auf 15 Sekunden gesetzt und so lief er jetzt seit ca. 3 Jahren völlig ohne Probleme. Seit 3 Tagen setzt sich das Register durch ein "PowerOn" (15:22:04) auf den Wert 240s, motionCount beginnt dann auch wieder bei 1. Batterien sind neu. Ist der Melder defekt, oder wer kann PowerOn triggern? Das passiert völlig von selbst! Hatte schon jemand dieses seltsame Phänomen?

Schönes WE da draußen


2021-04-10_15:19:10 Bewegung motion: off
2021-04-10_15:19:10 Bewegung motionDuration: 32
2021-04-10_15:19:10 Bewegung noMotion
2021-04-10_15:19:11 Bewegung battery: ok
2021-04-10_15:19:11 Bewegung brightness: 44
2021-04-10_15:19:11 Bewegung commState: CMDs_done
2021-04-10_15:19:11 Bewegung motion: on (to SCC)
2021-04-10_15:19:11 Bewegung motionCount: 125_next:15s
2021-04-10_15:19:11 Bewegung motion
2021-04-10_15:19:11 Bewegung trigDst_F11234: noConfig
2021-04-10_15:19:11 Bewegung trigger_cnt: 125
2021-04-10_15:19:31 Bewegung motion: off
2021-04-10_15:19:31 Bewegung motionDuration: 20
2021-04-10_15:19:31 Bewegung noMotion
2021-04-10_15:19:31 Bewegung commState: CMDs_pending
2021-04-10_15:19:31 Bewegung set_reset noArg
2021-04-10_15:22:02 Bewegung battery: ok
2021-04-10_15:22:02 Bewegung brightness: 44
2021-04-10_15:22:02 Bewegung commState: CMDs_processing...
2021-04-10_15:22:02 Bewegung motion: on (to SCC)
2021-04-10_15:22:02 Bewegung motionCount: 126_next:15s
2021-04-10_15:22:02 Bewegung motion
2021-04-10_15:22:02 Bewegung trigDst_F11234: noConfig
2021-04-10_15:22:02 Bewegung trigger_cnt: 126
2021-04-10_15:22:02 Bewegung commState: CMDs_done
2021-04-10_15:22:04 Bewegung battery: ok
2021-04-10_15:22:04 Bewegung brightness: 49
2021-04-10_15:22:04 Bewegung powerOn: 2021-04-10 15:22:04
2021-04-10_15:22:04 Bewegung sabotageError: off
2021-04-10_15:22:08 Bewegung battery: ok
2021-04-10_15:22:08 Bewegung brightness: 49
2021-04-10_15:22:08 Bewegung motion: on (to broadcast)
2021-04-10_15:22:08 Bewegung motionCount: 1_next:240s
2021-04-10_15:22:08 Bewegung motion
2021-04-10_15:22:08 Bewegung trigger_cnt: 1

frank

normal sollte der trigger counter mindestens bis 255 zählen, dann geht es wieder von vorne los.

der sensor wurde scheinbar sogar resettet, da die trigger nun an broadcast gesendet werden und nicht mehr an scc.
das pairing ist also auch futsch.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

SHOFHEM

#2
Hallo Frank,

kannst du mir bitte kurz erklären, oder sagen wo ich mir Info holen kann bzgl. dem Thema motion on to broadcast im Vergleich to SCC.
Mein Bewegungsmelder funktioniert völlig normal auch mit "motion to broadcast" und meldet der Alarmanlage brav, wenn sich im Haus etwas unerlaubt bewegt.

Danke schon jetzt

frank

#3
ZitatMein Bewegungsmelder funktioniert völlig normal auch mit "motion to broadcast" und meldet der Alarmanlage brav, wenn sich im Haus etwas unerlaubt bewegt.
warum auch nicht?
mir fehlt der zusammenhang. was willst du damit sagen.

nicht gepairte geräte adressieren die messages an broadcast (alle). gepairte geräte in der regel an ihr "herrchen" (scc) und ggf peers.

wenn sich die adressierung plötzlich ändert (siehe log), gab es vermutlich ein reset. zumal auch counter und konfiguration "futsch" waren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

SHOFHEM

Hallo Frank,
danke für die Antwort. Der Bewegungsmelder spricht also weiter mit meinem FHEM. Denkst du der Melder ist defekt? Ich kann mir nicht erklären woher diese Resets immer herkommen.

frank

ZitatIch kann mir nicht erklären woher diese Resets immer herkommen.
zumindestens hat fhem 2s vor dem reset mit dem sensor erfolgreich kommuniziert.
ich würde mal die rawmessages sniffen, um zu sehen, was da genau passiert. siehe wiki sniffen.

Zitatich betreibe einen Bewegungsmelder HM-SEC-MDIR-2 als Teil meiner Alarmanlage
ein sensor als teil einer alarmanlage, der selbstständige resets macht, würde ich nicht einsetzen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

SHOFHEM

Hallo Frank,

dann kommt gleich ein neuer her. Danke

Gruß S.

frank

Zitatdann kommt gleich ein neuer her.
falls der alte in den müll soll, würde er mich als testobjekt interessieren.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

SHOFHEM

Sobald der neue da ist, und hoffentlich keine Fehler zeigt, können wir gerne darüber reden.


1.fhemtester

Irgendwie sieht das ganze Verhalten nach Factoryreset aus, wodurch auch immer ausgelöst.

Üblicherweise machen HM Geräte ein Reset wenn die Batteriespannung einbricht. Wenn die Batteriespannung danach wieder ausreichend ist und die Firmware das eingebaut hat, wird auch ein ein powerOn Reading geschrieben.

Leider haben aber nicht alle Bewegungsmelder powerOn implementiert.

Ich würd daher vor dem Austausch des Bewegungsmelder die Batterien in Augenschein nehmen und allenfalls die aktuelle Firmware flashen und neu anmelden.


SHOFHEM

Hallo Fhemtester,

danke für deine Rückmeldung ich verwende Firmware 1.6 und finde auch keine neuere Version. Batterien hatte ich schon getauscht, werde es nochmal mit einem neuen Satz probieren!

Gruß S.

1.fhemtester

Möglich wären auch HF-Einstrahlungen durch Sender im Nahbereich. Das kann alles mögliche sein, vom Amateurfunk, DECT-Basisstationen bis zum 5G Ausbau.
Eventuell könnte auch ein starkes Magnetfelder der Verursacher sein. Ein Check ob sich in der Nachbarschaft irgendwas Neues installiert wurde kann nicht schaden.
Grundsätzlich werden solche Umwelteinflüsse beim HW-Design berücksichtigt, lokal können trotzdem Grenzwerte überschritten werden.

Ich habe einen recht alten HM-SEC-MDIR mit Seriennummen GEQxxxx der läuft seit vielen Jahren problemlos.
Vor ca. einem Jahr hatte ich auch einen PowerOn  Eintrag der nicht mit einem Batteriewechsel zu tun hatte. Bei mir blieben aber alle Einstellungen erhalten.

Ich würd jedenfalls die Firmware neu flashen.

SHOFHEM

#12
Hallo 1.fhemtester,

ein Batteriewechsel hat nichts gebracht. Der Reset kam wieder. Kannst du mir bitte sagen wo es die neue Firmware gibt? Ich finde nichts bei EQ3 und im Internet. Der Melder steht neben einem DECT Telefon, hat aber an der Stelle über etliche Jahre gut funktioniert.

Zur Info der Reset kam mit einer Auslösung einer Bewegung.


2021-04-22_13:08:52 Bewegung sabotageError: off
2021-04-22_13:12:33 Bewegung battery: ok
2021-04-22_13:12:33 Bewegung brightness: 63
2021-04-22_13:12:33 Bewegung commState: CMDs_processing...
2021-04-22_13:12:33 Bewegung motion: on (to SCC)
2021-04-22_13:12:33 Bewegung motionCount: 24_next:240s
2021-04-22_13:12:33 Bewegung motion
2021-04-22_13:12:33 Bewegung trigDst_F11234: noConfig
2021-04-22_13:12:33 Bewegung trigger_cnt: 24
2021-04-22_13:12:33 Bewegung commState: CMDs_done
2021-04-22_13:12:35 Bewegung battery: ok
2021-04-22_13:12:35 Bewegung brightness: 65
2021-04-22_13:12:35 Bewegung sabotageError: off
2021-04-22_13:12:37 Bewegung battery: ok
2021-04-22_13:12:37 Bewegung brightness: 62
2021-04-22_13:12:37 Bewegung motion: on (to broadcast)
2021-04-22_13:12:37 Bewegung motionCount: 1_next:240s
2021-04-22_13:12:37 Bewegung motion
2021-04-22_13:12:37 Bewegung trigger_cnt: 1
2021-04-22_13:16:39 Bewegung motion: off
2021-04-22_13:16:39 Bewegung motionDuration: 246
2021-04-22_13:16:39 Bewegung noMotion
2021-04-22_13:21:12 Bewegung battery: ok
2021-04-22_13:21:12 Bewegung brightness: 59
2021-04-22_13:21:12 Bewegung motion: on (to broadcast)
2021-04-22_13:21:12 Bewegung motionCount: 2_next:240s
2021-04-22_13:21:12 Bewegung motion
2021-04-22_13:21:12 Bewegung trigger_cnt: 2
2021-04-22_13:23:16 Bewegung commState: CMDs_pending
2021-04-22_13:23:16 Bewegung set_reset noArg
2021-04-22_13:25:14 Bewegung motion: off
2021-04-22_13:25:14 Bewegung motionDuration: 242
2021-04-22_13:25:14 Bewegung noMotion
2021-04-22_13:40:25 Bewegung battery: ok
2021-04-22_13:40:25 Bewegung brightness: 59

1.fhemtester

Üblicherweise gibt's/gab's Firmwareupdate auf der eq3 Homepage. Da aber mittlerweile Revision 3 des HM-SEC-MDIR vertrieben wird, schaut es schlecht aus. Falls nicht jemand aus dem Forum eine HM-SEC-MDIR-2 Firmware hat, bleibt nur der Weg über ELV.

Das Verhalten ist recht komisch und der reset wird ganz sicher nicht durch einen set Befehl ausgelöst ?

Interessant ist auch
2021-04-10_15:19:11 Bewegung trigDst_F11234: noConfig

Was ist das ? Die HMId der vccu ?

frank

trigDst_F11234: noConfig
F11234 ist die hmid vom scc.
noConfig erscheint, da die hmid unbekannt ist, wegen fehlender vccu.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html