HM-Sec-SC-2 AES aktivieren?

frank · 31 Januar 2016, 14:04:51

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, .....

Bytechanger · 31 Januar 2016, 14:45:47

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:

Code Auswählen

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.

Bennemannc · 31 Januar 2016, 14:56:08

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

Bytechanger · 31 Januar 2016, 16:35:44

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

Gernott · 31 Januar 2016, 17:10:45

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.

Bytechanger · 31 Januar 2016, 17:19:40

Hier ist sie...

Code Auswählen

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

Gernott · 31 Januar 2016, 17:37:03

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.

Bennemannc · 31 Januar 2016, 17:56:09

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:

Code Auswählen

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

Bytechanger · 31 Januar 2016, 18:16:36

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

Gernott · 31 Januar 2016, 21:56:38

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.

Bytechanger · 31 Januar 2016, 22:25:29

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

Gernott · 31 Januar 2016, 22:50:16

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.

Bytechanger · 01 Februar 2016, 06:01:22

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

frank · 01 Februar 2016, 10:32:14

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.

Bytechanger · 01 Februar 2016, 11:21:41

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