HM-LGW-O-TW-W-EU-2 / CUL als VCCU und AES

[mgernoth]

Hallo,

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.

Code Auswählen Erweitern


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

[Klinki]

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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:

Code Auswählen Erweitern

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 

[automatisierer]

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

[Klinki]

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.

[frank]

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.

Code Auswählen Erweitern

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.

[Klinki]

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

Code Auswählen Erweitern

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.

[automatisierer]

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

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:

Code Auswählen Erweitern

set <Dev> assignHmKey

[Klinki]

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

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.

Code Auswählen Erweitern


....
    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.

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?

[mgernoth]

Hallo,

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

[Klinki]

Hi Michael,

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!

[Klinki]

Moin,

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

[automatisierer]

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.

[Klinki]

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.

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ß

[Klinki]

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.

[tndx]

Hi Klinki,

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