Hallo Homematic-Fans,
ich habe ein Problem, wo ich eure Unterstützung benötige.
In meiner alten FHEM-Installation hatte einen Keymatic-Schloss (HM-SEC-KEY-S). Irgendwann mal habe ich den Systemwechsel vollzogen, wo ganz viele Geräte rausgeflogen sind unter anderem auch das Schloss. Nun liegt es einsam in der Kiste und ich wollte das Teil verkaufen, allerdings bekomme ich das Teil nicht zurückgesetzt.
Ich habe Testweise einen FHEM auf Raspberry Pi mit Debian Stretch aufgebaut, wo das hmUART-Modul aufgesteckt ist. Ich kriege auch das Schloss gepairt, aber trotz des Setzens des damaligen hmKey-Schlüssels in der VCCU quitiert das Schloss die Übertragung mit:
aesCommToDev fail
Reihenfolge war:
1. VCCU definieren
2. attr hmKey auf den damaligen Wert setzen
3. Keymatic anlernen
4. set Keymatic getConfig
5. attr Keymatic aesCommReq 1
hier ist list vom Schloss:
Internals:
CFGFN
DEF 43B38E
FUUID 5f635062-f33f-80cb-01b4-ba23b499a3959ce8
HmUART_MSGCNT 78
HmUART_RAWMSG 05030027FEA41043B38E06127906010180
HmUART_RSSI -39
HmUART_TIME 2020-09-17 14:32:06
IODev HmUART
LASTInputDev HmUART
MSGCNT 78
NAME HM_43B38E
NOTIFYDEV global
NR 254
STATE MISSING ACK
TYPE CUL_HM
chanNo 01
lastMsg No:FD - t:10 s:43B38E d:061279 0100000000
protCmdDel 4
protLastRcv 2020-09-17 14:19:33
protRcv 35 last_at:2020-09-17 14:19:33
protResnd 3 last_at:2020-09-17 14:16:48
protResndFail 3 last_at:2020-09-17 14:16:53
protSnd 61 last_at:2020-09-17 14:19:33
protSndB 15 last_at:2020-09-17 14:19:31
protState CMDs_done
rssi_HmUART cnt:1 min:-41 max:-41 avg:-41 lst:-41
rssi_at_HmUART cnt:57 min:-41 max:-33 avg:-36.92 lst:-39
Helper:
DBLOG:
D-firmware:
SYS.DBLog:
TIME 1600344162.22464
VALUE 2.5
D-serialNr:
SYS.DBLog:
TIME 1600344162.22464
VALUE MEQ1789469
aesCommToDev:
SYS.DBLog:
TIME 1600345926.31295
VALUE fail
aesKeyNbr:
SYS.DBLog:
TIME 1600345009.52009
VALUE 02
battery:
SYS.DBLog:
TIME 1600344168.83369
VALUE low
cfgState:
SYS.DBLog:
TIME 1600345171.83849
VALUE updating
commState:
SYS.DBLog:
TIME 1600345173.61326
VALUE CMDs_done
direction:
SYS.DBLog:
TIME 1600344168.83369
VALUE none
error:
SYS.DBLog:
TIME 1600344168.83369
VALUE none
lock:
SYS.DBLog:
TIME 1600344168.83369
VALUE locked
state:
SYS.DBLog:
TIME 1600345013.3647
VALUE MISSING ACK
uncertain:
SYS.DBLog:
TIME 1600344168.83369
VALUE no
READINGS:
2020-09-17 14:02:42 D-firmware 2.5
2020-09-17 14:02:42 D-serialNr MEQ1789469
2020-09-17 14:19:32 PairedTo 0x061279
2020-09-17 14:19:32 RegL_00. 00:00 02:01 03:19 0A:06 0B:12 0C:79
2020-09-17 14:19:33 RegL_01. 00:00 14:00 15:64 16:00 17:18 18:0A 19:45 1A:30 1F:00
2020-09-17 14:32:06 aesCommToDev fail
2020-09-17 14:16:49 aesKeyNbr 02
2020-09-17 14:02:48 battery low
2020-09-17 14:19:31 cfgState updating
2020-09-17 14:19:33 commState CMDs_done
2020-09-17 14:02:48 direction none
2020-09-17 14:02:48 error none
2020-09-17 14:02:48 lock locked
2020-09-17 14:02:48 recentStateType info
2020-09-17 14:16:53 state MISSING ACK
2020-09-17 14:02:48 uncertain no
helper:
HM_CMDNR 253
cSnd 0106127943B38E01040000000001,0106127943B38E0103
mId 0026
peerFriend peerSens,peerVirt
peerIDsRaw ,00000000
peerOpt 3:keyMatic
regLst 0,1,3p
rxType 2
supp_Pair_Rep 0
cmds:
TmplKey :no:1600344167.18017
TmplTs 1600344167.18017
cmdKey 1:1:0::HM_43B38E:0026:01:
cmdLst:
assignHmKey noArg
clear [readings|trigger|register|oldRegs|rssi|msgEvents|msgErrors|attack|all]
deviceRename newName
fwUpdate -filename- -bootTime- ...
getConfig noArg
getDevInfo noArg
getRegRaw [List0|List1|List2|List3|List4|List5|List6] ... [-PeerChannel-]
inhibit [on|off]
lock noArg
open [-sec-] ...
peerBulk -peer1,peer2,...- [set|unset]
peerSmart -peerOpt-
press [long|short] -peer- [-repCount(long only)-] [-repDelay-] ...
raw data ...
regBulk -list-.-peerChn- -addr1:data1- -addr2:data2- ...
regSet [prep|exec] -regName- -value- ... [-peerChannel-]
reset noArg
sign [on|off]
statusRequest noArg
tplDel -tplDel-
unlock [-sec-] ...
unpair noArg
lst:
condition slider,0,1,255
peer
peerOpt ,VCCU
tplDel
expert:
def 0
det 0
raw 1
tpl 0
io:
newChn +43B38E,01,00,02
nextSend 1600345926.48058
prefIO
rxt 0
vccu
p:
43B38E
01
00
02
mRssi:
mNo FE
io:
HmUART:
-31
-31
prt:
bErr 0
sProc 0
rspWait:
q:
qReqConf
qReqStat
regCollect:
role:
chn 1
dev 1
prs 1
rpt:
IO HmUART
flg A
ts 1600345173.60724
ack:
HASH(0x4fdbf78)
FD800206127943B38E00
rssi:
HmUART:
avg -41
cnt 1
lst -41
max -41
min -41
at_HmUART:
avg -36.9298245614035
cnt 57
lst -39
max -33
min -41
shadowReg:
tmpl:
role:
Attributes:
IODev HmUART
aesCommReq 1
autoReadReg 4_reqStatus
expert rawReg
firmware 2.5
model HM-SEC-KEY-S
msgRepeat 1
peerIDs 00000000,
serialNr MEQ1789469
subType keyMatic
webCmd lock:inhibit on:inhibit off
geht es überhaupt so? Oder muss ich meine alte Installation irgendwo ausgraben? Und von dort das Teil resetieren
Konnte doch noch ein Backup vom alten System finden. Damit war das Zurücksetzen kein Problem.
Eventuell wäre interessant was an dem Backup jetzt anders war gegenüber deinem ersten Versuch. Eigentlich sah der nicht schlecht aus ;)
Gruß Otto
ZitatEventuell wäre interessant was an dem Backup jetzt anders war gegenüber deinem ersten Versuch. Eigentlich sah der nicht schlecht aus
Der Unterschied ist meiner Meinung nach nur, dass auf dem Backupsystem der Perl-Modul:
libcrypt-rijndael-perl
installiert ist.
Aber den braucht man doch nur für den CUL oder braucht der HmUART das auch?
gab es mehrere keys auf dem alten system?
so, dass die key-nummer anders war für den aktuellen key?
Moin,
ich sag mal - könnte vielleicht sein. Der Rauchmelder braucht das auch - Zitat aus dem 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
In meiner Installation ist das glaube ich per default drin.
Der CUL braucht es generell, da hast Du Recht. Ob andere Geräte als der SD-2 es auch brauchen weiß ich nicht.
Gruß Otto
Zitatgab es mehrere keys auf dem alten system?
so, dass die key-nummer anders war für den aktuellen key?
Nein es gab nur einen neuen Schlüssen. Das Reading
aesKeyNbr 02
war im Backup auch auf 02
Habe noch 2 Handsender zum Zurücksetzen ebenfalls mit AES-Kommunikation. Jetzt könnte man natürlich noch mal ausprobieren.
Zitat von: EinEinfach am 18 September 2020, 09:41:23
Habe noch 2 Handsender zum Zurücksetzen ebenfalls mit AES-Kommunikation. Jetzt könnte man natürlich noch mal ausprobieren.
dann sniffe doch die aktionen.