Fehlerhafte initMessage (+) bei Geraeten mit aesCommReq

[mgernoth]

Hallo,

Fhem sendet eine falsche '+'-Nachricht fuer Geraete mit aesCommReq:

• Es wird immer der Schluessel mit Index 1 angegeben
• Es werden nur Signaturen fuer Nachrichten der Kanaele 1-4 angefordert (0x1E)

Der Aufbau der +-Nachricht ist anscheinend wie folgt:

Code Auswählen Erweitern


+IDIDID,FL,KI,MASK

IDIDID: HMID des Geraets
FL: Flags (1 << 0 - AES, 1 << 1 - data pending)
KI: Schluesselindex fuer AES
MASK: Kanalmaske fuer die AES-Signaturen angefordert werden


Fhem hat hier bei KI hartkodiert 01 stehen, hier sollte wohl am besten der hoechste Index aus hmKey* genommen werden.

Bei MASK wird hartkodiert 0x1E gesendet, was zumindest bei einer RC-19B deutlich zu wenig ist Dieses Feld kann laenger als ein Byte werden, wenn ich das auf 0xFFFF aendere, dann funktionierts auch mit einer RC-19B auf Kanal 13.
Wenn ich den Homegear Quellcode richtig interpretiere, wird die Kanalmaske als Little-Endian gesendet, um also Kanaele 1 bis 15 zu aktivieren (0 nicht), sollte FEFF gesendet werden.

Viele Gruesse
  Michael

[martinp876]

`mask' verstehe ich nicht. ist das ein Bitfeld? Kann man also 16 Kanäle kodieren und jeden einzeln einschalten?
schaltet man dann einfach FFFF ein alle Kanäle werden AES "behandelt"? Eigentlich sollte man es sogar mehr also 16 Bit erlauben. Sicher sind 32 Channels erlaubt.

[mgernoth]

Hallo Martin,

`mask' verstehe ich nicht. ist das ein Bitfeld? Kann man also 16 Kanäle kodieren und jeden einzeln einschalten?
schaltet man dann einfach FFFF ein alle Kanäle werden AES "behandelt"? Eigentlich sollte man es sogar mehr also 16 Bit erlauben. Sicher sind 32 Channels erlaubt.

Ja, Mask ist ein Bitfeld in "verdrehter" Byteordnung (Little-Endian).  Das Ding hat eine dynamische Länge, kann also 1 Byte oder mehr sein. Ich denke "FEFFFFFF" (11111111111111111111111111111110) wäre ein sinnvoller Default. Anscheinend erwartet eQ-3 fuer den Geraetekanal 0 nie eine Signatur, das muss ich aber an einer CCU2 mal pruefen.

Die dynamische Länge des Felds hat auch dazu geführt, dass ich es falsch an den HMCFGUSB uebertragen habe, da der da noch ein Laengenbyte erwartete, das habe ich dann durch Deine Kommentare in 10_CUL_HM  erraten

Wäre es sinnvoll, aesCommReq per Kanal setzbar zu machen? IIRC kann man das bei der CCU so tun. Muss meiner mal wieder Strom geben und schauen...

Gruß
  Michael

[mgernoth]

Nur um das hier noch zu dokumentieren:
Ich hab mal an einer CCU2 mitgesniffed (hmland als HM-LAN-CFG angemeldet) und nacheinander aufsteigend alle Kanaele eines HM-MOD-Re-8 auf gesichert gestellt:

Code Auswählen Erweitern


2015-07-02 22:41:54.608588: LAN > +353A6B,01,00,02
2015-07-02 22:42:11.217867: LAN > +353A6B,01,00,06
2015-07-02 22:42:26.347738: LAN > +353A6B,01,00,0E
2015-07-02 22:42:37.813488: LAN > +353A6B,01,00,1E
2015-07-02 22:42:48.925378: LAN > +353A6B,01,00,3E
2015-07-02 22:43:00.896104: LAN > +353A6B,01,00,7E
2015-07-02 22:43:13.797575: LAN > +353A6B,01,00,FE
2015-07-02 22:43:24.424470: LAN > +353A6B,01,00,FE01


Ist also wirklich Little-Endian mit dynamischer Laenge. Kanal 0 scheint nicht aktiviert zu werden, obwohl das Geraet in der WebUI auch als "gesichert" angezeigt wird.

Gruss
  Michael

[frank]

interessantes thema. da fallen mir gleich ein paar fragen zu ein. 

Code Auswählen Erweitern

2015.07.03 14:28:54.324 0: HMLAN_Send:  hmlan1 S:+1DE620,00,01,FE1F
wenn ich es richtig verstanden habe, soll die message bedeuten, dass nur channel 12 von 1DE620
gesichert ist. also nicht alle 12 channel.

der sec-sc hat aber nur 1 channel und gesichert ist dort eigentlich auch nichts. ein weiterer sec-sc und ein sec-rhs zeigen das gleiche verhalten. müsste also statt "FE1F" "00" heissen, wie sonst bei allen anderen devices, da ich keine sicherung benutze. hier noch ein list nach frischem getconfig.

Code Auswählen Erweitern

Internals:
   .triggerUsed 1
   DEF        1DE620
   IODev      hmlan1
   LASTInputDev hmlan1
   MSGCNT     15
   NAME       Tuer.SZ
   NR         305
   NTFY_ORDER 50-Tuer.SZ
   STATE      Tuer:open (to ccu), Status:open, Sabotage:on, Bat:ok
   TYPE       CUL_HM
   hmlan1_MSGCNT 9
   hmlan1_RAWMSG R53F6F283,0001,00C3ABA1,FF,FFC8,84A0101DE6201ACE1F0201000000
   hmlan1_RSSI -56
   hmlan1_TIME 2015-07-03 14:49:29
   hmusb1_MSGCNT 6
   hmusb1_RAWMSG E1DE620,0000,000BE77C,FF,FFC5,84A0101DE6201ACE1F0201000000
   hmusb1_RSSI -59
   hmusb1_TIME 2015-07-03 14:49:29
   lastMsg    No:84 - t:10 s:1DE620 d:1ACE1F 0201000000
   peerList   SwitchPBU01_Sw_01,
   protLastRcv 2015-07-03 14:49:29
   protSnd    9 last_at:2015-07-03 14:49:29
   protState  CMDs_done
   rssi_at_hmlan1 avg:-56.77 min:-63 max:-55 lst:-56 cnt:9
   rssi_at_hmusb1 avg:-62 min:-67 max:-59 lst:-59 cnt:6
   Readings:
     2015-07-03 14:49:27   .D-devInfo      810101
     2015-07-03 14:49:27   .D-stc          80
     2015-07-03 14:49:29   .protLastRcv    2015-07-03 14:49:29
     2015-07-03 14:49:27   Activity        alive
     2015-05-11 11:56:29   CommandAccepted yes
     2015-07-03 14:49:27   D-firmware      2.0
     2015-07-03 14:49:27   D-serialNr      JEQ0644828
     2015-07-03 14:49:27   PairedTo        0x1ACE1F
     2015-05-11 11:56:44   R-SwitchPBU01_Sw_01-expectAES off
     2015-05-11 11:56:44   R-SwitchPBU01_Sw_01-peerNeedsBurst off
     2015-05-11 11:55:12   R-cyclicInfoMsg on
     2015-05-11 11:55:12   R-eventDlyTime  2 s
     2015-05-11 11:55:12   R-ledOnTime     0.5 s
     2015-05-11 11:55:12   R-msgScPosA     closed
     2015-05-11 11:55:12   R-msgScPosB     open
     2015-05-11 11:55:12   R-pairCentral   0x1ACE1F
     2015-05-11 11:55:12   R-sabotageMsg   on
     2015-05-11 11:55:12   R-sign          off
     2015-05-11 11:55:12   R-transmDevTryMax 6
     2015-05-11 11:55:12   R-transmitTryMax 6
     2015-07-03 14:49:27   RegL_00:          02:01 09:01 0A:1A 0B:CE 0C:1F 10:01 14:06 00:00
     2015-07-03 14:49:28   RegL_01:          08:00 20:60 21:02 22:64 30:06 00:00
     2015-07-03 14:49:29   RegL_04:SwitchPBU01_Sw_01   01:00 00:00
     2015-07-03 14:23:31   alive           yes
     2015-07-03 14:23:31   battery         ok
     2015-07-03 14:23:31   contact         open (to ccu)
     2015-07-03 14:49:29   peerList        SwitchPBU01_Sw_01,
     2015-07-03 14:23:31   recentStateType info
     2015-07-03 14:23:31   sabotageError   on
     2015-07-03 14:23:31   state           open
     2015-05-12 10:18:29   trigger_cnt     37
   Helper:
     HM_CMDNR   132
     cSnd       011ACE1F1DE6200103,011ACE1F1DE6200104266EA50304
     mId        002F
     peerIDsRaw ,266EA503,00000000
     rxType     4
     Bm:
       Cul_hm_get:
         cnt        4
         dmx        0
         max        1
         tot        4
         mAr:
           HASH(0x1482d98)
           Tuer.SZ
           ?
       Cul_hm_set:
         cnt        5
         dmx        0
         max        7
         tot        24
         mAr:
           HASH(0x1482d98)
           Tuer.SZ
           getConfig
     Io:
       newChn     +1DE620,00,01,FE1F
       nextSend   1435927769.92919
       rxt        0
       vccu       ccu
       p:
         1DE620
         00
         01
         FE1F
       prefIO:
         hmlan1
     Mrssi:
       mNo        84
       Io:
         hmlan1     -54
         hmusb1     -59
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         hmlan1
       flg        A
       ts         1435927769.81553
       ack:
         HASH(0x1482d98)
         8480021ACE1F1DE62000
     Rssi:
       At_hmlan1:
         avg        -56.7777777777778
         cnt        9
         lst        -56
         max        -55
         min        -63
       At_hmusb1:
         avg        -62
         cnt        6
         lst        -59
         max        -59
         min        -67
     Shadowreg:
Attributes:
   IODev      hmusb1
   IOgrp      ccu:hmlan1
   actCycle   028:00
   actStatus  alive
   autoReadReg 0_off
   comment    Lueftung
   event-on-change-reading .*
   expert     2_full
   firmware   2.0
   group      Alarmmelder
   model      HM-SEC-SC
   peerIDs    00000000,266EA503,
   room       01_ALARM,50_SZ
   serialNr   JEQ0644828
   stateFormat Tuer:contact, Status:state, Sabotage:sabotageError, Bat:battery
   subType    threeStateSensor

edit: ich sehe gerade, dass die "+"-message auf dieses device sogar in mehreren varianten erfolgt.

Code Auswählen Erweitern

2015.07.03 10:38:13.335 0: HMLAN_Send:  hmlan1 I:+1DE620,00,00,
2015.07.03 11:15:56.555 0: HMLAN_Send:  hmlan1 I:+1DE620,00,01,FE1F
2015.07.03 14:28:54.324 0: HMLAN_Send:  hmlan1 S:+1DE620,00,01,FE1F


die variante, ohne MASK, scheint nach einem umassignen zu kommen.

Code Auswählen Erweitern

2015.07.03 10:38:13.331 0: HMLAN_Send:  hmusb1 I:-1DE620
2015.07.03 10:38:13.335 0: HMLAN_Send:  hmlan1 I:+1DE620,00,00,

gruss frank

[mgernoth]

Hallo,

Code Auswählen Erweitern

2015.07.03 14:28:54.324 0: HMLAN_Send:  hmlan1 S:+1DE620,00,01,FE1F
wenn ich es richtig verstanden habe, soll die message bedeuten, dass nur channel 12 von 1DE620
gesichert ist. also nicht alle 12 channel.

Nein, wieso?

1FFE sichert Kanaele 1-12, siehe Bitmuster: 1111111111110

der sec-sc hat aber nur 1 channel und gesichert ist dort eigentlich auch nichts. ein weiterer sec-sc und ein sec-rhs zeigen das gleiche verhalten. müsste also statt "FE1F" "00" heissen, wie sonst bei allen anderen devices, da ich keine sicherung benutze.

Fuer gesicherte Uebertragung muesste es 02 heissen (bzw. wurde das ausreichen), fuer ungesicherte Uebertragung tut es 00.
Fhem schickt hier im Augenblick hartkodierte Werte, da die Bedeutung des Felds nicht klar war.

Gruss
  Michael

[frank]

Nein, wieso?

habe ich so (falsch) aus deinem ccu2-sniff geschlussfolgert, da du die kanäle nacheinander einzeln gesichert hast. demnach wird also immer die komplette config gesendet.

1FFE sichert Kanaele 1-12, siehe Bitmuster: 1111111111110

das bitmuster war mir schon klar. bis zum ccu2-sniff hätte ich auch gemeint das hiermit die ersten 12 kanäle gesichert werden, macht ja auch mehr sinn.

gruss frank

[mgernoth]

habe ich so (falsch) aus deinem ccu2-sniff geschlussfolgert, da du die kanäle nacheinander einzeln gesichert hast.

Ah.

demnach wird also immer die komplette config gesendet.

Genau, ein + ueberschreibt immer die vorherige Config eines Geraets.

Gruss
  Michael

[martinp876]

das Prinzip ist somit klar. Dass man es in der ccu einzel einstellen kann auch.
Grund ist sicher die nicht unerhebliche längere Verzögerung. Man kann damit einzelne Kanäle schützen, andere aber "schnell" lassen.

aesCommReq kann man (jetzt) für Channels setzen
aesKey setzt den zu nutzenden Key dieses Devices - default =default

[mgernoth]

Hallo Martin,

aesCommReq kann man (jetzt) für Channels setzen
aesKey setzt den zu nutzenden Key dieses Devices - default =default

Wow, danke
Allerdings werden jetzt fuer Geraete bei denen keine eigenen Channels angelegt werden (z.B. TFK) keine Requests mehr gestellt, Patch dafuer im Anhang.
Und der Defaultkey ist 00, auch im Patch.

EDIT: Hmm, wenn ich drueber nachdenke waere es wohl am sinnvollsten, doch den hoechsten Keyindex zu nehmen, wenn aesKey nicht gesetzt wurde.

EDIT2: Ich habe mal eingebaut, dass der Schluessel aus der VCCU oder dem HMLAN geholt wird aber anscheinend wird die Funktion zu frueh aufgerufen und owner_VCCU ist noch nicht unbedingt gesetzt...

Danke & Gruss
  Michael

[martinp876]

all in

[mgernoth]

all in

Danke

Kann man den Aufruf von CUL_HM_hmInitMsg soweit hinauszoegern, bis dem IO eine evtl. existierende VCCU zugewiesen wurde? Einige meiner Geraete bekommen noch den Defaultkey 0 zugewiesen, da ich den Key nur in der VCCU definiert habe und der IO noch nicht das owner_VCCU-Attribut hat.

Ich nehme mal an, dass da im Augenblick die Reihenfolge der Definition ausschlaggebend ist?

EDIT: Hmm, passiert auch wenn ich den Schluessel direkt im IO definieren. Anscheinend fehlt da beim restart die IO-Zuordnung noch komplett, kann das sein? Wenn ich das Attribut zur Laufzeit setze, ist alles OK.

Danke & Gruss
  Michael

[martinp876]

Muss ich mir ansehen, laesst sich sicher loesen

[mgernoth]

Muss ich mir ansehen, laesst sich sicher loesen

Danke

Wenn man die Keys direkt im IO definiert, geht es, wenn man meinen Bug im CUL_HM_getKeys behebt, da er ohne zugewiesene CCU auch gar nicht im Geraet geschaut hat. Das mit der VCCU ist aber wohl wirklich ein Timingproblem.
Patch fuer meinen Bug habe ich angehaengt.

Gruss
  Michael

[martinp876]

done