HM-LGW-O-TW-W-EU-2 / CUL als VCCU und AES

[Klinki]

hmKey  unkenntlich machen...

Warum? Der AES-Key wird nur als Hash gespeichert und lässt sich nicht rück-ermitteln. Das Passwort für das LAN-GW habe ich aber rausgestrichen 

Aber unrecht hast Du nicht. Es kann nicht schaden...

[Otto123]

...mag ja sein, aber nochmal: Sowohl CUL als auch LGW haben die vccu als Owner. Das meinte ich mit "...richtig sein"

Hi,

ich weiß nicht genau wann das Owner gesetzt wird, aber was Frank sagt hat schon seine Berechtigung.
Das hier ist wichtig-> STATE      CUL_0:ok,meinLGW:ok,
Und ich glaube das wird nicht dagestanden haben, solange wie in Deiner IOList ein Leerzeichen war. Da wurde das LGW nämlich nicht verwendet.

Gruß Otto

[Klinki]

ich weiß nicht genau wann das Owner gesetzt wird, aber was Frank sagt hat schon seine Berechtigung.
Das hier ist wichtig-> STATE      CUL_0:ok,meinLGW:ok,
Und ich glaube das wird nicht dagestanden haben, solange wie in Deiner IOList ein Leerzeichen war. Da wurde das LGW nämlich nicht verwendet.

Ich habe mich vielleicht misverständlich ausgedrückt: Natürlich habe ich Frank´s Bemerkung ernst genommen und das Leerzeichen auch rausgelöscht.

Das war´s leider nicht.

Aber es ändert nichts an der Tatsache, dass es jetzt nicht mehr da ist, CUL und LGW als owner die vccu eingetragen haben. Es jetzt also in Ordnung sein sollte (-so ich hoffe).
Leider funktioniert es jetzt immer noch nicht.

Ich hatte zwischenzeitlich auch versucht, den HMKey beim LGW als Attribut zu hinterlegen. Obwohl die Signierung ja von der vccu kommen sollte (wie auch von Otto schon beschrieben).
Brachte jedenfalls keine Änderung.

Wenn euch auch keine Fehler mehr auffallen, würde ich die Definitionen von IOs und vccu noch mal neu machen.

gruß
klinki

[automatisierer]

Also Zusammenfassung:
HM_LGW war nicht assigned 》somit war der schon mal raus.

Der CUL hat eine ungeignete Firmware und ist als prefIO gesetzt.

somit sollte klar sein, warum dein AES nicht funktioniert.

Gruß
Ingo

[Klinki]

Der CUL hat eine ungeignete Firmware und ist als prefIO gesetzt.

Verstehe ich nicht: was hat denn der CUL damit zu tun, wenn über LGW keine AES-Signierung stattfindet?

Hinweis am Rande: Die Kommunikation über LGW funktioniert grundsätzlich. Sogar mit CUL/LGW-Roaming (man latscht...) - nur nicht mit AES-Signierung


EDIT: Den CUL gegen einen nanoCUL mit aktueller FW 1.67 getauscht. Keine Änderung

[Klinki]

VCCU und alle IOs noch einmal komplett neu angelegt. Diesmal von Anfang an ohne Leerzeichen 
Fhem neu gestartet.
Keine Änderung.

LGW und fhem-Raspi spannungsfrei gemacht und neu gestartet.
Die AES-Sgnierung funktioniert jetzt in ca. 30% der Versuche!
An der Empfangsqualität im Bereich des LGW kann es eigentlich nicht liegen. Bei Kanälen der gleichen FB ohne AES-Request funktioniert die Kommunikation bei 100% der Versuche.

Es sieht also so aus, als wenn das LAN-Gateway das Problem ist. Ich werde weiter probieren und berichten!

Danke für euren Rat!

[mgernoth]

Hallo,

Mittlerweile funktioniert über das Lan Gateway überhaupt kein AES mehr. Beim folgenden Versuch liegt das LGW nicht mehr direkt neben mir und der CUL, welcher ebenfalls zur virtuellen CCU gehört, ist (gerade eben) noch in Reichweite.

Tja, aber dummerweise wird trotzdem der CUL und nicht das LAN-Gateway zum senden verwendet:

Code Auswählen Erweitern


2017.01.05 07:25:56.285 4: CUL_Parse: CUL_0 A 0B F7 A240 39776C F0815F 432CC7 -102.5
2017.01.05 07:25:56.386 4: CUL_send:  CUL_0As 11 F7 A002 F0815F 39776C 043ECE84C309EF02


CUL empfängt (gerade noch) die FB und sendet die Signaturanforderung. Die kommt beim LGW (wahrscehinlich wegen Entfernung) gar nicht an.

Code Auswählen Erweitern


2017.01.05 07:25:56.515 4: CUL_send:  CUL_0As 11 F7 A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.539 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: F7 A0 02 F0815F 39776C 043ECE84C309EF02


Cul sendet 2. Signaturanforderung, kommt diesmal beim LGW an, nicht aber bei der Fernbedienung

Code Auswählen Erweitern


2017.01.05 07:25:56.556 0: HMUARTLGW meinLGW recv: 01 05 00 00 32 msg: F8 A2 40 39776C F0815F 432C


FB wiederholt request, kommt nur bei LGW an, nicht bei CUL. CUL sendet aber wieder AES challenge, da er präferiert ist und funktioniert:

Code Auswählen Erweitern


2017.01.05 07:25:56.660 4: CUL_send:  CUL_0As 11 F8 A002 F0815F 39776C 043ECE84C309EF02


Wenn Du die FB auf den CUL festnagelst, macht das LGW nie AES (bzw. redet gar nicht mit dem Gerät), ausser der CUL ist offline. Das ist normal.

Wenn Du AES mit Roaming machst, geht der erste Request meistens schief, da die VCCU die FB erst dem LGW bekannt machen muss, bevor dieses den AES-Request beantwortet. Das geht aber natürlich erst, wenn der Tastendruck beim LGW angekommen ist (und dann ist es zu spät, das GW wird erst auf den nächsten _neuen_ (nicht wiederholten) Tastendruck reagieren).

Viele Grüße
  Michael

[Klinki]

Hallo Michael,

Vielen Dank für die informative Antwort!
Was ich dabei allerdings nicht so recht verstehe ist, dass die FB zuerst mit dem CUL redet - auch wenn die rssi deutlich schlechter ist. Vermutlich weil der CUL als letzter Gesprächspartner bekannt ist, oder?

Nur verstehe ich auch nicht, warum es vor dem Kaltstart des LGWs gar nicht mehr mit AES geklappt hatte.

Das schlechte Roaming-Verhalten werde ich mal beobachten.
Könnte man, sozusagen als workaround, die FB ausschließlich am LGW anlernen und gar nicht die vccu nutzen? Rein praktisch geht es darum in einem bestimmten Bereich die FB benutzen zu können. Dieser wird vollständig vom LGW abgedeckt.

gruß
klinki

[automatisierer]

Hallo Michael,

Vielen Dank für die informative Antwort!
Was ich dabei allerdings nicht so recht verstehe ist, dass die FB zuerst mit dem CUL redet - auch wenn die rssi deutlich schlechter ist. Vermutlich weil der CUL als letzter Gesprächspartner bekannt ist, oder?

Nur verstehe ich auch nicht, warum es vor dem Kaltstart des LGWs gar nicht mehr mit AES geklappt hatte.

Das schlechte Roaming-Verhalten werde ich mal beobachten.
Könnte man, sozusagen als workaround, die FB ausschließlich am LGW anlernen und gar nicht die vccu nutzen? Rein praktisch geht es darum in einem bestimmten Bereich die FB benutzen zu können. Dieser wird vollständig vom LGW abgedeckt.

gruß
klinki

du hattest bei der FB den CUL als prefIO gesetzt, wenn du den LGW nutzen willst, dann musst du den als preffIO setzen und das wars... Dann antwortet der auch der FB.

[Klinki]

du hattest bei der FB den CUL als prefIO gesetzt

habe ich nicht. Das macht fhem von ganz alleine.
Genauso wie es auch umsetzt ein anderes preferredIO zu nehmen, falls das erste nicht erreichbar ist. Genau das darf NICHT passieren. Die FB darf NUR mit dem LGW sprechen

[automatisierer]

beim ersten pairen, wird dem Device automatisch ein prefIO zugewiesen. Richtig!

Das verändert FHEM danach aber nicht mehr selbstständig!!

Wenn du ein anderes prefIO nutzen möchtest, dann musst du das von Hand in dem Attribut ändern!

wenn du kein preffIo vergibst, also bei dem Attribut IOgrp nur vccu einträgst - ohne :CUL Dann entscheidet die vccu selbst über welches IO das Device angesprochen wird.

Also, prefIO bedeutet:

Code Auswählen Erweitern

attr <device> IOgrp vccu:CUL
oder

Code Auswählen Erweitern

attr <device> IOgrp vccu:hmLGW

ohne prefIO bedeutet:

Code Auswählen Erweitern

attr <device> IOgrp vccu

Das kann man auch alles schön im Wiki nachlesen:

https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU

[Klinki]

ja, ich kann lesen. Aber noch mal: Auch wenn das LGW als prefIO gesetzt ist; die fb nutzt den CUL, wenn das LGW nicht erreichbar ist. Das bedeutet nun mal "preffered".
Beim nächsten Senden schickt die FB den ersten Befehl an das letzte erreichbare IO. Falls das der CUL war, läuft die AES-Sgnierung schief.
Ich habe es ausprobiert.

Wie dem auch sei: Meine Frage lautet, ob man verhindern kann, dass die FB überhaupt mit dem CUL redet.

Vielleicht ist das mit prefio aber auch praxis-tauglich genug. Das werde ich mal testen.

Wenn ich wieder vor Ort bin, werde ich mal ausprobieren, was passiert wenn die FB an das LGW angelernt wird. Ohne vccu...
schau mer mal

[automatisierer]

ja, ich kann lesen. Aber noch mal: Auch wenn das LGW als prefIO gesetzt ist; die fb nutzt den CUL, wenn das LGW nicht erreichbar ist. Das bedeutet nun mal "preffered".
Beim nächsten Senden schickt die FB den ersten Befehl an das letzte erreichbare IO. Falls das der CUL war, läuft die AES-Sgnierung schief.
Ich habe es ausprobiert.

so ein Schwachsinn! Die FB sendet Funkwellen aus und die werden von allen IO's empfangen! Mit preffIO legst du fest, mit welchem IO FHEM(die vccu) antwortet und nicht mit welchem IO die FB spricht. Die vccu entscheidet entweder spontan mit welchem IO sie antwortet, oder sie antwortet mit dem preffIO - wenn eingetragen. Sollte die FB diese Antwort dann nicht empfangen können, weil sie außerhalb der Reichweite des preffIO ist, dann is halt nix mit ACK oder AES oder was auch immer!! Der einzige Grund, wesshalb die vccu den preffIO nicht nutzt, ist, wenn dieser nicht

Code Auswählen Erweitern

cond    ok      2017-01-05 17:58:29
in den Readings stehen hat (die Uhrzeit kann von der im Beispiel abweichen)

Gründe wären zum Beispiel ein overload oder ein diconnect. Damit die HM-Installation dann nicht für diese Zeit tot ist, versucht die vccu ihr bestes über einen anderen IO - sofern ein weiterer vorhanden ist.

Wie dem auch sei: Meine Frage lautet, ob man verhindern kann, dass die FB überhaupt mit dem CUL redet.

Stöpsel ihn aus oder wickel ihn in Alufolie!

Vielleicht ist das mit prefio aber auch praxis-tauglich genug. Das werde ich mal testen.

das ist sogar sehr praxistauglich! Funktioniert bei mir und vielen Anderen 100%ig.

Wenn ich wieder vor Ort bin, werde ich mal ausprobieren, was passiert wenn die FB an das LGW angelernt wird. Ohne vccu...
schau mer mal

mir fällt nix mehr ein!

[Klinki]

so ein Schwachsinn! Die FB sendet Funkwellen aus und die werden von allen IO's empfangen! Mit preffIO legst du fest, mit welchem IO FHEM(die vccu) antwortet und nicht mit welchem IO die FB spricht. Die vccu entscheidet entweder spontan mit welchem IO sie antwortet, oder sie antwortet mit dem preffIO - wenn eingetragen. Sollte die FB diese Antwort dann nicht empfangen können, weil sie außerhalb der Reichweite des preffIO ist, dann is halt nix mit ACK oder AES oder was auch immer!!

Du sagst es doch selbst: Die erste Kommunikation mit AES schlägt fehl. PreffIO hin oder her.

Es bringt mir also an dieser Stelle einfach Nichts. Punkt. Nimm´s hin

[Klinki]

Um aber wieder sachlicher zu werden:

Ich habe es grad mal durchgespielt:
- Wenn das LGW Teil einer VCCU ist, kann man auch kein Device nur an das LGW anlernen. Es hat als IOgrp dann doch immer die vccu. Dass nur die eine FB den CUL also ignoriert scheint nicht zu funktionieren
- Wenn die FB im Funkbereich des CUL war und betätigt wurde, schlägt die erste Kommunikation über das LGW in 30% der Fälle fehl. Wenn das preffIO-Attribut auf das LGW gesetzt wurde nur in ca. 10% der Fälle
- Wenn man umgekehrt in den Bereich des NICHT-preferred IOs kommt, schlägt die AES-Signierung in 80% der Fälle fehl (wenn man wiederholt am gleichen Standort drückt). "Roamt" man in den Bereich des NICHT-preferred IOS funktioniert die AES-Signierung beim ersten Mal drücken eigentlich nie.

Mein Fazit:
Mit gesetztem preferredIO-Attribut funktioniert die FB also im gefragten Bereich ausreichend gut.

EDIT: Nachtrag: Wenn man die FB mit AES-Signierung mit allen FunkIOs nutzen will, muss man hinnehmen, dass die AES-Signierung wahrscheinlich beim ersten Mal fehlschlägt nachdem man "geroamt" hat.

Danke an alle Beteiligten!