Hallo,
als Anfänger habe ich eine Frage,
ich habe Fensterkontakte und möchte sie AES-Signieren.
Die Fensterkontakte sind NUR mit der VCCU gepairt.
Per WEB habe ich den AES-Schlüssel mit SET assignHmKey übertragen.
Wie geht es weiter? Wenn ich unter Attribute aesCommReq 1 setze, sehe ich im Eventmonitor:
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:47 CUL_HM EG_Kueche battery: ok
2016-01-30 15:51:47 CUL_HM EG_Kueche contact: closed (to vccu)
2016-01-30 15:51:47 CUL_HM EG_Kueche closed
2016-01-30 15:51:47 CUL_HM EG_Kueche trigDst_vccu: noConfig
2016-01-30 15:51:47 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:47 CUL_HM EG_Kueche trigger_cnt: 60
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:47 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:48 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:48 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:48 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:49 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:49 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:49 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:51 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:52 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:52 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:56 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:56 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:56 CUL_HM EG_Kueche trig_aes_vccu: ok:60
Und die LED am Fensterkontakt leuchtet mehrere Sekunden orange, dann ROT. (Sonst kurz grün und OK).
Das Status wird aber weiterhin übertragen...
Greets Byte
Zitat von: Bytechanger am 30 Januar 2016, 15:52:36
Hallo,
als Anfänger habe ich eine Frage,
ich habe Fensterkontakte und möchte sie AES-Signieren.
Die Fensterkontakte sind NUR mit der VCCU gepairt.
Per WEB habe ich den AES-Schlüssel mit SET assignHmKey übertragen.
Wie geht es weiter? Wenn ich unter Attribute aesCommReq 1 setze, sehe ich im Eventmonitor:
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:47 CUL_HM EG_Kueche battery: ok
2016-01-30 15:51:47 CUL_HM EG_Kueche contact: closed (to vccu)
2016-01-30 15:51:47 CUL_HM EG_Kueche closed
2016-01-30 15:51:47 CUL_HM EG_Kueche trigDst_vccu: noConfig
2016-01-30 15:51:47 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:47 CUL_HM EG_Kueche trigger_cnt: 60
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:47 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:47 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:48 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:48 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:48 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:49 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:49 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:49 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:51 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:52 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:52 CUL_HM EG_Kueche trig_aes_vccu: ok:60
2016-01-30 15:51:56 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-30 15:51:56 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-30 15:51:56 CUL_HM EG_Kueche trig_aes_vccu: ok:60
Und die LED am Fensterkontakt leuchtet mehrere Sekunden orange, dann ROT. (Sonst kurz grün und OK).
Das Status wird aber weiterhin übertragen...
Greets Byte
Halt dich hier ran http://fhemwiki.de/wiki/AES_Encryption
Rot kommt, wenn des PEERINGS nicht korrekt sind. Da ist ein großer Unterschied zum PAIRING. Ich nutze das Peering für den Fall, dass FHEM nicht läuft. Wenn Du das nicht brauchst, würde ich die Peerings löschen. Was hast DU für Aktoren?
Achso und wichtig ist, wenn DU die AES Signierung verwendest, dass du beim Aktivieren immer die Anlerntaste drücken musst. Danach verschwindet das Pending.
Hallo,
ich habe nicht gepeert, da nur die vccu die Daten braucht.
Das wiki kenne ich, habe es aber offenbar nicht verstanden.
Daher hoffe ich auf Hilfe...
Hallo,
es gibt bei den AES fähigen Geräten das Register "sign". Das muss auf "on" gestetzt werden. Das geht mit set Gerät resSet sign on. Damit ist die Signierung am Fensterkontakt eingeschlaltet.
Gruß Christoph
Ok, das hatte ich auch gesehen:
Wiki hatte ich so verstanden:
1. Schlüssel auf Gerät übertragen mit --> assignHmKey
scheint auch geklappt zu haben..
"Eine AES-Signatur muss vom Empfänger angefordert werden" -> Empfnger wäre in meinem Fall ja die VCCU, sonst gibt es keinen
set Geraet sign on
set Schalter_Btn_01 sign on
"Ein Sender, der mit einem Empfänger gepeert ist sollte wissen, ob dieser AES nutzen wird. Das Register expectAES ist hierbei auf on zu setzen."
-> set Schalter_Btn_01 regSet expectAES on Geraet
Habe nichts gepeert!
"Die Zentrale kann ebenfalls eine AES-Signatur von einem Gerät anfordern"
->Hierzu ist im Device (und evtl. entsprechendem Kanal) das Attribut aesCommReq auf 1
Das verwirrte mich etwas. Mein Aufbau ist, dass die Fensterkontakte alle nur mit der Zentrale gepairt sind und nicht gepeert.
Ich könnte sie nun alle mit einem Virtuellen Button der VCCU peeren, wenn dies hierfür erforderlich wäre?
Habe EG_Kueche Fensterkontakt nun auf sign on gesetzt und den Anlernbutten gedrückt.
Hier ist keine Veränderung zur normalen übertragung im Eventmonitor ersichtlich
Also augenscheinlich keine Signierung.
2016-01-31 08:16:45 CUL_HM EG_Kueche battery: ok
2016-01-31 08:16:45 CUL_HM EG_Kueche contact: closed (to vccu)
2016-01-31 08:16:45 CUL_HM EG_Kueche closed
2016-01-31 08:16:45 CUL_HM EG_Kueche trigDst_vccu: noConfig
2016-01-31 08:16:45 CUL_HM EG_Kueche trigger_cnt: 69
Das Setzen des aesCommReq auf 1 gibt das EventLog:
2016-01-31 09:01:59 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 09:01:59 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 09:01:59 CUL_HM EG_Kueche battery: ok
2016-01-31 09:01:59 CUL_HM EG_Kueche contact: closed (to vccu)
2016-01-31 09:01:59 CUL_HM EG_Kueche closed
2016-01-31 09:01:59 CUL_HM EG_Kueche trigDst_vccu: noConfig
2016-01-31 09:01:59 CUL_HM EG_Kueche trig_aes_vccu: ok:95
2016-01-31 09:01:59 CUL_HM EG_Kueche trigger_cnt: 95
2016-01-31 09:01:59 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 09:01:59 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 09:01:59 CUL_HM EG_Kueche trig_aes_vccu: ok:95
2016-01-31 09:02:00 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 09:02:00 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 09:02:00 CUL_HM EG_Kueche trig_aes_vccu: ok:95
2016-01-31 09:02:01 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 09:02:01 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 09:02:01 CUL_HM EG_Kueche trig_aes_vccu: ok:95
2016-01-31 09:02:03 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 09:02:04 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 09:02:04 CUL_HM EG_Kueche trig_aes_vccu: ok:95
2016-01-31 09:02:08 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 09:02:08 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 09:02:08 CUL_HM EG_Kueche trig_aes_vccu: ok:95
Also quasi wenn ich das richtig sehe 6 mal eine Anfrage mit 6x Ergebnis OK (Dauer 9 Sekunden!).
Aber der Fensterkontakt zeigt am Schluss auch das rote Licht?!
Ich bin etwas ratlos.
Greets
Byte
Hallo,
eine Bestätigung - grünes Licht - kommt nur, wenn auch jemand den Befehl mit ack - angekommen - quitiert. Das machen aber nur Geräte, die gepeert sind, weil nur diese direkt mit Adresse angesprochen werden. Sind mehrere Geräte gepeert, müssen alle mit ack Antworten, damit die grüne Bestätigung kommt.
So kenne ich das zumindest. Es muss aber nicht jeder Kontakt mit einem eigenen Kanal der VCCU gepeert werden. Man kann auch alle Fensterkontakte mit einem virtuellen Kanal peeren.
Gruß Christoph
Hallo,
im "normalen" Modus, also ohne AES, verhält sich der Fensterkontakt (nur gepaired!!) wie folgt:
->Zustandsänderung = LED für bruchteil einer Sekunde orange, dann GRÜN !!
wenn ich aesCommReq auf 1 setzte, dann ist 10 Sekunden orange und kurz rot!
Das Eventlog gefällt mir da auch nicht, da dort 6 Anfragen sind?!
2 wären doch normal Anforderung der Signierung und Bestätigung?!
Wenn aesCommReq auf 1 ist, dann kann ich auch nicht auf die Anlerntaste drücken, dann ist ebenfalls lange Orange blinkend und dann rot!
Greets
Byte
Hat die VCCU den Key? Per assignHMKey?
Hallo,
soweit ich weiß wird der Key bei der VCCU als Attribut hmKey, hmKey2, hmKey3 hinterlegt. Danach wird der erst übertragen.
Gruß Christoph
Ja, oder so, hab hier nur HMLAN
Ja, im WEB kann man ihn in den Attributen sehen (habe ich bei der Definitinon in der fhem.cfg von Hand eingegeben:
hmKey 01:0ablablalbllab
Im Gerät habe ich dann auf SET assignhmkey geklickt und den Anlernknopf gedrückt.
Was mich manchmal wundert ist, dass unter Readings
protCmdPend 3 CMDs_pending
steht und es mit dem Drücken des Anlernknopfes nicht weg geht.
Waran merke ich, dass der Schlüssel erfolgreich übertragen wurde?
(Das Log 2016-01-31 09:01:59 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 09:01:59 CUL_HM EG_Kueche aesCommToDev: ok
sagt aber doch, dass sie Signierung akzeptiert wurde...)
Greets
Byte
Es muss schnell blinken als Antwort. Wenn es nur langsam blinkt, nochmal ganz kurz die Anlerntaste drücken. Oder hast Du NACK in den Readings, da antwortet etwas nicht.
Es blinkt gar nichts. Druck auf Anlerntaste = kurz orange dann lange grün.
STATE ist open oder closed; kein NACK
Wenn ich das Register für cyclicInfoMsg auf on setzte scheint das auch zu funktionieren.
Nur derzeit stehen in den Internals immer noch protCmdPend 3 CMDs_pending.
Ein getConfig oder get "reg all" brachte auch nichts.
Sign am Aktor muss aktiv sein
Setzt das Ding zurück.
set FK regSet pairCentral 0x98bde kurz Anlerntaste , schnelles Blinken, 0 Pending
set perChanel 0 Aktor single set kurz Anlerntaste , schnelles Blinken, 0 Pending
set assignhmkey ...... kurz Anlerntaste , schnelles Blinken, 0 Pending
set FK expectAES on Aktor kurz Anlerntaste , schnelles Blinken, 0 Pending
set aescommreq ..... kurz Anlerntaste , schnelles Blinken, 0 Pending
Fertig, so geht es bei mir
Ja, du hast son magn. Teil, da gibt es das schnelle Blinken nicht. Hauptsache Pending auf 0
ZitatWenn ich das Register für cyclicInfoMsg auf on setzte scheint das auch zu funktionieren.
Nur derzeit stehen in den Internals immer noch protCmdPend 3 CMDs_pending.
sei gnädig zu dem kleinen sensor. der kann bei jedem knöpfchen drücken nicht soviel auf einmal machen. immer nur häppchenweise, dann wieder knöpfchen drücken, .....
Hallo,
also ich habe keinen Aktor mit den Fensterkontakten verbunden, nur vccu!
Ich kann zwar mit einem virtuellen Kanal der vccu peeren, der hat aber keine Register, so dass exceptAES entfällt!
Hier kann ich höchstens aesCommReq 1 setzen!
Habe kein pending mehr,
bleibt aber dabei, dass das Log selbst bei gepeerten virtuellen Button so aussieht wenn ich sign on und aesCommandReq setzte:
2016-01-31 14:37:12 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 14:37:12 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 14:37:12 CUL_HM EG_Kueche battery: ok
2016-01-31 14:37:12 CUL_HM EG_Kueche contact: open (to vccu)
2016-01-31 14:37:12 CUL_HM EG_Kueche open
2016-01-31 14:37:12 CUL_HM EG_Kueche trig_aes_vccu: ok:216
2016-01-31 14:37:12 CUL_HM EG_Kueche trigger_cnt: 216
2016-01-31 14:37:12 CUL_HM v_button1 trig_aes_EG_Kueche: ok:215
2016-01-31 14:37:12 CUL_HM v_button1 trig_aes_EG_Kueche: ok:215
2016-01-31 14:37:12 CUL_HM v_button1 trig_aes_EG_Kueche: ok:215
2016-01-31 14:37:12 CUL_HM v_button1 trig_aes_EG_Kueche: ok:215
2016-01-31 14:37:12 CUL_HM v_button1 trig_aes_EG_Kueche: ok:215
2016-01-31 14:37:12 CUL_HM v_button1 trigLast: EG_Kueche:open
2016-01-31 14:37:12 CUL_HM v_button1 trig_EG_Kueche: open
2016-01-31 14:37:12 CUL_HM v_button1 trig_aes_EG_Kueche: ok:216
2016-01-31 14:37:12 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 14:37:13 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 14:37:13 CUL_HM EG_Kueche trig_aes_vccu: ok:216
2016-01-31 14:37:13 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 14:37:13 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 14:37:13 CUL_HM EG_Kueche trig_aes_vccu: ok:216
2016-01-31 14:37:14 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 14:37:15 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 14:37:15 CUL_HM EG_Kueche trig_aes_vccu: ok:216
2016-01-31 14:37:17 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 14:37:17 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 14:37:17 CUL_HM EG_Kueche trig_aes_vccu: ok:216
2016-01-31 14:37:21 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 14:37:21 CUL_HM EG_Kueche aesCommToDev: ok
2016-01-31 14:37:21 CUL_HM EG_Kueche trig_aes_vccu: ok:216
Grundstätzlich würde ich als Laie behaupte, die AES Kommunikation funktioniert, da nach esCommToDev: pending ein aesCommToDev: ok kommt.
Erschreckend ist nur, das diese Kommunikation mehrfach stattfindet...
Ich möchte es ungern in diesem Zustand lassen, AES ist mir wichtig, aber 10 Sekunden senden des Sensors lutscht vermutlich die Batterien sehr schnell leer!
Need Help!
EDIT: Übrigens zeigt das WEB nach dem ersten esCommToDev: pending ein aesCommToDev: ok bereits den Status offen.
Keine Ahnung, irgendwie scheint der Sensor nicht zu verstehen, dass seine Meldung akzeptiert wurde und versucht es weiterhin, quittiert dann am Gerät mit ROT dass er meint, es hätte nicht funktioniert.
Wie gesagt, dieses Verhalten nur bei AES.
Hallo,
nachdem Du jetzt einiges probiert hast, würde ich den Fensterkontakt auf Werkszustand setzen, und ihn neu anlernen. Den Key rüber sign on und testen. Es kann durchaus sein, das er sich bei dem Testen verschluckt hat. Ich hatte so etwas auch schon mal - nur bei mir hörte der überhaupt nicht mehr auf zu senden (mit kurzen Pasen dazwischen).
Wie groß ist der Anstand zwischen. HMLAN und Kontakt - wenn die zu nah beieinander liegen, kann das auch zu Problemen führen.
Gruß Christoph
OK,
also mein Vorgehen jetzt,
(zur Config, ich benutze einen CUL über eine VCCU)
So habe einen Werksreset gemacht (2x 5 Sekunden).
Neu angelernt Key rüber und Sign on. Da passiert noch nix. Auch keine signaturanfrage.
Das passiert doch erst bei aesCommandReq.
Bevor ich falsch liege, die Signatur fordert doch der Empfänger an, also in meinem Fall die VCCU.
Ich gehe davon aus, wenn ich beim Sensor unter Attribute das aesCommandReq auf 1 setzte, dass damit die VCCU die Signatur anfordert.
Also ob im Sensor Readings R-sign ON oder OFF ist, scheint im Eventmonitor egal zu sein.
Die AES-Signaturprüfung startet, wenn ich das aesCommandReq setzte. Das wird ja auch offensichtlich akzeptiert, nur rennt das Ding immer weiter und verhält sich m.E. so, als hätte die Zentrale die Signatur erneut und erneut angefordert....
Ich glaube, ich mache irgendwo einen entscheidenden Anfängerfehler. Aber diese Konsterlation Fenstersensor->VCCU mit AES haben doch bestimmt viele ?!
Greets
Byte
Poste doch bitte mal ein "list <device>". Da sieht man einfach mehr. Vorher mal im Sensor ein "getConfig" absetzen, danach Knöpfchen drücken, bis keine Cmd pending mehr steht.
Gruß
G.
Hier ist sie...
Internals:
CFGFN
CUL0_MSGCNT 255
CUL0_RAWMSG A0E27A0102782051DA4620100000000::-61:CUL0
CUL0_RSSI -61
CUL0_TIME 2016-01-31 17:18:44
DEF 278205
IODev CUL0
LASTInputDev CUL0
MSGCNT 255
NAME EG_Kueche
NR 615
STATE closed
TYPE CUL_HM
lastMsg No:27 - t:10 s:278205 d:1DA462 0100000000
protEvt_AESCom-ok 54 last_at:2016-01-31 17:18:41
protLastRcv 2016-01-31 17:18:44
protSnd 115 last_at:2016-01-31 17:18:44
protState CMDs_done
rssi_at_CUL0 avg:-57.96 cnt:147 min:-85 lst:-61 max:-40.5
Readings:
2016-01-31 17:18:43 Activity alive
2016-01-31 17:17:48 CommandAccepted yes
2016-01-31 17:18:43 D-firmware 2.4
2016-01-31 17:18:43 D-serialNr LEQ0214384
2016-01-31 17:18:44 PairedTo 0x1DA462
2016-01-31 17:17:48 R-cyclicInfoMsg on
2016-01-31 16:22:37 R-eventDlyTime 0 s
2016-01-31 16:26:48 R-pairCentral 0x1DA462
2016-01-31 16:22:37 R-sabotageMsg on
2016-01-31 17:16:16 R-sign on
2016-01-31 17:18:43 RegL_00. 02:01 09:01 0A:1D 0B:A4 0C:62 10:01 14:06 00:00
2016-01-31 17:18:44 RegL_01. 08:01 20:60 21:00 22:64 30:06 00:00
2016-01-31 17:18:41 aesCommToDev ok
2016-01-31 17:17:47 aesKeyNbr 02
2016-01-31 17:18:32 battery ok
2016-01-31 17:18:32 contact closed (to vccu)
2016-01-31 17:18:32 state closed
2016-01-31 17:18:32 trigDst_vccu noConfig
2016-01-31 17:18:41 trig_aes_vccu ok:11
2016-01-31 17:18:32 trigger_cnt 11
Helper:
HM_CMDNR 39
PONtest 1
cSnd 011DA46227820501040000000001,011DA4622782050103
mId 00B1
peerIDsRaw ,00000000
rxType 28
Expert:
def 1
det 0
raw 1
tpl 0
Io:
newChn +278205,01,01,02
nextSend 1454257124.54621
prefIO
rxt 2
vccu
p:
278205
01
01
02
Mrssi:
mNo 27
Io:
CUL0 -59
Prt:
bErr 0
sProc 0
try 1
Rspwait:
Q:
qReqConf
qReqStat
Role:
chn 1
dev 1
Rpt:
IO CUL0
flg A
ts 1454257124.45185
ack:
HASH(0x1aab1d0)
2780021DA46227820500
Rssi:
At_cul0:
avg -57.9625850340136
cnt 147
lst -61
max -40.5
min -85
Shadowreg:
Role:
Attributes:
IODev CUL0
IOgrp vccu:CUL0
actCycle 028:00
actStatus alive
aesCommReq 1
autoReadReg 4_reqStatus
expert 2_raw
firmware 2.4
model HM-SEC-SC-2
peerIDs 00000000,
room CUL_HM,EG
serialNr LEQ0214384
subType threeStateSensor
Das sieht grundsätzlich nicht anders aus als bei mir. Eventuell ist der CUL das Problem der langen Kommunikation. Damit kenne ich mich leider nicht aus, habe nur HMLAN und HMUSB.
Gruß
G.
Hallo,
ZitatBevor ich falsch liege, die Signatur fordert doch der Empfänger an, also in meinem Fall die VCCU.
Das lese ich auch so in der Beschreibung. Wir haben auf dem Homematic-Seminar das Thema kurz angeschnitten. Dabei haben wir den Schlüssel mit der HM-Config Software auf Windows erstellen lassen. Soweit ich weiß muss das Teil eine bestimmte Läbge haben. Das ist auch nicht "Klartext" - der Text bzw. die Buchstaben werden in eine Hex-Code umgesetzt und dieser wird übermittelt. -- hier:
http://forum.fhem.de/index.php/topic,43888.msg398897.html#new ist der Link dazu. Markus Bloch hat uns das gezeigt - der kennt sich sehr gut damit aus. Vielleicht macht es Sinn, Dein Problem dort mal zu posten.
Gruß Christoph
OK um das auszuschließen,
habe hier noch einen hmlan rumfliegen. Könnte den doch problemlos mit der vccu verbinden und dem Fensterkontakt sagen, er solle bevorzugt mit hmlan kommunizieren.
Wenn das Problem dann immer noch auftritt, liegt es nicht am cul.
Damit ich nichts falsch mache, hmlan ans netzwerk, zunächst mit Windows Software die verschlüsselung (lan<->pc) abschalten, dann an fhem betreiben?!
Die hmid bekommt der hmlan dann doch wie der cul von der vccu, genau wie der aes key?!
@Gernott: Hast Du auch die Konfiguration, dass die Fensterkontakte nur mit der VCCU gepairt sind?
Im Fensterkontakt im WEB hast du Sign on und aesCommandReq 1 ?? Habe ich sonst noch etwas vergessen?
Greets
Byte
Ja, bei mir ist der Sensor nur mit der vccu gepaired. Die AES-Kommunikation läuft allerdings nur zwischen dem IO-Device (bei Dir CUL) und dem Sensor. Die vccu hart damit nichts zu tun. Zumindest habe ich das so verstanden. Ich habe meine Logs nicht im Detail analysiert. Aber, wenn ich das Fenster aufmache, kommt nach kurzer Zeit die grüne Quittierung und dann ist Ruhe.
Gruß
G.
So,
habe mir eine HM-Cfg-Lan geliehen und auch mit der VCCU verbunden.
Dann beim Fensteraktor IODevice HMLAN eingestellt, so dass die Kommunikation bevorzugt damit läuft, und siehe da, es läuft!
Es scheint mir, der CUL macht hier arge Probleme!!
Das ärgert mich, sollte doch auch damit funktionieren, oder??
Auf dem CUL habe ich eine schön dicke Antenne drauf, damit ich keine Empfangsprobleme bekomme, wenn ich das nicht hinbekomme, wäre das ding für mich nutzlos...
Aber wie gesagt, es scheint nur an der fehlerhaften Rückmeldung des CUL an den Sensor zu liegen!
Greets
Byte
Um AES mit dem CUL zu nutzen, mußt Du noch ein Perl-Modul nachinstallieren. Suche mal hier im Forum bzw. im fhemwiki.
Gruß
G.
Hallo,
habe ich installiert.
Grundsätzlich funktioniert es ja, die Übertragung und die Signatur wird auch erfolgreich geprüft.
2016-01-31 14:37:12 CUL_HM EG_Kueche aesCommToDev: pending
2016-01-31 14:37:12 CUL_HM EG_Kueche aesCommToDev: ok
Habe nur gerade durch Bennemanncs Tipp erfahren, dass CUL nicht aesCommandReq kann!
Überprüfe gerade, wass das für mich bedeutet. Ich bin grundsäztlich davon ausgegangen, dass CUL vollwertig alles AES kann, was HM-Cfg-LAN auch kann.
Ansonsten macht es m.E. für Homematic überhaupt keinen Sinn einen CUL zu nehmen, da der auch teurer ist.
Greets
Byte
ZitatAnsonsten macht es m.E. für Homematic überhaupt keinen Sinn einen CUL zu nehmen, da der auch teurer ist.
genau. warum willst du ihn dennoch?
auch das timing ist in der regel schlechter, da in der "normalen" fw keine timestamps erzeugt werden. versuch mal mit der angepinnten fw.
Zitatgenau. warum willst du ihn dennoch?
weil ich ihn leider teuer gekauft habe.
Aber zu dem aesCommandReq mit CUL gibt es wieder sehr engagierte Mitglieder,
hier wird sich damit beschäftigt
http://forum.fhem.de/index.php/topic,43675.30.html
ich glaube auch, dass es im aktuellen Update schon drin ist, kann es erst heute abend testen...
Für einen Laien, was bedeutet "das timing ist in der regel schlechter," konkret für mich als Nutzer?
Was machen diese keine timestamps ??
Greets
Byte
die devices erwarten antworten in einem bestimmten zeitfenster. ohne timestamp kann fhem das nicht gewährleisten.
So, findige Nutzer haben das CUL Modul angepasst, jetzt geht auch aesCommReq mit dem CUL!
Zwei Zeichen löschen reicht...
http://forum.fhem.de/index.php/topic,43675.30.html
Greets
Byte