VCCU: aesKeyNbr 00 trotz gesetzter hmkey und hmkey2

[tndx]

Ich habe seit ein paar Tagen wieder das Problem, dass mein Neigungssensor nicht signieren will, obwohl ich das störende RPi-Modul erstmal ausgestellt habe... Das Problem ist dieses Mal auch ein anderes: aesKeyNbr der VCCU steht auf 00, obwohl 2 AES-Schlüssel eingetragen sind und ich auch nichts bewußt an der Konfiguration geändert habe:

Code Auswählen Erweitern


Internals:
   DEF        F3A460
   IODev      nanoCUL
   LASTInputDev nanoCUL
   MSGCNT     6
   NAME       VCCU
   NOTIFYDEV  global
   NR         72
   NTFY_ORDER 50-VCCU
   STATE      nanoCUL:ok,
   TYPE       CUL_HM
   assignedIOs nanoCUL
   lastMsg    No:50 - t:3F s:F3A460 d:000000 020220127B50
   nanoCUL_MSGCNT 6
   nanoCUL_RAWMSG A0F50943FF3A460000000020220127B50::-40.5:nanoCUL
   nanoCUL_RSSI -40.5
   nanoCUL_TIME 2017-01-18 19:22:23
   protLastRcv 2017-01-18 19:22:23
   rssi_at_nanoCUL max:-40.5 cnt:6 min:-40.5 avg:-40.5 lst:-40.5
   Readings:
     2017-01-18 17:48:06   CommandAccepted yes
     2017-01-18 11:00:11   aesKeyNbr       00
     2016-12-28 21:28:24   aesReqTo        Garage_TorNeigung
     2017-01-18 16:53:41   state           nanoCUL:ok,
     2016-10-30 11:09:32   unknown_3E84A8  received
     2016-10-18 21:01:26   unknown_400FE5  received
     2016-10-16 22:03:09   unknown_469DBC  received
     2016-10-20 21:10:30   unknown_46F729  received
     2016-11-04 21:43:08   unknown_4B50C1  received
     2016-10-26 22:42:29   unknown_4CFDD8  received
     2016-11-19 20:18:47   unknown_4CFDD9  received
     2016-10-22 15:22:25   unknown_4EA476  received
     2017-01-02 14:24:43   unknown_510207  received
     2016-12-19 12:12:03   unknown_510223  received
     2016-12-21 10:46:25   unknown_51027E  received
     2016-12-21 10:46:27   unknown_510299  received
     2016-12-20 11:52:20   unknown_5102AC  received
     2016-12-04 10:19:22   unknown_51033C  received
     2017-01-02 14:15:24   unknown_510371  received
     2016-10-29 00:00:39   unknown_F3A461  received
   Helper:
     HM_CMDNR   80
     mId        FFF0
     rxType     1
     supp_Pair_Rep 0
     Ack:
     Expert:
       def        1
       det        0
       raw        0
       tpl        0
     Io:
       nextSend   1484763743.81609
       vccu       VCCU
       ioList:
         nanoCUL
     Mrssi:
       mNo        50
       Io:
         nanoCUL    -38.5
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
       vrt        1
     Rssi:
       At_nanocul:
         avg        -40.5
         cnt        6
         lst        -40.5
         max        -40.5
         min        -40.5
     Tmpl:
Attributes:
   IODev      nanoCUL
   IOList     nanoCUL
   IOgrp      VCCU
   hmKey      01:<key1>
   hmKey2     02:<key2>
   model      CCU-FHEM
   room       VCCU
   subType    virtual
   webCmd     virtual:update


Der Neigungssensor hat natürlich auch 2 Schlüssel gesetzt, die auch schon mal funktioniert haben, eine bewusste Änderung gab es auch hier nicht (aesCommReq habe ich temporär deaktiviert):

Code Auswählen Erweitern


Internals:
   DEF        4B50C1
   IODev      nanoCUL
   NAME       Garage_TorNeigung
   NOTIFYDEV  global
   NR         140
   NTFY_ORDER 50-Garage_TorNeigung
   STATE      closed
   TYPE       CUL_HM
   Readings:
     2017-01-18 16:53:41   Activity        alive
     2016-12-28 21:52:08   CommandAccepted yes
     2017-01-15 14:28:27   D-firmware      1.5
     2017-01-15 14:28:27   D-serialNr      NEQ0674842
     2017-01-15 14:26:33   PairedTo        0xF3A460
     2016-12-10 14:56:58   R-cyclicInfoMsg on
     2016-12-06 20:34:53   R-pairCentral   0xF3A460
     2016-12-06 20:34:53   R-sabotageMsg   on
     2016-12-28 21:52:09   R-sign          on
     2017-01-15 14:26:33   RegL_00.        02:01 09:01 0A:F3 0B:A4 0C:60 10:01 14:06 00:00
     2017-01-15 14:26:33   RegL_01.        08:01 20:60 22:64 23:00 30:06 00:00
     2017-01-15 14:41:35   aesCommToDev    fail
     2016-12-28 21:28:24   aesKeyNbr       04
     2017-01-18 11:00:11   aesReqTo        VCCU
     2017-01-16 14:32:54   alive           yes
     2017-01-18 11:00:11   battery         ok
     2017-01-18 11:00:11   contact         closed (to VCCU)
     2017-01-16 14:32:54   cover           closed
     2017-01-15 14:23:24   powerOn         2017-01-15 14:23:24
     2017-01-16 14:32:54   recentStateType info
     2017-01-18 11:00:11   state           closed
     2017-01-15 14:41:35   trig_aes_VCCU   fail:13
     2017-01-18 11:00:11   trigger_cnt     23
   Helper:
     HM_CMDNR   1
     mId        0043
     rxType     12
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4B50C1,00,02,00
       rxt        2
       vccu       VCCU
       p:
         4B50C1
         00
         02
         00
       prefIO:
         nanoCUL
     Mrssi:
       mNo
     Prt:
       bErr       0
       sProc      0
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Tmpl:
Attributes:
   IODev      nanoCUL
   IOgrp      VCCU:nanoCUL
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.5
   model      HM-SEC-TIS
   peerIDs    00000000,
   room       Garage
   serialNr   NEQ0674842
   subType    threeStateSensor


Offenbar wird der default Key (00) beim Verifizieren der Signatur verwendet, so dass die Signierung fehlschlägt. Komischerweise funktioniert das mit meinem Handsender, der bzgl. der Verschlüsselung die gleichen Einstellungen hat.

Hat jemand eine Idee?

[mgernoth]

Hallo,

bitte sniffe die Raw-Messages.

EDIT:

Ich habe seit ein paar Tagen wieder das Problem, dass mein Neigungssensor nicht signieren will, obwohl ich das störende RPi-Modul erstmal ausgestellt habe...

Wie genau hast Du es ausgestellt? Wenn Du es nur in Fhem deaktiviert hast, dann mischt sich die Firmware von dem Ding immernoch in den Funkverkehr ein, ich sollte das Ding dann am besten in den Bootloader schicken...

Fuehre mal bitte folgendes aus (als root):

Code Auswählen Erweitern


echo 18 >/sys/class/gpio/export
echo out >/sys/class/gpio/gpio18/direction
echo 0 >/sys/class/gpio/gpio18/value
sleep 0.2
echo 1 >/sys/class/gpio/gpio18/value


Damit resettest Du das Modul und es landet (wie bei einem Kaltstart auch) im Bootloader und mischt sich nicht mehr in den Funkverkehr ein.

Viele Gruesse
  Michael

[mgernoth]

Hallo,

Und nun mit dem RPi-Modul im Bootloader, nach Deiner Anleitung (oh Wunder, es geht wieder!):

Gut

Code Auswählen Erweitern


10_CUL_HM.pm 13085 2017-01-15 13:24:15Z martinp876

ist bereits im Einsatz, und sollte eh besser mit dem RPi-Modul zurechtkommen, selbst wenn es noch aktiv wäre?!

Ja, sollte jetzt keine Probleme mehr geben. Ich hatte Martin einen Patch dafür geschickt, der in diese Version eingeflossen ist.

Kannst Du was erkennen, was hier das Problem ist/war?

Code Auswählen Erweitern


2017.01.21 20:32:53.504 4: CUL_send:  nanoCULAs 11 3E A002 F3A460 4B50C1 04E484169D69ED04
2017.01.21 20:32:53.535 4: CUL_Parse: nanoCUL A 11 3E A002 F3A460 4B50C1 04A1340000340D00 43 -40.5


Der HMUART kannte Garage_TorNeigung noch "halb", allerdings mit Keyindex 0 und hat fast gleichzeitig mit dem CUL den Signaturrequest losgeschickt. Da kam dann zum Schluss nur Murks raus, der CUL hat den zweiten Request auch gesehen und deshalb hat Fhem die KeyNbr 0 bei der VCCU eingetragen, da der HMUART unter der hmId der VCCU eine Signatur mit ID 0 angefordert hat...

BTW: Wie aktiviere ich wieder das RPi-Modul, wenn ich es wieder brauche?

Einfach wieder definieren.

Wenn man jetzt das Modul auf "close" setzt oder (im laufenden Betrieb) das Dummy-Attribut setzt, wird jetzt auch automatisch der Bootloader betreten und damit das reinfunken unterbunden.

Viele Grüße
  Michael

[tndx]

Hallo Michael,

vielen Dank!

Dann kann ich ja morgen wieder das RPi-Modul aktivieren und habe wieder normale Funkabdeckung! *freu*