[erledigt]HM-Sen-MDIR-O-2 nach Batteriewechsel keine Verbindung zu FHEM

Begonnen von jove01, 28 August 2018, 12:46:38

Vorheriges Thema - Nächstes Thema

jove01

Hallo zusammen

mein HM-Sen-MDIR-O-2 war gestern abend ausfgefallen, meine Annahme: die Batterien. Doch selbst nach dem Wechsel der Batterien konnte ich ihn nicht neu pairen. Diverse Versuche mit Reset und der Werkswiederherstellung am BW führten nicht zu einer neuen Verbindung. Danach habe ich das Device in FHEM gelöscht, nochmals ein Werksreset, aber auch kein Erfolg. Jetzt bekomme ich den BW trotz autocreate auch nicht mehr angelegt.

Das Anlernen mittels Anlerntaste und VCCU endet übrigens immer mit dem roten LED, als ob der Bewegungsmelder noch irgendwo gepairt wäre; ist er aber nicht-

Hier ein Zwischenstand des List des Devices
Internals:
   DEF        3BAB24
   HMLAN01_MSGCNT 2
   HMLAN01_RAWMSG E3BAB24,0000,9C293340,FF,FFC7,14A6413BAB24286508010DA570
   HMLAN01_RSSI -57
   HMLAN01_TIME 2018-08-28 10:40:32
   IODev      HMLAN01
   LASTInputDev HMLAN01
   MSGCNT     2
   NAME       HM_Bewm_Eingang
   NOTIFYDEV  global
   NR         693
   NTFY_ORDER 50-HM_Bewm_Eingang
   STATE      noMotion
   TYPE       CUL_HM
   lastMsg    No:14 - t:41 s:3BAB24 d:286508 010DA570
   protCmdPend 1 CMDs_pending
   protLastRcv 2018-08-28 10:40:32
   protRcv    1 last_at:2018-08-28 10:40:32
   protSnd    1 last_at:2018-08-28 10:40:32
   protState  CMDs_pending
   rssi_at_HMLAN01 cnt:2 min:-57 max:-53 avg:-55 lst:-57
   Helper:
     DBLOG:
       brightness:
         myDbLog:
           TIME       1535445632.81614
           VALUE      165
       motion:
         myDbLog:
           TIME       1535445754.66616
           VALUE      off
   READINGS:
     2018-08-28 10:30:17   Activity        dead
     2018-08-28 09:47:16   D-firmware      1.6
     2018-08-28 09:47:16   D-serialNr      MEQ0394616
     2018-08-28 10:40:32   battery         ok
     2018-08-28 10:40:32   brightness      165
     2018-08-28 10:17:45   cover           closed
     2018-08-28 10:42:34   motion          off
     2018-08-28 10:40:32   motionCount     13_next:120s
     2018-08-28 10:42:34   motionDuration  122
     2018-08-28 10:17:45   recentStateType info
     2018-08-28 10:42:34   state           noMotion
     2018-08-28 10:40:32   trigger_cnt     13
   cmdStack:
     ++A0112865083BAB240400
   helper:
     HM_CMDNR   20
     cfgChkResult No regs found for:HM_Bewm_Eingang


     getCfgList all
     getCfgListNo ,4
     mId        00C1
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3BAB24,02,00,00
       nextSend   1535445632.6286
       rxt        2
       vccu       vccu
       p:
         3BAB24
         00
         00
         00
       prefIO:
         HMLAN01
     mRssi:
       mNo        14
       io:
         HMLAN01:
           -51
           -51
     prt:
       bErr       0
       sProc      2
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rpt:
       IO         HMLAN01
       flg        A
       ts         1535445632.5411
       ack:
         HASH(0x2c55278)
         1480022865083BAB240101A500
     rssi:
       at_HMLAN01:
         avg        -55
         cnt        2
         lst        -57
         max        -53
         min        -57
     tmpl:
   nb:
     cnt        2
Attributes:
   DbLogExclude .*
   DbLogInclude brightness,motion
   IODev      HMLAN01
   IOgrp      vccu:HMLAN01
   actCycle   000:10
   actStatus  dead
   alias      Bewegungsm. Eingang
   autoReadReg 4_reqStatus
   event-on-change-reading brightness,motion,battery
   expert     2_full
   firmware   1.6
   group      Statusinformationen
   model      HM-Sen-MDIR-O-2
   peerIDs    00000000,
   room       02 Devices,07 LichtSteuerung,07 RolloSteuerung,Eingang
   serialNr   MEQ0394616
   showtime   1
   subType    motionDetector


Für jede Hilfe bin ich dankbar, da der Bewegungsmelder Licht und Rollladen steuert.

Jürgen

Aktuelles FHEM auf Raspi 3 und dbLog
CUL 433
HMLan Rolladensteuerung

Beta-User

Vorab: Kannst du mir erklären, warum du ein neues Pairing machst, nur weil die Batterien gewechselt wurden?

So wie ich das list verstehe, gibt es den Sensor weiterhin (wieder) in FHEM, soweit also alles ok. Es hat auch ziemlich sicher keinen Werksreset gegeben, das Teil kennt mindestens einen Peer, vermutlich die VCCU (die müßte noch als IOGrp-Attribut zum Sensor), für die ich als HmID auf 286508 tippen würde.

Setze also als erstes mal die IOGrp und lösche die Sende-Queue (set ... clear ...) ;) .
Ansonsten ist das Teil das zickigste HM-Device, das ich kenne...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

jove01

Hallo Bet-User, danke für die schnelle Antwort.

Wie ich geschrieben habe, stammt das List von einem Zwischenstand. Danach habe ich das Device gelöscht und demzufolge gibt es es nicht mehr im Fhem.

Ich ging auch davon aus, das für den Batteriewechsel kein neues Pairen erforderlich sei. Aber da keine Infos über Bewegungen ankamen, habe ich zuerst ein getconfig gemacht. Ergebiss waren 3 Commands depending. Erst dann habe ich, versucht neu zu pairen

Jürgen
Aktuelles FHEM auf Raspi 3 und dbLog
CUL 433
HMLan Rolladensteuerung

darkness

#3
Hallo,

Wenn du es jetzt in FHEM gelöscht hast, würde ich ein Werksreset im Device machen. Danach entsprechend neu anlernen und den Anlernvorgang im Eventlog verfolgen und das Ergebnis ggf. hier posten.

Commands pendig kann mehrere Ursachen haben. Z.b. sendet der Bewegungsmelder ja nicht sofort sondern meldet sich zyklich und verarbeitet dann die Befehle --> lazyConfig nennt sich das glaube ich.
Manchmal reicht es auch, den Configknopf kurz zu drücken und so die Übertragung anzustoßen.

Gruß

@Beta-User

Im List fehlt doch ein PairedTo, oder?

frank

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

Beta-User

Zitat von: frank am 28 August 2018, 13:39:05
schon mal folgendes eingegeben:
list HM_3BAB24
+1

Ach so war das mit "Zwischenstand" gemeint... Hatte das so verstanden, dass du wieder bis zu diesem Stand gekommen bist, aber nicht weiter...
Halten wir fest: um 10:xx Uhr gab es Funkverkehr zwischen dem Teil und FHEM.

Lege das Device daher einfach manuell wieder an, wenn das List ein negatives Ergebnis liefern sollte; die erforderlichen Infos stehen ja in dem List (oder einer Vorversion deiner config, die du ja irgendwo gesichert hattest! Ggf. die VCCU-Angabe ergänzen.). Am besten mit RAW-Import, da geht es alles auf einen Rutsch.

Dann solltest du warten, ob und was an wen gesendet wird, um zu sehen, ob der Reset geklappt hat. Bis auf weiteres solltest du auch erst mal nicht versuchen, irgendwas an das Teil zu senden, also insbesondere _kein_ getConfig auslösen.
Gibt es dann Nachrichten, die an eine bestimmte Adresse gehen, die nicht broadcast ist ("d:000000"), gibt es noch ein Pairing bzw. Peerings - das Teil ist wie gesagt zickig, schlecht zu pairen und und gibt seinen wahren Status ungern preis, diese Übung hatte ich auch mal >:( .

Deswegen würde ich von einem Reset auch (zumindest vorerst) dringend abraten! Entweder die Angaben sind derzeit noch vorhanden, konnten aber noch nicht abgerufen werden, oder es ist bereits erledigt mit dem Reset, dann muß sowieso "nur" neu gepairt werden...
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

jove01

Danke für die ausführliche Antwort

Habe das Device über Raw wieder angelegt und sieht fast gut aus. Es reagiert sehr träge (hängt immer wieder bei "on (to broadcast)"). Aber es fehlt
ZitatPairedTo
, obwohl es beider VCCU über getDevice angezeigt wird.



Internals:
   CFGFN     
   DEF        3BAB24
   HMLAN01_MSGCNT 5
   HMLAN01_RAWMSG E3BAB24,0000,9D55E44E,FF,FFC6,0684413BAB240000000106AA80
   HMLAN01_RSSI -58
   HMLAN01_TIME 2018-08-28 16:08:55
   IODev      HMLAN01
   LASTInputDev HMLAN01
   MSGCNT     5
   NAME       HM_Bewm_Eingang
   NOTIFYDEV  global
   NR         3837
   STATE      motion
   TYPE       CUL_HM
   lastMsg    No:06 - t:41 s:3BAB24 d:000000 0106AA80
   protLastRcv 2018-08-28 16:08:55
   protRcv    5 last_at:2018-08-28 16:08:55
   rssi_at_HMLAN01 cnt:5 min:-66 max:-53 avg:-57.8 lst:-58
   Helper:
     DBLOG:
       brightness:
         myDbLog:
           TIME       1535464247.35331
           VALUE      170
       motion:
         myDbLog:
           TIME       1535465335.53305
           VALUE      on (to broadcast)
   READINGS:
     2018-08-28 15:57:39   Activity        alive
     2018-08-28 15:47:39   D-firmware      1.6
     2018-08-28 15:47:39   D-serialNr      MEQ0394616
     2018-08-28 16:08:55   battery         ok
     2018-08-28 16:08:55   brightness      170
     2018-08-28 16:08:55   motion          on (to broadcast)
     2018-08-28 16:08:55   motionCount     6_next:240s
     2018-08-28 16:07:27   motionDuration  242
     2018-08-28 16:08:55   state           motion
     2018-08-28 16:08:55   trigger_cnt     6
   helper:
     HM_CMDNR   6
     PONtest    1
     mId        00C1
     moStart    1535465335.40766
     regLst     ,0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +3BAB24,00,00,00
       nextSend   1535465335.49615
       rxt        2
       vccu       vccu
       p:
         3BAB24
         00
         00
         00
       prefIO:
         HMLAN01
     mRssi:
       mNo        06
       io:
         HMLAN01:
           -52
           -52
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_HMLAN01:
         avg        -57.8
         cnt        5
         lst        -58
         max        -53
         min        -66
     tmpl:
Attributes:
   DbLogExclude .*
   DbLogInclude brightness,motion
   IODev      HMLAN01
   IOgrp      vccu:HMLAN01
   actCycle   000:10
   actStatus  alive
   alias      Bewegungsm. Eingang
   autoReadReg 4_reqStatus
   event-on-change-reading brightness,motion,battery
   expert     2_full
   firmware   1.6
   group      Statusinformationen
   model      HM-Sen-MDIR-O-2
   peerIDs    00000000,
   room       02 Devices,07 LichtSteuerung,07 RolloSteuerung,Eingang
   serialNr   MEQ0394616
   showtime   1
   subType    motionDetector
Aktuelles FHEM auf Raspi 3 und dbLog
CUL 433
HMLan Rolladensteuerung

Beta-User

Zitat von: Beta-User am 28 August 2018, 13:48:00
Gibt es dann Nachrichten, die an eine bestimmte Adresse gehen, die nicht broadcast ist ("d:000000"), gibt es noch ein Pairing

Gibt es scheinbar nicht, also muß tatsächlich neu gepairt werden.

Würde daher jetzt tatsächlich die VCCU in "pairForSec" versetzen und den Knopf am MDIR-O drücken. Dann _WARTEN_....Kann gut sein, dass es mehrere Zyklen dauert, bis alles sauber abgearbeitet ist, also erst mal kein "getConfig" oder so (wird sowieso automatisch ausgelöst).

Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

jove01

gemacht
Jetzt habe ich zum ersten mal R-pairCentralset_0x286508

Warten oder erneut pairen ?
Aktuelles FHEM auf Raspi 3 und dbLog
CUL 433
HMLan Rolladensteuerung

Beta-User

Zitat von: Beta-User am 28 August 2018, 16:22:17
Dann _WARTEN_....
Nach Möglichkeit, bis keine cmd's mehr pending sind (sollte doch was zu sehen sein, oder?). Eventuell kannst du das Beschleunigen, indem du den Knopf drückst. Kann aber auch kontraproduktiv sein, daher am besten bitte erst mal Geduld...

Zumindest aber: Keine weiteren Befehle von FHEM aus!
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: ZigBee2mqtt, MiLight@ESP-GW, BT@OpenMQTTGw | ZWave | SIGNALduino | MapleCUN | RHASSPY
svn: u.a Weekday-&RandomTimer, Twilight,  div. attrTemplate-files, MySensors

jove01

Aktuelles FHEM auf Raspi 3 und dbLog
CUL 433
HMLan Rolladensteuerung