FHEM Forum

FHEM - Hausautomations-Systeme => Homematic => Thema gestartet von: Bytechanger am 31 August 2016, 16:40:53

Titel: AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 31 August 2016, 16:40:53
Hallo,

nachdem mir es mir bei den Fenstersensoren auffiel, habe ich nun auch Steckdosen getestet.
Sobald in FHEM ein "Signatur-Handshake" über den CUL laufen soll läuft es schief ..

Bei den Fenstersendoren steht  aesCommToDev: pending .
Gleiches gilt für Aktoren. Dort wird ebenfalls aesCommToDev: pending
eingeblendet.
Sämtliche Aktionen / Meldungen bleiben dann natürlich ignoriert!

Da vor geraumer Zeit alles funktionierte, bin ich nun auf der Suche nach dem Fehler.
Da ich Homematic über eine VCCU in Kombi mit einem HMLAN und dem CUL nutze, kann
ich in den Devices über

IODev CUL0
IOgrp vccu:CUL0

und

IODev HMLAN1
IOgrp vccu:HMLAN1

umschalten. Bei HMLAN1 funktioniert alles... ??

Internals:
   CMDS       BbCFiAZNkGMKUYRTVWXefmLltux
   CUL0_MSGCNT 8
   CUL0_TIME  2016-08-31 16:36:03
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-busware.de_CUL868-if00 0000
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00
   FHTID      0000
   NAME       CUL0
   NR         124
   NR_CMD_LAST_H 4
   PARTIAL
   RAWMSG     A0EA380021DA462343DCC0068A52CE821
   RSSI       -57.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
Ar
   owner_CCU  vccu
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2016-08-31 16:36:03   cmds             B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2016-08-28 18:22:53   hmSioDly        0
     2016-08-29 08:01:41   raw             V 1.66 CUL868
     2016-08-31 16:36:03   state           Initialized
     2016-08-30 06:15:37   version         V 1.66 CUL868
   XMIT_TIME:
     1472654192.50399
     1472654193.8701
     1472654198.30359
     1472654204.09606
   Helper:
     456779:
       QUEUE:
     467509:
       QUEUE:
Attributes:
   event-on-change-reading .*
   group      Sender
   hmId       1DA111
   icon       cul_cul
   rfmode     HomeMatic
   room       Basis


Internals:
   CUL0_MSGCNT 6
   CUL0_RAWMSG A0EA380021DA462343DCC0068A52CE8::-57.5:CUL0
   CUL0_RSSI  -57.5
   CUL0_TIME  2016-08-31 16:36:03
   DEF        1DA462
   HMLAN1_MSGCNT 731
   HMLAN1_RAWMSG E1DA462,0000,110C683C,FF,FFC7,04A0111DA4624567790201C80000
   HMLAN1_RSSI -57
   HMLAN1_TIME 2016-08-31 16:32:36
   IODev      HMLAN1
   LASTInputDev CUL0
   MSGCNT     737
   NAME       vccu
   NOTIFYDEV  global
   NR         140
   NTFY_ORDER 50-vccu
   STATE      HMLAN1:ok,CUL0:ok,
   TYPE       CUL_HM
   assignedIOs CUL0,HMLAN1
   channel_01 V_HS_AL_armInt
   channel_02 V_HS_AL_armExt
   channel_03 V_HS_AL_light
   channel_04 V_HS_AL_disarm
   lastMsg    No:A3 - t:02 s:1DA462 d:343DCC 0068A52CE8
   protLastRcv 2016-08-31 16:36:03
   rssi_at_CUL0 max:-57.5 avg:-58.41 min:-59 lst:-57.5 cnt:6
   rssi_at_HMLAN1 lst:-57 cnt:46 avg:-62.89 min:-77 max:-57
   Readings:
     2016-08-31 16:36:03   CommandAccepted yes
     2016-08-31 16:36:01   aesKeyNbr       02
     2016-08-28 10:00:00   aesReqTo        AussenSwitch
     2016-08-30 12:45:08   state           HMLAN1:ok,CUL0:ok,
     2016-08-26 21:42:50   unknown_10F5B8  received
     2016-08-24 20:08:43   unknown_144111  received
     2016-08-31 11:22:09   unknown_152097  received
     2016-08-29 22:24:36   unknown_1941B4  received
     2016-08-31 15:59:12   unknown_206B03  received
     2016-08-30 06:23:46   unknown_23FBE0  received
     2016-08-24 20:08:44   unknown_411111  received
     2016-08-31 16:26:03   unknown_FD1D5F  received
   Helper:
     HM_CMDNR   163
     mId        FFF0
     rxType     1
     Ack:
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       nextSend   1472654233.25728
       prefIO
       vccu
       ioList:
         HMLAN1
         CUL0
     Mrssi:
       mNo        A3
       Io:
         CUL0       -57.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Rssi:
       At_cul0:
         avg        -58.4166666666667
         cnt        6
         lst        -57.5
         max        -57.5
         min        -59
       At_hmlan1:
         avg        -62.8913043478261
         cnt        46
         lst        -57
         max        -57
         min        -77
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOList     HMLAN1,CUL0
   event-on-change-reading .*
   group      Sender
   hmKey      01:jajajuajaja
   model      CCU-FHEM
   room       Basis
   subType    virtual
   webCmd     virtual:update

Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 31 August 2016, 17:27:47
Mit einer 10_CUL_HM Version von Mai 2016 bekomme ich zumindest ein statusRequest bei den Aktoren hin....
Schalten geht weiterhin nicht, es erscheint damit aber kein Pending mehr.

Vermute also damit, dass es an Änderungen an der 10_CUL_HM liegt ??!!


Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 31 August 2016, 19:08:47
Hallo,

Zitat von: Bytechanger am 31 August 2016, 16:40:53

   IOList     HMLAN1,CUL0
   hmKey      01:jajajuajaja


Das funktioniert so nicht. Der Key muss in der VCCU definiert sein und die VCCU muss in der IOList des Geräts vorkommen, sonst findet der CUL-Code den Schlüssel nicht. Da die VCCU den Schlüssel in den HMLAN schreibt, funktioniert es hier, auch wenn die VCCU nicht selbst in der IOList steht.

EDIT: Und gibt es irgendwelche Einträge im Log?

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 31 August 2016, 19:38:40
Keine Sorge, ich habe den Key nur rausgenommen!
Ich wollte ihn nicht ins Internet posten
Der ist natürlich richtig drin, sonst würde HMLAN auch nicht funktionieren!

Gruß

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 31 August 2016, 19:40:35
Hi,

Zitat von: Bytechanger am 31 August 2016, 19:38:40
Keine Sorge, ich habe den Key nur rausgenommen!
Ich wollte ihn nicht ins Internet posten
Der ist natürlich richtig drin, sonst würde HMLAN auch nicht funktionieren!

Ähja, sorry. Das war ja die VCCU. Ich hatte das irgendwie für ein List der Steckdose gehalten...

Aber nochmal: Taucht bei Schaltversuchen irgendwas im Fhem-Log auf? Ist das Perl-Modul installiert?

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 31 August 2016, 19:47:47
Wie gesagt, vccu->HM-Lan funktioniert ! Nur der CUL streikt !


So sieht der Fensterkontakt aus, wenn er über HMLAN ordnungsgemäß funktioniert:
Internals:
   DEF        278291
   HMLAN1_MSGCNT 18
   HMLAN1_RAWMSG E278291,0040,11BB7F69,01,FFC0,27A6412782911DA462015D00
   HMLAN1_RSSI -64
   HMLAN1_TIME 2016-08-31 19:43:50
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     18
   NAME       EG.bu.Buero.TK
   NOTIFYDEV  global
   NR         382
   NTFY_ORDER 50-EG.bu.Buero.TK
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:27 - t:41 s:278291 d:1DA462 015D00
   protEvt_AESCom-ok 2 last_at:2016-08-31 19:43:50
   protLastRcv 2016-08-31 19:43:50
   protSnd    2 last_at:2016-08-31 19:43:50
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:2 lst:-64 avg:-62 min:-64 max:-60
   Readings:
     2016-08-30 06:48:32   Activity        alive
     2016-08-29 20:23:19   D-firmware      2.4
     2016-08-29 20:23:19   D-serialNr      LEQ0214244
     2016-08-29 20:24:15   PairedTo        0x1DA462
     2016-08-29 20:24:15   R-cyclicInfoMsg on
     2016-08-29 20:24:16   R-eventDlyTime  0 s
     2016-08-29 20:24:15   R-pairCentral   0x1DA462
     2016-08-29 20:24:15   R-sabotageMsg   on
     2016-08-29 20:24:16   R-sign          on
     2016-08-29 20:24:15   RegL_00.        02:01 09:01 0A:1D 0B:A4 0C:62 10:01 14:06 00:00
     2016-08-29 20:24:16   RegL_01.        08:01 20:60 21:00 22:64 30:06 00:00
     2016-08-31 19:43:50   aesCommToDev    ok
     2016-08-31 06:22:52   alive           yes
     2016-08-31 19:43:50   battery         ok
     2016-08-31 19:43:50   contact         closed (to vccu)
     2016-08-31 06:22:52   recentStateType info
     2016-08-31 06:22:52   sabotageError   off
     2016-08-31 19:43:50   state           closed
     2016-08-31 19:43:50   trigDst_vccu    noConfig
     2016-08-31 19:43:50   trig_aes_vccu   ok:93
     2016-08-31 19:43:50   trigger_cnt     93
   Helper:
     HM_CMDNR   39
     mId        00B1
     rxType     28
     Aescommrq:
       challenge  85AB7439BA43
       kNo        1
       msg        A0C26A6412782911DA462015CC8
       msgIn      A0C26A6412782911DA462015CC8:AESCom-ok:-69:HMLAN1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +278291,01,01,02
       nextSend   1472665429.81064
       rxt        2
       vccu       vccu
       p:
         278291
         01
         01
         02
       prefIO:
         HMLAN1
     Mrssi:
       mNo        27
       Io:
         HMLAN1     -62
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1472665430.10168
       ack:
         HASH(0x2f393f8)
         2780021DA46227829100
     Rssi:
       At_hmlan1:
         avg        -62
         cnt        2
         lst        -64
         max        -60
         min        -64
     Tmpl:
   Role:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   028:00
   actStatus  alive
   aesCommReq 1
   alarmDevice Sensor
   alarmSettings alarm6,|EG.bu.Buero.TK:[Oo]pen.*|Fenster Büro|on
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green
   expert     2_raw
   firmware   2.4
   group      Fenster
   icon       fts_window_2w_open
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       CUL_HM,Zustand,Öffnungssensoren
   serialNr   LEQ0214244
   subType    threeStateSensor

Und so das Eventlog:
2016-08-31 19:43:49 CUL_HM EG.bu.Buero.TK aesCommToDev: pending
2016-08-31 19:43:50 CUL_HM EG.bu.Buero.TK aesCommToDev: ok
2016-08-31 19:43:50 CUL_HM EG.bu.Buero.TK battery: ok
2016-08-31 19:43:50 CUL_HM EG.bu.Buero.TK contact: closed (to vccu)
2016-08-31 19:43:50 CUL_HM EG.bu.Buero.TK closed
2016-08-31 19:43:50 CUL_HM EG.bu.Buero.TK trigDst_vccu: noConfig
2016-08-31 19:43:50 CUL_HM EG.bu.Buero.TK trig_aes_vccu: ok:93
2016-08-31 19:43:50 CUL_HM EG.bu.Buero.TK trigger_cnt: 93


------------ und jetzt, wenn ich auf CUL0 schalte ------->
Internals:
   DEF        278291
   HMLAN1_MSGCNT 25
   HMLAN1_RAWMSG E278291,0040,11BDD729,01,FFC0,29A6412782911DA462015F00
   HMLAN1_RSSI -64
   HMLAN1_TIME 2016-08-31 19:46:23
   IODev      CUL0
   LASTInputDev HMLAN1
   MSGCNT     25
   NAME       EG.bu.Buero.TK
   NOTIFYDEV  global
   NR         382
   NTFY_ORDER 50-EG.bu.Buero.TK
   STATE      open
   TYPE       CUL_HM
   lastMsg    No:28 - t:41 s:278291 d:1DA462 015EC8
   protEvt_AESCom-ok 3 last_at:2016-08-31 19:45:35
   protLastRcv 2016-08-31 19:45:35
   protSnd    3 last_at:2016-08-31 19:45:35
   protState  CMDs_done
   rssi_at_HMLAN1 avg:-62.66 min:-64 max:-60 cnt:3 lst:-64
   Readings:
     2016-08-30 06:48:32   Activity        alive
     2016-08-29 20:23:19   D-firmware      2.4
     2016-08-29 20:23:19   D-serialNr      LEQ0214244
     2016-08-29 20:24:15   PairedTo        0x1DA462
     2016-08-29 20:24:15   R-cyclicInfoMsg on
     2016-08-29 20:24:16   R-eventDlyTime  0 s
     2016-08-29 20:24:15   R-pairCentral   0x1DA462
     2016-08-29 20:24:15   R-sabotageMsg   on
     2016-08-29 20:24:16   R-sign          on
     2016-08-29 20:24:15   RegL_00.        02:01 09:01 0A:1D 0B:A4 0C:62 10:01 14:06 00:00
     2016-08-29 20:24:16   RegL_01.        08:01 20:60 21:00 22:64 30:06 00:00
     2016-08-31 19:46:23   aesCommToDev    pending
     2016-08-31 06:22:52   alive           yes
     2016-08-31 19:45:35   battery         ok
     2016-08-31 19:45:35   contact         open (to vccu)
     2016-08-31 06:22:52   recentStateType info
     2016-08-31 06:22:52   sabotageError   off
     2016-08-31 19:45:35   state           open
     2016-08-31 19:45:35   trigDst_vccu    noConfig
     2016-08-31 19:45:35   trig_aes_vccu   ok:94
     2016-08-31 19:45:35   trigger_cnt     94
   Helper:
     HM_CMDNR   40
     mId        00B1
     rxType     28
     Aescommrq:
       challenge  85AB7439BA43
       kNo        1
       msg        A0C29A6412782911DA462015F00
       msgIn      A0C29A6412782911DA462015F00:AESCom-ok:-64:HMLAN1
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +278291,01,01,02
       nextSend   1472665583.32335
       rxt        2
       vccu       vccu
       p:
         278291
         01
         01
         02
       prefIO:
         CUL0
     Mrssi:
       mNo        28
       Io:
         HMLAN1     -62
     Prt:
       bErr       0
       sProc      0
       sleeping   0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1472665535.86242
       ack:
         HASH(0x2f393f8)
         2880021DA46227829100
     Rssi:
       At_hmlan1:
         avg        -62.6666666666667
         cnt        3
         lst        -64
         max        -60
         min        -64
     Tmpl:
   Role:
Attributes:
   IODev      CUL0
   IOgrp      vccu:CUL0
   actCycle   028:00
   actStatus  alive
   aesCommReq 1
   alarmDevice Sensor
   alarmSettings alarm6,|EG.bu.Buero.TK:[Oo]pen.*|Fenster Büro|on
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_1w_open@red closed:fts_window_1w@green
   expert     2_raw
   firmware   2.4
   group      Fenster
   icon       fts_window_2w_open
   model      HM-SEC-SC-2
   peerIDs    00000000,
   room       CUL_HM,Zustand,Öffnungssensoren
   serialNr   LEQ0214244
   subType    threeStateSensor

Hier das Log--->
2016-08-31 19:46:23 CUL_HM EG.bu.Buero.TK aesCommToDev: pending
2016-08-31 19:46:23 CUL_HM EG.bu.Buero.TK aesCommToDev: pending

Scheint so, als ob der AES-Handshake ins leere läuft!

Meine Hoffnung liegt auf @Martin786
Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 31 August 2016, 19:57:16
Hallo,

Zitat von: Bytechanger am 31 August 2016, 19:47:47
Hier das Log--->
2016-08-31 19:46:23 CUL_HM EG.bu.Buero.TK aesCommToDev: pending
2016-08-31 19:46:23 CUL_HM EG.bu.Buero.TK aesCommToDev: pending

Scheint so, als ob der AES-Handshake ins leere läuft!

Ja, vielleicht findet sich ein Hinweis in der fhem-Logdatei (und nicht im Eventlog). Schau bitte einmal in die fhem-Logdatei.
Und evtl. auch gleich Sniffing aktivieren.

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 31 August 2016, 20:12:20
Das war das Log...


wenn ich dieses Device noch auf verbose 5 Stelle sieht es im Fall von

HMLAN
2016.08.31 20:13:40 5: CUL_HM EG.bu.Buero.TK prep ACK for 01
2016.08.31 20:13:40 5: CUL_HM EG.bu.Buero.TK protEvent:CMDs_done
2016.08.31 20:13:40 5: CUL_HM EG.bu.Buero.TK sent ACK:2



CUL0
2016.08.31 20:14:27 5: CUL_HM EG.bu.Buero.TK requesting signature with challenge 85AB7439BA43 for key 1
2016.08.31 20:14:27 5: CUL_HM EG.bu.Buero.TK requesting signature with challenge 85AB7439BA43 for key 1


aus
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 31 August 2016, 20:25:00
2016.08.31 20:20:26 5: HMLAN/RAW: /E278291,0100,11DD0774,FF,FFBF,30A6412782911DA4620166C8

2016.08.31 20:20:26 5: HMLAN_Parse: HMLAN1 R:E278291   stat:0100 t:11DD0774 d:FF r:FFBF     m:30 A641 278291 1DA462 0166C8
2016.08.31 20:20:26 5: HMLAN1 dispatch A0C30A6412782911DA4620166C8:AESpending:-65:HMLAN1
[b]2016.08.31 20:20:26 5: CUL_HM EG.bu.Buero.TK requesting signature with challenge 85AB7439BA43 for key 1
2016.08.31 20:20:26 5: CUL0 sending As1130A0021DA4622782910485AB7439BA4302
2016.08.31 20:20:26 5: CUL 278291 dly:83ms
2016.08.31 20:20:26 4: CUL_send:  CUL0As 11 30 A002 1DA462 278291 0485AB7439BA4302
2016.08.31 20:20:26 5: Triggering EG.bu.Buero.TK (1 changes)[/b]
2016.08.31 20:20:26 5: Starting notify loop for EG.bu.Buero.TK, first event aesCommToDev: pending
2016.08.31 20:20:27 5: ZE.Batterie: not on any display, ignoring notify
2016.08.31 20:20:27 5: HMLAN/RAW: /E1DA462,0000,11DD0813,FF,FFC6,30A0021DA4622782910485AB7439BA4302

2016.08.31 20:20:27 5: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:11DD0813 d:FF r:FFC6     m:30 A002 1DA462 278291 0485AB7439BA4302
2016.08.31 20:20:27 5: HMLAN1 dispatch A1130A0021DA4622782910485AB7439BA4302::-58:HMLAN1
2016.08.31 20:20:27 5: HMLAN/RAW: /E278291,0040,11DD0774,01,FFBF,30A6412782911DA4620166C8

2016.08.31 20:20:27 5: HMLAN_Parse: HMLAN1 R:E278291   stat:0040 t:11DD0774 d:01 r:FFBF     m:30 A641 278291 1DA462 0166C8
2016.08.31 20:20:27 5: HMLAN1 dispatch A0C30A6412782911DA4620166C8:AESCom-ok:-65:HMLAN1
[b]2016.08.31 20:20:27 5: CUL_HM EG.bu.Buero.TK requesting signature with challenge 85AB7439BA43 for key 1
2016.08.31 20:20:27 5: CUL0 sending As1130A0021DA4622782910485AB7439BA4302
2016.08.31 20:20:27 4: CUL_send:  CUL0As 11 30 A002 1DA462 278291 0485AB7439BA4302[/b]
[b]2016.08.31 20:20:27 5: Triggering EG.bu.Buero.TK (1 changes)[/b]
[b]2016.08.31 20:20:27 5: Starting notify loop for EG.bu.Buero.TK, first event aesCommToDev: pending[/b]
2016.08.31 20:20:27 5: ZE.Batterie: not on any display, ignoring notify
2016.08.31 20:20:27 5: HMLAN/RAW: /E1DA462,0000,11DD0927,FF,FFC6,30A0021DA4622782910485AB7439BA4302

2016.08.31 20:20:27 5: HMLAN_Parse: HMLAN1 R:E1DA462   stat:0000 t:11DD0927 d:FF r:FFC6     m:30 A002 1DA462 278291 0485AB7439BA4302
2016.08.31 20:20:27 5: HMLAN1 dispatch A1130A0021DA4622782910485AB7439BA4302::-58:HMLAN1
2016.08.31 20:20:27 4: CUL_HM vccu dupe: dont process
2016.08.31 20:20:29 5: HMLAN_Send:  HMLAN1 I:K
2016.08.31 20:20:29 5: HMLAN/RAW: /HHM-LAN-IF,03C5,LEQ0640815,2CD8CE,1DA462,11DD12E7,001E,02


und hier über HMLAN wenns ok ist
2016.08.31 20:23:51 5: Triggering EG.bu.Buero.TK (1 changes)
2016.08.31 20:23:51 5: Starting notify loop for EG.bu.Buero.TK, first event aesCommToDev: pending
2016.08.31 20:23:51 5: ZE.Batterie: not on any display, ignoring notify
2016.08.31 20:23:51 5: HMLAN/RAW: /E278291,0040,11E02678,01,FFBE,32A6412782911DA4620168C8

2016.08.31 20:23:51 5: HMLAN_Parse: HMLAN1 R:E278291   stat:0040 t:11E02678 d:01 r:FFBE     m:32 A641 278291 1DA462 0168C8
2016.08.31 20:23:51 5: HMLAN1 dispatch A0C32A6412782911DA4620168C8:AESCom-ok:-66:HMLAN1
2016.08.31 20:23:51 5: CUL_HM EG.bu.Buero.TK prep ACK for 01
2016.08.31 20:23:51 5: HMLAN: Skip ACK
2016.08.31 20:23:51 5: CUL_HM EG.bu.Buero.TK protEvent:CMDs_done
2016.08.31 20:23:51 5: CUL_HM EG.bu.Buero.TK sent ACK:2
2016.08.31 20:23:51 5: Triggering EG.bu.Buero.TK (7 changes)
2016.08.31 20:23:51 5: Starting notify loop for EG.bu.Buero.TK, first event aesCommToDev: ok
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 31 August 2016, 20:35:52
Hallo,

Ich habe es gerade eben mit dem aktuellen Code getestet, AES funktioniert noch. Allerdings habe ich nur einen Aktor geschaltet.

Zitat von: Bytechanger am 31 August 2016, 20:12:20
Das war das Log...

Hmm, bei mir landen diese Events nicht im fhem-Log, nur in den einzelnen gerätespezifischen Logdateien (wenn überhaupt).

Zitat
CUL0
2016.08.31 20:14:27 5: CUL_HM EG.bu.Buero.TK requesting signature with challenge 85AB7439BA43 for key 1
2016.08.31 20:14:27 5: CUL_HM EG.bu.Buero.TK requesting signature with challenge 85AB7439BA43 for key 1


Also ist das Perl-Modul installiert und der Schlüssel wurde in der VCCU gefunden. Jetzt wäre interessant, was wirklich gesendet wurde.

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 31 August 2016, 20:58:24
Du hast auch einen CUL und eine VCCU??

Wie kann ich noch weitergehende Logs senden??

Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 31 August 2016, 21:57:25
Hi,

Zitat von: Bytechanger am 31 August 2016, 20:58:24
Du hast auch einen CUL und eine VCCU??

Ja, hatte gerade mein Testsystem gestartet.

Zitat
Wie kann ich noch weitergehende Logs senden??

Siehe: https://forum.fhem.de/index.php/topic,16563.msg107848.html#msg107848

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 01 September 2016, 07:00:43
OK,

also diese Einstellung:

attr global verbose 1
attr global mseclog 1
attr <cul> verbose 4

Ergibt beim Öffnen des Fensters folgendes Log:
2016.09.01 06:59:13.430 4: CUL_send:  CUL0As 11 34 A002 1DA462 278291 04DEFB7A40FD6502
2016.09.01 06:59:13.717 4: CUL_send:  CUL0As 11 34 A002 1DA462 278291 04DEFB7A40FD6502


und beim Schalten eines Aktors:
016.09.01 07:13:24.370 4: CUL_send:  CUL0As 0E 02 A011 1DA462 456779 0201C80000
2016.09.01 07:13:29.307 4: CUL_send:  CUL0As 0E 02 A011 1DA462 456779 0201C80000


Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 01 September 2016, 09:31:29
Hi,

Zitat von: Bytechanger am 01 September 2016, 07:00:43
Ergibt beim Öffnen des Fensters folgendes Log:
2016.09.01 06:59:13.430 4: CUL_send:  CUL0As 11 34 A002 1DA462 278291 04DEFB7A40FD6502
2016.09.01 06:59:13.717 4: CUL_send:  CUL0As 11 34 A002 1DA462 278291 04DEFB7A40FD6502


und beim Schalten eines Aktors:
016.09.01 07:13:24.370 4: CUL_send:  CUL0As 0E 02 A011 1DA462 456779 0201C80000
2016.09.01 07:13:29.307 4: CUL_send:  CUL0As 0E 02 A011 1DA462 456779 0201C80000


Uh, wenn das alles ist, empfängt Dein CUL nichts. Nur der HMLAN empfängt, weswegen im Fenster-Fall der CUL als primäres IO versucht die Challenge zu senden.
Für mich sieht das nach einem HW-Problem des CUL aus.

In Deinem Log von 20:25 gestern Abend waren auch keine empfangenen Frames beim CUL zu sehen, die hätten aber jetzt definitiv auftauchen müssen...

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: frank am 01 September 2016, 09:56:10
ZitatUh, wenn das alles ist, empfängt Dein CUL nichts. Nur der HMLAN empfängt, weswegen im Fenster-Fall der CUL als primäres IO versucht die Challenge zu senden.
Für mich sieht das nach einem HW-Problem des CUL aus.
dazu habe ich mal eine frage?
wenn dem so wäre, dass der cul nichts empfängt, müsste dann nicht fhem die antworten über den hmlan bekommen und die weiteren messages wieder über den cul senden? es heisst doch immer, dass alle io's empfangen, und nach der ersten eingehenden message, egal von wem sie empfangen wurde, fhem reagiert.

gruss frank
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 01 September 2016, 10:01:22
Hallo Frank,

Zitat von: frank am 01 September 2016, 09:56:10
dazu habe ich mal eine frage?
wenn dem so wäre, dass der cul nichts empfängt, müsste dann nicht fhem die antworten über den hmlan bekommen und die weiteren messages wieder über den cul senden? es heisst doch immer, dass alle io's empfangen, und nach der ersten eingehenden message, egal von wem sie empfangen wurde, fhem reagiert.

Ja, deswegen sendet der CUL auch die Challenge raus. Das passt zum List von 19:47 gestern:


   IODev      CUL0
   LASTInputDev HMLAN1


Evtl. kommt die Challenge aber auch nicht beim Fenstersensor an, wenn das Funkmodul einen Defekt hat.

Viele Grüße,
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 01 September 2016, 10:22:16
Dieses Verhalten habe ich auch bei einem Actor.
Also ein CUL Problem??

Wo kann ich hier ansetzen??
Mit dem CUL kann ich ja kommunizieren...
Er hat auch (nachweislich vor einiger Zeit) ordnungsgemäß funktioniert...


Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 01 September 2016, 10:46:31
Einige Test haben nun folgendes ergeben:

Wenn ich im CUL in FHEM ein reopen mache geht zumindest manchmal der statusRequest.

Was auch dagegen spricht ist, wenn ich beim Fensterkontakt AES Signaturanforderung abschalte, gehts...
Also sendet und empfängt der CUL...


Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 01 September 2016, 12:46:11
Hallo,

schalte doch mal testweise Deinen HMLAN ab. Funktioniert dann noch irgendwas? (Die VCCU benutzt dann für alles den CUL)
Wo steckt der CUL dran? Ist die Stromversorgung ausreichend dimensioniert (bei Einplatinencomputern)?

Wenn Dein Log kein vom CUL empfangenen Pakete zeigt, ist irgendwas ausserhalb von CUL_HM kaputt...

EDIT: Achja, bei einem reopen wird der CC1101 auf dem CUL reinitialisiert.

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 01 September 2016, 21:04:48
Tja,

da kommt nix mehr an. Habe mal kurz ein Disconnect Connect im Log gesehen,

also CUL ist defekt oder wie?
Nochmal 50€ für ein neuen??

Geflashed habe ich das Teil schon mehrfach...
Leider ohne Erfolg.

Spannung kann es nicht sein, hab ihn mal an einen USB-Hub mit Spannungsversorgung geklemmt..


Aber das Log liest sich, als käme noch was
2016.09.01 20:59:36.061 4: CUL_Parse: CUL0 0 D2 E2 D07D 3913D0 4
2016.09.01 20:59:36.123 2: CUL0: unknown message 0D2E2D07D3913D04
2016.09.01 20:59:36.123 4: CUL_Parse: CUL0 3 20 00 0060 021656 A
2016.09.01 20:59:36.183 2: CUL0: unknown message 320000060021656A
2016.09.01 20:59:36.184 4: CUL_Parse: CUL0 5 5E 43 023B 900070 0
2016.09.01 20:59:36.244 2: CUL0: unknown message 55E43023B9000700
2016.09.01 20:59:36.245 4: CUL_Parse: CUL0 1 81 46 C070 090876 B
2016.09.01 20:59:36.305 2: CUL0: unknown message 18146C070090876B
2016.09.01 20:59:36.306 4: CUL_Parse: CUL0 F 85 61 1EF2 C1A1F4 1
2016.09.01 20:59:36.308 5: CUL0 dispatch 810f04xx0101a00185611e00f2c1a1f41
2016.09.01 20:59:36.376 3: FS20 Unknown device 8561 (31222312), Button 1e (1243) Code d2 (unknown_d2 1024), please define it
2016.09.01 20:59:36.877 4: CUL_Parse: CUL0 0 05 97 F3F8 8310B0 0
2016.09.01 20:59:37.008 2: CUL0: unknown message 00597F3F88310B00
2016.09.01 20:59:38.011 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.09.01 20:59:38.074 1: Perfmon: possible freeze starting at 20:59:37, delay is 1.073
2016.09.01 20:59:38.573 1: /dev/ttyACM0 reappeared (CUL_0)
2016.09.01 20:59:43.828 1: Perfmon: possible freeze starting at 20:59:41, delay is 2.827
2016.09.01 21:00:02.081 4: CUL_send:  CUL0V     
2016.09.01 21:00:02.092 5: CUL/RAW (ReadAnswer): V 1.61 CUL868

2016.09.01 21:00:46.820 1: Perfmon: possible freeze starting at 21:00:44, delay is 2.819
2016.09.01 21:01:44.799 3: set CUL0 raw e
2016.09.01 21:01:44.800 4: CUL_send:  CUL0e     
2016.09.01 21:01:45.335 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.09.01 21:01:45.392 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 disconnected, waiting to reappear (CUL0)
2016.09.01 21:01:45.811 4: CUL_send:  CUL0V     
2016.09.01 21:01:45.822 5: CUL/RAW (ReadAnswer): V 1.61 CUL868

2016.09.01 21:01:45.823 4: CUL_send:  CUL0?     
2016.09.01 21:01:45.834 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 01 September 2016, 23:26:43
Hallo,

Zitat von: Bytechanger am 01 September 2016, 21:04:48
Tja,

da kommt nix mehr an. Habe mal kurz ein Disconnect Connect im Log gesehen,

also CUL ist defekt oder wie?

Zumindest scheint er die Fehlerursache zu sein.

Zitat
Nochmal 50€ für ein neuen??

Flashe erst nochmal culfw 1.66, die 1.61 ist schon etwas älter, ich bin mir gerade nicht mehr sicher, ob die schon alle HomeMatic-fixes enthält. (Die 1.66 hattest Du anfangs drauf)

Hast Du evtl. nicht-Homematic-Geräte, die über den CUL geschaltet werden? Die dynamische Protokollumschaltung zwischen den einzelnen Funkprotokollen kann evtl. zu komischem Verhalten führen, hier könnte es Bugs in der culfw geben. Wenn ja, welches Protokoll ist das?

Ansonsten in  jedem Fall mal den CUL einfach als Homematic-Sniffer ausserhalb von Fhem betreiben:
- CUL in Fhem auf closed setzen oder ganz disablen
- screen -c /dev/null /dev/serial/by-id/usb-busware.de_CUL868-if00 115200
  (Baudrate ist egal)

Im screen dann erstmal mit "V<ENTER>" schauen, ob der cul überhaupt reagiert. Wenn er das tut, den CUL mit "Ar<ENTER>" in den AskSin(BidCos/HomeMatic)-Empfangsmodus versetzen. Wenn jetzt durch ein Gerät bzw. den HMLAN eine Homematic-Nachricht gesendet wird, sollte diese mit Prefix "A" auftauchen.
Das ganze mal eine Zeit lang mitlaufen lassen und schauen, ob es irgendwann plötzlich aufhört.

Zitat
Aber das Log liest sich, als käme noch was
2016.09.01 20:59:36.061 4: CUL_Parse: CUL0 0 D2 E2 D07D 3913D0 4
2016.09.01 20:59:36.123 2: CUL0: unknown message 0D2E2D07D3913D04
2016.09.01 20:59:36.123 4: CUL_Parse: CUL0 3 20 00 0060 021656 A
2016.09.01 20:59:36.183 2: CUL0: unknown message 320000060021656A


Irgendwelche Bytes schickt der CUL, aber zumindest für mich ist das kein bekanntes Protokoll. Sieht eher zufällig aus.

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 02 September 2016, 08:27:29
Hallo,

jetzt wird es interessant, da ich mehr über die Details erfahre:

Also auch nach einer Stunde empfängt der CUL noch etwas, wenn ich auf der Console schaue:


screen -c /dev/null /dev/serial/by-id/usb-busware.de_CUL868-if00 115200
V 1.66 CUL868
A0C6CA6412782911DA46201A2C835
A0A6C80021DA4622782910016
A0B2FA0011DA462456779010E17
A0A2F80021DA4624567790016
A123080024567791DA4620101C80034DC5B03CCF5
A1131A0024567791DA462049A67E13CF30E02F5
A1931A0031DA46245677923402F43F3898F454A6DDD0FFFEA3DEC16
A123180024567791DA4620101000034F7ECA1C9F3
A11EFA00217E2BB1C58010455493D31949A02D7
A0EEF800217E2BB1C580100E68E1AADD6
A0E32A0111DA462456779020100000015
A1133A0024567791DA462047C4546CBDF6602F5
A1933A0031DA4624567793AE27B08138F4980D85D599B07C6068715
A0E34A4104567791DA4620601C80034F6
A1135A0024567791DA46204767EE69B90FA02F6
A1935A0031DA462456779843BE1887019FA007B7E653DF4ECEB2D15
A1136A0024567791DA46204667E23FD3D9C02F4
A1936A0031DA462456779F097DDEA78A919018C870BDB92C4C8C215
A1142A00241702A408A0A048B790000791E02D9
A1937A0031DA462456779AC98BB9492976D6F2694CD468B57822815
A1143A00241702A408A0A04587E00007E1F02D2
A0E38A4104567791DA4620601000034F5


Greets

Byte


PS: Ich musste "screen" erstmal installieren; Am Schluss musste ich auch ganz schön suchen, bis ich den Ausgang gefunden habe ;-)  Ctrl+A  dann D   macht es
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 03 September 2016, 19:15:08
Hi,

Zitat von: Bytechanger am 02 September 2016, 08:27:29
Also auch nach einer Stunde empfängt der CUL noch etwas, wenn ich auf der Console schaue:


A0E38A4104567791DA4620601000034F5


Sieht gut aus, also scheint der CUL Nachrichten zu empfangen.

Sende testweise mal eine Nachricht:

As09998112999999000000<ENTER>


Empfängt der CUL danach immer noch Nachrichten?

Hast du evtl. nicht-Homematic-Geräte, die den CUL als IO benutzen? Die Protokollumschaltung ist nicht ganz sauber da...

Zitat
PS: Ich musste "screen" erstmal installieren; Am Schluss musste ich auch ganz schön suchen, bis ich den Ausgang gefunden habe ;-)  Ctrl+A  dann D   macht es

Damit hast Du dich nur detached, der screen läuft weiter (reattach mit screen -r).
Wirklich beendet kriegst Du ihn it CTRL-A \ (oder einfach den CUL abziehen).

Viele Grüße
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 05 September 2016, 17:05:50
OK,

bin nun davon ausgegangen, dass der CUL defekt ist.
Habe einen neuen bestellt. Diesen geflashed und installiert...

Leider zeigt er das gleiche Verhalten.
Ich kann also mit großer Sicherheit einen Hardwaredefekt ausschließen.
Nein ich habe keine anderen Devices außer HM.

Benötige also weiterhin Hilfe!

Ach so, kann ich über Putty mit "Maus rechts" in das screen Fenster den Sendebefehl kopieren?
Man bekommt ja keine Optische Rückmeldung, was man eingetippt hat...

Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 05 September 2016, 18:24:46
Hi,

Zitat von: Bytechanger am 05 September 2016, 17:05:50
Leider zeigt er das gleiche Verhalten.
Ich kann also mit großer Sicherheit einen Hardwaredefekt ausschließen.

Ja, scheint so.

Zitat
Nein ich habe keine anderen Devices außer HM.

Ok, dann kann das als Ursache ausgeschlossen werden.

Was bekommst Du denn als Ausgabe, wenn Du das folgende ausfuehrst wenn der CUL in Fhem eingebunden ist?

sudo lsof /dev/ttyACM*

(Evtl. vorher Paket lsof installieren)

Zitat
Ach so, kann ich über Putty mit "Maus rechts" in das screen Fenster den Sendebefehl kopieren?
Man bekommt ja keine Optische Rückmeldung, was man eingetippt hat...

Ja, screen macht da kein lokales Echo. Du koenntest es hoechstens mit einem zweiten CUL im Sniffing-Modus sehen. Aber ich gehe jetzt mal davon aus, dass das alles klappt und Du an dieser Stelle nicht weitersuchen musst.

Viele Gruesse
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 05 September 2016, 19:01:47
So also,

in meinem CUL Log steht:
2016.09.01 19:38:52.970 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:38:52.971 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E
2016.09.01 19:38:54.994 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:38:54.995 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E
2016.09.01 19:39:00.273 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:39:00.274 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E
2016.09.01 19:39:04.303 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:39:04.304 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E


Habe mir da ein As 0B 2C A001 1DA462 456779 010E geschnappt und gesendet und sogar eine Antwort gesehen:
A0E2CA4104567791DA462060100004EF9
A0A2C80021DA462456779002A


Also scheint Senden und Empfangen OK zu sein... Ist ja auch der neue CUL...

sudo lsof /dev/ttyACM*
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
perl    1170 fhem   36u   CHR  166,0      0t0 15157 /dev/ttyACM0
perl    1170 fhem   38u   CHR  166,0      0t0 15157 /dev/ttyACM0


Sieht doch auch gut aus, bis auf die Tatsache, dass er doppelt vorkommt????

Greets

Byte
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: mgernoth am 05 September 2016, 19:23:27
Hi,

Zitat von: Bytechanger am 05 September 2016, 19:01:47
Habe mir da ein As 0B 2C A001 1DA462 456779 010E geschnappt und gesendet und sogar eine Antwort gesehen:
A0E2CA4104567791DA462060100004EF9
A0A2C80021DA462456779002A

Also scheint Senden und Empfangen OK zu sein... Ist ja auch der neue CUL...

Ja, sieht gut aus.

Zitat
sudo lsof /dev/ttyACM*
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
perl    1170 fhem   36u   CHR  166,0      0t0 15157 /dev/ttyACM0
perl    1170 fhem   38u   CHR  166,0      0t0 15157 /dev/ttyACM0


Sieht doch auch gut aus, bis auf die Tatsache, dass er doppelt vorkommt????

Nein, er sollte nur einmal offen sein (ich habe das gerade nochmal sicherheitshalber hier nachgeschaut). Wenn er mehrfach geoffnet wird, kannst Du Dir in Empfangsrichtung nie sicher sein, wo die Bytes genau zugestellt werden. Das wuerde auch Deine "zufaelligen" Bytes in einem aelteren Log erklaeren.

Schau mal in Deine Fhem-Config, der Port muesste da zweimal definiert sein (evtl. einmal nicht als CUL).

Viele Gruesse
  Michael
Titel: Antw:AES mit CUL nicht mehr möglich?
Beitrag von: Bytechanger am 05 September 2016, 21:10:58
Hey,

darauf muss man erstmal kommen, dem war so!!!!
In der FHEM.config war an einer Stelle plötzlich

define CUL_0 CUL /dev/ttyACM0@9600 1034

definiert !!!  Das war ich ganz bestimmt nicht!! Insbesondere weil dort eine ID vergeben wurde, ich habe den CUL immer nur mit 0000 definiert!
Es stand auch mitten zwischen irgend welchen anderen devices ganz alleine ohne weitere attribute !

nach einem Neustart ist er jetzt nur noch einmal drin:

ALSO Stand ist nun:
Die Statusinfos scheinen ohne AES jetzt gut zu laufen.

ABER bei den Fensterkontakten habe ich das problem, dass das ACK offensichtlich nicht an den Fensterkontakt übertragen wird.
Er bleibt sehr lange auf orange um dann später auf ROT zu gehen!

Das Reading aesCommToDev bleibt auch auf "pending"

Das Eventlog:
2016-09-05 21:07:39.753 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:39.955 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.054 CUL_HM EG_FensterBuero aesCommToDev: fail
2016-09-05 21:07:40.054 CUL_HM EG_FensterBuero trig_aes_vccu: fail:238
2016-09-05 21:07:40.249 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.443 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.630 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.825 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero aesCommToDev: ok
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero battery: ok
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero open
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero trig_aes_vccu: ok:238
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero trigger_cnt: 238
2016-09-05 21:07:41.248 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:41.448 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:41.646 CUL_HM EG_FensterBuero aesCommToDev: pending


Log:
2016.09.05 21:07:39.571 5: CUL/RAW: /A0CB8A6412782911DA46201EEC832

2016.09.05 21:07:39.573 4: CUL_Parse: CUL0 A 0C B8 A641 278291 1DA462 01EEC832 -49
2016.09.05 21:07:39.576 5: CUL0 dispatch A0CB8A6412782911DA46201EEC8::-49:CUL0
2016.09.05 21:07:39.579 5: CUL0 sending As11B8A0021DA4622782910455B720B8CF5F02
2016.09.05 21:07:39.581 5: CUL 278291 dly:93ms
2016.09.05 21:07:39.676 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0455B720B8CF5F02
2016.09.05 21:07:39.765 5: CUL/RAW: /A11B8A0021DA462278291046CFA5C12734E0220

2016.09.05 21:07:39.766 4: CUL_Parse: CUL0 A 11 B8 A002 1DA462 278291 046CFA5C12734E0220 -58
2016.09.05 21:07:39.768 5: CUL0 dispatch A11B8A0021DA462278291046CFA5C12734E02::-58:CUL0
2016.09.05 21:07:39.780 5: CUL0 sending As11B8A0021DA4622782910455B720B8CF5F02
2016.09.05 21:07:39.782 5: CUL 278291 dly:96ms
2016.09.05 21:07:39.879 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0455B720B8CF5F02
2016.09.05 21:07:39.977 5: CUL/RAW: /A19B8A2032782911DA4629BA1CAF28A8E0E74D0311507B15B4D8231

2016.09.05 21:07:39.978 4: CUL_Parse: CUL0 A 19 B8 A203 278291 1DA462 9BA1CAF28A8E0E74D0311507B15B4D8231 -49.5
2016.09.05 21:07:39.980 5: CUL0 dispatch A19B8A2032782911DA4629BA1CAF28A8E0E74D0311507B15B4D82::-49.5:CUL0
2016.09.05 21:07:40.074 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.075 5: CUL 278291 dly:95ms
2016.09.05 21:07:40.172 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.264 5: CUL/RAW: /A0CB8A2412782911DA46201EEC831

2016.09.05 21:07:40.265 4: CUL_Parse: CUL0 A 0C B8 A241 278291 1DA462 01EEC831 -49.5
2016.09.05 21:07:40.267 5: CUL0 dispatch A0CB8A2412782911DA46201EEC8::-49.5:CUL0
2016.09.05 21:07:40.271 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.272 5: CUL 278291 dly:94ms
2016.09.05 21:07:40.368 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.456 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.458 5: CUL 278291 dly:96ms
2016.09.05 21:07:40.555 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.652 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.653 5: CUL 278291 dly:96ms
2016.09.05 21:07:40.751 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.846 5: CUL/RAW: /A19B8A2032782911DA462AD0AE0625856903C68231A56B9CF4D032E
A0CB8A2412782911DA46201EEC82A

2016.09.05 21:07:40.847 4: CUL_Parse: CUL0 A 19 B8 A203 278291 1DA462 AD0AE0625856903C68231A56B9CF4D032E -51
2016.09.05 21:07:40.849 5: CUL0 dispatch A19B8A2032782911DA462AD0AE0625856903C68231A56B9CF4D03::-51:CUL0
2016.09.05 21:07:40.858 5: CUL0 sending As11B880021DA4622782910101C800299e8100
2016.09.05 21:07:40.860 5: CUL 278291 dly:88ms
2016.09.05 21:07:40.949 4: CUL_send:  CUL0As 11 B8 8002 1DA462 278291 0101C800299e8100
2016.09.05 21:07:41.069 4: CUL_Parse: CUL0 A 0C B8 A241 278291 1DA462 01EEC82A -53
2016.09.05 21:07:41.072 5: CUL0 dispatch A0CB8A2412782911DA46201EEC8::-53:CUL0
2016.09.05 21:07:41.075 5: CUL0 sending As11B8A0021DA46227829104BBD4EC49089D02
2016.09.05 21:07:41.077 5: CUL 278291 dly:94ms
2016.09.05 21:07:41.172 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 04BBD4EC49089D02
2016.09.05 21:07:41.274 5: CUL0 sending As11B8A0021DA46227829104BBD4EC49089D02
2016.09.05 21:07:41.275 5: CUL 278291 dly:96ms
2016.09.05 21:07:41.373 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 04BBD4EC49089D02
2016.09.05 21:07:41.471 5: CUL0 sending As11B8A0021DA46227829104BBD4EC49089D02
2016.09.05 21:07:41.472 5: CUL 278291 dly:96ms
2016.09.05 21:07:41.570 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 04BBD4EC49089D02


Auch wenn ich aesCommReq auf 0 setze läuft es nicht rund:

Eventmonitor:
2016-09-05 21:09:01.423 LaCrosse Thermo_KuehlschrankHund temperature: -0.3
2016-09-05 21:09:01.493 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero battery: ok
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero contact: closed (to vccu)
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero closed
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero trigger_cnt: 239
2016-09-05 21:09:01.778 CUL_HM EG_FensterBuero aesCommToDev: fail
2016-09-05 21:09:01.778 CUL_HM EG_FensterBuero trig_aes_vccu: fail:239
2016-09-05 21:09:01.987 CUL_HM EG_FensterBuero aesCommToDev: fail
2016-09-05 21:09:01.987 CUL_HM EG_FensterBuero trig_aes_vccu: fail:239


Log:

2016.09.05 21:09:01.504 5: CUL/RAW: /A0CB9A6412782911DA46201EF0031

2016.09.05 21:09:01.505 4: CUL_Parse: CUL0 A 0C B9 A641 278291 1DA462 01EF0031 -49.5
2016.09.05 21:09:01.507 5: CUL0 dispatch A0CB9A6412782911DA46201EF00::-49.5:CUL0
2016.09.05 21:09:01.515 5: CUL0 sending As0DB980021DA4622782910101C800
2016.09.05 21:09:01.517 5: CUL 278291 dly:89ms
2016.09.05 21:09:01.608 4: CUL_send:  CUL0As 0D B9 8002 1DA462 278291 0101C800
2016.09.05 21:09:01.796 5: CUL/RAW: /A0CB9A2412782911DA46201EF0030

2016.09.05 21:09:01.797 4: CUL_Parse: CUL0 A 0C B9 A241 278291 1DA462 01EF0030 -50
2016.09.05 21:09:01.799 5: CUL0 dispatch A0CB9A2412782911DA46201EF00::-50:CUL0
2016.09.05 21:09:01.803 5: CUL0 sending As0DB980021DA4622782910101C800
2016.09.05 21:09:01.804 5: CUL 278291 dly:94ms
2016.09.05 21:09:01.900 4: CUL_send:  CUL0As 0D B9 8002 1DA462 278291 0101C800


Ist das bei Euch auch so mit AES und dem HM-SEC-SC-2. Der steht im Register sign auf ON.

Der Aktor HM-LC-Sw1-Pl-DN-R1 läuft ohne Probleme auf AES !!!!!
Ein Implementierungsfehler des HM-SEC-SC-2??


********* Da ein Problem, dass nicht mehr ganz zum Titel passt, mache ich einen neuen Thread auf!


Greets

Byte