aesCommReq und CUL bei HM-SEC-SC-2 BUG??

[Bytechanger]

Hallo zusammen,

ich betreibe Homematic über eine VCCU und habe dort ein HMLAN und einen CUL angeschlossen.
Meine Kommunikation verläuft über AES-Signierung.

Da die Zustände an die Zentrale gemeldet werden habe ich in den devices aesCommReq auf 1 gesetzt.
Über HMLAN oder bei deaktiviertem  aesCommReq funktioniert alles einwandfrei:

ABER sobald die Kommunikation über CUL laufen muss (bessere Empfangswerte) scheint die AES Kommunikation gestört zu sein und
die Zustandsänderungen werden von der Zentrale NICHT akzeptiert! Damals gab es schon mal ein Problem mit der Rückmeldung an das
Device, aber die Eigentliche Zustandsänderung wurde akzeptiert... Nun kann ich aber AES mit CUL NICHT benutzten...
Da scheint sich ein BUG eingeschlichen zu haben!

EVENTMONITOR:

Code Auswählen Erweitern

2016-08-28 08:25:00 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-08-28 08:25:00 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-08-28 08:25:00 CUL_HM EG_FensterBuero aesCommToDev: ok
2016-08-28 08:25:00 CUL_HM EG_FensterBuero battery: ok
2016-08-28 08:25:00 CUL_HM EG_FensterBuero contact: closed (to vccu)
2016-08-28 08:25:00 CUL_HM EG_FensterBuero closed
2016-08-28 08:25:00 CUL_HM EG_FensterBuero trig_aes_vccu: ok:51
2016-08-28 08:25:00 CUL_HM EG_FensterBuero trigger_cnt: 51
2016-08-28 08:25:01 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-08-28 08:25:01 CUL_HM EG_FensterBuero aesCommToDev: pending

im Device:
aesCommToDev pending 2016-08-28 08:25:47

Greets

Byte

[Bytechanger]

Hat niemand das gleiche Problem, oder nutzt niemand CUL mit AES bei den Fensterkontakten?

Greets

Byte

[Bytechanger]

Bin etwas ratlos,

ich habe nun mal eine ältere 00_CUL.pm und auch CUL Firmware 1.61 aufgespielt.
Das gleiche Verhalten.

@Martin876: Ich benötige mal Deine Hilfe. Aus einem mir unersichtlichen Grund werden AES-Signierte Meldungen über CUL ignoriert...


Greets

Byte

[Bytechanger]

Im Zuge meiner Tests ist mir in Bezug auf VCCU aufgefallen, dass

ich bin davon ausgegengen dass im Device das Attribut

Code Auswählen Erweitern

IOgrp vccu:HMLAN1
dafür sorgt, dass die VCCU benutzt wird mit HMLAN1 als preferred.
Zusätzlich steht dort noch

Code Auswählen Erweitern

IODev HMLAN1
was aber ignoriert werden sollte (siehe Post: https://forum.fhem.de/index.php/topic,56108.msg476785.html#msg476785)
Allerdings schaut FHEM offensichtlich nur nach IODev, da ein IOgrp vccu:HMLAN1 und ein IODev CUL0 dazu führt, das CUL0 benutzt wird.

Sollte die VCCU beim Senden gar nicht benutzt werden, erklärt dies meinen Fehler, da mein CUL keine HMID hat, sondern diese über die VCCU bekommen sollte...


Greets

Byte