Hab hier eine EIB/KNX Installation und wollte mit FHEM / HMLAN per Funk gewisse Sachen schalten die sicherheitsrelevant sind.
Hab im HomeMatic Konfigurator die RC-4-2 hinzugefügt Übertragungsmodus steht auf Gesichert.
Meine frage dazu ist wenn ich das Signal in FHEM auswerte ist das dann schon gesichert oder müsste FHEM zur RC-4-2 eine Anfrage senden
bezüglich AES oder wird das automatisch gemacht?
hab leider dazu nicht wirklich was gefunden :-(
für das Device (nicht Channel...) muss das Attribut aesCommReq 1 gesetzt werden.
Der trigger der remote wird immer aufgefangen werden - dann wird FHEM (HMLAN) eine AES signatur erfragen.
Du solltest den Channel mit einem channel einer vccu peeren. Also erst eine virtual ccu einrichten, dort ein paar channel anlegen und mit der RC4 peeren. Ich würde jeden Button mit einem eigenen Virtual channel der vccu peeren.
Das Reading trig_aes... wird dann inchannel der VCCU erscheinen, wenn es erfolgrich war. Das ist dann auch der, den du zum notify nehmen solltest.
könntest du mir da bitte eine kleine Hilfestellung dazu geben wie man das anlegt
und mit notify auswertet
danke
Zitat von: mycroft2k am 25 Juli 2014, 15:57:18
Hab hier eine EIB/KNX Installation und wollte mit FHEM / HMLAN per Funk gewisse Sachen schalten die sicherheitsrelevant sind.
Und du solltest unbedingt einen eigenen AES-Key vergeben. Ansonsten ist die Kommunikation nicht sicher.
das hab ich schon gemacht per Homematic Konfigurator aber danke für die Info
bin jetzt soweit das der wohl das richtig im event anzeigt
2014-07-26 04:13:33 CUL_HM RC4_1 battery: ok
2014-07-26 04:13:33 CUL_HM RC4_1 RC4_1_Btn_02 Short (to ccu)
2014-07-26 04:13:33 CUL_HM RC4_1 CMDs_done
2014-07-26 04:13:33 CUL_HM RC4_1_Btn_02 Short (to ccu)
2014-07-26 04:13:33 CUL_HM RC4_1_Btn_02 trigger: Short_160
2014-07-26 04:13:33 CUL_HM ccu_Btn1 trig_aes_RC4_1_Btn_02: ok:B2
2014-07-26 04:13:33 CUL_HM ccu_Btn1 trig_RC4_1_Btn_02: short
2014-07-26 04:13:33 CUL_HM ccu_Btn1 trigLast: RC4_1_Btn_02 :short
2014-07-26 04:13:34 CUL_HM RC4_1 aesCommToDev: ok
jetzt komm ich nicht mehr weiter wie ich die Auswertung machen soll kann mir da wer helfen?
Zitat2014-07-26 04:13:33 CUL_HM ccu_Btn1 trig_aes_RC4_1_Btn_02: ok:B2
ist ein primäres event.
Das notify hängt jetzt davon ab, ob:
- ccu_Btn1 nur mit RC4_1_Btn_02 gepeert ist oder auch mit anderen
- du long/short unterscheiden willst
z.B.:
define nf notify ccu_Btn1:trig_aes_RC4_1_Btn_02:.ok.* set licht on
danke so weit geht das jetzt aber wie unterscheidet man lang/kurz
hätte es so probiert:
define nf notify ccu_Btn1:trig_CUL_RC4_1_Btn_02:.short:trig_aes_RC4_1_Btn_02:.ok.* set licht on
define nf1 notify ccu_Btn1:trig_CUL_RC4_1_Btn_02:.long:trig_aes_RC4_1_Btn_02:.ok.* set licht off
das hat nicht funktioniert
kann man auch auf release button aktion ausführen?
wie sieht das ganze aus wenn ich mehrere HMLANs habe und ich möchte das die
FB bei jeden HMLAN geht mit AES mit den Bidcos Service gibts ja roaming ist das mit fhem auch möglich?
Zitatdefine nf notify ccu_Btn1:trig_CUL_RC4_1_Btn_02:.short:trig_aes_RC4_1_Btn_02:.ok.* set licht on
define nf1 notify ccu_Btn1:trig_CUL_RC4_1_Btn_02:.long:trig_aes_RC4_1_Btn_02:.ok.* set licht off
kann nicht gehen. Jedes Reading wird separat geschrieben AES sagt nur, dass es AES war.
define nf1 notify ccu_Btn1:trig_aes_RC4_1_Btn_02:.ok.* {if (ReadingsVal($NAME,"trig_CUL_RC4_1_Btn_02","") =~ m/long/){fhem "set licht off"}
Also einen zum triggern nehmen und dann im Trigger die anderen bedingungen prüfen.
Zitatkann man auch auf release button aktion ausführen?
ja, wenn der button gepeert ist. Sonst kommt kein Release.
Beachte:
- Release wird im Button explizit gemeldet - nicht im gepeerten Aktor
- trigAES kommt erst, wenn es ein Release gegeben hat (ist also implizit immer ein Release)
- sollte mehr als ein Device an den Button gepeert sein könnte es zu Problenem mit dem "long" trigger kommen - beim erkennen des starts (ende ist sicher ok).
Zitatwie sieht das ganze aus wenn ich mehrere HMLANs habe und ich möchte das die
FB bei jeden HMLAN geht mit AES mit den Bidcos Service gibts ja roaming ist das mit fhem auch möglich?
nutze eine vccu. weise deine IOs der vccu zu (dann werden auch die HMIds der HMLAN abgeglichen).
Beachten musst du, dass ein Device immer EINEM io zugewiesen sein sollte. FHEM (mit vccu) regelt dies. Es wird immer das IO verwendet, dass den besten rssi-wert hat.
Zitatdefine nf1 notify ccu_Btn1:trig_aes_RC4_1_Btn_02:.ok.* {if (ReadingsVal($NAME,"trig_CUL_RC4_1_Btn_02","") =~ m/long/){fhem "set licht off"}
macht da bei mir leider keine Funktion :-(
vielleicht mal so ;) :
define nf1 notify ccu_Btn1:trig_aes_RC4_1_Btn_02:.ok.* {if (ReadingsVal("$NAME","trig_CUL_RC4_1_Btn_02","") =~ m/long/){fhem "set licht off"}}
ja, sicher. eine klammer zu wenig.
Ich hoffe, das Prinzip ist verstanden - dann kannst du beliebige bedingungen selbst bauen.
Wenn du wissen willst, welche Trigger kommen schalte inform an und löse den Trigger aus.
danke sieht jetzt gut aus.
ist der Event Monitor(webinterface) nicht das gleiche wie inform? per telnet
roaming muss ich noch testen leider hat sich ein hmlan beim update verabschiedet :-(
Zitatist der Event Monitor(webinterface) nicht das gleiche wie inform? per telnet
ja
von wo könnte der Fehler herkommen das der zweimal on macht vor allem beim ersten wurde AES ja noch nicht überprüft es ist nur die notify aktiv
define nf2 notify ccu_Btn1:trig_aes_RC4_1_Btn_02:.ok.* {if (ReadingsVal("$NAME","trig_RC4_1_Btn_02","") =~ m/short/){fhem "set licht on"}}
2014-07-31 20:13:55 CUL_HM RC4_1 battery: ok
2014-07-31 20:13:55 CUL_HM RC4_1 RC4_1_Btn_02 Short (to ccu)
2014-07-31 20:13:55 CUL_HM RC4_1 CMDs_done
2014-07-31 20:13:55 CUL_HM RC4_1_Btn_02 Short (to ccu)
2014-07-31 20:13:55 CUL_HM RC4_1_Btn_02 trigger: Short_61
2014-07-31 20:13:55 EIB licht on
2014-07-31 20:13:55 CUL_HM ccu_Btn1 trig_aes_RC4_1_Btn_02: ok:2F
2014-07-31 20:13:55 CUL_HM ccu_Btn1 trig_RC4_1_Btn_02: short
2014-07-31 20:13:55 CUL_HM ccu_Btn1 trigLast: RC4_1_Btn_02 :short
2014-07-31 20:13:55 EIB licht on
2014-07-31 20:13:56 CUL_HM RC4_1 aesCommToDev: ok
Ist es ein Fehler?
Könnte sein, dass der Aktor ein Ack an den Sender mit Status sendet und dann eine Info an die Zentrale.
FHEM wertet immer alle messages möglichst komplett aus. Damit ist es immer möglich, dass Readings doppelt gesetzt werden.
Daher rate ich immer wieder und für ALLE entites (zumindest alle HM-relvanten)
attr <entity> event-on-change-reading .*
zu setzen.
Am besten so
attr TYPE=CUL_HM event-on-change-reading .*
Hallo Martin,
Am besten so
attr TYPE=CUL_HM event-on-change-reading .*
wo muss das hin? Kann ich das einfach in der Befehlszeile eingeben ?
Gruß Christoph
Geh direkt in den key rein. Unten gibts dann den attr Button einfach auswählen was du haben willst und fertig
kann man direkt in die Kommadozeile eingeben.
Ich verändere dies manchmal beim testen - und will es dann wieder gerade ziehen - automatisch. "save" muss aber immer gehen. Daher mein Konzept der config files:
fhem.cfg und seine unterfiles (als includes im fhem.cfg verankert) enthalten defines und attribut (und kommentare).
Ein "userConfig" wird dann nach dem Ende es Init per notify gestartet. Das
- kommt nach dem initialisieren des sytems
- wird nicht von save überschrieben
- kann daher beliebige kommandos beinhalten.
Also schreiben ich so etwas dort hinein.