diese Rauchmelder sind einfach zum Verzweifeln!
ich habe folgende Ausstattung: pi + cul, VCCU, virtueller team lead (RM_Team), 4 gepairte und mit RM_Team gepeerte RM. Funktioniert alles!
ich habe damals auch sehr lange gebraucht sie hinzubekommen, leider habe ich das nicht dokumentiert grrr, selber schuld.
jetzt möchte ich weitere 3 in dieser Gruppe integrieren und schaffe nicht einmal ein richtiges pairing.
wie ist eigentlich die richtige Reihenfolge? oder ist das egal?
1. neues RM mit VCCU pairen? (set VCCU hmPairForSec 60 und dann RM_neu im Pairmodus versetzen?
2. wie richtig mit dem RM_Team peeren
nach dem Pairen habe ich entweder der klassische MISSING ACK oder zur Abwechslung RESPONSE TIMEOUT:RegisterRead
R-pairCentral set_0x123456 zeigt dass das paring nicht vollständig ist, beim Pairen wie oben hat der neue RM rot geblinkt.
Auch das Peeren mit einem alten RM aus dem Team führt zur rotes Blinken nach dem Vorgang...
wie soll ich die Sache angehen?
Danke!
Moin,
im Wiki (https://wiki.fhem.de/wiki/HM-SEC-SD_Rauchmelder) steht eigentlich alles drin.
Rauchmelder mit VCCU pairen und danach mit dem Teamleader peeren:
set Rauchmelder_TeamLeader peerChan 0 Rauchmelder_Neu single set actor
Gruß
Zitat von: ramses am 30 Juli 2017, 22:19:30
Auch das Peeren mit einem alten RM aus dem Team führt zur rotes Blinken nach dem Vorgang...
Solange das Pairen nicht geklappt hat, brauchst du auch nicht Peeren.
VCCU in den Anlernmodus und danach den RM nach Anleitung pairen (entsprechend Konfigtaste drücken, bin mir gerade nicht sicher, wie das bei denen war).
Schauen das alle Befehle abgearbeitet wurden und nicht noch Befehle pending sind.
Danach ein getconfig, Configtaste drücken und dann schauen, ob alles geklappt hat.
Zitat von: darkness am 31 Juli 2017, 07:14:10
entsprechend Konfigtaste drücken, bin mir gerade nicht sicher, wie das bei denen war
Die Taste auf dem RM länger drücken bis es anfängt zu blinken.
Kurzes drücken löst nur den Alarm aus ::)
2017-07-31 08:14:03 CUL_HM HM_4B2ABF Activity: alive
2017-07-31 08:14:04 CUL_HM HM_4B2ABF ResndFail
2017-07-31 08:14:04 CUL_HM HM_4B2ABF MISSING ACK
2017-07-31 08:14:10 CUL_HM HM_4B2ABF Activity: alive
2017-07-31 08:14:10 CUL_HM HM_4B2ABF D-firmware: 1.0
2017-07-31 08:14:10 CUL_HM HM_4B2ABF D-serialNr: NEQ000xxxx
2017-07-31 08:14:11 CUL_HM HM_4B2ABF alarmTest: ok
2017-07-31 08:14:11 CUL_HM HM_4B2ABF battery: ok
2017-07-31 08:14:11 CUL_HM HM_4B2ABF level: 0
2017-07-31 08:14:11 CUL_HM HM_4B2ABF smokeChamber: ok
2017-07-31 08:14:11 CUL_HM HM_4B2ABF off
2017-07-31 08:14:11 CUL_HM HM_4B2ABF R-pairCentral: 0x000000
2017-07-31 08:14:11 CUL_HM HM_4B2ABF sdRepeat: off
das kommt beim Pairen raus, inkl. anschließendes (nochmaliges) länger Drücken der Taste, quasi Bestätigung/Abschließen des Pairings.
die LED blinkt rot nach dem Pairen. Vorher wurde der RM zurückgesetzt.
Wurde der RM vorher woanders eingesetzt?
Ansonsten noch mal nach Anleitung zurücksetzen und in FHEM löschen.
Danach das übliche
set VCCU hmPairForSec 60
und die RM-Taste länger drücken bis es anfängt orange zu blinken.
Danach sollte es kurz grün leuchten...
Kannst du noch mal ein List auf den RM machen.
die "alten" RM laufen ohne Probleme? Ich kenne mich allerdings nicht mit der Kombination Pi + CUL aus.
Zitat von: pataya am 31 Juli 2017, 08:23:39
Wurde der RM vorher woanders eingesetzt?
Ansonsten noch mal nach Anleitung zurücksetzen und in FHEM löschen.
Danach das übliche
set VCCU hmPairForSec 60
und die RM-Taste länger drücken bis es anfängt orange zu blinken.
Danach sollte es kurz grün leuchten...
die 3 neuen sind wirklich neu, außerdem habe ich sie mehrmals zurückgesetzt (länger drauf bleiben bis orange blinkt, weiter drauf bleiben bis rot blinkt, loslassen, RM rebootet)
genauso habe ich pairing auf der VCCU Seite angestoßen, dann am RM drauf gedrückt bis orange blinkt, losgelassen => leuchtet ca 2 Sek rot (also nicht erfolgreich)
Zitat von: darkness am 31 Juli 2017, 08:24:52
Kannst du noch mal ein List auf den RM machen.
die "alten" RM laufen ohne Probleme? Ich kenne mich allerdings nicht mit der Kombination Pi + CUL aus.
die "alten" funktionieren ohne Probleme.
Internals:
CFGFN
CUL1_MSGCNT 6
CUL1_RAWMSG A0EADA0104B2ABF1234560100000000::-40:CUL1
CUL1_RSSI -40
CUL1_TIME 2017-07-31 08:14:12
DEF 4B2ABF
IODev CUL1
LASTInputDev CUL1
MSGCNT 6
NAME HM_4B2ABF
NOTIFYDEV global
NR 949
STATE off
TYPE CUL_HM
lastMsg No:AD - t:10 s:4B2ABF d:123456 0100000000
protCmdDel 2
protLastRcv 2017-07-31 08:14:11
protResnd 1 last_at:2017-07-31 08:14:00
protResndFail 1 last_at:2017-07-31 08:14:04
protSnd 9 last_at:2017-07-31 08:14:12
protState CMDs_done
rssi_CUL1 lst:-29 min:-29 cnt:1 max:-29 avg:-29
rssi_at_CUL1 avg:-41 min:-42 cnt:6 max:-40 lst:-40
Helper:
DBLOG:
Activity:
DBLogging:
TIME 1501481650.84167
VALUE alive
D-firmware:
DBLogging:
TIME 1501481650.84167
VALUE 1.0
D-serialNr:
DBLogging:
TIME 1501481650.84167
VALUE NEQ000xxxx
R-pairCentral:
DBLogging:
TIME 1501481651.74151
VALUE 0x000000
aesKeyNbr:
DBLogging:
TIME 1501481638.46388
VALUE 00
alarmTest:
DBLogging:
TIME 1501481651.44899
VALUE ok
battery:
DBLogging:
TIME 1501481651.44899
VALUE ok
level:
DBLogging:
TIME 1501481651.44899
VALUE 0
sdRepeat:
DBLogging:
TIME 1501481651.74151
VALUE off
smokeChamber:
DBLogging:
TIME 1501481651.44899
VALUE ok
state:
DBLogging:
TIME 1501481651.44899
VALUE off
READINGS:
2017-07-31 08:14:10 Activity alive
2017-07-31 08:14:10 D-firmware 1.0
2017-07-31 08:14:10 D-serialNr NEQ000xxxx
2017-07-31 08:14:11 PairedTo set_0x123456
2017-07-31 08:14:11 R-pairCentral 0x000000
2017-07-31 08:14:11 RegL_00. 02:00 0A:00 0B:00 0C:00 16:00 1F:00 00:00
2017-07-31 08:13:58 aesKeyNbr 00
2017-07-31 08:14:11 alarmTest ok
2017-07-31 08:14:11 battery ok
2017-07-31 08:14:11 level 0
2017-07-31 08:14:11 recentStateType info
2017-07-31 08:14:11 sdRepeat off
2017-07-31 08:14:11 smokeChamber ok
2017-07-31 08:14:11 state off
helper:
HM_CMDNR 173
cSnd 011234564B2ABF00040000000000,011234564B2ABF0103
mId 00AA
peerIDsRaw ,00000000
rxType 6
supp_Pair_Rep 0
expert:
def 1
det 0
raw 1
tpl 0
io:
newChn +4B2ABF,00,00,00
nextSend 1501481652.01861
prefIO
rxt 0
vccu
p:
4B2ABF
00
00
00
mRssi:
mNo AD
io:
CUL1 -38
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
role:
chn 1
dev 1
rpt:
IO CUL1
flg A
ts 1501481651.92214
ack:
HASH(0x22d7668)
AD80021234564B2ABF00
rssi:
CUL1:
avg -29
cnt 1
lst -29
max -29
min -29
at_CUL1:
avg -41
cnt 6
lst -40
max -40
min -42
shadowReg:
tmpl:
Attributes:
IODev CUL1
IOgrp VCCU:CUL1
actCycle 099:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_raw
firmware 1.0
model HM-SEC-SD-2
msgRepeat 1
peerIDs 00000000,
room CUL_HM
serialNr NEQ000xxxx
subType smokeDetector
webCmd statusRequest log Auszug beim letzten Pairing
2017.07.31 08:13:46 3: CUL_HM set VCCU hmPairForSec 60
2017.07.31 08:13:58 2: CUL_HM Unknown device HM_4B2ABF is now defined
2017.07.31 08:13:58 2: autocreate: define HM_4B2ABF CUL_HM 4B2ABF
2017.07.31 08:13:58 2: autocreate: define FileLog_HM_4B2ABF FileLog ./log/HM_4B2ABF-%Y.log HM_4B2ABF
2017.07.31 08:13:58 3: Device HM_4B2ABF added to ActionDetector with 099:00 time
2017.07.31 08:13:58 3: CUL_HM pair: HM_4B2ABF smokeDetector, model HM-SEC-SD-2 serialNr
2017.07.31 08:13:58 1: CUL_HM HM_4B2ABF need Crypt::Rijndael to answer signing request with CUL
2017.07.31 08:14:03 3: Device HM_4B2ABF added to ActionDetector with 099:00 time
2017.07.31 08:14:10 3: Device HM_4B2ABF added to ActionDetector with 099:00 time
2017.07.31 08:14:10 3: CUL_HM set HM_4B2ABF statusRequest
2017.07.31 08:14:10 3: CUL_HM set HM_4B2ABF getConfigich sehe dass, das Signal sehr stark ist, kann sein, dass der Empfänger im RM übersteuert ist? bin aber 3m weg vom CUL
hm, hast du am Ende des Pairing noch mal ein get config gemacht?
getConfig nicht, aber nochmals in den Pairing mode auf der RM Seite. In dem Moment wird beim R-pairCentral aus set_0x123456 => 0x000000, somit nicht richtig gepairt.
ist das Gleiche wie getConfig, oder?
Nein, ist es nicht. Daher hatte ich es eingangs erwähnt...
2017.07.31 08:13:58 1: CUL_HM HM_4B2ABF need Crypt::Rijndael to answer signing request with CUL
einfach das tun, was da steht. das ist ein perl modul.
Nochmal der Hinweis auf das schon genannte Wiki
ZitatDer HM-SEC-SD-2 Rauchmelder arbeitet mit aesCBC, er benötigt dafür zwingend das Modul libcrypt-rijndael-perl unabhängig vom IO Device, auch für den HM-CFG-LAN!
;D
Gruß Otto
also tatsächlich hat das Modul libcrypt-rijndael-perl gefehlt!!!
wie geht das denn? wie haben dann die anderen RMs funktioniert?
ich verstehe es einfach nicht...
trotzdem vielen Dank fürs Geduld! ;-)
Handelt es sich bei deinen alten RM um die erste Generation?
Die benötigen das Modul nämlich nicht.