Hallo,
nachdem ich gelesen hatte, dass AES jetzt auch mit CUL geht, habe ich versucht meinen HM-Sec-SC mit dem CUL zu verbinden. Pairing hat auf Anhieb geklappt. Folgendes habe ich dann nach vielem Lesen im Forum gemacht:
- Modul libcrypt-rijndael-perl auf dem Raspi installiert.
- vccu mit der selben hmid wie beim CUL_0 definiert
define vccu CUL_HM 31AE26
attr vccu IODev CUL_0
attr vccu autoReadReg 4_reqStatus
attr vccu expert 2_full
attr vccu model CCU-FHEM
attr vccu room CUL_HM
attr vccu subType virtual
attr vccu webCmd virtual:updateIm device HM-Sec-SC die vccu definiert:
define EG_TuerFens_SchiebeHebe CUL_HM 22542F
attr EG_TuerFens_SchiebeHebe IODev CUL_0
attr EG_TuerFens_SchiebeHebe IOgrp vccu
attr EG_TuerFens_SchiebeHebe aesCommReq 1
attr EG_TuerFens_SchiebeHebe autoReadReg 4_reqStatus
attr EG_TuerFens_SchiebeHebe expert 2_full
attr EG_TuerFens_SchiebeHebe room CUL_HMKonnte allerdings nie die register nicht auslesen. Das steht im logfile::
Zitat2015-09-27_19:19:00 EG_TuerFens_SchiebeHebe ResndFail
2015-09-27_19:19:00 EG_TuerFens_SchiebeHebe RESPONSE TIMEOUT:RegisterRead
Dann habe ich gelesen
Zitathttp://www.fhemwiki.de/wiki/AES_Encryption
, dass ich den AES-Schlüssel definieren und eingeben muss. Einen Schlüssel festgelegt und per
attr vccu hmkey xxxxx eingegeben. Daraufhin hat sich FHEM sofort verabschiedet und war erst nach einem reboot des Raspi wieder ansprechbar. Der key war nicht eingetragen. Der Absturz ist reproduzierbar. Das steht immer im logfile:
Zitat2015.09.27 19:19:44 4: CUL_Parse: CUL_0 A 14 D3 A270 EF38E0 31AE26 00DD2825DF000000A209C422 -57
2015.09.27 19:19:44 4: CUL_send: CUL_0As 0A D3 8002 31AE26 EF38E0 00
Undefined subroutine &main::md5 called at ./FHEM/10_CUL_HM.pm line 839.
2015.09.27 19:21:01 2: Perfmon: ready to watch out for delays greater than one second
2015.09.27 19:21:01 1: Including fhem.cfg
Hat jemand eine Idee, woran das liegen kann?
Grüße Jürgen
Generiere mal den md5 Hash manuell und trage ihn da ein...
Hallo Virsacer,
jetzt muss ich gestehen dass ich noch nie etwas von einem md5 hash gehört habe. Hast Du mir einen Link oder Hinweis wo ich nachlesen kann wie ich den denn generieren oder herausfinde sowie wie und wo ich den eingeben soll?
Hatte den Schlüssel über einen codegenerator im Netz erzeugt und dann (Buchstaben- und Zahlenkombination ohne Sonderzeichen) als key eingetragen. Evtl. liegt da der Fehler.
Gruß Jürgen
Schau mal hier: http://www.md5generator.de
Einfach das Ergebnis anstelle deines Keys bei "attr vccu hmkey" verwenden - fhem sollte erkennen, dass er bereits gehasht ist und den Schritt überspringen...
Wenn du Details wissen willst, hilft Wikipedia weiter: https://de.wikipedia.org/wiki/Message-Digest_Algorithm_5
Hallo Virsacer,
hat geklappt. Besten Dank.
Aber ich muss schon sagen, dass FHEM für jemand der aus der Windows-Welt kommt und sich nur in der Freizeit damit beschäftigt, echt kompliziert ist. Da spielen so viele verschiedene Dinge hinein (Internetzugriff, Programmierung, Reverse proxy server, Raspi mit Linux...), dass es sehr schwierig ist, ohne Hilfe voranzukommen. Deswegen ein Dank an alle Helfer im Forum, die ihre Zeit investieren, um Beginnern wie mir zu helfen.
So wie ich es verstanden habe, muss ich jetzt den Code an die Device übertragen. Mal sehen,ob das klappt und ich meinen Fensterkontakt doch noch auslesen kann.
Ergänzung:
Habe versucht, mit
set EG_TuerFens_SchiebeHebe assignHmKey den code an das device zu senden, bekomme aber die Fehlermeldugn:
ZitatassignHmKey requires VCCU with hmKeys
Das bedeutet doch, das das device die VCCU nicht findet. Im List ist aber zu erkennen, dass sie als IOgrp angegeben ist, oder muss sie als IODev angegeben sein?
List des Device:
Internals:
DEF 22542F
IODev CUL_0
NAME EG_TuerFens_SchiebeHebe
NR 580
STATE RESPONSE TIMEOUT:RegisterRead
TYPE CUL_HM
Readings:
2015-09-27 19:08:57 RegL_00: 0
2015-09-27 21:03:20 aesCommToDev ok
2015-09-27 21:03:20 recentStateType info
2015-09-27 18:48:53 state RESPONSE TIMEOUT:RegisterRead
2015-09-27 21:03:15 trig_aes_vccu ok:57
2015-09-27 21:03:15 trigger_cnt 57
Helper:
HM_CMDNR 1
Io:
newChn +22542F,01,00,02
rxt 0
vccu VCCU
p:
22542F
01
00
02
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Role:
Attributes:
IODev CUL_0
IOgrp VCCU
aesCommReq 1
autoReadReg 4_reqStatus
expert 2_full
room CUL_HM Kann hier jemand helfen?
Gruß Jürgen
Hallo,
Zitat von: bmwfan am 28 September 2015, 19:55:37
Das bedeutet doch, das das device die VCCU nicht findet. Im List ist aber zu erkennen, dass sie als IOgrp angegeben ist, oder muss sie als IODev angegeben sein?
Das bedeutet eigentlich, dass Dein IO keiner VCCU zugewiesen ist, die mehr als den Defaultkey kennt.
Hat Dein CUL_0 ein Internal owner_CCU? Das sollte eigentlich durch die VCCU gesetzt werden. Und an dieser dort eingetragenen ccu müsstest Du das hmKey-Attribut setzen.
fhem> list HMCFGUSB
Internals:
DEF 127.0.0.1:1234
...
owner_CCU VCCU
...
fhem> list VCCU
...
Attributes:
IODev HMCFGUSB
IOList HMCFGUSB
hmKey 01:...
...
Viele Grüße
Michael
Hallo Michael,
den Eintrag owner_ccu habe ich nicht. Anbei das List:
Internals:
CMDS BbCFiA....
CUL_0_MSGCNT 2913
CUL_0_TIME 2015-09-29 21:08:44
Clients :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
DEF /dev/ttyACM0@9600 1034
DeviceName /dev/ttyACM0@9600
FD 12
FHTID 1034
NAME CUL_0
NR 65
PARTIAL
RAWMSG A1440845E2A8260000000848BC700000500000948FCEC
RSSI -84
STATE Initialized
TYPE CUL
VERSION V 1.65 CUL868
initString X21
Ar
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
D:CUL_IR ^I............
H:STACKABLE_CC ^\*
Readings:
2015-09-28 20:06:30 cmds B b C F i A .....
2015-09-29 21:08:44 state Initialized
Helper:
182aaa:
QUEUE:
22542f:
QUEUE:
257247:
QUEUE:
27238a:
QUEUE:
2a8260:
QUEUE:
316c1f:
QUEUE:
35c7f4:
QUEUE:
Ef38e0:
QUEUE:
Attributes:
hmId 31AE26
model CUL
rfmode HomeMatic
verbose 4
Und das list des VCCU:
Internals:
DEF 31AE26
IODev CUL_0
NAME VCCU
NR 577
STATE CUL_0:UAS,
TYPE CUL_HM
assignedIOs CUL_0
Readings:
2015-09-28 20:06:37 state CUL_0:UAS,
Helper:
HM_CMDNR 1
mId FFF0
rxType 1
Io:
prefIO
vccu
ioList:
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Attributes:
IODev CUL_0
autoReadReg 4_reqStatus
expert 2_full
hmKey 01:........
model CCU-FHEM
room CUL_HM
subType virtual
webCmd virtual:update
Woran kann es denn noch liegen?
Gruß Jürgen
Hallo Michael,
habe jetzt an der VCCU den CUL_0 mit attr IOList CUL_0 eingetragen. Jetzt erscheint tatsächlich bei einem list CUL_0 folgender Eintrag STATE Initialized
TYPE CUL
VERSION V 1.65 CUL868
initString X21
Ar
owner_CCU VCCU
Matchlist:
1:CUL_HM ^A....................
8:HMS ^810e04....(1|5|9).a001
Bei einem set EG_TuerFens_SchiebeHebe assignhmkey erhalte ich jedoch die Meldung MISSING ACK Internals
DEF 22542F
IODev CUL_0
NAME EG_TuerFens_SchiebeHebe
NR 580
STATE MISSING ACK
TYPE CUL_HM
protCmdDel 3
protCmdPend 1CMDs pending
protResnd 6 last_at:2015-09-29 22:30:51
protResndFail 2 last_at:2015-09-29 22:30:56
protSnd 3 last_at:2015-09-29 22:36:53
protState CMDs_processing...
Readings
RegL_00:
aesCommToDev ok 2015-09-27 21:03:20
recentStateType info 2015-09-27 21:03:20
state MISSING ACK 2015-09-29 22:37:11
trig_aes_vccu ok:57 2015-09-27 21:03:15
trigger_cnt 57 2015-09-27 21:03:15
Das bedeutet doch, dass der Status nicht zurückgemeldet wird, da sich das device nicht rückmeldet. Also steht die Kommunikation nicht.
Was kann ich noch tun?
Gruß Jürgen
Hallo,
weils ichs gerade sehe:
Schmeiss das aesCommReq erstmal aus dem Gerät raus, das kann erst funktionieren, wenn das Gerät wirklich den Schlüssel kennt. Davor unterbindet es eine erfolgreiche Kommunikation (Fhem will alles mit dem dem Gerät unbekannten Schlüssel signiert haben).
Ausserdem fehlen Attribute wie "model". Hat das initiale Pairing geklappt?
Viele Grüße
Michael
Kam nicht weiter und hab das device in FHEM komlett gelöscht und auf Werkseinstellungen gesetzt. Dann versucht zu pairen. Hier das List danach:
Internals:
CFGFN
CUL_0_MSGCNT 4
CUL_0_RAWMSG A0A06800222542F31AE2600::-75:CUL_0
CUL_0_RSSI -75
CUL_0_TIME 2015-10-03 10:25:02
DEF 22542F
IODev CUL_0
LASTInputDev CUL_0
MSGCNT 4
NAME HM_22542F
NR 591
STATE ???
TYPE CUL_HM
lastMsg No:06 - t:02 s:22542F d:31AE26 00
protCmdPend 3 CMDs_pending
protLastRcv 2015-10-03 10:25:02
protSnd 3 last_at:2015-10-03 10:25:02
protState CMDs_pending
rssi_at_CUL_0 avg:-70.87 min:-75 max:-69 lst:-75 cnt:4
Readings:
2015-10-03 10:25:07 Activity alive
2015-10-03 10:25:02 CommandAccepted yes
2015-10-03 10:25:02 D-firmware 2.1
2015-10-03 10:25:02 D-serialNr KEQ0366855
2015-10-03 10:25:02 R-pairCentral set_0x31AE26
cmdStack:
++A00131AE2622542F00040000000000
++A00131AE2622542F01040000000001
++A00131AE2622542F0103
Helper:
HM_CMDNR 6
cSnd 0131AE2622542F000802010A310BAE0C26,0131AE2622542F0006
getCfgList all
getCfgListNo ,4
mId 002F
rxType 4
Io:
newChn +22542F,00,01,00
nextSend 1443860703.02137
prefIO
rxt 0
vccu
p:
22542F
00
01
00
Mrssi:
mNo 06
Io:
CUL_0 -73
Prt:
bErr 0
sProc 2
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rssi:
At_cul_0:
avg -70.875
cnt 4
lst -75
max -69
min -75
Shadowreg:
RegL_00: 02:01 0A:31 0B:AE 0C:26
Attributes:
IODev CUL_0
IOgrp VCCU:CUL_0
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 2.1
model HM-SEC-SC
room CUL_HM
serialNr KEQ0366855
subType threeStateSensor
Ich vermute aber, dass es nicht geklappt hat da bei R-pairCentral ein "set_0x31AE26" und nicht nur "0x31AE26" steht. Ich kann auch seit dem Pairingversuch keine Daten auslesen. Der Zeitstempel bleibt unverändert.
Auch meine weiteren Versuche mit set <device> regSet pairCentral 0x31AE26 blieben erfolglos. Lediglich die pending register (?) erhöhen sich. Ich vermute, dass dies Befehle in der Warteschleife sind, die auf Grund fehlender Verbindung zum device nicht abgearbeitet werden können.
lastMsg No:06 - t:02 s:22542F d:31AE26 00
protCmdPend 14 CMDs_pending
protLastRcv 2015-10-03 10:25:02
protSnd 3 last_at:2015-10-03 10:25:02
protState CMDs_pending
rssi_at_CUL_0 avg:-70.87 min:-75 max:-69 lst:-75 cnt:4
Readings:
2015-10-03 10:25:07 Activity alive
2015-10-03 10:25:02 CommandAccepted yes
2015-10-03 10:25:02 D-firmware 2.1
2015-10-03 10:25:02 D-serialNr KEQ0366855
2015-10-03 10:25:02 R-pairCentral set_0x31AE26
cmdStack:
++A00131AE2622542F00040000000000
++A00131AE2622542F01040000000001
++A00131AE2622542F0103
++A00431AE2622542F1b60e99fde0eaa8f9d14542fbc87863f
++A00431AE2622542F7c869fc1a381ff266fb4a315473c9046
++A00131AE2622542F00040000000000
++A00131AE2622542F01040000000001
++A00131AE2622542F0103
++A00131AE2622542F00040000000000
++A00131AE2622542F01040000000001
++A00131AE2622542F0103
++A00131AE2622542F00050000000000
++A00131AE2622542F000802010A310BAE0C26
++A00131AE2622542F0006
Helper:
HM_CMDNR 6
cSnd 0131AE2622542F000802010A310BAE0C26,0131AE2622542F0006
getCfgList all
getCfgListNo ,4
Wie kann ich das Problem lösen? Bleibt nur übrig, ein Device zu kaufen mit dem ich das AES des Fensterkontaktes abschalten kann? Das wäre aber nicht meine präferierte Lösung, da ich die Verschlüsselung schon gerne im Betrieb hätte.
http://forum.fhem.de/index.php/topic,41600.msg338507.html#msg338507
Hallo Ralli,
wurde gleich zu Anfang installiert.
Habe jetzt nochmal gepairt und dann war das set_ bei R-pairCentral weg. Nochmal gepairt und wieder da. Solnage versucht, bis es wieder weg war. Beim pairen wirden die pendings abgearbeitet. Danach nicht mehr.
Gruß Jürgen
ZitatBeim pairen wirden die pendings abgearbeitet. Danach nicht mehr.
pendings werden immer beim drücken des tasters abgearbeitet, da der fk sonst schläft. bei vielen pendings öfter drücken.
OK, jetzt stoße ich wieder an meine Grenzen des Wissens über FHEM.
Ich dachte pendings sind die Befehle an ein device (hier FK), eine Aktion durchzuführen wie z.B. Auslesen eines registers, schalten eines kontaktes... je nachdem, was es für ein device ist. Das muss doch aber immer abgearbeitet werden, auch wenn niemand den Taster (ich denke Du meinst den Konfigurationstaster am Gerät) drückt.
Wenn es so ist wie Du beschreibst, müßte ich doch nach dem pairen (da werden ja anscheinend alle Register ausgelesen, danach bei einem getConfig nur noch 3 Register) den assignhmkey-Befehl absetzen und gleich anschließend die Konfigurationstaste am FK drücken, damit der Befehl übernommen wird. Das würde auch erklären, warum ich die Register nur beim Pairvorgang auslesen kann und danach nicht mehr. Dann den sign on-Befehl und wieder Taste drücken und so weiter.
Ist das so korrekt?
yes.
die config modes der devices sind in einem wiki beschrieben. deiner kann eventuell auch lazy config. dann koennen auch befehle bei statusaenderung empfangen werden, open
/close.
Die Statusmeldungen werden jetzt übertragen. Allerdings kann ich nicht sagen, ab welchem Zeitpunkt meiner Versuche.
Bedeutet das Übertragen des Status (Open / closed) automatisch, dass AES aktiviert ist? Wenn nicht, wie kann ich prüfen, ob es aktiviert ist?
In den Readings sign = on und aesKeyNbr sollte einen recht aktuellen Zeitstempel haben.
In den Internals:
protEvt_AESCom-ok
12 last_at:2015-10-03 ...
Dann nicht. Ich habe weder in den readings ein "sign", noch einen "aeskeynbr" und in den inetrnales keinen protEvt_AESCom.
Ich fürchte aber, wenn ich nochmal den Versuch mit "assignhmkey" und "sign on" mache, dass dann wieder meine Verbindung nicht geht. Ist das möglich oder kann jetzt, da die Daten übertragen werden, der Fall nicht mehr eintreten?
Versuch macht kluch ;).
Erst sign on, Config-Taster am Device, dann assign hmkey, Config-Taster am Device usw...
Ich sehe an Deinem Device nur ein IODev aber kein IOgrp, ist das überhaupt der vCCU (bzw. ihrem IO) zugeordnet?
Versuch kann auch viel Arbeit bringen. ;)
Ist zugeordnet:
ZitatReadings:
2015-10-03 19:28:04 Activity alive
2015-10-03 18:25:09 D-firmware 2.1
2015-10-03 18:25:09 D-serialNr KEQ0366855
2015-10-03 19:30:03 alive yes
2015-10-03 19:30:44 battery ok
2015-10-03 19:30:44 contact closed (to VCCU)
2015-10-03 19:30:03 recentStateType info
2015-10-03 19:30:03 sabotageError off
2015-10-03 19:30:44 state closed
2015-10-03 19:30:44 trigger_cnt 34
Attributes:
IODev CUL_0
IOgrp VCCU:CUL_0
actCycle 028:00
actStatus alive
autoReadReg 4_reqStatus
expert 2_full
firmware 2.1
model HM-SEC-SC
peerIDs 00000000,
room Wohnzimmer
serialNr KEQ0366855
subType threeStateSensor Was bedeutet das Reading Sabotage Error?