HM-PB-2-WM55-2 aes aktivieren

[mikrobi]

Hallo liebe FHEM Gemeinde
ich habe mir vor kurzen einen Funk Wandtaster HM-PB-2-WM55-2 zugelegt. Ich konnte den problemlos mit meiner VCCU pairen. 2 virtuelle Buttons sind mit dem Taster gepeert. Alles funktioniert soweit perfekt. Nun wollte ich damit gern die Alarmanlage unscharf bzw. scharf schalten. Da das etwas sicherer sein sollte, frage ich mich nun wie man bei diesem Taster aes aktiviert? Gibt es dazu irgendwo eine Anleitung bzw. kann mir eventuell jemand weiter helfen dem das geglückt ist?

Ich habe folgendes gemacht:
auf dem Taster Device assignHmKey. Es passiert aber nichts. Kein reading mit easKeyNbr gefunden. Was muss ich hier machen? Ich benutze einen HM-LAN Adapter der als IO der VCCU zugeordnet ist. Es sind 3 Keys eingetragen die aber alle gleich sind.

Vielen Dank
Robert

[Otto123]

Hallo Robert,

vorausgesetzt Du weißt was Du generell mit AES tust wird Dir eventuell. Der neue Key wird wohl erst bei einem Wechsel sign on sign off übertragen.

Code Auswählen Erweitern

set <tasterChannel> sign on
helfen.

Gruß Otto

[mikrobi]

OK. Danke für den Hinweis. Es hat nun auch funktioniert. Damit es für andere nützlich sein möge - das habe ich gemacht:

Taster Device:
HM_588555 aesCommReq = 1 (Attribut)
HM_588555_Btn_01 aesCommReq = 1 (Attribut)
HM_588555_Btn_01 sign = on (Register)
R-VCCU_Btn1-expectAES = on (Register)

VCCU:
aesCommReq = 1 (Attribut)
VCCU_Btn1 aesCommReq = 1 (Attribut)

und dann natürlich noch HM_588555 assignHmKey. Dann paar mal anlernen Taste gedrückt und auch ein paar Schaltvorgänge und aes war an.

aesCommToDev
ok
aesKeyNbr
06

in den readings. Die aesKeyNbr hat eine Weile gebraucht um in den Readings zu erscheinen - warum auch immer. Trotz mehrmaliger clear readings und getconfig's 
Das Beispiel ist nur für einen Button. Für den anderen muss man natürlich das gleiche noch mal setzen. Bin mir nicht sicher ob aesCommReq am Taster notwendig war oder ob das nur auf die VCCU gehört.

In den logs sieht man das folgende:

Code Auswählen Erweitern


2018-04-03 21:49:22 CUL_HM EG_FLUR_TASTER01 aesCommToDev: pending
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 aesCommToDev: ok
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 battery: ok
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 CMDs_done
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 HM_588555_Btn_02 Long
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 Long 1_176 (to VCCU)
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 trig_aes_VCCU: ok:176
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 trigger: Long_176
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 trigger_cnt: 176
2018-04-03 21:49:23 CUL_HM VCCU_Btn2 trigLast: HM_588555_Btn_02:long
2018-04-03 21:49:23 CUL_HM VCCU_Btn2 trig_HM_588555_Btn_02: Long_176
2018-04-03 21:49:23 CUL_HM VCCU_Btn2 trig_aes_HM_588555_Btn_02: ok:176
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 aesCommToDev: pending
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 aesCommToDev: ok
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 battery: ok
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 CMDs_done
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 HM_588555_Btn_02 Long
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 Long 2_176 (to VCCU)
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 trig_aes_VCCU: ok:176
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 trigger: Long_176
2018-04-03 21:49:23 CUL_HM HM_588555_Btn_02 trigger_cnt: 176
2018-04-03 21:49:23 CUL_HM VCCU_Btn2 trigLast: HM_588555_Btn_02:long
2018-04-03 21:49:23 CUL_HM VCCU_Btn2 trig_HM_588555_Btn_02: Long_176
2018-04-03 21:49:23 CUL_HM VCCU_Btn2 trig_aes_HM_588555_Btn_02: ok:176
2018-04-03 21:49:23 CUL_HM EG_FLUR_TASTER01 aesCommToDev: pending
2018-04-03 21:49:24 notify n_alertcontacts disabled
2018-04-03 21:49:24 Global global ATTR n_alertcontacts disable 1
2018-04-03 21:49:24 DOIF di_alertcontacts_operation cmd_nr: 2
2018-04-03 21:49:24 DOIF di_alertcontacts_operation cmd: 2
2018-04-03 21:49:24 DOIF di_alertcontacts_operation cmd_event: alertcontacts
2018-04-03 21:49:24 DOIF di_alertcontacts_operation cmd_2
2018-04-03 21:49:24 dummy alertcontacts off
2018-04-03 21:49:24 CUL_HM EG_FLUR_TASTER01 aesCommToDev: ok
2018-04-03 21:49:24 CUL_HM EG_FLUR_TASTER01 battery: ok
2018-04-03 21:49:24 CUL_HM EG_FLUR_TASTER01 CMDs_done
2018-04-03 21:49:24 CUL_HM EG_FLUR_TASTER01 HM_588555_Btn_02 LongRelease
2018-04-03 21:49:24 CUL_HM HM_588555_Btn_02 LongRelease 2_176 (to VCCU)
2018-04-03 21:49:24 CUL_HM HM_588555_Btn_02 trig_aes_VCCU: ok:176
2018-04-03 21:49:24 CUL_HM HM_588555_Btn_02 trigger: Long_176
2018-04-03 21:49:24 CUL_HM HM_588555_Btn_02 trigger_cnt: 176
2018-04-03 21:49:24 CUL_HM VCCU_Btn2 trigLast: HM_588555_Btn_02:long
2018-04-03 21:49:24 CUL_HM VCCU_Btn2 trig_HM_588555_Btn_02: Long_176
2018-04-03 21:49:24 CUL_HM VCCU_Btn2 trig_aes_HM_588555_Btn_02: ok:176


Nicht wundern - Schalter habe ich mittlerweile in EG_FLUR_TASTER01 umbenannt.
Allerdings habe ich auch bemerkt das ich sign off am Taster machen kann und auch expectAES auf off - trotzdem werden notify's ausgeführt. Das würde ja heissen es geht auch ohne Signatur? Was mus man da noch machen damit die notifies bei fehlender aes Signatur nicht ausgeführt werden?

Viele Grüße
Robert

[Otto123]

Hallo Robert,

mein Verständnis vom AES bei Homematic ist so:
Wird von einem Gerät sign erwartet, werden nur signierte Befehle akzeptiert. Die Signatur wird überprüft, sie muss stimmen sonst wird der Befehl nicht akzeptiert.

Ein notify liest Events, die haben damit gar nichts zu tun.

Mit sign on wird die signatur erwartet damit es funktioniert, mit sign off wird keine Signatur erwartet. Man kann damit die Kommunikation/Steuerung absichern aber nicht verhindern.

Gruß Otto

[mgernoth]

Hallo,

Taster Device:
HM_588555 aesCommReq = 1 (Attribut)
HM_588555_Btn_01 aesCommReq = 1 (Attribut)
HM_588555_Btn_01 sign = on (Register)
R-VCCU_Btn1-expectAES = on (Register)

Ich würde aesCommReq immer ganz zum Schluss setzen, da sonst nicht-signierte Frames verworfen werden. Dies kann bei der Inbetriebnahme dann z.B. der Fall sein, wenn Fhem denkt, dass das Gerät den eigenen Schlüssel schon kennt, obwohl assignHmKey noch nicht ausgeführt wurde (z.B. nach einem Gerätereset).

VCCU:
aesCommReq = 1 (Attribut)
VCCU_Btn1 aesCommReq = 1 (Attribut)

aesCommReq an der VCCU hat keine Auswirkung, es wird nur an der Ereignisquelle benötigt.

aesCommReq fordert von dem Gerät an dem es gesetzt wurde Signaturen bei Ereignismeldungen an, wenn diese an die hmId von Fhem (IO/VCCU) gerichtet sind.

Das Beispiel ist nur für einen Button. Für den anderen muss man natürlich das gleiche noch mal setzen. Bin mir nicht sicher ob aesCommReq am Taster notwendig war oder ob das nur auf die VCCU gehört.

Genau andersrum Nur am Taster.

Allerdings habe ich auch bemerkt das ich sign off am Taster machen kann und auch expectAES auf off - trotzdem werden notify's ausgeführt. Das würde ja heissen es geht auch ohne Signatur? Was mus man da noch machen damit die notifies bei fehlender aes Signatur nicht ausgeführt werden?

"sign" am Taster bedeutet, dass der Taster eine Signatur anfordert, wenn z.B. seine Konfiguration durch Fhem verändert wird.

Zu expectAES: Der Taster beantwortet die Signaturanfrage auch, obwohl expectAES nicht gesetzt ist, da er auf ein Ack wartet, empfangsbereit ist und den entsprechenden Schlüssel kennt. expectAES sagt dem Taster nur, dass eine Signaturanfrage kommen _muss_ -- und sollte diese ausbleiben das Frame nochmal gesendet werden soll bzw. der Benutzer durch eine rote LED benachrichtigt werden soll (nach 3 maligem ausbleiben der korrekten Signatur).

Einfachster Test ob AES funktioniert: In Fhem temporär den Key ändern und schauen ob die Ereignisse noch ankommen.

Wird von einem Gerät sign erwartet, werden nur signierte Befehle akzeptiert. Die Signatur wird überprüft, sie muss stimmen sonst wird der Befehl nicht akzeptiert.

Ein notify liest Events, die haben damit gar nichts zu tun.

Wenn expectAES an einem Gerät gesetzt ist, werden für an Fhem gerichtete Ereignis-Nachrichten keine Ereignisse in Fhem erzeugt wenn die Signatur ausbleibt oder falsch ist. Ereignis-Nachrichten an Broadcast bzw. an andere hmIds erzeugen aber weiterhin Fhem-Ereignisse (mit entsprechendem Empfänger). Ein korrekt signiertes Ereignis erkennt man immer an einem trig_aes_...ok...-Ereignis (darauf laufen bei mir die Notifies).

Viele Grüße
  Michael

[mikrobi]

Vielen Dank für die ausführliche Beschreibung. Jetzt weiß ich mehr. Leider ist das in der aes Dokumentation nicht immer ganz klar - was ist mit Gerät gemeint, was gilt für VCCU usw. Nur noch mal die Nachfrage: hab ich es richtig verstanden, ich muss in meinen Notifies 'trig_aes_...ok'  prüfen bevor ich die Kommandos (Alarm aus) ausführe? Ich dachte immer es gibt kein Event wenn die Signatur nicht stimmt. Ich habe die Keys mal aus fhem gelöscht. Und tatsächlich es gab eine rote LED und kein Event. Und somit auch kein Notify. Also eigentlich alles OK. Es würde mich jetzt nur noch interessieren was passiert wenn der Taster den Key nicht kennt. Ich werde ihn bei Gelegenheit mal zurücksetzen und testen wie VCCU bzw fhem darauf reagiert.

Gruß
Robert

[mikrobi]

Leider kann man den Taster nicht zurücksetzen. Aber OK. Es geht jetzt alles. Obwohl sich der Taster manchmal komisch verhält und hin und wieder rote LED leuchten lässt und kein Ereignis ausgeführt wird. Damit kann ich aber leben, das Ereignis muss ja nicht immer ohne Funkstörung durchkommen