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
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
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
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
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
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
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
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
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
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
Du hast auch einen CUL und eine VCCU??
Wie kann ich noch weitergehende Logs senden??
Greets
Byte
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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