Pairing HM-SEC-RHS - CUL scheitert: RESPONSE TIMEOUT

[oelidoc]

Hallo,
seit einem Batteriewechsel bekomme ich einen meiner beiden HM-SEC-RHS nicht mehr mit dem CUL gepairt:

Code Auswählen Erweitern

Internals:
   CFGFN
   CUL_Pi_MSGCNT 18
   CUL_Pi_RAWMSG A0E40800223B01DF1080400758EF8D5::-80:CUL_Pi
   CUL_Pi_RSSI -80
   CUL_Pi_TIME 2017-07-12 21:45:50
   DEF        23B01D
   IODev      CUL_Pi
   LASTInputDev CUL_Pi
   MSGCNT     18
   NAME       HM_23B01D
   NOTIFYDEV  global
   NR         686
   STATE      RESPONSE TIMEOUT:RegisterRead
   TYPE       CUL_HM
   lastMsg    No:40 - t:02 s:23B01D d:F10804 00758EF8D5
   protCmdDel 3
   protLastRcv 2017-07-12 21:45:50
   protResndFail 1 last_at:2017-07-12 21:45:55
   protSnd    8 last_at:2017-07-12 21:45:50
   protState  CMDs_done_Errors:1
   rssi_at_CUL_Pi cnt:18 max:-68.5 min:-89 lst:-80 avg:-80.58
   Readings:
     2017-07-12 21:45:48   Activity        alive
     2017-07-12 21:45:50   CommandAccepted yes
     2017-07-12 21:45:48   D-firmware      2.1
     2017-07-12 21:45:48   D-serialNr      KEQ0846918
     2017-07-12 21:45:48   R-pairCentral   set_0xF10804
     2017-07-12 21:45:50   aesCommToDev    ok
     2017-07-12 21:45:50   aesKeyNbr       00
     2017-07-12 21:44:12   battery         ok
     2017-07-12 21:44:12   contact         open (to broadcast)
     2017-07-12 21:45:55   state           RESPONSE TIMEOUT:RegisterRead
     2017-07-12 21:44:12   trigger_cnt     20
     Regl_00.:
       VAL
   Helper:
     HM_CMDNR   64
     cSnd       01F1080423B01D0006,01F1080423B01D00040000000000
     getCfgList all
     getCfgListNo ,4
     mId        0030
     rxType     4
     supp_Pair_Rep 0
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +23B01D,00,00,00
       nextSend   1499888751.04661
       prefIO
       rxt        0
       vccu
       p:
         23B01D
         00
         00
         00
     Mrssi:
       mNo        40
       Io:
         CUL_Pi     -78
     Prt:
       bErr       0
       sProc      0
       Helper:
         Prt:
           Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rssi:
       At_cul_pi:
         avg        -80.5833333333333
         cnt        18
         lst        -80
         max        -68.5
         min        -89
     Shadowreg:
       RegL_00.    02:01 0A:F1 0B:08 0C:04
     Tmpl:
Attributes:
   IODev      CUL_Pi
   IOgrp      virtualCCU:CUL_Pi
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   2.1
   model      HM-SEC-RHS
   room       CUL_HM
   serialNr   KEQ0846918
   subType    threeStateSensor

Was ich bisher gemacht habe:
HM-SEC-RHS zurückgesetzt
Gerät in FHEM gelöscht und neu angelegt über autocreate
Neu gepairt an CUL oder an VCCU mittels hmPairForSec und hmPairSerial

Aber egal wie oft ich getconfig mache und die Taste am Gerät drücke, es bleibt immer bei R-pairCentral set_0xF10804 

Irgendwie werde ich den Verdacht nicht los, dass das Ganze irgendetwas mir AES zu tun hat, denn was bedeutet "aesCommToDev ok" und "aesKeyNbr 00"?

Der zweite HM-SEC-RHS funktioniert an dem CUL problemlos, weswegen ich glaube die Installation an sich als Ursache auschliessen zu können - aber ich lasse mich natürlich gerne auch eines Besseren belehren.

Gruß

oelidoc

[frank]

eventuell timing probleme beim cul => nutze die ts_culfw.
schon mal über einen hmuart anstsatt des cul am pi nachgedacht, sicher die bessere wahl.

funk verbessern, könnte man auch probieren.
vielleicht beeinflusst deine anwesenheit in der funkstrecke beim knöpfchen drücken die kommunikation negativ.

schon mal gesnifft, wie im wiki beschrieben?

[oelidoc]

Hallo Frank,
vielen Dank für deine Antwort. Eine Veränderung oder gar ein Austausch der Hardware erscheint mir in Anbetracht der Tatsache, dass der Fensterkontakt bis zum Batteriewechsel jahrelang problemlos funktioniert hat und ein anderer Fensterkontakt im selben Raum mit sogar minimal schlechteren Empfangswerten nach dem Batteriewechsel anstandslos seinen Dienst verrichtet, eher weit gegriffen. Aber ich kann den Fenstergriff ja mal demontieren und zum CUL tragen. Sniffen kann ich frühestens heute abend/nacht....
Im übrigen gibt es andernorts ja z.Zt. ähnliche Probleme: https://forum.fhem.de/index.php/topic,70708.0.html.
Kannst du evtl. noch etwas zu den Readings "aesCommToDev ok" und "aesKeyNbr 00" sagen? Heißt das, dass trotz des (erfolgreichen) Zurücksetzen des HM-SEC-RHS noch eine Verschlüsselung/Kodierung im Gerät aktiv ist? Kann man ein Gerät, bei dem AES voreingestellt ist, überhaupt mit einem IO pairen?

Gruß

oelidoc

[frank]

eventuell reicht auch eine usb verlängerung am cul.

aes mit default key 0 wurde benutzt und war wohl auch erfolgreich, laut timestamps. bei vielen kontakten ist aes eingeschaltet ab werk. kannst du aber ausschalten, wenn gepairt ist. (sign => off)

[oelidoc]

Danke für den Tip mit der USB-Verlängerung - müsste noch irgendwo zu finden sein 

Also müsste das initiale pairing auch mit eingeschaltetem AES möglich sein?

Gruß

oelidoc

[oelidoc]

So, hab heute den Türgriff in Sichtweite des CUL mit super rssi Werten und neuen Batterien versucht zu pairen. Aber egal was ich mache - es kommt immer Response Timerout: RegisterRead und das Pairing bleibt auf set_XXXXX. Langsam glaube ich, dass der HM-SEC-RHS defekt ist, weil zwei andere Fensterkontakte (1x HM-SEC-RHS, 1x HM-SEC-SC) sich problemlos pairen und regsetten lassen. Werde wohl einen neuen kaufen müssen, falls hier keiner mehr eine durchschlagende Idee hat.

Gruß

oelidoc