Gesperrte HM Geräte nach wechsel von HMLAN auf CCU

[ohosch]

Hallo Fhem Kollegen,

Im Laufe der Zeit habe ich einige HM Komponenten an meinem HMLAN Adapter über FHEM betrieben.
Irgendwann war der HMLAN kaputt. Mit einem recht geringen Aufwand gelang es mir alle Komponenten im laufenden Betrieb auf HMUARTLGW  als CUL1 erreichbar zu machen. Soweit alles gut.

Um HMIP Komponenten mit in FHEM einzubinden hatte ich mir vor einiger Zeit eine Raspimatik (CCU3) zugelegt. Die macht auch prima was sie soll, auch wenn das Interworking mit FHEM manchmal etwas aufwändiger als mit dem CUL ist.
Nichtsdestotrotz zieh ich langsam aber sicher die Komponenten von CUL auf die CCU3 um.

Leider konnte ich bis jetzt 2 Komponenten nicht mehr an die CCU3 anmelden. Einen Fenster/Tür Kontakt und einen innen Bewegungsmelder (die Runde Standbauform)
Bei einem Reset blinkt nur die rote LED was sowas heisst wie "Sicherheitssperre". Ich schaffe es leider weder die Komponenten an die neue Zentrale, noch an den CUL in FHEM anzulernen.  Beim 2ten Gerät hatte ich explizit ein "unpair" Befehl vor dem Reset geschickt.

Jetzt habe ich Angst, dass mir das auch bei weiteren Komponenten passiert. Was wird auf Dauer etwas teuer...

Hat jemand eine Idee was ich falsch mache, und wie ich die gestrandeten Komponenten wieder fit bekomme?

Viele Grüße
Ohosch

[amenomade]

Aes Signierung aktiviert?

[frank]

Beim 2ten Gerät hatte ich explizit ein "unpair" Befehl vor dem Reset geschickt.

das ist natürlich ganz schlecht.
nach erfolgreichem unpair funktionieren keine befehle mehr.

du nutzt scheinbar einen eigenen aes key. dieser kann nur durch die gepairte zentrale, die den key kennt, über "set reset" gelöscht werden. dadurch wird natürlich auch das pairing gelöscht.

also wieder an deiner zentrale anlernen und dann resetten.

[ohosch]

Ja, AES Key ist aktiviert, und auch auf eingenen Wert gesetzt.

Leider bekomme ich beide Geräte auch nicht mehr an den FHEM angelernt. Den Weg erst zurück und dann noch mal gezielt nach vorne wollte ich schon gehen..... Leider bis jetzt ohne Erfolg.

[frank]

irgend etwas machst du aber scheinbar falsch.
zeig mal je ein list der devices.

[ohosch]

Hi Frank,
Ich hoffe das ich etwas falsch mache

Ich kann Dir nur noch ein Device zeigen, das andere hatte ich beide bei der hin under her Bastelei gelöscht. Hoffentlich was das nicht der entscheidende Fehler.

Die IDs hier kennt der CUL noch, die 3118EE ist der Bewegungsmelder.

Code Auswählen Erweitern

assignedIDs: 10
4C6876 : 1OG_SZ_Rauchmelder
4BE063 : Lueftung_Temp_Sen_Aussen
4C6F95 : Reserve_Rauchmelder
4A6C2E : Portabler_Sender_1
389D1C : Schalterschnittstelle_Kueche_Wohn
4BE061 : Lueftung_Temp_Sen_Innen
3118EE : Var_Bewegungsmelder_1
5FD33C : Schalterschnittstelle_Kueche_Eingang
4B4619 : 1OG_SZ_Sonnenindikator_aussen
4C68C7 : EG_D_Rauchmelder

Was willst Du für ein List, oder reicht Dir das so?

Was mir gerade auffällt, ist das der Bewegungsmelder sich offensichtlich wieder gemeldet hat...... Ist schon etwas her dass ich löschen und Anlernen gemacht habe.
Der wird wieder als Alive gemeldet. **freu**

Code Auswählen Erweitern


Readings
Activity
alive
2019-06-10 17:04:37
D-firmware
1.6
2019-06-10 16:54:37
D-serialNr
LEQxxxxxxx
2019-06-10 16:54:37
RegL_00.
2019-06-11 09:16:31
battery
ok
2019-06-12 15:19:06
brightness
36
2019-06-12 15:19:06
cover
closed
2019-06-12 15:19:06
motion
off
2019-06-10 16:55:09
recentStateType
info
2019-06-12 15:19:06
state
RESPONSE TIMEOUT:RegisterRead
2019-06-10 17:12:12


Dann versuche ich den Türkontakt auch mal wieder mit Strom zu versehen. Vielleicht bekomme ich den ja doch wieder in die alte Zentrale rein.

Was mache ich denn dann um ihn sauber abzulernen. Einen set reset?

Viele Grüße
Oliver

[amenomade]

Ein "list" von einem Device ist hier erklärt: https://forum.fhem.de/index.php/topic,71806.0.html
Also: "list Var_Bewegungsmelder_1" im Eingabefeld von FHem eingeben, und das Ergebnis posten

[ohosch]

Oh, das war jetzt einfach, einfach das den Device Namen einzugeben hatte ich in meiner Blindheit übersehen.

Warum auch immer, der Bewegungsmelder funktioniert am CLU wieder.

Diesmal müsste ich es nur schaffen den sauber abzulernen.

Den Tür Sensor habe ich gestern Abend nicht in den Anlernmodus gebracht. Da muss ich noch mal in die Anleitung von EQ3 schauen, irgendwie muss ich den ja wieder zu Kommunizieren bekommen.

Code Auswählen Erweitern


Internals:
   CHANGED   
   CUL1_MSGCNT 2305
   CUL1_RAWMSG 0500003776A6103118EE6714A706012700
   CUL1_RSSI  -55
   CUL1_TIME  2019-06-13 08:40:47
   DEF        3118EE
   FUUID      5c4ac244-f33f-51bc-2397-acb00412ee004d80
   IODev      CUL1
   LASTInputDev CUL1
   MSGCNT     2305
   NAME       Var_Bewegungsmelder_1
   NOTIFYDEV  global
   NR         1207
   NTFY_ORDER 50-Var_Bewegungsmelder_1
   STATE      noMotion
   TYPE       CUL_HM
   chanNo     01
   lastMsg    No:76 - t:10 s:3118EE d:6714A7 06012700
   protCmdDel 3
   protLastRcv 2019-06-13 08:40:45
   protRcv    777 last_at:2019-06-13 08:40:45
   protResnd  3 last_at:2019-06-10 17:06:17
   protResndFail 1 last_at:2019-06-10 17:12:12
   protSnd    4 last_at:2019-06-10 17:12:07
   protState  CMDs_done_Errors:1
   rssi_at_CUL1 cnt:2305 min:-78 max:-31 avg:-39.33 lst:-55
   Helper:
     DBLOG:
       motion:
         logdb:
           TIME       1560400229.45235
           VALUE      off
       state:
         logdb:
           TIME       1560400229.45235
           VALUE      noMotion
   READINGS:
     2019-06-10 17:04:37   Activity        alive
     2019-06-10 16:54:37   D-firmware      1.6
     2019-06-10 16:54:37   D-serialNr      LEQxxxxxxxx
     2019-06-11 09:16:31   RegL_00.       
     2019-06-13 08:40:45   battery         ok
     2019-06-13 08:40:45   brightness      39
     2019-06-13 08:40:45   cover           closed
     2019-06-13 06:30:29   motion          off
     2019-06-13 06:28:27   motionCount     0_next:120s
     2019-06-13 06:30:29   motionDuration  241
     2019-06-13 08:40:45   recentStateType info
     2019-06-13 06:30:29   state           noMotion
     2019-06-13 06:28:27   trigDst_6714A7  noConfig
     2019-06-13 06:28:27   trigger_cnt     0
   helper:
     HM_CMDNR   118
     cSnd       Xxxxxxxxxxxx,xxxxxxxxxxxxx
     getCfgList all
     getCfgListNo ,4
     mId        004A
     peerFriend peerAct,peerVirt
     peerOpt    4:motionDetector
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +3118EE,00,01,00
       nextSend   1560408047.80705
       prefIO     
       rxt        2
       vccu       
       p:
         3118EE
         00
         01
         00
     mRssi:
       mNo        76
       io:
         CUL1:
           -49
           -49
     prt:
       bErr       0
       sProc      0
       sleeping   0
       rspWait:
     q:
       qReqConf   
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_CUL1:
         avg        -39.3362255965292
         cnt        2305
         lst        -55
         max        -31
         min        -78
Attributes:
   IODev      CUL1
   actCycle   000:20
   actStatus  alive
   autoReadReg 4_reqStatus
   event-on-update-reading motion,state
   expert     2_raw
   firmware   1.6
   model      HM-SEC-MDIR-2
   room       CUL_HM
   serialNr   LEQxxxxxxx
   subType    motionDetector

[frank]

vorweg: das verschleiern deiner hmid ist sinnlos, da sie jeder in deiner nähe sowieso schnell ermitteln kann.

ein sauberes pairing des bm ist nicht zu erkennen. auch fehlen fhem diverse daten des bm.

allerdings wurde eine message an ein device mit der id 6714A7 gesendet. ist das die hmid deiner zentrale oder ein gepeertes device?
wenn das die zentrale ist, mach ein "set getConfig" am bm. knöpfchen drücken nicht vergessen, bis du cmds_done erkennst. eventuell kann fhem mit dem melder auch kommunizieren, wenn du bewegungen auslöst. wenn die daten komplett sind, poste bitte ein aktuelles list.

hast du beim pairingversuch auch beim io ein "set hmPairForSec" zuvor ausgelöst?

du kennst das wiki pairen und peeren?


wurde beim anlernversuch an die ccu eigentlich nicht nach einem key gefragt? bei der alten konfigurationssoftware von eq3 war das jedenfalls so.

[ohosch]

Hi Frank,

Danke schon mal für Analyse.

Da hast Du wohl recht, solange es nicht um den AES Key geht, brauche ich wohl keine Daten verschleiern...

Die 6714A7 ist die Original HMID des CUL. Ich habe sie auf die ehemalige HMID meines defekten HMLAN 73AD48 umgesetzt.
Ob ich irgendwann mal versucht habe den Bewegungsmelder unter der original HMID des CUL zu pairen, kann ich nicht mit Sicherheit sagen.
Pairen mache ich meistens mit hmPairForSec, manachmal auch per hmPairSerial. Funktioniert normalerweise auch reibungsfrei, nur bei den beiden Devices, die offensichtlich nicht sauber abgelernt wurden hatte ich Probleme.

Das beim Anlernen an die CCU ein key Abgefragt wird habe ich noch nicht erlebt. Da starte ich einfach eine suche und entweder liegt was im Posteingang oder nicht.

Nach dem WIKI pairen habe ich auch den Befehl ,,set unpair" auf den Fensterkontakt abgesetzt. Mit dem beschäftige ich mich seit gestern wieder, verzweifele aber noch daran ihn überhaupt wieder in einen Definierten zustand zum Wiederverbinden an den FHEM zu bringen.
Was ich in dem WIKI allerdings nicht verstehe ist: ,,Wichtig ist dabei, dass das IO-Device, das entpairt werden soll, mit der ursprünglich in das HM-Gerät geschriebenen HMID konfiguriert ist.,,
Muss ich vor dem entpairen auf die original HMID die meine HMLAN mal hatte?  Die 73AD48 hatte ich dem HMLAN nach der Erstinstallation vergeben. Der HLAN war dann irgendwann kaputt gegangen und durch den CUL ersetzt worden. Den ich dann mit dem AES und 73AD48 konfiguriert habe.

Viele Grüße
Oliver


   

[frank]

ganz schönes chaos bei dir. 

wieso redest du immer von cul? das müste doch wohl das hmuart modul für den pi sein. poste mal ein list davon.

pairen:
ein gepairtes gerät führt nur befehle aus, die von dieser hmid gesendet werden.

falls der bm mit 6714A7 gepairt ist, kann nur eine zentrale mit dieser id befehle senden, die auch ausgeführt werden. also hmid beim io dafür ändern.

und vergiss endlich "set unpair". mach, wie gesagt, besser "set reset", damit auch eventuelle keys gelöscht werden. ein reset löscht auch das pairing.

[ohosch]

In der Tat, Zuviel Chaos . Das gesamte System ist schon etwas komplex geworden, und in jeden Aspekt muss Mann sich wieder rein arbeiten, wenn ein Problem auftaucht, oder man was ändern will.
Aber ich nutze ja FHEM gerade weil es so universell ist.

Den Fensterkontakt hab ich übrigens gestern wieder an FHEM angelernt bekommen, mit set reset zurückgesetzt und dann an die CCU angelernt. Das Tut  .

Der Bewegungsmelder ist etwas bockiger. Ich habe gestern mal die HMID von  HMUART auf  6714A7 gesetzt.  Damit kann ich sporadisch mit dem BM kommunizieren. Sonderbarerweise werden Kommandos wie set GetConfig manchmal mit grün am BM quittiert, wenn ich es noch mal absetze dann wieder nicht.....
Ein set reset habe ich noch nicht erfolgreich quittiert bekommen. Da ist er immer auf command_pending hängen geblieben.

Gibt es eine Möglichkeit, wie ich den BM von hmid 6714A7 auf 73AD48 ändern kann?

   
Hier übrigends das Listing vom HMUART (heisst bei mir CUL1)

Code Auswählen Erweitern


Internals:
   AssignedPeerCnt 11
   CNT        60
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DEVCNT     60
   DevState   99
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         69
   FUUID      5c4ac244-f33f-51bc-bfff-d35606d75a6301f7
   LastOpen   1560489457.43268
   NAME       CUL1
   NR         1206
   PARTIAL   
   RAWMSG     040200
   RSSI       -73
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   1
   model      HM-MOD-UART
   msgLoadCurrent 0
   msgLoadHistory 0/0/0/0/0/0/0/0/0/0/0/0
   msgLoadHistoryAbs 0/0/0/0/0/0/0/0/0/0/0/0/0
   owner      73AD48
   Helper:
     CreditTimer 514
     FW         66561
     Initialized 1
     SendCnt    3
     AckPending:
     DBLOG:
       D-HMIdAssigned:
         logdb:
           TIME       1560489461.08349
           VALUE      73AD48
       D-HMIdOriginal:
         logdb:
           TIME       1560489461.17018
           VALUE      6714A7
       D-firmware:
         logdb:
           TIME       1560489461.25597
           VALUE      1.4.1
       D-serialNr:
         logdb:
           TIME       1560489461.2978
           VALUE      PEQ0174930
       cond:
         logdb:
           TIME       1560489461.37051
           VALUE      ok
       loadLvl:
         logdb:
           TIME       1560489461.37051
           VALUE      low
       state:
         logdb:
           TIME       1560489564.62222
           VALUE      UNKNOWNCODE A0C2A84702D331F00000000BB3E::-73:CUL1
     LastSendLen:
       3
       3
     Log:
       IDs:
     PeerQueue:
     PendingCMD:
     RoundTrip:
       Delay      0.0161869525909424
     loadLvl:
       lastHistory 1560497261.33506
   MatchList:
     1:CUL_HM   ^A......................
   Peers:
     3118EE     +3118EE,02,01,00
     389D1C     +389D1C,00,01,00
     41AE63     +41AE63,00,01,00
     4A6C2E     +4A6C2E,00,01,00
     4B4619     +4B4619,00,01,00
     4BE061     +4BE061,00,01,00
     4BE063     +4BE063,00,01,00
     4C6876     +4C6876,00,01,00
     4C68C7     +4C68C7,00,01,00
     4C6F95     +4C6F95,00,01,00
     5FD33C     +5FD33C,00,01,00
   READINGS:
     2019-06-14 07:17:41   D-HMIdAssigned  73AD48
     2019-06-14 07:17:41   D-HMIdOriginal  6714A7
     2019-06-14 07:17:41   D-firmware      1.4.1
     2019-06-14 07:17:41   D-serialNr      PEQ0174930
     2019-06-10 16:54:28   D-type          HM-MOD-UART
     2019-06-14 07:17:41   cond            ok
     2019-06-14 08:22:18   load            0
     2019-06-14 07:17:41   loadLvl         low
     2019-06-14 07:17:37   state           opened
   helper:
Attributes:
   comment    D-HMIdAssigned

73AD48

D-HMIdOriginal

6714A7

   hmId       73AD48
   hmKey     Xxxxxxxxxxxxxx
   room       HomeMatik
   verbose    2



Ich werde am WE unterwegs, und komme wohl erst nächste Woche zu weitern versuchen.
Vielen Dank schon mal

Oliver

[frank]

Ein set reset habe ich noch nicht erfolgreich quittiert bekommen. Da ist er immer auf command_pending hängen geblieben.

ich habe keine erfahrung mit reset. könnte aber ein indiz sein, dass der reset erfolgreich war. das device kennt ja nun keine zentrale mehr zum antworten.
zeig mal ein aktuelles list.

umpairen kann man auch mit "set regSet pairCentral 73AD48". aber auch hier gibt es bei erfolg keine antwort mehr, wie bei reset und unpair.

ich würde reset empfehlen und danach neu pairen. natürlich jeweils mit passender hmid.