AES (mit CUL) einrichten

[Virsacer]

Danke, habs jetzt aber noch nicht getestet...

Ja, das kann sein...
Mein Trigger ist in dem Fall

Code Auswählen Erweitern

[Window] eq "open"

[mgernoth]

Mein Trigger ist in dem Fall

Code Auswählen Erweitern

[Window] eq "open"

Hmm, ich habe DOIF noch nie benutzt, aber das ueberprueft die AES-Signatur nicht.
Habe gerade mal was zusammengebastelt, was hier in meinem Testsystem mit einer Fernbedienung funktioniert:

Code Auswählen Erweitern


([FB_KeyMatic_light:?trig_aes_VCCU.*ok] and [FB_KeyMatic_light] =~ "Short") (set Lampe_Decke_AZ toggle)


Wichtig ist hierbei, wirklich auf das Event trig_aes_xxx zu reagieren.

Gruss
  Michael

[Virsacer]

Das DOIF reagiert jedesmal, wenn sich irgendein Reading von Window ändert und überprüft, ob der state "open" ist - mit der AES-Signatur hat das nix zu tun

Ich werde das mal testen, die Woche siehts aber gerade zeitlich schlecht aus...

[mgernoth]

Hi,

Das DOIF reagiert jedesmal, wenn sich irgendein Reading von Window ändert und überprüft, ob der state "open" ist - mit der AES-Signatur hat das nix zu tun

Yep, das ist genau das Problem. Den state kann man von aussen "setzen", ohne die Signaturfrage zu beantworten. Nur direkt nach dem trig_aes-Event (deswegen das ) kann man sich sicher sein, dass der Status authentisiert ist.

Ich hab das jetzt auch mal in meinem Prod.-System mit einem TFK implementiert:

Code Auswählen Erweitern


([Balkontuere_AZ:?trig_aes_VCCU.*ok] and [Balkontuere_AZ] eq "open")


Ich werde das mal testen, die Woche siehts aber gerade zeitlich schlecht aus...

Waere klasse, hier siehts mittlerweile gut aus, getConfig, regSet und so laeuft alles durch

Gruss
  Michael

[Ralli]

Mache lieber ein

Code Auswählen Erweitern


([Balkontuere_AZ:?trig_aes_VCCU.*ok] and [?Balkontuere_AZ] eq "open")


draus .

[mgernoth]

Mache lieber ein

Code Auswählen Erweitern


([Balkontuere_AZ:?trig_aes_VCCU.*ok] and [?Balkontuere_AZ] eq "open")


draus .

Danke

Haette ich in der Dokumentation zu DOIF nie gefunden, weil es nirgends eine einfach Uebersicht der moeglichen Operatoren gibt, nur Beispiele, aus denen man sich alles zusammenkratzen muss...

Gruss
  Michael

[Virsacer]

Yep, das ist genau das Problem. Den state kann man von aussen "setzen", ohne die Signaturfrage zu beantworten.

Aber das widerspricht doch genau dem Sinn von der Signatur: Dass der Status nur akzeptiert wird, wenn er von einem legitimierten Gerät kommt

[mgernoth]

Aber das widerspricht doch genau dem Sinn von der Signatur: Dass der Status nur akzeptiert wird, wenn er von einem legitimierten Gerät kommt

Verhaelt sich genauso, wie bei einem echten HM-IO (siehe hier). Da ich moechte, dass sich alle IOs gleich verhalten, muesste Martin das Verhalten von 10_CUL_HM bei aesCommReq global aendern. Einfach auf trig_aes triggern sollte aber eigentlich funktionieren (man koennte bei trig_aes den Status in ein eigenes Reading kopieren, um immer einen authentisierten Status zu haben).

EDIT: z.B. so:

Code Auswählen Erweitern


define Authenticate_State notify .*:trig_aes_.*:.ok.* {\
  fhem "setreading $NAME AESstate ".ReadingsVal($NAME, "state", $EVENT)\
    if ((time() - time_str2num(ReadingsTimestamp($NAME,"state",0))) < 15)\
}


Wobei die Zeitabfrage eher Paranoia ist, ein Trigger sollte nur kommen, wenn der State uebertragen wurde.

Gruss
  Michael

[Virsacer]

Hm, ok - Ich finde das Verhalten etwas seltsam, aber nungut...

Bin noch nicht dazu gekommen, aber werde es auf jeden Fall testen

[mgernoth]

Hi,

Hm, ok - Ich finde das Verhalten etwas seltsam, aber nungut...

Ist hauptsaechlich darin begruendet, dass die Informationen in unterschiedlichen Nachrichten kommen. Also zuerst die Statusaenderung und danach noch die AES-Signatur.

Bin noch nicht dazu gekommen, aber werde es auf jeden Fall testen

Habe mal die aktuelle Version angehaengt, ist eigentlich nur das Logging geaendert. Signaturnachrichten haben jetzt Level 4, Debug Level 5.

@Martin: Kannst Du Dir das mal bitte anschauen, wenn Du Zeit hast und evtl. uebernehmen? Danke

Viele Gruesse
  Michael

[Virsacer]

Ist hauptsaechlich darin begruendet, dass die Informationen in unterschiedlichen Nachrichten kommen. Also zuerst die Statusaenderung und danach noch die AES-Signatur.

Also das ist kein Grund...
Die Devices speichern ja auch die Befehle zwischen und führen sie erst aus, wenn die Signatur kommt

Habs jetzt nur mal kurz getestet:
getConfig funktioniert und das Triggern mit [Window:?trig_aes_VCCU.*ok] auch.
Allerdings hatte ich jetzt auch noch keine nicht angekommenen Signaturpakete...

EDIT:
Hab jetzt auch die fehlende Signatur getestet, indem ich in der VCCU den Key verändert habe - State wird aktualisiert, aber der Trigger nicht ausgelöst
Das funktioniert also auch, aber dass der State sich vorher ändert sollte trotzdem noch korrigiert werden, damit es "werkseitig" sicher ist

[mgernoth]

Hi,

Also das ist kein Grund...

Doch, das ist der Grund, warum Fhem sich im Augenblick so verhält. 10_CUL_HM ist halt an der Stelle Eventgetrieben und parst alle einkommenden Nachrichten.
Dass das nicht ideal ist, sehe ich aber auch so (und es macht das Anfordern der Signaturen für nicht-Trigger-Nachrichten eigentlich nutzlos).

Die Devices speichern ja auch die Befehle zwischen und führen sie erst aus, wenn die Signatur kommt

Das war übrigens mein erster Versuch, die Signaturprüfung mit CUL zu implementieren. Ich habe die Nachrichten gecached, musste sie aber teilweise Parsen um herauszufinden, ob sie überhaupt eine Signatur benötigen...
Das ist mir dann total um die Ohren geflogen. Und als ich gesehen habe, dass das bei normalen HM-IOs auch nicht gemacht wird, habe ichs erstmal so implementiert.

Habs jetzt nur mal kurz getestet:
getConfig funktioniert und das Triggern mit [Window:?trig_aes_VCCU.*ok] auch.
Allerdings hatte ich jetzt auch noch keine nicht angekommenen Signaturpakete...

EDIT:
Hab jetzt auch die fehlende Signatur getestet, indem ich in der VCCU den Key verändert habe - State wird aktualisiert, aber der Trigger nicht ausgelöst

Gutgut

Das funktioniert also auch, aber dass der State sich vorher ändert sollte trotzdem noch korrigiert werden, damit es "werkseitig" sicher ist

Ja, schon. Nur habe ich die Befürchtung, dass das eine größere Änderung der 10_CUL_HM nach sich zieht, das kann aber nur Martin beurteilen, mit fehlt immer noch der ganze Überblick über das Modul.

Viele Grüße
  Michael

[Virsacer]

10_CUL_HM ist halt an der Stelle Eventgetrieben und parst alle einkommenden Nachrichten.

Ok, DAS ist ein Grund

Dass das nicht ideal ist, sehe ich aber auch so (und es macht das Anfordern der Signaturen für nicht-Trigger-Nachrichten eigentlich nutzlos).

Ja, schon. Nur habe ich die Befürchtung, dass das eine größere Änderung der 10_CUL_HM nach sich zieht, das kann aber nur Martin beurteilen, mit fehlt immer noch der ganze Überblick über das Modul.

Dann ist ja gut, wenn du das genauso siehst und das irgendwann noch umgebaut wird

Hab aber noch einen Fehler bemerkt:
"set Thermostat_Clima desired-temp 18" funktioniert nicht mehr

[mgernoth]

Hab aber noch einen Fehler bemerkt:
"set Thermostat_Clima desired-temp 18" funktioniert nicht mehr

Huh?
Was ist das für ein Thermostat? HM-CC-RT-DN? Wandthermostat?
Wie sind die AES-Settings bei Dem Ding (also sign auf dem Kanal und aesCommReq)?

(HM-CC-RT-DN und passenden WT habe ich, hängen aber an meinem System mit HMCFGUSB. Kann ich aber zum Testen umhängen, brauche nur Details)

Gruß
  Michael

[Virsacer]

Ja, das ist ein HM-CC-RT-DN
Channel 2 um genau zu sein

Ich hab das Device und alle Channels auf R-sign on und aesCommReq 1 stehen...