FHEM Forum

Hallo Forum,

Bin mal wieder mit meinem Latein am Ende und frage deshalb die schlauen Leute im Forum...

Also: Ich betreibe eine virtuelle CCU mit einem Busware CUL. Dort sind u.A. mehrere Fernbedienungen vom Typ HM-RC-Sec4-2 angelernt. Diese signieren auf mindestens einem Kanal (je nach Anwendung) per AES. Funktioniert. Keine Probleme.

Um die Reichweite des Systems zu erhöhen, habe ich zusätzlich noch ein HM-LGW-O-TW-W-EU-2 HM/LAN-Gateway eingebunden. Dieses dann als Teil der virtuellen CCU konfiguriert. Das funktioniert auch soweit: je nach rssi kommunizieren die Geräte entweder über den CUL oder das LGW.
Was aber nicht funktioniert ist die AES-Signierung, falls ein Gerät über das Gateway kommunizieren will. In diesem Fall wird mehrfach ein
...aesCommToDev: pending wiederholt.
Also das gleiche Verhalten, als wenn kein HMKey hinterlegt wäre. Im fhem Wiki steht, dass das LGW die AES-Signierung von sich aus beherrscht. Demnach müsste ich dem Gateway meinen HM-AES-Schlüssel also noch mitteilen.
Aber wie geht das? Als Attribut kann man den hmKeys hinterlegen. Ist das richtig? jedenfall ändert sich am Verhalten des LGWs dann nichts. Es mag immer noch nicht AES-signiert kommunizieren.

Habt ihr vielleicht einen Tipp?

gruß & frohe Weihnachten
klinki

Hi,

wo hast Du bisher die hmKeys eingetragen? VCCU oder CUL?
Eigentlich so ->  https://wiki.fhem.de/wiki/AES_Encryption#Zentrale

Gruß Otto

Nach diesem Artikel bin ich vorgegangen.
HMKey in der VCCU eingetragen.

Nur, wenn ich das recht verstehe, findet beim LGW die AES-Signierung dort statt. Nur bei CUL übernimmt die fhem-Zentrale das Signieren. Heißt das nicht, dass das LGW den hmkey denn auch kennen muss?

ZitatDer erste Schritt ist, in der virtuellen CCU von FHEM oder nur einem I/O-Device einen Schlüssel (Key) zu vergeben

Wenn ich das richtig verstehe, gibt die VCCU die hmKey an die zugeordneten IOs. Man macht es entweder bei der VCCU für alle oder beim einzelnen IO. Also wenn Dein IO zur VCCU gehört kennt er den hmKey.

Ist beim HMLAN genauso, auch dort wird es so beschrieben.

Gruß Otto

Hallo,

Zitat von: Klinki am 23 Dezember 2016, 08:46:30
Was aber nicht funktioniert ist die AES-Signierung, falls ein Gerät über das Gateway kommunizieren will. In diesem Fall wird mehrfach ein

Code Auswählen Erweitern

...aesCommToDev: pending wiederholt.

Steht expectAES im Register für das Peer der entsprechenden Taste auf yes? Gibt es noch irgendwelche Meldungen im Log? Was ist das Peer der Taste?

Viele Grüße
  Michael

Zitat von: mgernoth am 23 Dezember 2016, 11:29:18
Steht expectAES im Register für das Peer der entsprechenden Taste auf yes? Gibt es noch irgendwelche Meldungen im Log? Was ist das Peer der Taste?

Die Taste hat keinen Peer. Das Event "aesCommToDev: ok" wird direkt in fhem verarbeitet.

Zitat von: Otto123 am 23 Dezember 2016, 11:03:01
Wenn ich das richtig verstehe, gibt die VCCU die hmKey an die zugeordneten IOs. Man macht es entweder bei der VCCU für alle oder beim einzelnen IO. Also wenn Dein IO zur VCCU gehört kennt er den hmKey.

Ich habe Otto's Worte noch einmal wirken lassen und anschließend alle I/O Devices und die VCCU gelöscht und von ganz vorne angelegt. Dabei zuerst CUL, dann LGW, dann VCCU definiert. VCCU die HMid und den HMKey zugewiesen und dann die zwei IOs in die IOLIst der VCCU eingetragen.
Anschließend der Fernbedienung den beigebracht...assignhmkey..sign on...aesCommReq=1...

jetzt funktioniert es wieder. Zumindest bei der einen Fernbedienung. Ich kann leider nicht sagen, was damals nicht geklappt hat. Vielleicht wg. diverser Release-Wechsel zwischen vccu und dem Einfügen des LGW.
Leider kann ich jetzt auch kein HM-Sniffing des Fehlers mehr liefern.

Ich teste mal weiter. Vielleicht ereilt mich noch die Erkenntnis...

Danke an euch!

Zitat von: Klinki am 23 Dezember 2016, 08:46:30
je nach rssi kommunizieren die Geräte entweder über den CUL oder das LGW.

du solltest deinen AES nutzenden Devices ein preffIO zuweisen.
Ansonsten läuft der erste versuch einer aes signierung schief, wenn die vccu dem Device auf grund von geänderten rssi werten einen anderen IO zuweist. Das hatte was mit dem timing zu tun.

Zitat von: automatisierer am 23 Dezember 2016, 13:55:38
du solltest deinen AES nutzenden Devices ein preffIO zuweisen.

schadet sicher nicht. Aber auch wenn die Geräte überhaupt nicht das I/O-Device wechseln, trat der Fehler auf.

Ich bin jetzt etwas weiter mit meiner Testerei. Grundsätzlich funktioniert die AES-signierte Kommunikation ja jetzt. Allerdings nicht sehr zuverlässig. Auch wenn letzten Endes die Unterhaltung in einem "trig_aes_vccu: ok" endet, so werden doch immer mehrere Versuche benötigt.

Die Kommunikation läuft hier über die virtuelle CCU und als IO das HM-LAN Gateway.

Ich hatte auch schon mal das Attribut msgRepeat auf 3 gesetzt. Das brachte keine Änderung.

Beispiel für eine erfolgreiche Unterhaltung:
Events:

2017-01-02 13:08:01.936 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:08:02.057 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:08:02.068 CUL_HM vccu aesKeyNbr: 02
2017-01-02 13:08:02.449 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:08:02.573 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:08:02.589 CUL_HM vccu aesKeyNbr: 02
2017-01-02 13:08:02.957 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:08:03.082 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:08:03.104 CUL_HM vccu aesKeyNbr: 02
2017-01-02 13:08:03.263 CUL_HM HM_4D8F32 aesCommToDev: ok
2017-01-02 13:08:03.263 CUL_HM HM_4D8F32 battery: ok
2017-01-02 13:08:03.263 CUL_HM HM_4D8F32 CMDs_done
2017-01-02 13:08:03.263 CUL_HM HM_4D8F32 HM_4D8F32_armInt Short
2017-01-02 13:08:03.326 CUL_HM HM_4D8F32_armInt Short (to vccu)
2017-01-02 13:08:03.326 CUL_HM HM_4D8F32_armInt trig_aes_vccu: ok:67
2017-01-02 13:08:03.326 CUL_HM HM_4D8F32_armInt trigger: Short_67
2017-01-02 13:08:03.326 CUL_HM HM_4D8F32_armInt triggerTo_vccu: Short_67
2017-01-02 13:08:03.326 CUL_HM HM_4D8F32_armInt trigger_cnt: 67
2017-01-02 13:08:03.350 CUL_HM HM_4D8F32_armInt triggerTo_vccu: Short_67_ack

Log:
2017.01.02 13:07:59.026 0: HMUARTLGW meinLGW roundtrip delay: 0.0071
2017.01.02 13:08:01.938 0: HMUARTLGW meinLGW recv: 01 05 00 00 2A msg: 9D A2 40 4D8F32 F0815F 0143
2017.01.02 13:08:02.060 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: 9D A0 02 F0815F 4D8F32 04ECC76E9B331D02
2017.01.02 13:08:02.455 0: HMUARTLGW meinLGW recv: 01 05 00 00 2A msg: 9E A2 40 4D8F32 F0815F 0143
2017.01.02 13:08:02.580 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: 9E A0 02 F0815F 4D8F32 04ECC76E9B331D02
2017.01.02 13:08:02.962 0: HMUARTLGW meinLGW recv: 01 05 00 00 2A msg: 9F A2 40 4D8F32 F0815F 0143
2017.01.02 13:08:03.092 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: 9F A0 02 F0815F 4D8F32 04ECC76E9B331D02
2017.01.02 13:08:03.116 0: HMUARTLGW meinLGW recv: 01 05 00 00 2A msg: 9F A2 03 4D8F32 F0815F 5416518CA5B3EB2935A176643B1ADEE5
2017.01.02 13:08:03.330 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: 9F 80 02 F0815F 4D8F32 00CF385F90
2017.01.02 13:08:06.171 0: HMUARTLGW meinLGW:keepAlive send (3): K19
2017.01.02 13:08:06.179 0: HMUARTLGW meinLGW:keepAlive read (4): >K19

Hier funktioniert´s nicht:
Events:
2017.01.02 13:10:36.347 0: HMUARTLGW meinLGW:keepAlive send (3): K28
2017.01.02 13:10:36.354 0: HMUARTLGW meinLGW:keepAlive read (4): >K28
2017.01.02 13:10:38.471 0: HMUARTLGW meinLGW recv: 01 05 00 00 2A msg: A0 A2 40 4D8F32 F0815F 0404
2017.01.02 13:10:38.479 0: HMUARTLGW meinLGW recv: 01 05 00 00 2D msg: A0 80 02 F0815F 4D8F32 00
2017.01.02 13:10:42.509 0: HMUARTLGW meinLGW recv: 01 05 00 00 26 msg: 18 86 10 42B388 000000 0A88DE0C0000
2017.01.02 13:10:42.784 0: HMUARTLGW meinLGW recv: 01 05 00 00 2D msg: A1 A2 40 4D8F32 F0815F 0144
2017.01.02 13:10:42.914 0: HMUARTLGW meinLGW recv: 01 05 00 00 2D msg: A1 A0 02 F0815F 4D8F32 044EE7312250B802
2017.01.02 13:10:43.292 0: HMUARTLGW meinLGW recv: 01 05 00 00 2D msg: A2 A2 40 4D8F32 F0815F 0144
2017.01.02 13:10:43.422 0: HMUARTLGW meinLGW recv: 01 05 00 00 2D msg: A2 A0 02 F0815F 4D8F32 044EE7312250B802
2017.01.02 13:10:43.804 0: HMUARTLGW meinLGW recv: 01 05 00 00 2E msg: A3 A2 40 4D8F32 F0815F 0144
2017.01.02 13:10:43.934 0: HMUARTLGW meinLGW recv: 01 05 00 00 2D msg: A3 A0 02 F0815F 4D8F32 044EE7312250B802
2017.01.02 13:10:44.091 0: HMUARTLGW meinLGW send: 00 08
2017.01.02 13:10:44.102 0: HMUARTLGW meinLGW recv: 00 040200, state 98
2017.01.02 13:10:44.103 0: HMUARTLGW meinLGW GetSet Ack: 02, state 98
2017.01.02 13:10:44.105 0: HMUARTLGW meinLGW roundtrip delay: 0.0073
2017.01.02 13:10:46.358 0: HMUARTLGW meinLGW:keepAlive send (3): K29
2017.01.02 13:10:46.366 0: HMUARTLGW meinLGW:keepAlive read (4): >K29
2017.01.02 13:10:56.381 0: HMUARTLGW meinLGW:keepAlive send (3): K2a
2017.01.02 13:10:56.402 0: HMUARTLGW meinLGW:keepAlive read (4): >K2a

Log:
2017-01-02 13:10:42.774 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:10:42.904 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:10:42.925 CUL_HM vccu aesKeyNbr: 02
2017-01-02 13:10:43.284 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:10:43.413 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:10:43.434 CUL_HM vccu aesKeyNbr: 02
2017-01-02 13:10:43.794 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:10:43.925 CUL_HM HM_4D8F32 aesCommToDev: pending
2017-01-02 13:10:43.945 CUL_HM vccu aesKeyNbr: 02


mir gehen die Ideen aus  :-\

Moin,

Mittlerweile funktioniert über das Lan Gateway überhaupt kein AES mehr. Beim folgenden Versuch liegt das LGW nicht mehr direkt neben mir und der CUL, welcher ebenfalls zur virtuellen CCU gehört, ist (gerade eben) noch in Reichweite.
Hier ein Beispiel für 3 x Taste drücken:
Die Events:

2017-01-05 07:25:56.405 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:25:56.534 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:25:56.552 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:25:56.679 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:25:56.714 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:25:56.906 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:25:57.034 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:25:57.052 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:26:02.179 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:26:02.307 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:26:02.326 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:26:02.454 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:26:02.489 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:26:02.687 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:26:02.723 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:26:04.571 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:26:04.607 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:26:04.821 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:26:04.856 CUL_HM vccu aesKeyNbr: 02
2017-01-05 07:26:05.071 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-05 07:26:05.107 CUL_HM vccu aesKeyNbr: 02

Das Log:

2017.01.05 07:25:56.285 4: CUL_Parse: CUL_0 A 0B F7 A240 39776C F0815F 432CC7 -102.5
2017.01.05 07:25:56.386 4: CUL_send:  CUL_0As 11 F7 A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.411 0: HMUARTLGW meinLGW recv: 01 05 00 00 32 msg: F7 A2 40 39776C F0815F 432C
2017.01.05 07:25:56.515 4: CUL_send:  CUL_0As 11 F7 A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.539 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: F7 A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.556 0: HMUARTLGW meinLGW recv: 01 05 00 00 32 msg: F8 A2 40 39776C F0815F 432C
2017.01.05 07:25:56.660 4: CUL_send:  CUL_0As 11 F8 A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.701 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: F8 A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.786 4: CUL_Parse: CUL_0 A 0B F9 A240 39776C F0815F 432CBD -107.5
2017.01.05 07:25:56.888 4: CUL_send:  CUL_0As 11 F9 A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.910 0: HMUARTLGW meinLGW recv: 01 05 00 00 33 msg: F9 A2 40 39776C F0815F 432C
2017.01.05 07:25:57.015 4: CUL_send:  CUL_0As 11 F9 A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:57.039 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: F9 A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:57.057 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: F9 A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:57.183 0: HMUARTLGW meinLGW:keepAlive send (3): K1b
2017.01.05 07:25:57.191 0: HMUARTLGW meinLGW:keepAlive read (4): >K1b
2017.01.05 07:26:02.057 4: CUL_Parse: CUL_0 A 0B FA A240 39776C F0815F 032DBE -107
2017.01.05 07:26:02.159 4: CUL_send:  CUL_0As 11 FA A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:02.184 0: HMUARTLGW meinLGW recv: 01 05 00 00 31 msg: FA A2 40 39776C F0815F 032D
2017.01.05 07:26:02.288 4: CUL_send:  CUL_0As 11 FA A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:02.313 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: FA A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:02.329 0: HMUARTLGW meinLGW recv: 01 05 00 00 33 msg: FB A2 40 39776C F0815F 032D
2017.01.05 07:26:02.435 4: CUL_send:  CUL_0As 11 FB A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:02.476 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: FB A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:02.564 0: HMUARTLGW meinLGW recv: 01 05 00 00 33 msg: FC A2 40 39776C F0815F 032D
2017.01.05 07:26:02.668 4: CUL_send:  CUL_0As 11 FC A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:02.709 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: FC A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:03.572 0: HMUARTLGW meinLGW send: 00 08
2017.01.05 07:26:03.582 0: HMUARTLGW meinLGW recv: 00 040200, state 98
2017.01.05 07:26:03.584 0: HMUARTLGW meinLGW GetSet Ack: 02, state 98
2017.01.05 07:26:03.585 0: HMUARTLGW meinLGW roundtrip delay: 0.0073
2017.01.05 07:26:04.447 0: HMUARTLGW meinLGW recv: 01 05 00 00 33 msg: FD A2 40 39776C F0815F 032E
2017.01.05 07:26:04.552 4: CUL_send:  CUL_0As 11 FD A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:04.593 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: FD A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:04.697 0: HMUARTLGW meinLGW recv: 01 05 00 00 33 msg: FE A2 40 39776C F0815F 032E
2017.01.05 07:26:04.802 4: CUL_send:  CUL_0As 11 FE A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:04.843 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: FE A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:04.948 0: HMUARTLGW meinLGW recv: 01 05 00 00 33 msg: FF A2 40 39776C F0815F 032E
2017.01.05 07:26:05.053 4: CUL_send:  CUL_0As 11 FF A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:05.094 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: FF A0 02 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:26:07.196 0: HMUARTLGW meinLGW:keepAlive send (3): K1c
2017.01.05 07:26:07.204 0: HMUARTLGW meinLGW:keepAlive read (4): >K1c


Die Internals der Fernbedienung
Internals:
   CUL_0_MSGCNT 23
   CUL_0_RAWMSG A1906A00339776CF0815FC9D4304919815989556E481F48BADA2B::-66:CUL_0
   CUL_0_RSSI -66
   CUL_0_TIME 2017-01-05 07:45:51
   DEF        39776C
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     56
   NAME       FB_Thomas
   NOTIFYDEV  global
   NR         85
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 FB_Thomas_armInt
   channel_02 FB_Thomas_armExt
   channel_03 FB_Thomas_light
   channel_04 FB_Thomas_disarm
   lastMsg    No:06 - t:03 s:39776C d:F0815F C9D4304919815989556E481F48BADA2B
   meinLGW_MSGCNT 33
   meinLGW_RAWMSG 0500005306A00339776CF0815FC9D4304919815989556E481F48BADA2B
   meinLGW_RSSI -83
   meinLGW_TIME 2017-01-05 07:45:50
   protEvt_AESCom-ok 3 last_at:2017-01-05 07:45:50
   protLastRcv 2017-01-05 07:45:51
   protSnd    6 last_at:2017-01-05 07:45:51
   protState  CMDs_done
   rssi_at_CUL_0 avg:-65.33 min:-66 max:-64.5 lst:-66 cnt:3
   rssi_at_meinLGW avg:-86 min:-88 max:-84 lst:-86 cnt:3
   Helper:
     Dblog:
       Battery:
         Logdb:
           TIME       1483598750.95638
           VALUE      ok
   Readings:
     2017-01-04 14:03:42   CommandAccepted yes
     2017-01-04 14:03:41   D-firmware      1.2
     2017-01-04 14:03:41   D-serialNr      MEQ0076971
     2017-01-04 07:07:40   PairedTo        0xF0815F
     2017-01-04 07:07:40   R-pairCentral   0xF0815F
     2017-01-04 07:07:40   RegL_00.        02:01 0A:F0 0B:81 0C:5F 18:00 00:00
     2017-01-05 07:45:50   aesCommToDev    ok
     2017-01-04 07:23:57   aesKeyNbr       02
     2017-01-05 07:45:51   aesReqTo        vccu
     2017-01-04 07:03:03   alive           yes
     2017-01-05 07:45:50   battery         ok
     2017-01-04 07:03:03   powerOn         2017-01-04 07:03:03
     2017-01-04 07:03:03   recentStateType info
     2017-01-05 07:45:51   state           CMDs_done
   Helper:
     HM_CMDNR   6
     mId        00A5
     rxType     20
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +39776C,01,00,1E
       nextSend   1483598751.22528
       rxt        2
       vccu       vccu
       p:
         39776C
         01
         00
         1E
       prefIO:
         CUL_0
     Mrssi:
       mNo        06
       Io:
         CUL_0      -64
         meinLGW    -86
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1483598751.12811
       ack:
         HASH(0x2625c80)
         068002F0815F39776C00
     Rssi:
       At_cul_0:
         avg        -65.3333333333333
         cnt        3
         lst        -66
         max        -64.5
         min        -66
       At_meinlgw:
         avg        -86
         cnt        3
         lst        -86
         max        -84
         min        -88
     Tmpl:
   Role:
Attributes:
   IODev      CUL_0
   IOgrp      vccu:CUL_0
   aesCommReq 1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   group      Fernbedienung
   model      HM-RC-Sec4-2
   room       EDV
   serialNr   MEQ0076971
   subType    remote
   webCmd     getConfig:clear msgEvents

und die Definition der VCCU und deren IOs:

define CUL_0 CUL /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1034
attr CUL_0 hmId F0815F
attr CUL_0 icon cul_cul
attr CUL_0 rfmode HomeMatic
attr CUL_0 room Hilfsmodule
attr CUL_0 verbose 4


define vccu CUL_HM F0815F
attr vccu IODev CUL_0
attr vccu IOList CUL_0, meinLGW
attr vccu expert 2_raw
attr vccu hmKey 01:5bc85af58437921d673541f19ba020af
attr vccu model CCU-FHEM
attr vccu room Hilfsmodule
attr vccu subType virtual
attr vccu webCmd virtual:update

define meinLGW HMUARTLGW 172.16.1.192
attr meinLGW icon hm_lan
attr meinLGW lgwPw xxxxxxxxxxxx
attr meinLGW room Hilfsmodule
attr meinLGW logIDs all,sys

Ich habe keine Ahnung, was ich noch ausprobieren kann  :-[

attr vccu IOList CUL_0, meinLGW
das leerzeichen hinter dem komma muss weg.  ;)

edit:
attr vccu expert 2_raw
ist expert hier erlaubt? würde ich mal löschen

deine culfw gibt es neuer => ts_fw.

Hi Frank,

Zitat von: frank am 05 Januar 2017, 08:04:20
das leerzeichen hinter dem komma muss weg.  ;)

Das war´s leider nicht. LGW und CUL haben auch jeweils als "owner_CCU" das Gerät "vccu" in den Internals. So ist das, denke ich mal, auch richtig

Zitat von: frank am 05 Januar 2017, 08:04:20

Code Auswählen Erweitern

attr vccu expert 2_raw
ist expert hier erlaubt? würde ich mal löschen

-> erledigt. Keine Änderung

Zitat von: frank am 05 Januar 2017, 08:04:20
deine culfw gibt es neuer => ts_fw.

Da es sich um ein produktives System handelt, würde ich ungern am CUL rumbasteln. Der läuft ja eigentlich stabil. Es ging "nur" darum die Reichweite des Systems mit Hilfe eines LAN Gateways zu vergrößern.

ZitatSo ist das, denke ich mal, auch richtig

nein, trennzeichen ist komma, nicht komma plus leerzeichen.
schau mal in den status der vccu.

schau auch noch mal in meinen letzten post.

wenn du ein list von device auch den io's postest statt der definition, dann könnte man alle relevanten sachen sehen

Zitat von: frank am 05 Januar 2017, 08:16:23
nein, trennzeichen ist komma, nicht komma plus leerzeichen.
schau mal in den status der vccu.
schau auch noch mal in meinen letzten post.

...mag ja sein, aber nochmal: Sowohl CUL als auch LGW haben die vccu als Owner. Das meinte ich mit "...richtig sein"

Hier aber auch ein List der vccu:
Internals:
   CUL_0_MSGCNT 6
   CUL_0_RAWMSG A0908A112F0815F42C968::-79:CUL_0
   CUL_0_RSSI -79
   CUL_0_TIME 2017-01-05 08:19:09
   DEF        F0815F
   IODev      CUL_0
   LASTInputDev meinLGW
   MSGCNT     14
   NAME       vccu
   NOTIFYDEV  global
   NR         76
   NTFY_ORDER 50-vccu
   STATE      CUL_0:ok,meinLGW:ok,
   TYPE       CUL_HM
   assignedIOs CUL_0,meinLGW
   channel_01 vccu_Btn1
   channel_05 vccu_Btn5
   channel_06 vccu_Btn6
   channel_07 vccu_Btn7
   channel_08 vccu_Btn8
   channel_09 vccu_Btn9
   channel_10 vccu_Btn16
   channel_11 vccu_Btn17
   channel_12 vccu_Btn18
   channel_13 vccu_Btn19
   channel_14 vccu_Btn20
   channel_15 vccu_Btn21
   channel_16 vccu_Btn22
   channel_17 vccu_Btn23
   channel_18 vccu_Btn24
   channel_19 vccu_Btn25
   channel_20 vccu_Btn32
   channel_21 vccu_Btn33
   channel_22 vccu_Btn34
   channel_23 vccu_Btn35
   channel_24 vccu_Btn36
   lastMsg    No:A6 - t:11 s:F0815F d:42C968 86042D
   meinLGW_MSGCNT 8
   meinLGW_RAWMSG 05000050A6A011F0815F42C96886042D
   meinLGW_RSSI -80
   meinLGW_TIME 2017-01-05 08:19:10
   protLastRcv 2017-01-05 08:19:10
   rssi_at_CUL_0 avg:-78.5 min:-79 max:-78 lst:-79 cnt:6
   rssi_at_meinLGW avg:-78.87 min:-80 max:-75 lst:-80 cnt:8
   Readings:
     2017-01-05 08:10:12   CommandAccepted yes
     2017-01-05 08:10:11   aesKeyNbr       02
     2017-01-04 07:23:57   aesReqTo        FB_Thomas
     2017-01-05 08:16:48   state           CUL_0:ok,meinLGW:ok,
     2017-01-03 13:45:24   unknown_45B816  received
     2017-01-03 13:37:19   unknown_45B8F1  received
     2017-01-04 14:33:22   unknown_4B44B0  received
     2017-01-02 09:33:57   unknown_4D8F32  received
     2017-01-05 08:07:47   unknown_F10000  received
     2017-01-05 07:03:47   unknown_F4711F  received
   Helper:
     HM_CMDNR   166
     mId        FFF0
     rxType     1
     Ack:
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       nextSend   1483600751.27696
       prefIO
       vccu
       ioList:
         CUL_0
         meinLGW
     Mrssi:
       mNo        A6
       Io:
         meinLGW    -80
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Rssi:
       At_cul_0:
         avg        -78.5
         cnt        6
         lst        -79
         max        -78
         min        -79
       At_meinlgw:
         avg        -78.875
         cnt        8
         lst        -80
         max        -75
         min        -80
     Tmpl:
Attributes:
   IODev      CUL_0
   IOList     CUL_0,meinLGW
   hmKey      01:01234567890123456789012345678901234567890123456789
   model      CCU-FHEM
   room       Hilfsmodule
   subType    virtual
   webCmd     virtual:update

der CUL:
nternals:
   CMDS       BbCFiAZNkGMKUYRTVWXefmLltux
   CUL_0_MSGCNT 60
   CUL_0_TIME 2017-01-05 08:22:02
   Clients    :CUL_HM:HMS:CUL_IR:STACKABLE_CC:
   DEF        /dev/serial/by-id/usb-busware.de_CUL868-if00@9600 1034
   DeviceName /dev/serial/by-id/usb-busware.de_CUL868-if00@9600
   FD         11
   FHTID      1034
   NAME       CUL_0
   NR         73
   NR_CMD_LAST_H 20
   PARTIAL
   RAWMSG     A0C68865A40B614000000B4E1230F
   RSSI       -66.5
   STATE      Initialized
   TYPE       CUL
   VERSION    V 1.66 CUL868
   initString X21
Ar
   owner_CCU  vccu
   Matchlist:
     1:CUL_HM   ^A....................
     8:HMS      ^810e04....(1|5|9).a001
     D:CUL_IR   ^I............
     H:STACKABLE_CC ^\*
   Readings:
     2017-01-05 08:16:35   cmds             B b C F i A Z N k G M K U Y R T V W X e f m L l t u x
     2017-01-05 08:22:02   state           Initialized
   XMIT_TIME:
     1483600742.53667
     1483600742.79099
     1483600743.04246
     1483600743.30748
     1483600749.56244
     1483600749.81159
     1483600750.06401
     1483600750.33032
     1483600750.5945
     1483600750.85767
     1483600879.55751
     1483600879.81557
     1483600880.07942
     1483600880.34501
     1483600880.60859
     1483600917.28331
     1483600917.54155
     1483600917.81337
     1483600918.07315
     1483600918.33701
   Helper:
     42b72e:
       QUEUE:
     42c968:
       QUEUE:
Attributes:
   hmId       F0815F
   icon       cul_cul
   rfmode     HomeMatic
   room       Hilfsmodule
   verbose    4

und das GW:
Internals:
   AssignedPeerCnt 21
   CNT        138
   DEF        172.16.1.192
   DEVCNT     70
   DevState   99
   DevType    LGW
   DeviceName 172.16.1.192:2000
   FD         12
   LastOpen   1483600603.57916
   NAME       meinLGW
   NR         78
   PARTIAL
   RAWMSG     0500004B2C865A40B278000000A8D222
   RSSI       -75
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   msgLoadCurrent 1
   msgLoadHistory 1/-/-/-/-/-/-/-/-/-/-/-
   msgLoadHistoryAbs 1/0/-/-/-/-/-/-/-/-/-/-/-
   owner      F0815F
   owner_CCU  vccu
   Helper:
     CreditTimer 25
     FW         66561
     Initialized 1
     SendCnt    3
     Ackpending:
     LastSendLen:
       3
       3
     Log:
       IDs:
         all
         sys
     PeerQueue:
     PendingCMD:
     Roundtrip:
       Delay      0.00733304023742676
     Loadlvl:
       lastHistory 1483600908.73748
   Peers:
     3931A0     +3931A0,00,01,1E
     3AD5C5     +3AD5C5,00,01,00
     3C9997     +3C9997,00,01,00
     40B278     +40B278,00,01,00
     40B614     +40B614,00,01,00
     42B35F     +42B35F,00,01,00
     42B388     +42B388,00,01,00
     42EA2C     +42EA2C,00,01,00
     4731A9     +4731A9,00,01,00
     4734B6     +4734B6,00,01,00
     4734BE     +4734BE,00,01,00
     48EFF4     +48EFF4,00,01,1E
     48F009     +48F009,00,01,00
     48F023     +48F023,00,01,02
     48F02A     +48F02A,00,01,00
     4B44B0     +4B44B0,00,01,00
     4C3165     +4C3165,00,01,00
     4C6854     +4C6854,00,01,00
     4C6877     +4C6877,00,01,00
     4C68C8     +4C68C8,00,01,00
     4D8FAA     +4D8FAA,01,01,1E
   Readings:
     2017-01-05 08:16:48   D-HMIdAssigned  F0815F
     2017-01-05 08:16:48   D-HMIdOriginal  FFFFFF
     2017-01-05 08:16:43   D-LANfirmware   1.1.4
     2017-01-05 08:16:48   D-firmware      1.4.1
     2017-01-05 08:16:43   D-serialNr      NEQ0708092
     2017-01-05 08:16:43   D-type          eQ3-HM-LGW
     2017-01-05 08:16:48   cond            ok
     2017-01-05 08:21:49   load            1
     2017-01-05 08:16:48   loadLvl         low
     2017-01-05 08:16:43   state           opened
   Helper:
   Keepalive:
     CNT        65
     DEVCNT     64
     DevState   99
     DevType    LGW-KeepAlive
     DeviceName 172.16.1.192:2001
     FD         14
     LastOpen   1483600604.1391
     NAME       meinLGW:keepAlive
     NR         531
     PARTIAL
     STATE      opened
     TEMPORARY  1
     TYPE       HMUARTLGW
     XmitOpen   0
     Helper:
       NextKeepAlive 1483600975.88093
       Log:
         Resolve    1
         IDs:
     Readings:
       2017-01-05 08:16:44   state           opened
     Lgwhash:
Attributes:
   hmId       F0815F
   icon       hm_lan
   lgwPw      xxxxxxx
   logIDs     all,sys
   room       Hilfsmodule

hmKey  unkenntlich machen...

Zitat von: automatisierer am 05 Januar 2017, 08:28:57
hmKey  unkenntlich machen...

Warum? Der AES-Key wird nur als Hash gespeichert und lässt sich nicht rück-ermitteln. Das Passwort für das LAN-GW habe ich aber rausgestrichen  ;)

Aber unrecht hast Du nicht. Es kann nicht schaden...

Zitat von: Klinki am 05 Januar 2017, 08:21:38
...mag ja sein, aber nochmal: Sowohl CUL als auch LGW haben die vccu als Owner. Das meinte ich mit "...richtig sein"

Hi,

ich weiß nicht genau wann das Owner gesetzt wird, aber was Frank sagt hat schon seine Berechtigung.
Das hier ist wichtig-> STATE      CUL_0:ok,meinLGW:ok,
Und ich glaube das wird nicht dagestanden haben, solange wie in Deiner IOList ein Leerzeichen war. Da wurde das LGW nämlich nicht verwendet.

Gruß Otto

Zitat von: Otto123 am 05 Januar 2017, 10:01:31
ich weiß nicht genau wann das Owner gesetzt wird, aber was Frank sagt hat schon seine Berechtigung.
Das hier ist wichtig-> STATE      CUL_0:ok,meinLGW:ok,
Und ich glaube das wird nicht dagestanden haben, solange wie in Deiner IOList ein Leerzeichen war. Da wurde das LGW nämlich nicht verwendet.

Ich habe mich vielleicht misverständlich ausgedrückt: Natürlich habe ich Frank´s Bemerkung ernst genommen und das Leerzeichen auch rausgelöscht.

Zitat von: Klinki am 05 Januar 2017, 08:12:44
Das war´s leider nicht.

Aber es ändert nichts an der Tatsache, dass es jetzt nicht mehr da ist, CUL und LGW als owner die vccu eingetragen haben. Es jetzt also in Ordnung sein sollte (-so ich hoffe).
Leider funktioniert es jetzt immer noch nicht.

Ich hatte zwischenzeitlich auch versucht, den HMKey beim LGW als Attribut zu hinterlegen. Obwohl die Signierung ja von der vccu kommen sollte (wie auch von Otto schon beschrieben).
Brachte jedenfalls keine Änderung.

Wenn euch auch keine Fehler mehr auffallen, würde ich die Definitionen von IOs und vccu noch mal neu machen.

gruß
klinki

Also Zusammenfassung:
HM_LGW war nicht assigned 》somit war der schon mal raus.

Der CUL hat eine ungeignete Firmware und ist als prefIO gesetzt.

somit sollte klar sein, warum dein AES nicht funktioniert.

Gruß
Ingo

Zitat von: automatisierer am 05 Januar 2017, 10:40:16
Der CUL hat eine ungeignete Firmware und ist als prefIO gesetzt.

Verstehe ich nicht: was hat denn der CUL damit zu tun, wenn über LGW keine AES-Signierung stattfindet?

Hinweis am Rande: Die Kommunikation über LGW funktioniert grundsätzlich. Sogar mit CUL/LGW-Roaming (man latscht...) - nur nicht mit AES-Signierung


EDIT: Den CUL gegen einen nanoCUL mit aktueller FW 1.67 getauscht. Keine Änderung

VCCU und alle IOs noch einmal komplett neu angelegt. Diesmal von Anfang an ohne Leerzeichen  ;)
Fhem neu gestartet.
Keine Änderung.

LGW und fhem-Raspi spannungsfrei gemacht und neu gestartet.
Die AES-Sgnierung funktioniert jetzt in ca. 30% der Versuche!
An der Empfangsqualität im Bereich des LGW kann es eigentlich nicht liegen. Bei Kanälen der gleichen FB ohne AES-Request funktioniert die Kommunikation bei 100% der Versuche.

Es sieht also so aus, als wenn das LAN-Gateway das Problem ist. Ich werde weiter probieren und berichten!

Danke für euren Rat!

Hallo,

Zitat von: Klinki am 05 Januar 2017, 07:58:36
Mittlerweile funktioniert über das Lan Gateway überhaupt kein AES mehr. Beim folgenden Versuch liegt das LGW nicht mehr direkt neben mir und der CUL, welcher ebenfalls zur virtuellen CCU gehört, ist (gerade eben) noch in Reichweite.

Tja, aber dummerweise wird trotzdem der CUL und nicht das LAN-Gateway zum senden verwendet:

Zitat

Code Auswählen Erweitern


2017.01.05 07:25:56.285 4: CUL_Parse: CUL_0 A 0B F7 A240 39776C F0815F 432CC7 -102.5
2017.01.05 07:25:56.386 4: CUL_send:  CUL_0As 11 F7 A002 F0815F 39776C 043ECE84C309EF02


CUL empfängt (gerade noch) die FB und sendet die Signaturanforderung. Die kommt beim LGW (wahrscehinlich wegen Entfernung) gar nicht an.

Zitat

Code Auswählen Erweitern


2017.01.05 07:25:56.515 4: CUL_send:  CUL_0As 11 F7 A002 F0815F 39776C 043ECE84C309EF02
2017.01.05 07:25:56.539 0: HMUARTLGW meinLGW recv: 01 05 00 00 4F msg: F7 A0 02 F0815F 39776C 043ECE84C309EF02


Cul sendet 2. Signaturanforderung, kommt diesmal beim LGW an, nicht aber bei der Fernbedienung

Zitat

Code Auswählen Erweitern


2017.01.05 07:25:56.556 0: HMUARTLGW meinLGW recv: 01 05 00 00 32 msg: F8 A2 40 39776C F0815F 432C


FB wiederholt request, kommt nur bei LGW an, nicht bei CUL. CUL sendet aber wieder AES challenge, da er präferiert ist und funktioniert:

Zitat

Code Auswählen Erweitern


2017.01.05 07:25:56.660 4: CUL_send:  CUL_0As 11 F8 A002 F0815F 39776C 043ECE84C309EF02


Wenn Du die FB auf den CUL festnagelst, macht das LGW nie AES (bzw. redet gar nicht mit dem Gerät), ausser der CUL ist offline. Das ist normal.

Wenn Du AES mit Roaming machst, geht der erste Request meistens schief, da die VCCU die FB erst dem LGW bekannt machen muss, bevor dieses den AES-Request beantwortet. Das geht aber natürlich erst, wenn der Tastendruck beim LGW angekommen ist (und dann ist es zu spät, das GW wird erst auf den nächsten _neuen_ (nicht wiederholten) Tastendruck reagieren).

Viele Grüße
  Michael

Hallo Michael,

Vielen Dank für die informative Antwort!
Was ich dabei allerdings nicht so recht verstehe ist, dass die FB zuerst mit dem CUL redet - auch wenn die rssi deutlich schlechter ist. Vermutlich weil der CUL als letzter Gesprächspartner bekannt ist, oder?

Nur verstehe ich auch nicht, warum es vor dem Kaltstart des LGWs gar nicht mehr mit AES geklappt hatte.

Das schlechte Roaming-Verhalten werde ich mal beobachten.
Könnte man, sozusagen als workaround, die FB ausschließlich am LGW anlernen und gar nicht die vccu nutzen? Rein praktisch geht es darum in einem bestimmten Bereich die FB benutzen zu können. Dieser wird vollständig vom LGW abgedeckt.

gruß
klinki

Zitat von: Klinki am 05 Januar 2017, 15:11:26
Hallo Michael,

Vielen Dank für die informative Antwort!
Was ich dabei allerdings nicht so recht verstehe ist, dass die FB zuerst mit dem CUL redet - auch wenn die rssi deutlich schlechter ist. Vermutlich weil der CUL als letzter Gesprächspartner bekannt ist, oder?

Nur verstehe ich auch nicht, warum es vor dem Kaltstart des LGWs gar nicht mehr mit AES geklappt hatte.

Das schlechte Roaming-Verhalten werde ich mal beobachten.
Könnte man, sozusagen als workaround, die FB ausschließlich am LGW anlernen und gar nicht die vccu nutzen? Rein praktisch geht es darum in einem bestimmten Bereich die FB benutzen zu können. Dieser wird vollständig vom LGW abgedeckt.

gruß
klinki

du hattest bei der FB den CUL als prefIO gesetzt, wenn du den LGW nutzen willst, dann musst du den als preffIO setzen und das wars... Dann antwortet der auch der FB.

Zitat von: automatisierer am 05 Januar 2017, 16:20:07
du hattest bei der FB den CUL als prefIO gesetzt

habe ich nicht. Das macht fhem von ganz alleine.
Genauso wie es auch umsetzt ein anderes preferredIO zu nehmen, falls das erste nicht erreichbar ist. Genau das darf NICHT passieren. Die FB darf NUR mit dem LGW sprechen

beim ersten pairen, wird dem Device automatisch ein prefIO zugewiesen. Richtig!

Das verändert FHEM danach aber nicht mehr selbstständig!!

Wenn du ein anderes prefIO nutzen möchtest, dann musst du das von Hand in dem Attribut ändern!

wenn du kein preffIo vergibst, also bei dem Attribut IOgrp nur vccu einträgst - ohne :CUL Dann entscheidet die vccu selbst über welches IO das Device angesprochen wird.

Also, prefIO bedeutet:

attr <device> IOgrp vccu:CUL
oder
attr <device> IOgrp vccu:hmLGW

ohne prefIO bedeutet:

attr <device> IOgrp vccu

Das kann man auch alles schön im Wiki nachlesen:

https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU (https://wiki.fhem.de/wiki/Virtueller_Controller_VCCU)

ja, ich kann lesen. Aber noch mal: Auch wenn das LGW als prefIO gesetzt ist; die fb nutzt den CUL, wenn das LGW nicht erreichbar ist. Das bedeutet nun mal "preffered".
Beim nächsten Senden schickt die FB den ersten Befehl an das letzte erreichbare IO. Falls das der CUL war, läuft die AES-Sgnierung schief.
Ich habe es ausprobiert.

Wie dem auch sei: Meine Frage lautet, ob man verhindern kann, dass die FB überhaupt mit dem CUL redet.

Vielleicht ist das mit prefio aber auch praxis-tauglich genug. Das werde ich mal testen.

Wenn ich wieder vor Ort bin, werde ich mal ausprobieren, was passiert wenn die FB an das LGW angelernt wird. Ohne vccu...
schau mer mal

Zitat von: Klinki am 05 Januar 2017, 17:49:50
ja, ich kann lesen. Aber noch mal: Auch wenn das LGW als prefIO gesetzt ist; die fb nutzt den CUL, wenn das LGW nicht erreichbar ist. Das bedeutet nun mal "preffered".
Beim nächsten Senden schickt die FB den ersten Befehl an das letzte erreichbare IO. Falls das der CUL war, läuft die AES-Sgnierung schief.
Ich habe es ausprobiert.

so ein Schwachsinn! Die FB sendet Funkwellen aus und die werden von allen IO's empfangen! Mit preffIO legst du fest, mit welchem IO FHEM(die vccu) antwortet und nicht mit welchem IO die FB spricht. Die vccu entscheidet entweder spontan mit welchem IO sie antwortet, oder sie antwortet mit dem preffIO - wenn eingetragen. Sollte die FB diese Antwort dann nicht empfangen können, weil sie außerhalb der Reichweite des preffIO ist, dann is halt nix mit ACK oder AES oder was auch immer!! Der einzige Grund, wesshalb die vccu den preffIO nicht nutzt, ist, wenn dieser nicht
cond    ok      2017-01-05 17:58:29
in den Readings stehen hat (die Uhrzeit kann von der im Beispiel abweichen)

Gründe wären zum Beispiel ein overload oder ein diconnect. Damit die HM-Installation dann nicht für diese Zeit tot ist, versucht die vccu ihr bestes über einen anderen IO - sofern ein weiterer vorhanden ist.

Zitat
Wie dem auch sei: Meine Frage lautet, ob man verhindern kann, dass die FB überhaupt mit dem CUL redet.

Stöpsel ihn aus oder wickel ihn in Alufolie!

Zitat
Vielleicht ist das mit prefio aber auch praxis-tauglich genug. Das werde ich mal testen.

das ist sogar sehr praxistauglich! Funktioniert bei mir und vielen Anderen 100%ig.

Zitat
Wenn ich wieder vor Ort bin, werde ich mal ausprobieren, was passiert wenn die FB an das LGW angelernt wird. Ohne vccu...
schau mer mal

mir fällt nix mehr ein!

Zitat von: automatisierer am 05 Januar 2017, 18:59:01
so ein Schwachsinn! Die FB sendet Funkwellen aus und die werden von allen IO's empfangen! Mit preffIO legst du fest, mit welchem IO FHEM(die vccu) antwortet und nicht mit welchem IO die FB spricht. Die vccu entscheidet entweder spontan mit welchem IO sie antwortet, oder sie antwortet mit dem preffIO - wenn eingetragen. Sollte die FB diese Antwort dann nicht empfangen können, weil sie außerhalb der Reichweite des preffIO ist, dann is halt nix mit ACK oder AES oder was auch immer!!

Du sagst es doch selbst: Die erste Kommunikation mit AES schlägt fehl. PreffIO hin oder her.

Es bringt mir also an dieser Stelle einfach Nichts. Punkt. Nimm´s hin

Um aber wieder sachlicher zu werden:

Ich habe es grad mal durchgespielt:
- Wenn das LGW Teil einer VCCU ist, kann man auch kein Device nur an das LGW anlernen. Es hat als IOgrp dann doch immer die vccu. Dass nur die eine FB den CUL also ignoriert scheint nicht zu funktionieren
- Wenn die FB im Funkbereich des CUL war und betätigt wurde, schlägt die erste Kommunikation über das LGW in 30% der Fälle fehl. Wenn das preffIO-Attribut auf das LGW gesetzt wurde nur in ca. 10% der Fälle
- Wenn man umgekehrt in den Bereich des NICHT-preferred IOs kommt, schlägt die AES-Signierung in 80% der Fälle fehl (wenn man wiederholt am gleichen Standort drückt). "Roamt" man in den Bereich des NICHT-preferred IOS funktioniert die AES-Signierung beim ersten Mal drücken eigentlich nie.

Mein Fazit:
Mit gesetztem preferredIO-Attribut funktioniert die FB also im gefragten Bereich ausreichend gut.

EDIT: Nachtrag: Wenn man die FB mit AES-Signierung mit allen FunkIOs nutzen will, muss man hinnehmen, dass die AES-Signierung wahrscheinlich beim ersten Mal fehlschlägt nachdem man "geroamt" hat.

Danke an alle Beteiligten!

Zitat von: Klinki am 06 Januar 2017, 06:48:22
Du sagst es doch selbst: Die erste Kommunikation mit AES schlägt fehl. PreffIO hin oder her.

Es bringt mir also an dieser Stelle einfach Nichts. Punkt. Nimm´s hin

Letzter Versuch.
Wenn der preffIO das Device nicht erreicht, aber 'cond ok' ist, dann wird jede Kommunikation fehlschlagen. Die vccu sendet dann immer über das preffIO und nicht über den IO der bessere rssi Werte hat.

Beispiel - ohne preffIO:

Die FB sendet zu 1. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der CUL das sendende IO wird.
die FB wird dem CUL (http://cul) zugewiesen
die vccu antwortet uber CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sendet zum 2. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der CUL (http://cul) das sendende IO wird.
die FB ist dem CUL (http://cul) bereits zugewiesen
die vccu antwortet uber CUL - nun klappt AES, weil es nicht zu timning Problemen kommt.
--Befehl angekommen und ausgeführt--

Die FB sendet zum 3. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der LGW das sendende IO wird.
die FB wird dem LGW (http://lgw) zugewiesen
die vccu antwortet uber LGW - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sendet zum 4. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte aus und entscheidet das der LGW (http://lgw) das sendende IO wird.
die FB ist dem LGW (http://lgw) bereits zugewiesen
die vccu antwortet uber LGW - nun klappt AES, weil es nicht zu timning Problemen kommt.
--Befehl angekommen und ausgeführt--
usw...


Beispiel - mit preffIO:

Die FB sendet zu 1. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte nicht aus, das preffIO wird das sendende IO.
die FB wird dem preffIO (http://preffio) zugewiesen
vccu antwortet über preffIO - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sendet zu 2. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte nicht aus, das preffIO wird das sendende IO.
die FB ist dem preffIO (http://preffio) bereits zugewiesen
vccu antwortet über preffIO - nun klappt AES, weil es nicht zu timning Problemen kommt.
--Befehl angekommen und ausgeführt--

Die FB sendet zu 3. mal
LGW und CUL empfangen
die vccu wertet die rssi Werte nicht aus, das preffIO wird das sendende IO.
die FB ist dem preffIO (http://preffio) bereits zugewiesen
vccu antwortet über preffIO - FB ist außerhalb der Reichweite des preffIO
--Fehlversuch--

Die FB sendet zu 4. mal
LGW (preffIO aber disconnect) und CUL empfängt
die vccu wertet die rssi Werte aus, der CUL wird das sendende IO.
die FB wird dem CUL (http://cul) zugewiesen
vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

Das ist mal eine Ausführung. Danke dafür!

Deckt sich ja grundsätzlich auch mit meiner Beobachtung. Nur gibt es halt immer wieder die Fälle (die 10%), dass die AES-Signierung sporadisch nicht funktioniert. Man hat halt auch nicht immer Sniffing an oder Zeit sich damit zu beschäftigen.

Nur Dein letztes Beispiel ist mir nicht klar:
Die FB sendet zu 4. mal
LGW (preffIO aber disconnect) und CUL empfängt
die vccu wertet die rssi Werte aus, der CUL wird das sendende IO.
die FB wird dem CUL zugewiesen
vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sollte doch bei den Versuchen 1-3 dem CUL zugewiesen werden - wenn LGW außer Reichweite, richtig? Dann müsste Versuch 2 doch eigentlich schon funktionieren...

Zitat von: Klinki am 06 Januar 2017, 07:57:28
Das ist mal eine Ausführung. Danke dafür!

Deckt sich ja grundsätzlich auch mit meiner Beobachtung. Nur gibt es halt immer wieder die Fälle (die 10%), dass die AES-Signierung sporadisch nicht funktioniert. Man hat halt auch nicht immer Sniffing an oder Zeit sich damit zu beschäftigen.

Nur Dein letztes Beispiel ist mir nicht klar:

Code Auswählen Erweitern

Die FB sendet zu 4. mal
LGW (preffIO aber disconnect) und CUL empfängt
die vccu wertet die rssi Werte aus, der CUL wird das sendende IO.
die FB wird dem CUL zugewiesen
vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

Die FB sollte doch bei den Versuchen 1-3 dem CUL zugewiesen werden - wenn LGW außer Reichweite, richtig? Dann müsste Versuch 2 doch eigentlich schon funktionieren...

ich war davon ausgegangen, dass der LGW der preffIO ist...

... gedacht ist nicht gesagt... ;)


Ja, mit AES ist halt ein wenig schwierigwer als ohne. Da geantwortet werden muss und das in einem 'engen' Zeitfenster. Gerade bei beweglichen Devices gestaltet es sich schwierig, da sich die beiden Gesprächspartner 'unterhalten' müssen. Nutzt man AES bei Fernbedienungen nicht, dann müssen die IO's ja quasi nur zuhören. Und das können alle IO's gleichzeitig machen.

Zitat von: automatisierer am 06 Januar 2017, 08:21:03
ich war davon ausgegangen, dass der LGW der preffIO ist...

Deine Annahme war schon richtig. LGW ist das pref-IO. Ich will jetzt hier keine Haare spalten, es geht nur darum, ob ich Dein letztes Beispiel richtig verstanden habe.
Ich mache auch mal grad ein Beispiel:

1. Tastendruck
LGW ist prefIO und nicht erreichbar (rssi ist Minus Unendlich)
-> CUL empfängt
-> vccu wertet rssi aus und CUL wird das sendende IO
-> FB wird CUL zugewiesen
-> vccu antwortet über CUL - AES klappt wegen des timings nicht.
--Fehlversuch--

2. Tastendruck
LGW ist prefIO und nicht erreichbar (rssi ist Minus Unendlich)
-> CUL empfängt
-> der CUL ist der FB bereits als Sender zugewiesen
-> vccu antwortet über CUL
--AES funktioniert--

stimmt das woweit?

kurzum: wenn das sendende IO beim letzten Mal ein anderes war, geht die AES-Signierung immer schief? Kann man das so sagen?

wenn der LGW der preffIO ist, dann sendet die vccu immer über diesen IO - wirklich immer!! egal wie die rssi Werte sind. und egal über welchen IO die Sendung der FB empfangen wurde.

Die einzige Ausnahme in der die vccu von dem preffIO abweicht, ist, wenn der IO für die vccu nicht verfügbar ist. Das ist der Fall, wenn der IO z.B. den Zustand disconnected oder overload hat.

Verstanden. Danke nochmal für Deine Mühe & Geduld!

Ist aber schon etwas unpraktisch wenn das LGW überhaupt nicht vom Device gesehen (also praktisch kein rssi) wird und es dennoch als IO benutzt wird. Für meinen Zweck aber genau das Richtige!

Nur noch eine Randbemerkung: Nach meinem ganzen "Rumgefummel" funktionierte die AES-Signierung über das LGW plötzlich gar nicht mehr. "Plötzlich" kann ich leider nicht näher beschreiben.
Das LGW hatte dabei nach wie vor den Status "open". Ohne AES funktionierte die Kommunikation auch nach wie vor.

Jedenfalls brachte es Abhilfe das LGW neu zu starten. Diesmal nicht über Stecker raus/rein, sondern über das NetFinder-Programm und "Gerät neu starten". Man kann dabei beobachten wie das Gerät dann für eine halbe Minuten aus dem Netzwerk verschwindet, ein ping also in´s Leere läuft.

Ein "close"/"open" oder "restart" per fhem reichte dabei nicht.

du kannst deiner fernbedienung auch das lgw als "permanentes" io zuweisen, obwohl das io mit der vccu assigned ist.
wenn du das attribut IOgrp löscht, sendet immer das io, welches im attr IODev steht. hat natürlich den nachteil, dass auch bei "defektem" io kein roaming stattfindet.

Zitat von: frank am 07 Januar 2017, 21:05:18
du kannst deiner fernbedienung auch das lgw als "permanentes" io zuweisen, obwohl das io mit der vccu assigned ist.
wenn du das attribut IOgrp löscht, sendet immer das io, welches im attr IODev steht. hat natürlich den nachteil, dass auch bei "defektem" io kein roaming stattfindet.

Hallo Frank,

Ich habe es jetzt ein paar Tage mit dem bevorzugten IO versucht. Es lief nicht sonderlich gut. Daraufhin habe ich denn man Deinen Tipp befolgt und IOgrp gelöscht und das LGW als IODev gesetzt. Die ersten Versuche waren bisher erfolgreich. Was ich aber noch nicht so recht verstehe: Der CUL scheint an der Kommunikation doch immer noch beteiligt zu sein - oder sehe ich das falsch?

Hier das Sniffing (Kommunikation hat geklappt):
2017.01.12 07:21:51.952 4 : CUL_Parse: CUL_0 A 0B FF A240 39776C F0815F 033A17 -62.5
2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
2017-01-12 07:21:52.096 CUL_HM vccu aesKeyNbr: 02
2017.01.12 07:21:52.207 0 : HMUARTLGW meinLGW recv: 01 05 02 01 56 msg: FF A2 40 39776C F0815F 033A
2017-01-12 07:21:52.214 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 07:21:52.225 CUL_HM FB_Thomas aesCommToDev: ok
2017.01.12 07:21:52.227 4 : CUL_Parse: CUL_0 A 19 FF A003 39776C F0815F 4907ABC589E58A235BD13DA4CD74DB371A -61
2017-01-12 07:21:52.240 CUL_HM FB_Thomas aesReqTo: vccu
2017.01.12 07:21:52.330 4 : CUL_Parse: CUL_0 A 0E FF 8002 F0815F 39776C 00CCB2FF1E06 -71
2017.01.12 07:21:52.452 4 : CUL_Parse: CUL_0 A 0B 00 A240 39776C F0815F 033A1B -60.5
2017-01-12 07:21:52.505 CUL_HM FB_Thomas_light trig_aes_vccu: ok:58
2017.01.12 07:21:52.586 4 : CUL_Parse: CUL_0 A 11 00 A002 F0815F 39776C 04465E00005E170205 -71.5
2017-01-12 07:21:52.600 CUL_HM vccu aesKeyNbr: 02
2017.01.12 07:21:52.708 0 : HMUARTLGW meinLGW recv: 01 05 02 01 55 msg: 00 A2 40 39776C F0815F 033A
2017-01-12 07:21:52.719 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 07:21:52.731 CUL_HM FB_Thomas aesCommToDev: ok
2017.01.12 07:21:52.733 4 : CUL_Parse: CUL_0 A 19 00 A003 39776C F0815F 63971BF56298C1B94F6615B4FD9DA0681B -60.5
2017-01-12 07:21:52.749 CUL_HM FB_Thomas aesReqTo: vccu

Listing zur Fernbedienung:
Internals:
   CUL_0_MSGCNT 67
   CUL_0_RAWMSG A1900A00339776CF0815F63971BF56298C1B94F6615B4FD9DA068::-60.5:CUL_0
   CUL_0_RSSI -60.5
   CUL_0_TIME 2017-01-12 07:21:52
   DEF        39776C
   IODev      meinLGW
   LASTInputDev CUL_0
   MSGCNT     168
   NAME       FB_Thomas
   NOTIFYDEV  global
   NR         536
   NTFY_ORDER 50-FB_Thomas
   STATE      CMDs_done
   TYPE       CUL_HM
   channel_01 FB_Thomas_armInt
   channel_02 FB_Thomas_armExt
   channel_03 FB_Thomas_light
   channel_04 FB_Thomas_disarm
   lastMsg    No:00 - t:03 s:39776C d:F0815F 63971BF56298C1B94F6615B4FD9DA068
   meinLGW_MSGCNT 101
   meinLGW_RAWMSG 0502015500A24039776CF0815F033A
   meinLGW_RSSI -85
   meinLGW_TIME 2017-01-12 07:21:52
   protEvt_AESCom-ok 23 last_at:2017-01-12 07:21:52
   protLastRcv 2017-01-12 07:21:52
   protSnd    66 last_at:2017-01-12 07:21:52
   protState  CMDs_done
   rssi_at_CUL_0 avg:-62 min:-91 max:-55.5 lst:-60.5 cnt:67
   rssi_at_meinLGW avg:-80.78 min:-89 max:-46 lst:-85 cnt:23
   Helper:
     Dblog:
       Battery:
         Logdb:
           TIME       1484202112.46633
           VALUE      ok
   Readings:
     2017-01-11 10:26:27   CommandAccepted yes
     2017-01-12 07:09:58   D-firmware      1.2
     2017-01-12 07:09:58   D-serialNr      MEQ0076971
     2017-01-11 10:12:02   PairedTo        0xF0815F
     2017-01-11 10:12:02   R-pairCentral   0xF0815F
     2017-01-11 10:12:01   RegL_00.        02:01 0A:F0 0B:81 0C:5F 18:00 00:00
     2017-01-12 07:21:52   aesCommToDev    ok
     2017-01-11 10:12:33   aesKeyNbr       00
     2017-01-12 07:21:52   aesReqTo        vccu
     2017-01-12 07:21:52   battery         ok
     2017-01-12 07:21:52   state           CMDs_done
   Helper:
     HM_CMDNR   0
     PONtest    1
     mId        00A5
     rxType     20
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +39776C,01,01,1E
       nextSend   1484202112.83503
       prefIO
       rxt        2
       vccu
       p:
         39776C
         01
         01
         1E
     Mrssi:
       mNo        00
       Io:
         CUL_0      -60.5
         meinLGW    -83
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1484202112.73981
       ack:
         HASH(0x20df878)
         008002F0815F39776C00
     Rssi:
       At_cul_0:
         avg        -62.0074626865672
         cnt        67
         lst        -60.5
         max        -55.5
         min        -91
       At_meinlgw:
         avg        -80.7826086956522
         cnt        23
         lst        -85
         max        -46
         min        -89
     Tmpl:
   Role:
Attributes:
   IODev      meinLGW
   aesCommReq 1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   group      Fernbedienung
   model      HM-RC-Sec4-2
   room       EDV
   serialNr   MEQ0076971
   subType    remote
   webCmd     getConfig:clear msgEvents

ich sehe im log keine message, die der cul sendet.
empfangen kann der cul natürlich weiterhin. wie willst du ihm das verbieten? man kann also nur das senden steuern. das sieht man immer schön an den internals:
   IODev      meinLGW
   LASTInputDev CUL_0

gesendet wurde mit lgw, der letzte empfang kam vom cul.

was willst du eigentlich genau erreichen und was stört dich bisher?
nur die anzeige im log "bereinigen"?

ich sehe in dem IOgrp löschen und nur IOdev setzen keinen großen Unterschied.
außer das die vccu komplett hinten vor bleibt...

Zum Tjema AES im allgemeinen - Ich habe auch immer mal wieder Probleme damit. Ich habe mit dem neuen DOIFtools Modul (noch beta) das Funk und Event aufkommen in meinem HM-System deutlich verringert, von 2100 Events/h auf nun ca. 500. Dazu kam noch eine HM Messsteckdose für die Waschmaschine, die alleine hat wenn die Maschine lief ca 2000Events erzeugt - jetzt noch 150!
Seit dem funktionieren die AES Geräte besser!

Hi Frank,

So lange die Kommunikation funktioniert, dürfen im Log auch die Lottozahlen von 1980 stehen  ;)

Spaß beiseite: Ich verstehe es halt nicht. Bin davon ausgegangen, dass die Kommunikation (Senden/Empfangen) immer zwischen 2 Partnern stattfinden muss. In der zweiten Zeile
2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
steht, nach meinem Verständnis, dass das Device CUL_0 wieder an der Kommunikation beteiligt ist. Aber eigentlich sollte doch nur über das LGW gefunkt werden, oder gilt das nur für die Senderichtung? IODev heißt doch Input/Output Device...

Es geht mir um die Steuerung einer Alarmanlage (scharf/unscharf/Cancel) mit besagten Fernbedienungen. Da sicherheitskritisch mit AES-Signierung. Das muss nur im Funkbereich des LGW sauber funktionieren.
Nur funktioniert genau dies nicht sehr zuverlässig. Ich hatte gehofft, über die Sniffing-Logs die Probleme weiter eingrenzen zu können. Aber mir fehlt offensichtlich das Verständnis.
Mir wurde gesagt, dass die AES-Signierung nicht funktioniert, wenn mehrere IO-Devices beteiligt sind. Deshalb den habe ich den Eintrag mit der IOGruppe entfernt und nur noch ein Device.

Zitat von: automatisierer am 12 Januar 2017, 09:59:40
Zum Tjema AES im allgemeinen - Ich habe auch immer mal wieder Probleme damit. Ich habe mit dem neuen DOIFtools Modul (noch beta) das Funk und Event aufkommen in meinem HM-System deutlich verringert, von 2100 Events/h auf nun ca. 500. Dazu kam noch eine HM Messsteckdose für die Waschmaschine, die alleine hat wenn die Maschine lief ca 2000Events erzeugt - jetzt noch 150!
Seit dem funktionieren die AES Geräte besser!

...das Thema werde ich mir mal anschauen!

Aber dennoch würde ich die Sniffing-Logs gerne besser verstehen. Gibt es diesbezüglich vielleicht Dokumentation oder einen Leitfaden?

Gruß
klinki

2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
cul_parse sind empfangene messages, beim senden dann cul_send. send gibt es in deinem log nicht.
es ist eine message von device F0815F an device 39776C. also deine zentrale an die fb. da der cul mdiese nicht gesendet hat muss sie vom lgw gesendet worden sein, falls du nur diese beiden io hast.

für aes doku würde ich das forum nach beiträgen von mgernoth durchsuchen und einen blick auf seine "homepage" empfehlen. https://git.zerfleddert.de/hmcfgusb/AES/ (https://git.zerfleddert.de/hmcfgusb/AES/)

Zitat von: frank am 12 Januar 2017, 10:27:37

Code Auswählen Erweitern

2017.01.12 07:21:52.085 4 : CUL_Parse: CUL_0 A 11 FF A002 F0815F 39776C 04A221000021080204 -72
cul_parse sind empfangene messages, beim senden dann cul_send. send gibt es in deinem log nicht.
es ist eine message von device F0815F an device 39776C. also deine zentrale an die fb. da der cul mdiese nicht gesendet hat muss sie vom lgw gesendet worden sein, falls du nur diese beiden io hast.

Verstehe ich das richtig und man sieht dieser Nachricht nicht an über welches IO sie geschickt wurde?

Zitat von: Klinki am 12 Januar 2017, 10:35:03
Verstehe ich das richtig und man sieht dieser Nachricht nicht an über welches IO sie geschickt wurde?

richtig. man erkennt nur die sender id.

Hier jetzt ein Beispiel für den Zustand wenn die AES-Signierung zuverlässig nicht funktioniert.
Es wird hier auch der AES-Key Nummer 00 verwendet. Ich meine, grundsätzlich ist der Index ja richtig: die VCCU kennt nur den einen AES-Key und beim Schlüssel steht ja auch im Reading KeyNbr 00.

Außer einem "Shutdown restart" ist seit dem letzten Posting nichts passiert

2017.01.12 11:21:41.007 4 : CUL_Parse: CUL_0 A 0B 2B A240 39776C F0815F 034122 -57
2017-01-12 11:21:41.048 CUL_HM FB_Thomas battery: ok
2017-01-12 11:21:41.048 CUL_HM FB_Thomas CMDs_done
2017-01-12 11:21:41.048 CUL_HM FB_Thomas FB_Thomas_light Short
2017-01-12 11:21:41.067 CUL_HM FB_Thomas_light Short (to vccu)
2017-01-12 11:21:41.067 CUL_HM FB_Thomas_light trigger: Short_65
2017-01-12 11:21:41.067 CUL_HM FB_Thomas_light trigger_cnt: 65
2017.01.12 11:21:41.141 4 : CUL_Parse: CUL_0 A 11 2B A002 F0815F 39776C 042C3F00003F0F0003 -72.5
2017-01-12 11:21:41.152 CUL_HM vccu aesKeyNbr: 00
2017.01.12 11:21:41.258 4 : CUL_Parse: CUL_0 A 0B 2C A240 39776C F0815F 034121 -57.5
2017-01-12 11:21:41.292 CUL_HM FB_Thomas battery: ok
2017-01-12 11:21:41.292 CUL_HM FB_Thomas CMDs_done
2017-01-12 11:21:41.292 CUL_HM FB_Thomas FB_Thomas_light Short
2017-01-12 11:21:41.312 CUL_HM FB_Thomas_light Short (to vccu)
2017-01-12 11:21:41.312 CUL_HM FB_Thomas_light trigger: Short_65
2017-01-12 11:21:41.312 CUL_HM FB_Thomas_light trigger_cnt: 65
2017.01.12 11:21:41.399 0 : HMUARTLGW meinLGW recv: 01 05 03 00 57 msg: 2B A2 40 39776C F0815F 0341
2017-01-12 11:21:41.407 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 11:21:41.428 CUL_HM FB_Thomas_light trig_aes_vccu: fail:65
2017-01-12 11:21:41.432 CUL_HM FB_Thomas aesCommToDev: fail
2017.01.12 11:21:41.495 0 : HMUARTLGW meinLGW send: 00 08
2017.01.12 11:21:41.505 0 : HMUARTLGW meinLGW recv: 00 040203, state 98
2017.01.12 11:21:41.507 0 : HMUARTLGW meinLGW GetSet Ack: 02, state 98
2017.01.12 11:21:41.509 0 : HMUARTLGW meinLGW roundtrip delay: 0.0072
2017.01.12 11:21:41.512 4 : CUL_Parse: CUL_0 A 0B 2D A240 39776C F0815F 034120 -58
2017-01-12 11:21:41.546 CUL_HM FB_Thomas battery: ok
2017-01-12 11:21:41.546 CUL_HM FB_Thomas CMDs_done
2017-01-12 11:21:41.546 CUL_HM FB_Thomas FB_Thomas_light Short
2017-01-12 11:21:41.565 CUL_HM FB_Thomas_light Short (to vccu)
2017-01-12 11:21:41.565 CUL_HM FB_Thomas_light trigger: Short_65
2017-01-12 11:21:41.565 CUL_HM FB_Thomas_light trigger_cnt: 65
2017.01.12 11:21:41.641 4 : CUL_Parse: CUL_0 A 11 2D A002 F0815F 39776C 04963D00003D0F0002 -73
2017-01-12 11:21:41.652 CUL_HM vccu aesKeyNbr: 00
2017.01.12 11:21:41.763 0 : HMUARTLGW meinLGW recv: 01 05 03 00 58 msg: 2D A2 40 39776C F0815F 0341
2017-01-12 11:21:41.774 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-12 11:21:41.797 CUL_HM FB_Thomas_light trig_aes_vccu: fail:65
2017-01-12 11:21:41.801 CUL_HM FB_Thomas aesCommToDev: fail
2017.01.12 11:21:41.803 4 : CUL_Parse: CUL_0 A 19 2D A003 39776C F0815F 882A2A12D50B5EF9D344F3C2CC54396120 -58
2017-01-12 11:21:41.816 CUL_HM FB_Thomas aesReqTo: vccu
2017-01-12 11:21:41.816 CUL_HM FB_Thomas CMDs_done
2017.01.12 11:21:48.066 0 : HMUARTLGW meinLGW:keepAlive send (3): K36
2017.01.12 11:21:48.074 0 : HMUARTLGW meinLGW:keepAlive read (4): >K36

..langsam macht es keinen Spaß mehr  :'(

Hallo,

Zitat von: Klinki am 12 Januar 2017, 11:29:20
Hier jetzt ein Beispiel für den Zustand wenn die AES-Signierung zuverlässig nicht funktioniert.

Ja, weil die Entfernung zwischen LGW und Fernbedienung zu groß ist.


2017.01.12 11:21:41.399 0 : HMUARTLGW meinLGW recv: 01 05 03 00 57 msg: 2B A2 40 39776C F0815F 0341


Das ist ein RSSI von -87, dass das nicht wirklich funktioniert, ist klar.

Viele Grüße
  Michael

das ist die gleiche Position wie die Versuche heute morgen. Dass es bei schlechter rssi nicht zuverlässig funktioniert, ist klar. Aber es funktioniert zuverlässig nicht. Auch wenn ich mich in die Nähe des LGW begebe:

2017.01.12 13:17:03.143 0: HMUARTLGW meinLGW recv: 01 05 03 00 41 msg: 3C 84 40 39776C F0815F 4343
2017.01.12 13:17:03.393 0: HMUARTLGW meinLGW recv: 01 05 03 00 39 msg: 3D 84 40 39776C F0815F 4343
2017.01.12 13:17:03.434 4: CUL_Parse: CUL_0 A 0B 3D 8440 39776C F0815F 4343DE -91
2017.01.12 13:17:03.644 0: HMUARTLGW meinLGW recv: 01 05 03 00 36 msg: 3E 84 40 39776C F0815F 4343
2017.01.12 13:17:04.035 4: CUL_Parse: CUL_0 A 11 3F A002 F0815F 39776C 04AD310000310C0008 -70
2017.01.12 13:17:04.158 0: HMUARTLGW meinLGW recv: 01 05 03 00 3C msg: 3F A2 40 39776C F0815F 4343
2017.01.12 13:17:04.536 4: CUL_Parse: CUL_0 A 11 40 A002 F0815F 39776C 04526E00006E1B0007 -70.5
2017.01.12 13:17:04.658 0: HMUARTLGW meinLGW recv: 01 05 03 00 38 msg: 40 A2 40 39776C F0815F 4343
2017.01.12 13:17:05.037 4: CUL_Parse: CUL_0 A 11 41 A002 F0815F 39776C 04F62A00002A0A0009 -69.5
2017.01.12 13:17:05.159 0: HMUARTLGW meinLGW recv: 01 05 03 00 3D msg: 41 A2 40 39776C F0815F 4343


Es gibt im System nur einen AES-Schlüssel. Warum einmal AESKeyNbr 00 (keine AES Signierung) und einmal AESKeyNbr 02 (AES Signierung funktioniert) im Event-Log steht, ist mir schleierhaft. Es wurde nichts im fhem geändert!

Hier das Listing der vccu:
Internals:
   CUL_0_MSGCNT 100
   CUL_0_RAWMSG A0951A112F0815F42C968::-72:CUL_0
   CUL_0_RSSI -72
   CUL_0_TIME 2017-01-13 07:37:58
   DEF        F0815F
   IODev      CUL_0
   LASTInputDev CUL_0
   MSGCNT     128
   NAME       vccu
   NOTIFYDEV  global
   NR         38
   STATE      CUL_0:ok,meinLGW:ok,
   TYPE       CUL_HM
   assignedIOs CUL_0,meinLGW
   channel_01 vccu_Btn1
   channel_05 vccu_Btn5
   channel_06 vccu_Btn6
   channel_07 vccu_Btn7
   channel_08 vccu_Btn8
   channel_09 vccu_Btn9
   channel_10 vccu_Btn16
   channel_11 vccu_Btn17
   channel_12 vccu_Btn18
   channel_13 vccu_Btn19
   channel_14 vccu_Btn20
   channel_15 vccu_Btn21
   channel_16 vccu_Btn22
   channel_17 vccu_Btn23
   channel_18 vccu_Btn24
   channel_19 vccu_Btn25
   channel_20 vccu_Btn32
   channel_21 vccu_Btn33
   channel_22 vccu_Btn34
   channel_23 vccu_Btn35
   channel_24 vccu_Btn36
   lastMsg    No:51 - t:12 s:F0815F d:42C968
   meinLGW_MSGCNT 28
   meinLGW_RAWMSG 050000470EB011F0815F4C31650201C80000
   meinLGW_RSSI -71
   meinLGW_TIME 2017-01-13 07:37:12
   protLastRcv 2017-01-13 07:37:58
   rssi_at_CUL_0 avg:-72.4 min:-77.5 max:-71 lst:-72 cnt:99
   rssi_at_meinLGW avg:-70.62 min:-72 max:-69 lst:-71 cnt:27
   Readings:
     2017-01-13 07:37:12   CommandAccepted yes
     2017-01-13 07:32:38   aesKeyNbr       00
     2017-01-11 10:12:33   aesReqTo        HM_39776C
     2017-01-13 07:21:05   state           CUL_0:ok,meinLGW:ok,
     2017-01-11 10:11:40   unknown_39776C  received
     2017-01-13 07:07:22   unknown_453B7D  received
     2017-01-11 12:32:20   unknown_45B816  received
     2017-01-03 13:37:19   unknown_45B8F1  received
     2017-01-04 14:33:22   unknown_4B44B0  received
     2017-01-06 06:50:32   unknown_4D8F32  received
     2017-01-05 10:36:50   unknown_F10000  received
     2017-01-13 07:35:42   unknown_F4711F  received
   Helper:
     HM_CMDNR   81
     mId        FFF0
     rxType     1
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       nextSend   1484289478.40907
       prefIO
       vccu
       ioList:
         CUL_0
         meinLGW
     Mrssi:
       mNo        51
       Io:
         CUL_0      -70
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
       vrt        1
     Rssi:
       At_cul_0:
         avg        -72.4090909090909
         cnt        99
         lst        -72
         max        -71
         min        -77.5
       At_meinlgw:
         avg        -70.6296296296296
         cnt        27
         lst        -71
         max        -69
         min        -72
     Tmpl:
Attributes:
   IODev      CUL_0
   IOList     CUL_0,meinLGW
   hmKey      01:XXXXXXXXXXXXXXXXXXXXXXXXXXX
   model      CCU-FHEM
   room       Hilfsmodule
   subType    virtual
   webCmd     virtual:update

und hier das Listing der Fernbedienung:
Internals:
   CUL_0_MSGCNT 52
   CUL_0_RAWMSG A0B93A24039776CF0815F034A::-70:CUL_0
   CUL_0_RSSI -70
   CUL_0_TIME 2017-01-13 07:35:17
   DEF        39776C
   IODev      meinLGW
   LASTInputDev CUL_0
   MSGCNT     128
   NAME       FB_Thomas
   NOTIFYDEV  global
   NR         541
   STATE      FB_Thomas_light Short
   TYPE       CUL_HM
   channel_01 FB_Thomas_armInt
   channel_02 FB_Thomas_armExt
   channel_03 FB_Thomas_light
   channel_04 FB_Thomas_disarm
   lastMsg    No:93 - t:40 s:39776C d:F0815F 034A
   meinLGW_MSGCNT 76
   meinLGW_RAWMSG 0503005D8EA24039776CF0815F0349
   meinLGW_RSSI -93
   meinLGW_TIME 2017-01-13 07:32:38
   protLastRcv 2017-01-13 07:35:17
   protSnd    52 last_at:2017-01-13 07:35:17
   protState  CMDs_done
   rssi_at_CUL_0 avg:-60.6 min:-80.5 max:-53.5 lst:-70 cnt:52
   Helper:
     Dblog:
       Battery:
         Logdb:
           TIME       1484289317.30037
           VALUE      ok
   Readings:
     2017-01-11 10:26:27   CommandAccepted yes
     2017-01-12 07:09:58   D-firmware      1.2
     2017-01-12 07:09:58   D-serialNr      MEQ0076971
     2017-01-11 10:12:02   PairedTo        0xF0815F
     2017-01-11 10:12:02   R-pairCentral   0xF0815F
     2017-01-11 10:12:01   RegL_00.        02:01 0A:F0 0B:81 0C:5F 18:00 00:00
     2017-01-13 07:32:38   aesCommToDev    fail
     2017-01-11 10:12:33   aesKeyNbr       00
     2017-01-13 07:27:01   aesReqTo        vccu
     2017-01-13 07:35:17   battery         ok
     2017-01-13 07:35:17   state           FB_Thomas_light Short
   Helper:
     HM_CMDNR   147
     mId        00A5
     rxType     20
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +39776C,01,00,1E
       nextSend   1484289317.38446
       prefIO
       rxt        2
       vccu
       p:
         39776C
         01
         00
         1E
     Mrssi:
       mNo        93
       Io:
         CUL_0      -70
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       dev        1
     Rpt:
       IO         CUL_0
       flg        A
       ts         1484289317.29035
       ack:
         HASH(0x1d87628)
         938002F0815F39776C00
     Rssi:
       At_cul_0:
         avg        -60.6057692307692
         cnt        52
         lst        -70
         max        -53.5
         min        -80.5
     Tmpl:
   Role:
Attributes:
   IODev      meinLGW
   aesCommReq 1
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.2
   group      Fernbedienung
   model      HM-RC-Sec4-2
   room       EDV
   serialNr   MEQ0076971
   subType    remote
   webCmd     getConfig:clear msgEvents

Das Event:
017-01-13 07:40:17.093 CUL_HM FB_Thomas battery: ok
2017-01-13 07:40:17.093 CUL_HM FB_Thomas CMDs_done
2017-01-13 07:40:17.093 CUL_HM FB_Thomas FB_Thomas_armInt Short
2017-01-13 07:40:17.116 CUL_HM FB_Thomas_armInt Short (to vccu)
2017-01-13 07:40:17.116 CUL_HM FB_Thomas_armInt trigger: Short_31
2017-01-13 07:40:17.116 CUL_HM FB_Thomas_armInt trigger_cnt: 31
2017-01-13 07:40:17.202 CUL_HM vccu aesKeyNbr: 00
2017-01-13 07:40:17.340 CUL_HM FB_Thomas battery: ok
2017-01-13 07:40:17.340 CUL_HM FB_Thomas CMDs_done
2017-01-13 07:40:17.340 CUL_HM FB_Thomas FB_Thomas_armInt Short
2017-01-13 07:40:17.362 CUL_HM FB_Thomas_armInt Short (to vccu)
2017-01-13 07:40:17.362 CUL_HM FB_Thomas_armInt trigger: Short_31
2017-01-13 07:40:17.362 CUL_HM FB_Thomas_armInt trigger_cnt: 31
2017-01-13 07:40:17.456 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-13 07:40:17.465 CUL_HM FB_Thomas aesCommToDev: fail
2017-01-13 07:40:17.484 CUL_HM FB_Thomas_armInt trig_aes_vccu: fail:31
2017-01-13 07:40:17.591 CUL_HM FB_Thomas battery: ok
2017-01-13 07:40:17.591 CUL_HM FB_Thomas CMDs_done
2017-01-13 07:40:17.591 CUL_HM FB_Thomas FB_Thomas_armInt Short
2017-01-13 07:40:17.613 CUL_HM FB_Thomas_armInt Short (to vccu)
2017-01-13 07:40:17.613 CUL_HM FB_Thomas_armInt trigger: Short_31
2017-01-13 07:40:17.613 CUL_HM FB_Thomas_armInt trigger_cnt: 31


Ich = ratlos  :-\

wenn da aesKeyNbr 00 steht, dann hat das device den aktuellen key nicht. bei dir müssen alle devices die 02 haben!

Zitat von: automatisierer am 13 Januar 2017, 08:39:09
wenn da aesKeyNbr 00 steht, dann hat das device den aktuellen key nicht. bei dir müssen alle devices die 02 haben!

hm...okay...und wie mache ich das?
Ich meine, es hatte ja funktioniert. Ohne Änderung wollte er Key 00.
Den Schlüssel (und nicht nur diesen) habe ich bereits mehrfach komplett neu angelernt. Das funktioniert dann einen Tag lang.

warum kann ich in deinen logs eigentlich nicht die gesendeten messages des lgw sehen? sendet der überhaupt, oder hast du uns ein gateway verheimlicht? dein fhem ist hoffentlich tagesaktuell?

beim sniffen mit meinem hmuart erhalte ich zb folgende messages vom modul HMUARTLGW, (rcev=empfangen, send=senden). wenn der hmuart etwas sendet, ist das auch als solches zu erkennen. oder gibt es hier einen unterschied zum lgw? macht aber eigentlich keinen sinn.

2017.01.13 10:09:01.628 0 : HMUARTLGW hmuart1 recv: 01 04 03 00 3D msg: 83 80 02 206278 1ACE1F 00
2017.01.13 10:09:01.726 0 : HMUARTLGW hmuart1 send: 01 02 00 00 00 msg: 84 A0 11 1ACE1F 206278 020225

hast du das attr logIDs gesetzt? setze doch mal "sys,all", ob du überhaupt irgendeine send message im log siehst.

Zitat von: frank am 13 Januar 2017, 10:50:49
warum kann ich in deinen logs eigentlich nicht die gesendeten messages des lgw sehen? sendet der überhaupt, oder hast du uns ein gateway verheimlicht? dein fhem ist hoffentlich tagesaktuell?

beim sniffen mit meinem hmuart erhalte ich zb folgende messages vom modul HMUARTLGW, (rcev=empfangen, send=senden). wenn der hmuart etwas sendet, ist das auch als solches zu erkennen. oder gibt es hier einen unterschied zum lgw? macht aber eigentlich keinen sinn.
hast du das attr logIDs gesetzt? setze doch mal "sys,all", ob du überhaupt irgendeine send message im log siehst.

1. Keine Ahnung
2. Nein, 2 IOs: CUL_0 und meinLGW
3. Jawoll

Hatte diese Logs zwar gestern schon geschickt, aber hier das kombinierte Event/Log. Garantiert nichts rausgelöscht

2017.01.13 11:12:22.983 4 : CUL_Parse: CUL_0 A 0B 0D A240 39776C F0815F 0436D9 -93.5
2017-01-13 11:12:23.022 CUL_HM FB_Thomas battery: ok
2017-01-13 11:12:23.022 CUL_HM FB_Thomas CMDs_done
2017-01-13 11:12:23.022 CUL_HM FB_Thomas FB_Thomas_disarm Short
2017-01-13 11:12:23.044 CUL_HM FB_Thomas_disarm Short (to vccu)
2017-01-13 11:12:23.044 CUL_HM FB_Thomas_disarm trigger: Short_54
2017-01-13 11:12:23.044 CUL_HM FB_Thomas_disarm trigger_cnt: 54
2017.01.13 11:12:23.115 4 : CUL_Parse: CUL_0 A 11 0D A002 F0815F 39776C 04432B00002B0A00FE -75
2017-01-13 11:12:23.130 CUL_HM vccu aesKeyNbr: 00
2017.01.13 11:12:23.238 0 : HMUARTLGW meinLGW recv: 01 05 03 00 44 msg: 0D A2 40 39776C F0815F 0436
2017-01-13 11:12:23.249 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-13 11:12:23.259 CUL_HM FB_Thomas aesCommToDev: fail
2017-01-13 11:12:23.278 CUL_HM FB_Thomas_disarm trig_aes_vccu: fail:54
2017.01.13 11:12:23.281 4 : CUL_Parse: CUL_0 A 19 0D A003 39776C F0815F 97267B38396319F51A3A223EFE6CB0A9D5 -95.5
2017-01-13 11:12:23.297 CUL_HM FB_Thomas aesReqTo: vccu
2017-01-13 11:12:23.297 CUL_HM FB_Thomas CMDs_done
2017.01.13 11:12:23.483 4 : CUL_Parse: CUL_0 A 0B 0E A240 39776C F0815F 0436D4 -96
2017-01-13 11:12:23.519 CUL_HM FB_Thomas battery: ok
2017-01-13 11:12:23.519 CUL_HM FB_Thomas CMDs_done
2017-01-13 11:12:23.519 CUL_HM FB_Thomas FB_Thomas_disarm Short
2017-01-13 11:12:23.543 CUL_HM FB_Thomas_disarm Short (to vccu)
2017-01-13 11:12:23.543 CUL_HM FB_Thomas_disarm trigger: Short_54
2017-01-13 11:12:23.543 CUL_HM FB_Thomas_disarm trigger_cnt: 54
2017.01.13 11:12:23.616 4 : CUL_Parse: CUL_0 A 11 0E A002 F0815F 39776C 04E7670000671900FD -75.5
2017-01-13 11:12:23.631 CUL_HM vccu aesKeyNbr: 00
2017.01.13 11:12:23.739 0 : HMUARTLGW meinLGW recv: 01 05 03 00 43 msg: 0E A2 40 39776C F0815F 0436
2017-01-13 11:12:23.746 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-13 11:12:23.754 CUL_HM FB_Thomas aesCommToDev: fail
2017-01-13 11:12:23.831 CUL_HM FB_Thomas_disarm trig_aes_vccu: fail:54
2017.01.13 11:12:23.833 4 : CUL_Parse: CUL_0 A 19 0E A003 39776C F0815F 2375C56112B611AECE9E1DAF5ED3140FD8 -94
2017-01-13 11:12:23.853 CUL_HM FB_Thomas aesReqTo: vccu
2017-01-13 11:12:23.853 CUL_HM FB_Thomas CMDs_done
2017.01.13 11:12:23.984 4 : CUL_Parse: CUL_0 A 0B 0F A240 39776C F0815F 0436D2 -97
2017-01-13 11:12:24.021 CUL_HM FB_Thomas battery: ok
2017-01-13 11:12:24.021 CUL_HM FB_Thomas CMDs_done
2017-01-13 11:12:24.021 CUL_HM FB_Thomas FB_Thomas_disarm Short
2017-01-13 11:12:24.045 CUL_HM FB_Thomas_disarm Short (to vccu)
2017-01-13 11:12:24.045 CUL_HM FB_Thomas_disarm trigger: Short_54
2017-01-13 11:12:24.045 CUL_HM FB_Thomas_disarm trigger_cnt: 54
2017.01.13 11:12:24.118 4 : CUL_Parse: CUL_0 A 11 0F A002 F0815F 39776C 0452660000661900FE -75
2017-01-13 11:12:24.132 CUL_HM vccu aesKeyNbr: 00
2017.01.13 11:12:24.240 0 : HMUARTLGW meinLGW recv: 01 05 03 00 41 msg: 0F A2 40 39776C F0815F 0436
2017-01-13 11:12:24.250 CUL_HM FB_Thomas aesCommToDev: pending
2017-01-13 11:12:24.260 CUL_HM FB_Thomas aesCommToDev: fail
2017-01-13 11:12:24.278 CUL_HM FB_Thomas_disarm trig_aes_vccu: fail:54
2017.01.13 11:12:24.281 4 : CUL_Parse: CUL_0 A 19 0F A003 39776C F0815F A4A07EA9D547599D428B89692AF5157AD6 -95
2017-01-13 11:12:24.297 CUL_HM FB_Thomas aesReqTo: vccu
2017-01-13 11:12:24.297 CUL_HM FB_Thomas CMDs_done
2017.01.13 11:12:26.124 0 : HMUARTLGW meinLGW recv: 01 05 00 00 48 msg: 80 84 10 45B816 F0815F 06012A00
2017.01.13 11:12:26.131 4 : CUL_Parse: CUL_0 A 0D 80 8410 45B816 F0815F 06012A002B -52.5
2017.01.13 11:12:29.347 0 : HMUARTLGW meinLGW send: 00 08
2017.01.13 11:12:29.361 0 : HMUARTLGW meinLGW recv: 00 040206, state 98
2017.01.13 11:12:29.363 0 : HMUARTLGW meinLGW GetSet Ack: 02, state 98
2017.01.13 11:12:29.365 0 : HMUARTLGW meinLGW roundtrip delay: 0.0072
2017.01.13 11:12:29.447 0 : HMUARTLGW meinLGW:keepAlive send (3): K40
2017.01.13 11:12:29.456 0 : HMUARTLGW meinLGW:keepAlive read (4): >K40


Die Listings von Fernbedienung und VCCU haben sich nicht geändert.

im list deiner VCCU sind keine RSSI Werte vom HMLGW, der scheint nicht richtig assigned zu sein. also bitte einmal:

set vccu assignIO

danach dann einmal:

save

ich denke dass dein HMLGW desshalb nicht mitredet...


zum aesKeyNbr: Wenn da 00 steht, ist das nicht direkt ein Problem. Das Device sagt der vccu ja mit welchem Key es arbeitet. 00 ist halt der Standart Key und daher nicht sicher, da öffentlich bekannt.
den aktuellen HMkey setzt du in den Devices mit:

set <Dev> assignHmKey

Zitat von: automatisierer am 13 Januar 2017, 11:39:27
im list deiner VCCU sind keine RSSI Werte vom HMLGW, der scheint nicht richtig assigned zu sein. also bitte einmal:

Code Auswählen Erweitern

set vccu assignIO
danach dann einmal:

Code Auswählen Erweitern

save

hab ich gemacht. Keine Besserung

Zitat von: automatisierer am 13 Januar 2017, 11:39:27
den aktuellen HMkey setzt du in den Devices mit:

Code Auswählen Erweitern

set <Dev> assignHmKey

Hab ich auch noch mal gemacht. Ebenfalls keine Besserung.

Hier der neue Ausschnitt aus dem Listing der vccu. Jetzt mit rssi-Werten vom LGW.

....
    Rssi:
       At_cul_0:
         avg        -73.6821192052981
         cnt        151
         lst        -71.5
         max        -70
         min        -79.5
       At_meinlgw:
         avg        -71.1714285714286
         cnt        35
         lst        -69
         max        -69
         min        -74
     Tmpl:
Attributes:
   IODev      CUL_0
   IOList     CUL_0,meinLGW
   hmKey      01:xxxxxxxxxxxxxxxxxxxxxxx
   model      CCU-FHEM
   room       Hilfsmodule
   subType    virtual
   webCmd     virtual:update


Der AES-Key, dessen Hash in der vccu steht, ist definitiv der von mir erzeugte.

Zitat von: automatisierer am 13 Januar 2017, 11:39:27
zum aesKeyNbr: Wenn da 00 steht, ist das nicht direkt ein Problem. Das Device sagt der vccu ja mit welchem Key es arbeitet. 00 ist halt der Standart Key und daher nicht sicher, da öffentlich bekannt.

Damit hast Du mich aber auf eine Idee gebracht. Ich habe bei der FB jetzt mal das IODev auf den CUL geändert -> Kommunikation funktioniert!

Wenn man über das LGW ja nicht problemlos ohne AES kommunizieren könnte, würde ich sagen: Das Ding ist am Ar****. Aber es funktioniert ohne AES halt tadellos. Da AES ja mit der Zentrale stattfindet, kann es dann ja auch kein Problem des LGWs sein, oder?

Hallo,

Zitat von: Klinki am 13 Januar 2017, 11:59:41
Der AES-Key, dessen Hash in der vccu steht, ist definitiv der von mir erzeugte.
Damit hast Du mich aber auf eine Idee gebracht. Ich habe bei der FB jetzt mal das IODev auf den CUL geändert -> Kommunikation funktioniert!

Wenn man über das LGW ja nicht problemlos ohne AES kommunizieren könnte, würde ich sagen: Das Ding ist am Ar****. Aber es funktioniert ohne AES halt tadellos. Da AES ja mit der Zentrale stattfindet, kann es dann ja auch kein Problem des LGWs sein, oder?

Ohne gesetzte IOGrp funktioniert AES mit dem Gateway bei einer definierten VCCU nicht (CUL_HM setzt in newChn dann unter anderem nicht die richtige Key-ID, betrifft auch HMLAN)!
Mit dem CUL funktioniert es nur zufällig, würde das aber eher als Bug bezeichnen.

Viele Grüße
  Michael

Hi Michael,

Zitat von: mgernoth am 13 Januar 2017, 12:48:08
Ohne gesetzte IOGrp funktioniert AES mit dem Gateway bei einer definierten VCCU nicht (CUL_HM setzt in newChn dann unter anderem nicht die richtige Key-ID, betrifft auch HMLAN)!

Yo, funktioniert jetzt - Dank Deinem Tipp!

schönes Wochenende und Danke an alle für eure Mühe!

Moin,

Zitat von: automatisierer am 12 Januar 2017, 09:59:40
Zum Tjema AES im allgemeinen - Ich habe auch immer mal wieder Probleme damit. Ich habe mit dem neuen DOIFtools Modul (noch beta) das Funk und Event aufkommen in meinem HM-System deutlich verringert, von 2100 Events/h auf nun ca. 500.

wie das?

gruß
klinki

Zitat von: Klinki am 16 Januar 2017, 08:10:20
Moin,

wie das?

gruß
klinki

mit dem DOIFtool habe ich die Massen-Event-Verursacher ausfindig gemacht und dann bei den Devices, mit event-on-change-reading nur die Events rausgefiltert die ich wirklich benötige. Bei Device-Channels die ich gar nicht benötige habe ich das mit do_not_notify gemacht. Und bei einigen stetig sendenden Devices den minSendeintervall herauf gesetzt und den Threshold ebenfalls.
Zu wissen was man tut, ist immer gut! Also nicht alles wild raus filtern und nachher wundern, dass nix mehr funktioniert. Einige Devices sind sehr 'geschwätzig' und die meissten Infos benötigt man nicht wirklich.

Ich hatte das bisher auf Datenbank-Basis gemacht und so die lautesten Störquellen identifiziert.
Entsprechend dann auch die event-onchange...usw. -Filter gesetzt. War echt Arbeit - reduzierte die geloggten Events aber auf ca. 30%.

Nur reduzierte die Aktion die Funklast natürlich nicht.

Zitat von: automatisierer am 16 Januar 2017, 08:33:48
Und bei einigen stetig sendenden Devices den minSendeintervall herauf gesetzt und den Threshold ebenfalls.

genau das werde ich auch mal machen  :)

Danke für den Denkanstoß

Die Kombination läuft jetzt ein paar Tage und das Fazit ist sehr ernüchternd:
Mal funktioniert die AES-Signierung über LGW einen ganzen Tag tadellos (>90% aller Versuche klappen auf Anhieb). Dann gibt es Tage an denen nur jeder 10. Versuch funktioniert.
Und das bei einer sehr überschaubaren Anzahl von HM-Geräten.

Diese Probleme habe ich bei einer Installation mit nur einem CUL nicht. Wenn diese Reichweiten-Problematik nicht wäre, würde das LGW wieder rausfliegen.

Als Lösungsanstz fällt mir noch fhem2fhem ein. Den "Haupt-"Raspi kann ich nicht versetzen, da dieser über eine USV-Anlage angeschlossen ist und so auch einen Stromausfall per SMS melden muss.

Hi Klinki,

hast Du denn die hier https://forum.fhem.de/index.php/topic,64041.msg563535.html#msg563535 (https://forum.fhem.de/index.php/topic,64041.msg563535.html#msg563535) angesprochene Version im Einsatz?

Moin tndx,

jetzt ja!

Sieht bisher gut aus  :)

Werde berichten. Danke Dir!

Habe ein paar Tage testen können. Dank der Entwickler funktioniert es bisher tadellos.
Sogar das Roaming klappt einigermaßen. Normalerweise beim zweiten Tastendruck.
Das ist in meinem Fall aber gar kein Problem.

Danke, Danke, Danke!

https://forum.fhem.de/index.php/topic,64041.msg563535.html#msg563535