Hallo Martin und Michael,
wäre nach den neuesten AES-Erkenntnissen es nun nicht möglich, für die vCCU einzubauen, dass die virtuellen Kanäle wahlweise AES-Signatur vom gepeerten Device anfordern?
Das würde einiges vereinfachen und sicherer machen - Stichwort Fernbedienungen bzw. 6-fach-Taster, mit denen bspw. Alarmfunktionen aktivert und deaktiviert werden.
Hallo Ralli,
Zitat von: Ralli am 20 Juni 2015, 09:27:04
wäre nach den neuesten AES-Erkenntnissen es nun nicht möglich, für die vCCU einzubauen, dass die virtuellen Kanäle wahlweise AES-Signatur vom gepeerten Device anfordern?
Das hat Martin eigentlich schon eingebaut. Dafuer gibts das Attribut aesCommReq, das man am jeweiligen Geraet setzen kann. Das sollte dann dann zum Reading aesCommToDev fuehren.
Gruss
Michael
Hallo Michael,
das ist mir bekannt - funktioniert aber in der jetzigen Implementierung m.W. nur zwischen dem IO, welches AES kann, und dem Device, oder? Ich meine aber nun nicht zwischen IO und Device sondern zwischen vCCU und Device.
Denn momentan funktioniert das z.B. mit einem HM-PB-6-WM55 nicht so richtig. Denn für den bekomme ich kein trig_aes_...-Reading in dem Channel der vCCU, obwohl aesCommReq gesetzt ist.
Internals:
DEF 654321
IODev HMLAN0
NAME SZ_6fach_Ralf
NR 296
NTFY_ORDER 50-SZ_6fach_Ralf
STATE SZ_6fach_Ralf_Btn_1 Short
TYPE CUL_HM
channel_01 SZ_6fach_Ralf_Btn_1
channel_02 SZ_6fach_Ralf_Btn_2
channel_03 SZ_6fach_Ralf_Btn_3
channel_04 SZ_6fach_Ralf_Btn_4
channel_05 SZ_6fach_Ralf_Btn_5
channel_06 SZ_6fach_Ralf_Btn_6
Readings:
2015-02-15 13:30:18 CommandAccepted yes
2015-02-15 13:30:15 D-firmware 1.2
2015-02-15 13:30:15 D-serialNr LEQxxx
2014-12-14 10:34:17 PairedTo 0x123456
2014-12-14 10:34:17 R-pairCentral 0x123456
2014-12-14 10:34:17 RegL_00: 02:01 0A:12 0B:34 0C:56 18:00 00:00
2015-02-15 13:30:20 aesCommToDev ok
2015-02-15 13:30:17 aesKeyNbr 02
2015-02-15 13:30:20 aesReqTo CCU
2015-06-17 22:16:32 battery ok
2014-12-14 07:45:46 sabotageAttack ErrIoAttack cnt:10
2015-06-17 22:16:32 state SZ_6fach_Ralf_Btn_1 Short
Helper:
mId 00A9
rxType 28
Io:
newChn +2FBBC6,01,01,1E
rxt 2
vccu CCU
p:
2FBBC6
01
01
1E
prefIO:
HMLAN0
HMLAN1
HMLAN2
HMLAN3
Mrssi:
mNo
Prt:
bErr 0
sProc 0
Q:
qReqConf
qReqStat
Role:
dev 1
Role:
Attributes:
IODev HMLAN0
IOgrp CCU:HMLAN0,HMLAN1,HMLAN2,HMLAN3
aesCommReq 1
autoReadReg 4_reqStatus
expert 2_full
firmware 1.2
model HM-PB-6-WM55
room Schlafzimmer
serialNr LEQxxx
subType remote
webCmd getConfig:clear msgEvents
Exemplarisch der Kanal 6 (sign on, gepeerter Kanal der vCCU erfordert kein AES):
Internals:
DEF 65432106
NAME SZ_6fach_Ralf_Btn_6
NR 303
NTFY_ORDER 50-SZ_6fach_Ralf_Btn_6
STATE Short (to CCU)
TYPE CUL_HM
chanNo 06
device SZ_6fach_Ralf
peerList CCU_Btn6,
Readings:
2014-12-14 10:49:00 CommandAccepted yes
2014-12-14 10:34:28 R-CCU_Btn6-expectAES off
2014-12-14 10:34:28 R-CCU_Btn6-peerNeedsBurst off
2014-11-15 13:43:30 R-dblPress 0 s
2014-12-14 07:42:51 R-longPress 1 s
2014-12-14 10:34:25 R-sign on
2014-12-14 10:34:25 RegL_01: 04:70 08:01 09:00 00:00
2014-12-14 10:34:28 RegL_04:CCU_Btn6 01:00 00:00
2015-06-18 18:19:04 peerList CCU_Btn6,
2014-12-14 10:37:15 state Short (to CCU)
2014-11-15 14:41:48 trigDst_CCU noConfig
2014-12-14 10:37:15 trigger Short_3
2014-12-14 10:37:15 trigger_cnt 3
Helper:
Role:
chn 1
Attributes:
model HM-PB-6-WM55
peerIDs 00000000,12345606,
Internals:
DEF 12345606
NAME CCU_Btn6
NR 282
NTFY_ORDER 50-CCU_Btn6
STATE set_press long
TYPE CUL_HM
chanNo 06
device CCU
peerList SZ_6fach_Nocheiner_Btn_6,SZ_6fach_Ralf_Btn_6,
Readings:
2015-02-15 13:30:19 CommandAccepted yes
2015-06-18 18:19:01 peerList SZ_6fach_Nocheiner_Btn_6,SZ_6fach_Ralf_Btn_6,
2014-12-14 08:51:24 state set_press long
2014-12-14 10:37:15 trigLast SZ_6fach_Ralf_Btn_6 :short
2014-12-14 10:37:15 trig_SZ_6fach_Ralf_Btn_6 short
2014-12-14 07:49:59 trig_SZ_6fach_Nocheiner_Btn_6 short
2014-12-14 08:51:25 trigger_cnt 3
Helper:
Role:
chn 1
Attributes:
model CCU-FHEM
peerIDs 65432106,65432206,
webCmd press short:press long
Nun kann ich aber kein aesCommReq in der vCCU nur für einen Kanal setzen, den kann ich ja immer nur für das ganze Device setzen. Muss ich das nun auf die vCCU setzen, geht das überhaupt?
Hier das funktionierende Gegenbeispiel, der Kanal 7 der vCCU ist mit einem Kanal eines HM-PB-2-FM gepeered - auch hier erwartet zwar laut Reading der gepeerte Kanal der vCCU kein AES, klappt aber:
Internals:
DEF 12345607
NAME CCU_Btn7
NR 283
NTFY_ORDER 50-CCU_Btn7
STATE ???
TYPE CUL_HM
chanNo 07
device CCU
peerList GEN_Rollo_Zentral_Runter,
Readings:
2014-12-14 10:35:46 CommandAccepted yes
2015-06-18 18:19:01 peerList GEN_Rollo_Zentral_Runter,
2015-05-31 05:37:28 trigLast GEN_Rollo_Zentral_Runter :short
2015-05-31 05:37:28 trig_GEN_Rollo_Zentral_Runter short
2015-05-31 05:37:31 trig_aes_GEN_Rollo_Zentral_Runter ok:10
Helper:
Role:
chn 1
Attributes:
model CCU-FHEM
peerIDs ABCDEF01,
webCmd press short:press long
Internals:
DEF AABBCC01
NAME GEN_Rollo_Zentral_Runter
NR 493
NTFY_ORDER 50-GEN_Rollo_Zentral_Runter
STATE Short (to CCU)
TYPE CUL_HM
chanNo 01
device GEN_Rollo_Zentral_Device
peerList CCU_Btn7,
Readings:
2015-05-05 15:32:19 CommandAccepted yes
2015-05-05 16:06:57 R-CCU_Btn7-expectAES off
2015-05-05 16:06:57 R-CCU_Btn7-peerNeedsBurst off
2015-05-05 15:06:20 R-longPress 0.4 s
2015-05-05 15:16:47 R-sign on
2015-05-05 16:06:56 RegL_01: 04:10 08:01 30:03 00:00
2015-05-05 16:06:57 RegL_04:CCU_Btn7 01:00 00:00
2015-06-18 18:19:02 peerList CCU_Btn7,
2015-05-31 05:37:28 state Short (to CCU)
2015-05-31 05:37:31 trig_aes_CCU ok:10
2015-05-31 05:37:28 trigger Short_10
2015-05-31 05:37:28 trigger_cnt 10
Helper:
Role:
chn 1
Attributes:
model HM-PB-2-FM
peerIDs 00000000,12345607,
Hi,
Zitat von: Ralli am 20 Juni 2015, 13:27:48
Denn momentan funktioniert das z.B. mit einem HM-PB-6-WM55 nicht so richtig. Denn für den bekomme ich kein trig_aes_...-Reading in dem Channel der vCCU, obwohl aesCommReq gesetzt ist.
Wenn aesCommReq im Geraet gesetzt ist, fuehrt das dazu, dass der HMLAN/HMCFGUSB darueber informiert wird, dass er fuer Events dieses Geraets eine AES-Signatur anfordern soll. Mehr kann man da nicht definieren (Kanaele kann man auch nicht angeben), das IO entscheidet in der Firmware selbst, wann es die Signatur anfordert...
Ich habe das auch schon gesehen und bisher noch kein richtiges Muster feststellen koennen, wann AES angefordert wird und wann nicht, mit der Konfiguration von expectAES im Geraet hat das aber sicher nichts zu tun, das sagt nur dem Geraet, dass es sich auf eine AES-Anfrage vorbereiten soll (das Geraet muss dafuer z.B. das Event aufheben).
Gruss
Michael
Ich habe das Problem auch. Ich hätte erwartet den virtuellen Button per sign zu sagen er soll die Anfragen signieren. Allerdings bekomme ich immer folgenden Fehler:
sign failed: supported register are pairCentral
Solange das nicht der Fall ist, hab ich nun wieder das expectAES auf jedem Button ausgeschaltet.
virtuelle Devices haben keine Register.
Aber wie kann ich dem virtuellen Button mitteilen, seine Antworten gültig zu signieren? Den ein Taster wird die Anfrage immer mit Rot quittieren, da die Antwort nicht signiert ist.
Hallo,
Zitat von: traxanos am 09 August 2015, 18:23:37
Aber wie kann ich dem virtuellen Button mitteilen, seine Antworten gültig zu signieren? Den ein Taster wird die Anfrage immer mit Rot quittieren, da die Antwort nicht signiert ist.
aesCommReq im entsprechenden Kanal des Geräts setzen. Das ist kein Attribut der vccu sondern des entsprechenden Geräts, da es sich auf jede Kommunikation mit diesem Kanal bezieht und nicht nur auf virtuelle Geräte der vccu.
Gruß
Michael
Da muss ich dir leider wider sprechen. Das Device erwartet eine Signierte Antwort und bekommt diese nicht, dabei muss das virtuelle Device eine signierte Antwort schicken was eben nicht gemacht wird. Daher wir auch vom Device die Antwort abgelehnt und mit einem roten Leuchten signalisiert.
Hier ein Listing des ersten Tasters
Internals:
BNO 69
BNOCNT 3
DEF 31823601
NAME Schalter.Reserve2_Btn_01
NR 89
NTFY_ORDER 50-Schalter.Reserve2_Btn_01
STATE Short (to vCCU)
TYPE CUL_HM
chanNo 01
device Schalter.Reserve2
peerList vCCU_Btn1,
Readings:
2015-08-08 17:31:15 CommandAccepted yes
2015-08-04 23:32:12 R-dblPress 0 s
2015-08-04 23:32:12 R-longPress 0.4 s
2015-08-09 18:09:49 R-sign on
2015-08-09 18:04:14 R-vCCU_Btn1-expectAES on
2015-08-09 18:04:14 R-vCCU_Btn1-peerNeedsBurst off
2015-08-09 18:09:49 RegL_01: 04:10 08:01 09:00 00:00
2015-08-09 18:09:51 RegL_04:vCCU_Btn1 01:80 00:00
2015-08-09 18:09:50 peerList vCCU_Btn1,
2015-08-09 19:00:19 state Short (to vCCU)
2015-08-04 23:35:40 trigDst_vCCU noConfig
2015-08-09 19:00:19 trigger Short_82
2015-08-09 19:00:19 trigger_cnt 82
Helper:
peerIDsRaw ,26EBD701,00000000
Role:
chn 1
Shadowreg:
Role:
Attributes:
aesCommReq 1
model HM-PB-6-WM55
peerIDs 00000000,26EBD701,
Sich sagt dass AES angefordert werden soll. Bei einem virtuellen button ist sich daher irrelevant. Nur wenn man die Register aendern wollte wäre es gefragt. Er hat aber keine.
Beim aktor könnte man es einbauen um den Sender zu prüfen.
Verwendet man die virtuellen Kanäle der vccu klappt das schon. Mit aescomreq wird der Sender geprüft.
Für die anderen virtuellen Kanäle ist es bisher nicht eingeplant.
Machbar ist also schon jetzt alles über vccu
Ich nutze doch eine vCCU und ich habe aescomreq aktiviert. Dennoch werden die Trigger der Buttons ausgewertet. Und das ist ein Sicherheitsproblem. Auch wenn der KEY selber in der vCCU geändert wird (inkl. HMUSB und HMLAN).
Also wie im anderen Thread schon beschrieben geht es nun. Es musste auf dem Device zusätzlich auch das aesCommReq gesetzt werden (also 2x)
Auch bei mir ist das Thema nun aktuell geworden.
Ich versuche dem 6x Wandtaster AES beizubringen.
Denn was bringen mir Jalo Aktoren, die nur verschlüsselt von der Zentrale angesprochen werden, wenn ich diese mit einem Knopf hoch und runter fahren kann....
Daher habe ich auf dem Gerät assignHmKey gesetzt und als Attr aesCommReq 1 gesetzt.
In jedem Channel (Buttons) habe ich Sign on gesetzt und aesCommReq 1.
Was ich vermisse, ist das Reading aesKeyNr. Ich kann nicht erkennen, ob mein Key 02 verwendet wird.
Auch habe ich nun den Nebeneffekt, dass Commands manchmal von der Zentrale doppelt ausgeführt werden.
Kann mir da jemand helfen?
Macht man überhaupt ein sign on auf einen Button?! Wenn ich es mir richtig überlege sorgt das doch nur dafür, dass der Button auf das ACK ein Sign erwartet, oder???
Nachtrag: R-VCCU_Btn1-expectAES steht auf off bei mir...