Sorry, habe eine weitere Fragen zur AES und den Erläuterung im Wiki und er CommandRef.
Zusammenfassung:Auszug Wiki A):
ZitatZentrale <-> IO-Device
Homematic unterstützt AES auf dieser Strecke, dies ist in FHEM allerdings nicht implementiert. Nutzt man eine CCU(2) anstelle von FHEM als Zentrale, kann hier AES aktiviert werden. Wenn FHEM die Zentrale ist, muss im HMLAN Konfigurator die Netzwerkseitige AES-Verschlüsselung über die HM-PC-Software abgeschaltet werden, sonst kann FHEM nicht mit dem HMLAN Konfigurator kommunizieren.
Auszug Wiki B)
ZitatIO <-> Gerät
Dieses Teilstück kann mit AES gesichert werden. Es kann ein HMLAN Konfigurator, HM-CFG-USB USB Konfigurations-Adapter oder seit dem 28.6.2015 ein CUL-kompatibles Gerät genutzt werden
Auszug CommandRef C):
ZitataesCommReq wenn gesetzt wird HMLAN/USB AES signature anfordern bevor ACK zum Device gesendet wird.
Die Funktion abeitet aktuell nur mit HMLAN/USB.
Fragen:Wann gilt nun diese Aussage?
Auszug Wiki D):
ZitatAktivieren, Einrichten, Umgang in FHEM
Die Zentrale kann ebenfalls eine AES-Signatur von einem Gerät anfordern, so sie einen Trigger empfängt. Hierzu ist im Device (und evtl. entsprechendem Kanal) eines Geräts das Attribut aesCommReq auf 1 zu setzen
Kann "aesCommReq 1 " nur gesetzt werden, wenn FHEM die Zentrale ist und HMLAN/USB verwendet werden, also nicht bei Einsatz von FHEM und einem CUL (z.B. Busware-CUL)?
Stimmt diese Restriktion noch ?
Gruß
Leeloo
die cul-familie kann kein aes, sondern fhem übernimmt hier die aes-signierung.
eigentlich sollten alle aes-aspekte auch mit cul funktionieren.
allerdings sind timingprobleme mit cul grundsätzlich möglich, die durch zusätzliche aes-nutzung sicherlich nicht besser werden. ;)
mir scheint es, dass du eher ein theoretiker bist. ich würde es einfach probieren und schauen, ob es funktioniert. falls nicht, würde ich das forum nach "aesCommReq" durchsuchen, um zu sehen, ob es ein grundsätzliches problem damit gibt.
Hallo,
also, Wiki A bezieht sich auf die Verbindung FHEM mit IO-Gerät, also HMLan / HM-Cfg-Usb / CUL, usw.
Hier findet KEINE Verschlüsselung statt. Ist i.d.R. auch nicht notwendig, da sich dieses Gerät im "vertrauenswürdigen" Netz befinden sollte (also direkt am FHEM-Gerät oder per Lankabel im heimischen Netz.
Ich habe beide Geräte über eine VCCU im Einsatz. Also einen CUL und eine HMLAN.
Dabei geht AES ganz gut.
Grundsätzlich funktioniert es so:
Gerät ist mit Zentrale (FHEM) gepairt.
Es meldet FHEM also einen Zustand, FHEM (sobald aesCommReq als Attribut gesetzt) fordert eine Bestätigung beim Gerät, das Gerät schickt eine AES-Signierte Bestätigung
FHEM setzt das mitgeteilte Ereignis um und Bestätigt dass auch dem Gerät, dass mit ACK reagiert (grüne Lampe bestätigt z.B. bei Fensteröffner).
Also aesCommReq befindet sich nur in FHEM und beeinflusst das Verhalten von FHEM.
Bei meinen Fensterkontakten sieht es ohne AES so aus, dass bei Zustandsänderung kurz das grüne LED leuchtet.
Ist AES aktiviert. Dann leuchtet es orange, während die Signaturprüfung in FHEM stattfindet, meldet FHEM OK zurück, leuchtet der Fensterkontakt dann grün.
Die Geräte können aber auch mit anderen Geräten gepeert werden. Dann läuft die Kommunkation anders (wie im auch im Wiki beschrieben), aber dass ist ja nicht Bestandteil der Frage.
Greets
Byte
Hallo zusammen.
ich kann Euch beruhigen. Nein, ich bin wirklich kein Theoretiker. Grundsätzlich gehe ich pragmatisch an Aufgaben und Probleme heran.
Erst wenn ich mit der Praxis und der Theorie nicht mehr weiterkomme oder Unklarheiten und ggf. Wiedersprüche entdeckte, wende ich mich mit Fragen an andere.
Im speziellen Fall "FHEM-Forum" erst dann, wenn ich mir ganz sicher bin, dass ggf. auch andere von meinen Fragen und Anregungen profitieren können.
Zurück zur Theorie, um die Praxis für nachfolgende transparenter zu machen.
=> Text zur Ergänzung/Anpassung des Wiki
...
Grundsätzlich unterstützt die Zentrale (FHEM) alle AES-Aspekte. Also:
Zentrale <-> IO-Device
IO <-> Gerät
Gerät <-> Gerät
Einschränkung: Bei Verwendung eines CUL kann es zu Timeing-Problemen kommen. Ggf. ist genau zu Prüfen, wann ein Gerät zwingend (z.B.: Alarm-/Sicherheit) mittels AES mit der Zentrale kommunizieren soll (siehe dazu atrr aesCommReq 1).
...
Stimmt es so?
Wenn es passt, dann rein ins Wiki. Es kann nur Helfen.
Gruß
Leeloo
Zitat von: frank am 30 Juni 2016, 10:25:21
mir scheint es, dass du eher ein theoretiker bist.
Hallo Frank
kann aber auch sein, das in der commandref oder im Wiki noch etwas falsch/alt steht. Dann wäre es ja auch schön es zu korrigieren 8)
Immerhin konnte die cul Stick Family ja vor einiger Zeit noch gar kein AES, jetzt kann sie es immerhin mit Hilfe von FHEM ;)
Wiki ändern könnte ich machen ...
Allerdings ist die Aussage noch in der commandref für CUL_HM drin
ZitataesCommReq wenn gesetzt wird HMLAN/USB AES signature anfordern bevor ACK zum Device gesendet wird.
Die Funktion abeitet aktuell nur mit HMLAN/USB.
Die müsste eventuell durch Martin geändert werden
Gruß Otto
Ergänzung: Vielleicht hilft diese Info zusätzlich.
Das Setzen von "aesCommReq 1" führt aktuell zur folgenden Meldung/Funktionsweise beim ConfigCheck:
Meldung:
configCheck done:
aesCommReq set, IO not compatibel
IR_KontaktHM__EG_Eingang
IR_KontaktHM__EG_Kueche
IR_KontaktHM__EG_Wohnzimmer
RemoteHM_Leeloo
Funktion:
-die IR-Fensterkontakte melden Ihren Status.
-der Remote-Handsender kann keinen Schaltbefehl mehr absetzen.
Aes zwischen cpu und io geht nicht.
Aes zwischen cul und device pruefe ich. Also aescomreq. Geht bei hmlan und usb.
Cul muss wie Otto gesagt hat nachgegogen werden.
Device zu device ist eh eine eq3 angelegenheit.
Zitat von: martinp876 am 01 Juli 2016, 15:28:23
Aes zwischen cul und device pruefe ich. Also aescomreq. Geht bei hmlan und usb.
Und dann wird ja die Frage aufkommen: HMUART? --> also HM-MOD-RPI-PCB und HM-LGW-O-TW-W-EU
Jetzt wo es den HM-CFG-USB nicht mehr gibt? wird das ja zunehmend interessant.
Hi,
Zitat von: martinp876 am 01 Juli 2016, 15:28:23
Aes zwischen cul und device pruefe ich. Also aescomreq. Geht bei hmlan und usb.
aescomreq mit CUL sollte funktionieren. Hat es zumindest damals, als ich es implementiert habe.
Zitat von: Otto123 am 01 Juli 2016, 16:12:18
Und dann wird ja die Frage aufkommen: HMUART? --> also HM-MOD-RPI-PCB und HM-LGW-O-TW-W-EU
Da gehts auch.
Viele Grüße
Michael
Hi,
CUL <-> Device ; also "aesCommReq 1" scheint nicht zu gehen, da ein ConfigCheck mit gesetztem
attr xxx aesCommReq 1 z.Zt. zumindest bei folgenden Devices
- HM-SEC-SCo
- HM-SEC-MDIR-2
- HM-RC-Sec4-2
ein aesCommReq set, IO not compatibel
meldet.
Schönes WE.
Gruß
Leeloo
Dann ist es sicher nur der check, nicht das verhalten.
Wird bei gelegenheit korrigiert.
=> Coding:
OK, Danke. Sag einfach Bescheid, wenn Du soweit bist.
=> Wiki:
Ich glaube wir hätten dann alle Infos zusammen und das Wiki könnte bereits dahingehend angepaßt/geändert werden.
Moin zusammen,
da mit dem Software-Stand von heute noch keine Anpassung zu erkennen ist, wollte ich nochmals nachhacken damit es nicht in Vergessenheit gerät.
Kann jemand die Änderungen am ConfigCheck vornehmen?
Ich bin leider noch nicht soweit um hier eingreifen zu können.
LG
Leeloo