VCCU mit HMLAN und CUL macht Probleme bei AES, CUL_HM Fehler ?

[Bytechanger]

Hallo,

ich habe seit längerer Zeit Probleme mit AES-Signierten Fensterkontakten ( HM-SEC-SC-2 ). Wenn Sie über VCCU und den CUL kommunizieren, dann funkt
(laut Aussage noansi aus dem CUL Firmware-Forum) das HMLAN in den Verkehr dazwischen und die Signierung wird nicht erkannt.

In diesem Forum wurde ich gebeten, das Problem hier zu posten, da es nur über CUL_HM gelöst werden kann

Der Multi-IO Betrieb hat wohl so seine Tücken, die aber nicht auf Firmwareebene gelöst werden können, sondern es muss in CUL_HM gelöst und getrennt werden, welches device von welchem IO bedient wird. Sonst kann keines das Timing sauber halten.
HMLAN darf jedenfalls nicht (ungestraft  ) einfach so in die CUL Kommunikation eingreifen.

https://forum.fhem.de/index.php?topic=24436.new;topicseen#new

Beim Betrieb über vccu:CUL0 steht immer in den Readings "aesCommToDev pending" und der Statuswechsel wird nicht akzeptiert!
Der CUL ist mit einem HMLAN in einer vccu zusammengefasst. Kommuniziert der HMLAN mit den Fensterkontakten, geht es!

Meine gesnifften Datenpakete liegen auch in diesem Forum mit einer ersten Analyse: https://forum.fhem.de/index.php/topic,24436.msg552833.html#msg552833

Das Problem besteht schon länger, ich dachte nach Aussage von martin, dass ich es über die Timestamp-Firmware lösen könnte. Das Problem scheint jedoch im VCCU "Mischbetrieb" zu bestehen,
dass das HMLAN in die Kommunikation zwischen CUL und Fensterkontakt zwischenfunkt!?

Greets

Byte

[Bytechanger]

Kann niemand mein Provlem mit HMLAN und CUL in vccu bei einem gensterkontakt mit aes nachvollziehen?

Bei der CUL kommunikation scheint hmlan dazwischen zu funken...

Gruß

Byte

[Bytechanger]

@martin876:  Könntest Du einmal prüfen, ob es ein CUL_HM VCCU Problem mit der Kombination HMLAN und CUL unter Verwendung von AES bei Sensoren gibt?
                      Aktoren funktionieren wunderbar, nur scheint der HMLAN bei  den Fenstersensoren dazwischenzufunken....


Das (Fenstersensoren) und die Rauchmelder SD2 Geschichte sind die einzigen, die derzeit nicht richtig laufen....
AES in FHEM scheint wirklich "tricky" zu sein und nicht ganz so rund zu laufen. Ich kann die neuen Rauchmelder normal ansprechen (TeamCall, etc.) Aber ein getConfig läuft immer vor die Wand.
Die alten SD funktionieren aber...

Greets

Byte

[tndx]

Kann niemand mein Provlem mit HMLAN und CUL in vccu bei einem gensterkontakt mit aes nachvollziehen?

Bei der CUL kommunikation scheint hmlan dazwischen zu funken...

Ich kann das Problem sehr gut nachvollziehen. Bei mir ist es zwar die Kombination aus NanoCUL und HMUARTLGW (s. https://forum.fhem.de/index.php/topic,62680.msg548322.html#msg548322), aber das Problem ist höchstwahrscheinlich das Gleiche, von Ansgar habe ich auch eine ähnliche Antwort bekommen, dass es über die TS-SW alleine nicht zu lösen sei.

Außerdem wird hier auch von einem ähnlichen Problem berichtet: https://forum.fhem.de/index.php/topic,63284.msg545289.html#msg545289

[noansi]

Hallo Leute,

nutzt Ihr das aktuelle 10_CUL_HM.pm Modul    # $Id: 10_CUL_HM.pm 13085 2017-01-15 13:24:15Z martinp876 $

Michael hat da eine Änderung einfließen lassen, die das aesComReq Problem bei Mischbetrieb CUL etc. mit HMLAN etc.und VCCU IO Verwaltung hoffentlich entschärft.

Gruß, Ansgar.

[Bytechanger]

Hallo,

also habe ein UPDATE gemacht und eine neue 10_CUL_HM.pm kam rein.
Erste Test sehen vielversprechend aus !!!!
Danke martinp876

Greets

Byte

[SofB]

ich habe auch das Problem. Genutzt wird ein hmlan adapter und ein raspi aufsatz.
vielleicht sollte ich AES ja mal wieder anschalten und testen.
Bei mir blieben immer einige Jalos geschlossen/offen wenn ich AES einsetzte und die Gruppen schaltete.

[Klinki]

Moin,

Hatte bis dato auch das Problem. Lange und breit hier diskutiert: https://forum.fhem.de/index.php/topic,63284.0.html

Soeben das Update eingespielt. Bisher läuft es!

Danke für das Update!

[Klinki]

Nach ein paar Tagen des testens läuft es immer noch bestens!

Das Roaming klappt noch nicht immer beim ersten Mal.
Wenn man immer nur im Empfangsbereich eines meiner beiden Funk-I/Os die Tasten drückt, funktioniert es nahe 100%.

Muss ich das LGW dann doch nicht im See versenken 

Vielen Dank an die Macher!

[SofB]

Bei mir laufen die Jalos nun auch super. Selbst wenn ich alle in einer Gruppe schalte. Wenn ich die Daten richtig interpretiere, so wird der Sendeversuch mit AES mehrmals unternommen.
Nun habe ich noch versucht, meine 6 fach Wandtaster auf AES umzustellen. Kann es sein, dass ein LONG press nicht mit AES realisierbar gemacht werden kann?
Ansonsten Hut ab für die prima Umsetzung!

[Klinki]

...wieder sind ein paar Tage vergangen. Heute morgen ging es wieder nicht. Bestimmt 15 Versuche jedes Mal den Eintrag "aesCommToDev: pending".
Ich habe daraufhin das LAN-Gateway über fhem neu gestartet ("restart"). Keine Änderung.

Danach das Gateway über die "LAN Konfigurator"-Anwendung neu gestartet. Danach ging es wieder auf Anhieb.

gruß
klinki

[mgernoth]

Hallo,

...wieder sind ein paar Tage vergangen. Heute morgen ging es wieder nicht. Bestimmt 15 Versuche jedes Mal den Eintrag "aesCommToDev: pending".

Ich habe nochmal Deine alten Beiträge angeschaut: Du hast die Firmware des LGW nicht auf 1.1.5 aktualisiert, deshalb ist es nicht stabil.

Viele Grüße
  Michael

[Klinki]

aha. Hast Du vielleicht noch einen Tipp wo ich die Firmware finde? Auf der eq3-Seite hab ich nichts gefunden.

Auf der Homemeatic-Inside-Seite stand zumindest ein Hinweis, dass es die 1.1.5 geben soll. Aber ohne Download-Angabe.

vielleicht bin ich auch nur zu blind...

EDIT: Gefunden: https://wiki.fhem.de/wiki/HM-LGW-O-TW-W-EU_Funk-LAN_Gateway#Firmware

[Klinki]

ein ganz schöner Murks... "Bootloader konnte nicht gestartet werden"...keine Fehlermeldung, aber auch kein Update....10 Mal neu gestartet...
jetzt ist die 1.1.5er LAN und 1.4.1 App-Firmware jedenfalls drin.

dann schauen wir mal, was die nächsten Tage bringen.
Danke, Michael, für den Hinweis

[Klinki]

In den zwei Wochen gab es keine Probleme mehr.

Das Grad wird grüner