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
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...
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
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?
schon mal folgendes eingegeben:
list HM_3BAB24
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...
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
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).
gemacht
Jetzt habe ich zum ersten mal R-pairCentralset_0x286508
Warten oder erneut pairen ?
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!
er läuft wieder
Danke; super Hilfe von Dir :)