Einrichtung der HM-SEC-SD-2 funktioniert nicht

[dama]

@Otto: war ja nur eine Frage mit dem untereinander peeren. Steht so im Thread, auf den du hingewiesen hast - aber klar, dafür ist ja der virtuelle Lead in FHEM da.

Das mit dem AES-Key (auch wenn ich es nicht hätte tun sollen) kann meines Erachtens nicht falsch sein. Ich habe nicht mehrere durchprobiert, sondern einmalig einen selbst-generierten gesetzt. Das habe ich exakt nach der Anleitung aus dem wiki gemacht - und die Melder haben DAMIT auch schon mal funktioniert.

Ich drehe hier noch durch... weil ich jetzt langsam nichts mehr verstehe.

Der RM (ich teste mittlerweile nur noch mit einem) lässt sich - zumindest laut FHEM - nicht mehr pairen: der Melder selbst quittiert das Anlernen zwar mit grüner LED.
Aber wenn ich das betreffende Device in FHEM anschaue, dann sehe ich R-pairCentral/PairedTo=0x000000, also nicht gepaired. Das Log dazu im Post #12.
Ein paar Readings liefert er dann allerdings doch: smoke_detect, sdRepeat, peerList...
Ein getConfig führt er nicht aus, außer wenn ich ihn zuvor in den Anlernmodus versetze. Dann wird ein getConfig sofort umgesetzt und mit grüner LED quittiert. Ansonsten "RESPONSE TIMEOUT:RegisterRead" und "CMDs_done_Errors:1"
Und für mich völlig unerklärlich: ein teamCall aus FHEM auf dem Device selbst führt er jederzeit aus (grüne LED blinkt).


Kann das sein, dass FHEM sich die schon mal "gesehenen" Devices irgendwo merkt und sich deswegen so verhält? Ich habe die Devices jedes Mal gelöscht (delete im Web-Frontend im jew. Device), danach Save config und restart von FHEM durchgeführt. Im Log (s. oben) steht an diversen Stellen "dupe, dont process". Das kann ich nicht deuten in diesem Fall...

Eins der RM readings ist aesCBCCounter (steht auf 00009A). Das habe ich vorher nicht wahrgenommen. Was bedeutet das?

Grüße
dama

[Otto123]

Hi dama,

durchdrehen macht keinen Sinn - Du kämpfst mit einem Rauchmelder 

Bei dem Log aus Post #12 blicke ich nicht durch.
Das mit der grünen LED klingt eigentlich zuversichtlich.
Was steht in der peerlist?

Pairing bedeutet nicht, dass FHEM sich irgendwas merkt. Dabei wird die hmId des IO im Gerät eingetragen. Das Gerät nimmt danach Befehle von dem IO an der diese hmId trägt.
Du hast AES eingerichtet, vorausgesetzt das hat mal funktioniert, hat das Gerät den hmkey und kann mit diesem Key signierte Nachrichten akzeptieren.

Ob der RM Daten übertragt ohne oder mit "Knopf" drücken kann ich nicht sagen. Ich weiß es nicht. Offenbar macht er es mit Knopf drücken, Du sagst ja dann geht getConfig.
getConfig ändert aber nicht die Readings bezüglich pairing?

Gruß Otto

[dama]

Jetzt bin ich doch nicht durchgedreht, weil ich das Posting #237 ( https://forum.fhem.de/index.php/topic,35298.msg454390.html#msg454390 ) gefunden habe.   

Ich habe penibelst aufgeräumt diesmal zwei Melder nach dieser Anleitung in FHEM reingebracht.
Pairing mit FHEM hat astrein geklappt und Peering mit dem virtuellen Teammelder auch.

Teamcall geht immer noch nicht... bzw. blinken die RMs nicht. Im state des devices sehe ich aber was von teamcall stehen...

List des Teammelders

Code Auswählen Erweitern

Internals:
   DEF        32132101
   HMLAN1_MSGCNT 1
   HMLAN1_RAWMSG E4731BF,0000,0567166E,FF,FFCC,8086104731BF00000006010000
   HMLAN1_RSSI -52
   HMLAN1_TIME 2016-11-10 21:07:48
   LASTInputDev HMLAN1
   MSGCNT     1
   NAME       Teammelder
   NOTIFYDEV  global
   NR         320
   STATE      off
   TESTNR     1
   TYPE       CUL_HM
   chanNo     01
   device     TeamVirtuell
   peerList   HM_47319F,HM_4731BF,
   sdTeam     sdLead
   Readings:
     2016-11-10 21:17:03   aesCBCCounter   000007
     2016-11-10 21:18:01   eventNo         01
     2016-11-10 21:07:48   level           0
     2016-11-10 21:13:04   peerList        HM_47319F,HM_4731BF,
     2016-11-10 21:18:01   smoke_detect    none
     2016-11-10 21:22:39   state           off
     2016-11-10 21:18:01   teamCall        from TeamVirtuell:01
   Helper:
     count      1
     fkt        sdLead2
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Role:
       chn        1
       vrt        1
     Tmpl:
Attributes:
   model      virtual_1
   peerIDs    47319F01,4731BF01,
   room       Allgemein,CUL_HM,Technik
   webCmd     press short:press long

List der RMs

Code Auswählen Erweitern


Internals:
   CFGFN
   DEF        47319F
   HMLAN1_MSGCNT 45
   HMLAN1_RAWMSG E47319F,0000,0574B092,FF,FFCD,80A61047319F93AFB506010000
   HMLAN1_RSSI -51
   HMLAN1_TIME 2016-11-10 21:22:39
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     45
   NAME       HM_47319F
   NOTIFYDEV  global
   NR         335
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:80 - t:10 s:47319F d:93AFB5 06010000
   peerList   Teammelder,
   protEvt_AESCom-ok 4 last_at:2016-11-10 21:00:24
   protLastRcv 2016-11-10 21:22:39
   protResnd  2 last_at:2016-11-10 21:04:11
   protSnd    33 last_at:2016-11-10 21:22:39
   protState  CMDs_done
   rssi_HMLAN1 avg:-41.5 min:-46 max:-39 lst:-39 cnt:4
   rssi_at_HMLAN1 avg:-46.55 min:-52 max:-42 lst:-51 cnt:36
   Readings:
     2016-11-10 21:04:12   PairedTo        0x93AFB5
     2016-11-10 21:04:12   R-pairCentral   0x93AFB5
     2016-11-10 21:04:12   RegL_00.          02:01 0A:93 0B:AF 0C:B5 16:00 1F:00 00:00
     2016-11-10 21:22:39   alarmTest       ok
     2016-11-10 21:22:39   battery         ok
     2016-11-10 21:22:39   level           0
     2016-11-10 21:04:12   peerList        Teammelder,
     2016-11-10 21:22:39   powerOn         2016-11-10 21:22:39
     2016-11-10 21:22:39   recentStateType info
     2016-11-10 21:04:12   sdRepeat        off
     2016-11-10 21:22:39   smokeChamber    ok
     2016-11-10 21:18:01   smoke_detect    none
     2016-11-10 21:22:39   state           off
     2016-11-10 21:18:01   teamCall        from TeamVirtuell:01
   Helper:
     HM_CMDNR   128
     cSnd       0193AFB547319F0103,0193AFB547319F010E
     mId        00AA
     peerIDsRaw ,32132101,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +47319F,00,01,00
       nextSend   1478809359.64821
       prefIO
       rxt        0
       vccu
       p:
         47319F
         00
         01
         00
     Mrssi:
       mNo        80
       Io:
         HMLAN1     -49
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1478809359.5736
       ack:
         HASH(0x26395d0)
         80800293AFB547319F00
     Rssi:
       Hmlan1:
         avg        -41.5
         cnt        4
         lst        -39
         max        -39
         min        -46
       At_hmlan1:
         avg        -46.5555555555556
         cnt        36
         lst        -51
         max        -42
         min        -52
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,32132101,
   room       CUL_HM
   serialNr   NEQ0247991
   subType    smokeDetector
   webCmd     statusRequest


Internals:
   CFGFN
   DEF        4731BF
   HMLAN1_MSGCNT 46
   HMLAN1_RAWMSG R4FE00F5B,0001,056CAB96,FF,FFCD,BBA6104731BF93AFB5060100002B
   HMLAN1_RSSI -51
   HMLAN1_TIME 2016-11-10 21:13:54
   IODev      HMLAN1
   LASTInputDev HMLAN1
   MSGCNT     46
   NAME       HM_4731BF
   NOTIFYDEV  global
   NR         375
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:BB - t:10 s:4731BF d:93AFB5 060100002B
   peerList   Teammelder,
   protEvt_AESCom-ok 1 last_at:2016-11-10 21:13:05
   protLastRcv 2016-11-10 21:13:54
   protSnd    9 last_at:2016-11-10 21:13:54
   protState  CMDs_done
   rssi_HMLAN1 avg:-42 min:-43 max:-41 lst:-43 cnt:2
   rssi_at_HMLAN1 avg:-48.66 min:-52 max:-45 lst:-51 cnt:9
   Readings:
     2016-11-10 21:13:05   CommandAccepted yes
     2016-11-10 21:13:31   PairedTo        0x93AFB5
     2016-11-10 21:13:31   R-pairCentral   0x93AFB5
     2016-11-10 21:13:31   RegL_00.          02:01 0A:93 0B:AF 0C:B5 16:00 1F:00 00:00
     2016-11-10 21:13:05   aesCommToDev    ok
     2016-11-10 21:13:05   aesKeyNbr       00
     2016-11-10 21:13:54   alarmTest       ok
     2016-11-10 21:13:54   battery         ok
     2016-11-10 21:13:54   level           0
     2016-11-10 21:13:32   peerList        Teammelder,
     2016-11-10 21:13:54   recentStateType info
     2016-11-10 21:13:31   sdRepeat        off
     2016-11-10 21:13:54   smokeChamber    ok
     2016-11-10 21:18:01   smoke_detect    none
     2016-11-10 21:18:01   state           off
     2016-11-10 21:18:01   teamCall        from TeamVirtuell:01
   Helper:
     HM_CMDNR   187
     cSnd       0193AFB54731BF0103,0193AFB54731BF010E
     mId        00AA
     peerIDsRaw ,32132101,00000000
     rxType     6
     Expert:
       def        1
       det        0
       raw        1
       tpl        0
     Io:
       newChn     +4731BF,00,01,00
       nextSend   1478808834.16809
       prefIO
       rxt        0
       vccu
       p:
         4731BF
         00
         01
         00
     Mrssi:
       mNo        BB
       Io:
         HMLAN1     -49
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLAN1
       flg        A
       ts         1478808834.0831
       ack:
         HASH(0x26422c0)
         BB800293AFB54731BF00
     Rssi:
       Hmlan1:
         avg        -42
         cnt        2
         lst        -43
         max        -41
         min        -43
       At_hmlan1:
         avg        -48.6666666666667
         cnt        9
         lst        -51
         max        -45
         min        -52
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLAN1
   IOgrp      vccu:HMLAN1
   actCycle   099:00
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,32132101,
   room       CUL_HM
   serialNr   NEQ0247885
   subType    smokeDetector
   webCmd     statusRequest



Wie macht man einen RM zum Repeater (M_I_B's Punkt 12)?

[Otto123]

Das sieht jetzt gut aus!
Die RMs haben den Teamlead als peer und der Teamlead hat die RMs als peer, das ist richtig so!

Hast Du libcrypt-rijndael-perl installiert? Sonst geht wohl der Teamcall nicht.


Gruß Otto

[automatisierer]

Die pairings der SD2 scheinen noch nicht komplett zu sein. In den Readings fehlt bei dem ersten SD2 'aesKeyNbr' das zeigt welchen AES Key der SD2 benutzt. Wenn du in der VCCU den Key als '01' definiert hast, dann steht im Device 'aesKeyNbr 02' der Wert im Device ist immer der Wert in der VCCU mal 2, bei 'Key Nr2' also 'aesKeyNbr 04' - keine Ahnung warum - ist aber so. Wie gesagt, beim ersten fehlts noch und bei dem Zweiten steht 'aesKeyNbr 00' _ da stimmt also etwas noch nicht.

Grundsätzlich:
Man kann Devices nur mit einer Zentrale pairen und nicht untereinander. Also HM_SEC_SD2 mit FHEM oder einer CCU.
Man kann HM-Devices nur untereinander peeren. Genauer gesagt, die Kanäle der Devices (sofern es welche hat) kann man mit den Kanälen anderer Devices peeren.
Diese Begriffe bitte nicht verwechseln, das führt zu verwirrungen bei den Leser/Helfern.


Wenn du die SD2 pairst, dann Schritt für Schritt nach dieser Anleitung.

https://forum.fhem.de/index.php/topic,35298.msg460380.html#msg460380

Damit habe ich schon 30 St. gepairt und mit einem virt. Teamlead gepeert.

Mit Schritt für Schritt meine ich, dass du nicht alle Befehle stumpf eingibst, sondern nach jedem Schritt guckst ob das gewünschte Ergebnis da ist. Es kommt nicht immer alles was der Sender sendet beim Empfänger an...
Also nach dem Pairing gucken ob die entsprechenden Readings (pairedTo oder so ähnlich) da sind. Wenn nicht pairing wiederholen oder mal ein getConfig machen.

Dann assignHmKey und ein getConfig und das gegebenenfalls wiederholen, bis die Readings da sind und stimmen. Ansonsten brauchst du mit den nächsten Schritten nicht weiter zu machen.

Allgemeine Grundlagen sollte man natürlich auch beachten. Zum Beispiel den Abstand zum HMlan - nicht kleiner als 1m... Sonst gibts Funkprobleme.

Dann noch die Antwort auf:

Hast Du libcrypt-rijndael-perl installiert? Sonst geht wohl der Teamcall nicht.

So sieht das Listing aus wenn der SD2 richtig mit FHEM gepairt und mit dem virtTeamLead gepeert ist:

Code Auswählen Erweitern

Internals:
   CHANGED
   DEF        4C6C37
   HMLANingo1_MSGCNT 5
   HMLANingo1_RAWMSG E4C6C37,0000,00FEBCE1,FF,FFC5,85A6104C6C3735586706010000
   HMLANingo1_RSSI -59
   HMLANingo1_TIME 2016-11-10 23:44:18
   HMLANingo3_MSGCNT 4
   HMLANingo3_RAWMSG E4C6C37,0000,01004AF0,FF,FFC8,85A6104C6C3735586706010000
   HMLANingo3_RSSI -56
   HMLANingo3_TIME 2016-11-10 23:44:18
   HMLGW_1_MSGCNT 4
   HMLGW_1_RAWMSG 0501004385A6104C6C3735586706010000
   HMLGW_1_RSSI -67
   HMLGW_1_TIME 2016-11-10 23:44:18
   IODev      HMLGW_1
   LASTInputDev HMLANingo3
   MSGCNT     13
   NAME       Garage_SD2
   NOTIFYDEV  global
   NR         1459
   NTFY_ORDER 50-Garage_SD2
   STATE      off
   TYPE       CUL_HM
   lastMsg    No:85 - t:10 s:4C6C37 d:355867 06010000
   peerList   RM_TeamDev_Btn1,
   protLastRcv 2016-11-10 23:44:18
   protSnd    5 last_at:2016-11-10 23:44:18
   protState  CMDs_done
   rssi_HMLANingo1 avg:-57 min:-57 max:-57 lst:-57 cnt:1
   rssi_at_HMLANingo1 avg:-62.2 min:-63 max:-59 lst:-59 cnt:5
   rssi_at_HMLANingo3 avg:-55.5 min:-56 max:-55 lst:-56 cnt:4
   rssi_at_HMLGW_1 avg:-64.75 min:-67 max:-64 lst:-67 cnt:4
   Readings:
     2016-11-09 15:06:47   Activity        alive
     2016-06-23 16:14:33   CommandAccepted yes
     2016-06-23 16:14:31   D-firmware      1.0
     2016-06-23 16:14:31   D-serialNr      NEQ0450074
     2016-06-23 16:14:35   PairedTo        0x355867
     2016-05-28 17:55:58   R-devRepeatCntMax 0
     2016-06-23 16:14:35   R-pairCentral   0x355867
     2016-06-23 16:14:33   aesCommToDev    ok
     2016-06-23 16:14:32   aesKeyNbr       04
     2016-11-10 23:44:18   alarmTest       ok
     2016-11-10 23:44:18   battery         ok
     2016-11-10 23:44:18   level           0
     2016-11-09 15:06:47   peerList        RM_TeamDev_Btn1,
     2016-05-29 11:07:36   powerOn         2016-05-29 11:07:36
     2016-11-10 23:44:18   recentStateType info
     2016-06-23 16:14:35   sdRepeat        off
     2016-11-10 23:44:18   smokeChamber    ok
     2016-11-11 07:51:25   smoke_detect    none
     2016-11-11 07:51:25   state           off
     2016-11-11 07:51:17   teamCall        from RM_TeamDev:02
     2016-05-28 18:34:50   trigLast        RM_TeamDev_Btn1:0
     2016-05-28 18:34:50   trig_RM_TeamDev_Btn1 0
   Helper:
     HM_CMDNR   133
     cSnd       ,013558674C6C37010E
     mId        00AA
     rxType     6
     Ack:
     Expert:
       def        1
       det        1
       raw        0
       tpl        0
     Io:
       newChn     +4C6C37,00,02,00
       nextSend   1478817858.6861
       rxt        0
       vccu       vccu
       p:
         4C6C37
         00
         02
         00
     Mrssi:
       mNo        85
       Io:
         HMLANingo1 -59
         HMLANingo3 -56
         HMLGW_1    -65
     Prt:
       bErr       0
       sProc      0
       Rspwait:
     Q:
       qReqConf
       qReqStat
     Role:
       chn        1
       dev        1
     Rpt:
       IO         HMLGW_1
       flg        A
       ts         1478817858.59419
       ack:
         HASH(0x3a0de08)
         8580023558674C6C3700
     Rssi:
       Hmlaningo1:
         avg        -57
         cnt        1
         lst        -57
         max        -57
         min        -57
       At_hmlaningo1:
         avg        -62.2
         cnt        5
         lst        -59
         max        -59
         min        -63
       At_hmlaningo3:
         avg        -55.5
         cnt        4
         lst        -56
         max        -55
         min        -56
       At_hmlgw_1:
         avg        -64.75
         cnt        4
         lst        -67
         max        -64
         min        -67
     Shadowreg:
     Tmpl:
Attributes:
   IODev      HMLANingo1
   IOgrp      vccu
   actCycle   099:00
   actStatus  alive
   autoReadReg 5_readMissing
   devStateIcon off:general_ok *:secur_alarm
   event-on-change-reading .*
   expert     1_allReg
   firmware   1.0
   model      HM-SEC-SD-2
   msgRepeat  1
   peerIDs    00000000,19191901,
   room       __Geraete
   serialNr   NEQ0450074
   subType    smokeDetector
   webCmd     statusRequest

Den Repeaterbetrieb benötigst du nur, wenn sich nicht alle SD2 untereinander direkt per Funk erreichen können.
Im Fall eines Alarms, sendet der Ausgelöste SD2 halt einen "teamCall" und der muss von dem SD2 aus bis zu allen anderen kommen. SD2 die das Signal nicht erreicht, machen halt keinen Alarm. Wenn du den TeamCall von dem VirtTeamLead aus auslöst, dann muss der HMlan halt alle SD2 erreichen können - das ist ja meisstens gegeben.

Gruß
Ingo

[Otto123]

Hallo Ingo,

ich habe noch nicht verstanden (ich habe nur die SD und nicht die SD-2) wie Dein Listing die Sache mit der Installation/Funktion des libcrypt-rijndael-perl Paketes erklärt. Kannst Du das nochmal erklären?
Ich habe verstanden, dass aesCBC offenbar softwareseitig in CUL_HM geklärt ist.
Gruß Otto

[dama]

libcrypt-rijndael-perl habe ich installiert.

Ausgehend von dem Zustand gestern abend habe ich nun set <RM> assignHmKey.
Das führt sofort zum MISSING_ACK
Ein anschließendes statusRequest löst das auf.
Wenn ich anschließend getConfig mache, kommt nicht so richtig viel rüber: nur peerList, RegL_00 und PairedTo...
aesKeyNbr verbleibt eisern bei 00

Ich habe den Key, wie schon geschrieben, nur in VCCU gesetzt, nicht aber im HMLAN. Das ist doch ausreichend oder?

Die RMs befinden sich ca. 4m weg vom HMLAN (ohne Hindernisse dazwischen)

[dama]

Wir kommen langsam weiter 

assignHmKey akzeptieren die Kollegen offensichtlich nur, wenn sie keinen peer haben.

Wie ich im vorigen Posting geschrieben habe, habe ich es mehrfach versucht mit assignHmKey, statusRequest und getConfig

Kaum habe ich den im RM noch gesetzten Teammelder ungepeert, siehe da, beim nächsten getConfig steht plötzlich aesKeyNbr auf 02 ...

Dann kam mir aber die 1% Regel ins Gehege...   

[dama]

Es geht jetzt alles, auch der teamCall für alle... 

Oh Mann, bin ich froh...

Für die Nachwelt, worauf es m.E. ankam:

• Falls man vorher schon rumprobiert hat, FHEM komplett bereinigen von den entsprechenden Devices (auch Log-Definitionen usw.), danach am besten restart und x-check ob wirklich alles weg ist
• Auch die RM reseten (Knopf für 10+s drücken)
• Immer zuerst mit FHEM pairen / im Falle von explizit gesetztem Schlüssel zusehen, dass die Kommunikation tatsächlich über den korrekten AES-Key signiert wird (d.h. aesKeyNbr <> 00)
• Erst wenn letzter Punkt sauber funktioniert, dann kann man mit dem virtuellen Lead teamen

Mein Problem war zuletzt ganz klar (leider erst hinterher  ), dass die RMs den AES Key nicht akzeptieren wollten, weil sie den virtuellen Teamleader bereits in peerIDs gesetzt hatten.

"Again what learnt" würde ich sagen...

Danke allen für eure Geduld und Mühe.

[dama]

Nachdem ich jetzt den dritten Melder im Bunde eingebunden habe, muss ich meine Beobachtungen noch etwas ergänzen:

• Der SD2 (ich schätze, nur wenn eigene AES-Key gesetzt ist) akzeptiert am Anfang kurz nach dem Pairen nur Kommandos, wenn er in Pairing-Mode versetzt wird (orange LED blinkt). Das gilt insbesondere für getConfig. Ein Kommando wird dann mit einer grünen LED quitiert
• assignHmKey akzeptierten meine SD2 dann trotzdem erstmal nicht. Obwohl kein Peer im SD2 gesetzt war. Erst mit dem Kommando unten (SD2 im Pairing-Mode!) wurde assignHmKey umgehend verarbeitet. Verstehen tue ich es nicht, aber es ist 100% reproduzierbar

Code Auswählen Erweitern

set <Team> peerChan 0 <sd2> single unset actor

[automatisierer]

Hallo Ingo,

ich habe noch nicht verstanden (ich habe nur die SD und nicht die SD-2) wie Dein Listing die Sache mit der Installation/Funktion des libcrypt-rijndael-perl Paketes erklärt. Kannst Du das nochmal erklären?
Ich habe verstanden, dass aesCBC offenbar softwareseitig in CUL_HM geklärt ist.
Gruß Otto

Mein Listing hatte nichts mit der Erklärung zu libcrypt-rijndael-perl zu tun... das sollte nur zeigen wie es aussieht wenn es funktioniert - also aesKeyNbr z.B.

Wie das libcrypt... genau arbeitet und was das mit dem TeamCall zu tun hat kann ich dir auch nicht sagen. Ich hab nur weitergeben was mgernoth in dem SD2 Thread geschrieben hat...

[automatisierer]

Nachdem ich jetzt den dritten Melder im Bunde eingebunden habe, muss ich meine Beobachtungen noch etwas ergänzen:

• Der SD2 (ich schätze, nur wenn eigene AES-Key gesetzt ist) akzeptiert am Anfang kurz nach dem Pairen nur Kommandos, wenn er in Pairing-Mode versetzt wird (orange LED blinkt). Das gilt insbesondere für getConfig. Ein Kommando wird dann mit einer grünen LED quitiert
• assignHmKey akzeptierten meine SD2 dann trotzdem erstmal nicht. Obwohl kein Peer im SD2 gesetzt war. Erst mit dem Kommando unten (SD2 im Pairing-Mode!) wurde assignHmKey umgehend verarbeitet. Verstehen tue ich es nicht, aber es ist 100% reproduzierbar

Code Auswählen Erweitern

set <Team> peerChan 0 <sd2> single unset actor

ich tippe eher, dass das pairing noch nicht komplett abgeschlossen war. Wie gesagt jeden Schritt durchführen und dann kontrollieren ob es geklappt hat. erst dann den nächsten... Das gilt aber nicht nur für SD2 sondern auch für andere HM Geräte.

[ramses]

es wäre gut wenn man all diese Erkenntnisse ins Wiki einträgt, oder?

[Otto123]

es wäre gut wenn man all diese Erkenntnisse ins Wiki einträgt, oder?

Die Sache mit dem  libcrypt-rijndael-perl Modul habe ich eingefügt. Das scheint ja so zu sein. Das ermittelte Verhalten von dama mit der Anmerkung von automatisierer kann ich mangels SD-2 nicht verifizieren. Da muss ein anderer ran.

Gruß Otto

[Leeloo_Dallas]

Nachdem ich jetzt den dritten Melder im Bunde eingebunden habe, muss ich meine Beobachtungen noch etwas ergänzen:

• Der SD2 (ich schätze, nur wenn eigene AES-Key gesetzt ist) akzeptiert am Anfang kurz nach dem Pairen nur Kommandos, wenn er in Pairing-Mode versetzt wird (orange LED blinkt). Das gilt insbesondere für getConfig. Ein Kommando wird dann mit einer grünen LED quitiert
• assignHmKey akzeptierten meine SD2 dann trotzdem erstmal nicht. Obwohl kein Peer im SD2 gesetzt war. Erst mit dem Kommando unten (SD2 im Pairing-Mode!) wurde assignHmKey umgehend verarbeitet. Verstehen tue ich es nicht, aber es ist 100% reproduzierbar

Code Auswählen Erweitern

set <Team> peerChan 0 <sd2> single unset actor

Die beschriebene Vorgehensweise kann ich bestätigen. Es verhält sich mit den SD2 quasi wie mit anderen Komponenten wenn ein "hmkey" <> "default" im Einsatz ist (siehe dazu u.a. auch: https://forum.fhem.de/index.php/topic,55357.msg469966.html#msg469966 ).

Da es beim SD2 kein "sign" gibt, muss ein " ... single unset actor" gefolgt von einem "... single set actor" den gewünschten Key-Austausch an triggern. )