Löschen, Reset und neu pairen

teichtaucher · 07 Dezember 2019, 23:06:38

Ich habe ein Problem mit einem device und möchte es eigentlich gerne auf werkseinstellung zurücksetzen. Dummerweise wird das device schon in mehreren Doifs und anderen Funktionen verwendet. Mein Plan ist deshalb dass device zu löschen, es zu resetten, neu zu pairen und dann wieder auf den ursprünglichen Namen umzubenennen.
Bleiben beim Löschen des devices noch die ganzen Doifs und andere Funktionen erhalten? Oder wird das auch mit gelöscht? Und wenn ich das device wieder auf den ursprünglichen Namen umbenenne, funktionieren dann noch die ganzen alten Doifs?

MadMax-FHEM · 07 Dezember 2019, 23:22:06

Warum resetten, löschen, neu anlegen und umbenennen?

Was für ein Gerät ist es?

Pairing klingt nach Homematic?!
Da kann man auch einfach so "drüber pairen"...

Aber poste doch mal ein list von dem Device...
...und schildere warum den "Amok"...

Aber trotzdem die Antworten zu den Fragen:

Nein, normalerweise werden "verknüpfte" notify/DOIF etc. nicht mit gelöscht, wenn du NUR direkt beim Device unten den "Delete this Device" link nutzt.
Bei Löschen mit devspec oder/und RegEx kann schon mehr gelöscht werden

Und wenn nach dem Umbenennen wieder die gewohnten Events kommen (sollte ja), dann funktionieren auch notify/DOIF etc. wieder (wenn zuvor auch schon funktioniert)...

Gruß, Joachim

teichtaucher · 08 Dezember 2019, 20:56:33

Ich habe ein Problem mit einem Homematic Fensterkontakt. Wenn ich ein GetConfig mache und den Taster am FK drücke blinkt der FK erst orange und geht dann auf rot. Gestern war anscheinend der DutyCycle überschritten, da hat er nur noch rot geleuchtet.
Heute funktioniert er - zumindest was die Heizungsregler betrifft - wieder ganz normal und quittiert ein offenes oder geschlossenes Fenster mit grün.
Aber der Fehler mit GetConfig ist immer noch da. Das komische ist dass beim FK die Liste der PeerIDs komplett leer ist. Also kein 000000 oder gepeerte Heizungsregler - die Liste ist komplett leer. Ich sehe auch im Log vom FK dass beim Auslesen der peerlist ein Timeout kommt:

Code Auswählen


2019-12-08_16:04:03 ku.fk.Schiebetuer ResndFail
2019-12-08_16:04:04 ku.fk.Schiebetuer RESPONSE TIMEOUT:PeerList

Ich vermute dass der FK irgendwie hängt und überlege ihn deshalb auf Werkseinstellung zurückzusetzen, aber vorher aus FHEM zu löschen. Nach erneutem Pairen würde ich den gleichen Namen wieder verwenden damit die alten Doif wieder funktionieren. Klar, Peering muss ich neu machen.

Otto123 · 08 Dezember 2019, 21:00:40

Hi,

wie Joachim gestern schon gesagt hat, bevor Du Dir unnötigen Aufwand machst: wiederhole einfach den Pairing Vorgang OHNE Reset, OHNE Löschen.
Pass auf, dass Du den Sensor beim Pairen nicht auslöst, sondern die Configtaste drückst um die Datenübertragung anzustoßen.

Hast Du hmInfo definiert? Was sagt da configCheck zu deinem System ?

Gruß Otto

teichtaucher · 08 Dezember 2019, 21:39:41

Hallo Otto,

das mit dem erneuten Pairing habe ich schon versucht, da hat der FK am Ende auch grün geleuchtet. Die PeerList ist allerdings immer noch leer. Mein FK sieht so aus:

Code Auswählen


Internals:
   DEF        44257C
   FUUID      5cb63bfb-f33f-d318-6683-f8d5e56a3dd28e23
   HMLAN1_MSGCNT 1065
   HMLAN1_RAWMSG E44257C,0000,682D381B,FF,FFAE,4A800244257C3012350011AC5097
   HMLAN1_RSSI -82
   HMLAN1_TIME 2019-12-08 21:29:29
   IODev      gl.gw.Wemos
   LASTInputDev HMLAN1
   MSGCNT     2137
   NAME       ku.fk.Schiebetuer
   NOTIFYDEV  global
   NR         59
   NTFY_ORDER 50-ku.fk.Schiebetuer
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   gl.gw.Wemos_MSGCNT 1072
   gl.gw.Wemos_RAWMSG 040C00294A800244257C3012350011AC5097
   gl.gw.Wemos_RSSI -41
   gl.gw.Wemos_TIME 2019-12-08 21:29:28
   lastMsg    No:4A - t:02 s:44257C d:301235 0011AC5097
   protCmdDel 15
   protEvt_AESCom-ok 3 last_at:2019-12-08 21:29:28
   protLastRcv 2019-12-08 21:29:28
   protRcv    109 last_at:2019-12-08 21:29:28
   protRcvB   16 last_at:2019-12-08 18:07:37
   protResnd  6 last_at:2019-12-08 15:07:06
   protResndFail 2 last_at:2019-12-08 16:04:03
   protSnd    60 last_at:2019-12-08 21:29:28
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:1065 min:-92 max:-54 avg:-68.51 lst:-82 
   rssi_at_gl.gw.Wemos cnt:1069 min:-52 max:-36 avg:-40.33 lst:-41 
   READINGS:
     2019-12-08 21:29:26   Activity        alive
     2019-12-08 21:29:28   CommandAccepted yes
     2019-12-08 21:29:26   D-firmware      1.0
     2019-12-08 21:29:26   D-serialNr      MEQ1723075
     2019-12-08 12:44:10   PairedTo        0x301235
     2019-12-07 10:52:45   R-cyclicInfoMsg on
     2019-12-07 10:52:45   R-eventDlyTime  0 s
     2019-12-07 21:41:26   R-ku.ht.Heizung_WindowRec-expectAES set_off
     2019-12-07 21:41:26   R-ku.ht.Heizung_WindowRec-peerNeedsBurst set_on
     2019-12-08 21:29:26   R-pairCentral   set_0x301235
     2019-12-07 10:52:45   R-sabotageMsg   on
     2019-12-07 10:52:45   R-sign          on
     2019-12-08 21:29:28   aesCommToDev    ok
     2019-12-08 21:29:28   aesKeyNbr       00
     2019-12-08 20:55:43   alive           yes
     2019-12-08 20:55:43   battery         ok
     2019-12-08 20:55:43   contact         closed (to VCCU)
     2019-12-07 10:46:50   powerOn         2019-12-07 10:46:50
     2019-12-08 20:55:43   recentStateType info
     2019-12-08 20:55:43   sabotageError   off
     2019-12-08 20:55:43   state           closed
     2019-12-08 18:07:37   trigDst_az.ht.Heizung noConfig
     2019-12-08 18:07:37   trigDst_ku.ht.Heizung noConfig
     2019-12-08 18:07:38   trigDst_wz.Ht.Couch noConfig
     2019-12-08 18:07:37   trigDst_wz.ht.Essecke noConfig
     2019-12-08 18:07:39   trigger_cnt     14
   helper:
     HM_CMDNR   74
     PONtest    0
     cSnd       0130123544257C000802010A300B120C35,0130123544257C0006
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +44257C,00,00,00
       nextSend   1575836968.56129
       prefIO     
       rxt        2
       vccu       VCCU
       p:
         44257C
         00
         00
         00
     mRssi:
       mNo        4A
       io:
         HMLAN1:
           -82
           -82
         gl.gw.Wemos:
           -33
           -33
     prt:
       bErr       0
       sProc      0
       sleeping   0
     q:
       qReqConf   00
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_HMLAN1:
         avg        -68.519248826291
         cnt        1065
         lst        -82
         max        -54
         min        -92
       at_gl.gw.Wemos:
         avg        -40.3302151543499
         cnt        1069
         lst        -41
         max        -36
         min        -52
     shadowReg:
       RegL_00.    02:01 0A:30 0B:12 0C:35
     tmpl:
Attributes:
   IODev      gl.gw.Wemos
   IOgrp      VCCU:gl.gw.Wemos
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   icon       fts_window_1w
   model      HM-SEC-SCO
   peerIDs    
   room       Kueche
   serialNr   MEQ1723075
   subType    threeStateSensor

Danach habe ich noch versucht erneut zu Peeren aber da hat der FK am Ende rot geleuchtet protState steht noch auf CMDs_pending. Das ist doch nicht normal beim FK, der zickt doch rum.

Und ja, im HMinfo habe ich neben dem Fehler noch andere kleine Baustellen (obwohl sonst alles funktioniert). Die Fehler muss ich nach und nach mal beseitigen.

MadMax-FHEM · 08 Dezember 2019, 21:55:04

cmds_pending ist gerade beim FK normal.
Da Batterie-betrieben überträgt er halt nur ab und an Daten oder eben "Konfig-Taster" drücken (aufwecken).

Peering nach Pairing geht nur noch per Befehl von der Zentrale/fhem (hast du verm. ja auch so gemacht)...

Gepaired ist er ja jetzt so wie's aussieht...

Mach doch mal clear message und dann ein getConfig inkl. "Knöpfchen drücken"...

Und dann mal sehen was hminfo "sagt"...

Gruß, Joachim

Otto123 · 08 Dezember 2019, 22:08:04

Zitat von: teichtaucher am 08 Dezember 2019, 21:39:41
Das ist doch nicht normal beim FK, der zickt doch rum.

Doch der FK ist ne kleine Zicke.
configtaster nochmal drücken und viel Ruhe bewahren. Und erst wieder getconfig machen, wenn cmds pending weg ist.

teichtaucher · 09 Dezember 2019, 20:46:06

So, mal ein kleines Statusupdate: Habe ein getConfig gemacht und den Taster gedrückt aber am Ende der Kommunikation geht der FK immer auf rot. Witzigerweise sehe ich in FHEM CMDs_done. Aber ich sehe immer noch keine PeerList

Gut, er scheint immer noch zu funktionieren, die Heizungsregler fahren runter wenn das Fenster offen ist. Sieht halt nicht gut aus in hmInfo aber vielleicht muss ich einfach mit diesem Schönheitsfehler leben. Ansonsten überlege ich mir das und setze ihn wirklich einfach auf Werkseinstellung zurück.
Trotzdem danke für Eure Hilfe.

Otto123 · 09 Dezember 2019, 21:16:36

Und einfach nochmal pairen OHNE reset?

teichtaucher · 09 Dezember 2019, 21:28:27

Habe ich gerade nochmal versucht aber ohne Änderung. Der FK sieht so aus:

Code Auswählen



 
Internals:
   DEF        44257C
   FUUID      5cb63bfb-f33f-d318-6683-f8d5e56a3dd28e23
   HMLAN1_MSGCNT 1109
   HMLAN1_RAWMSG E44257C,0000,6D515829,FF,FFB3,F3800244257C301235000D4E5486
   HMLAN1_RSSI -77
   HMLAN1_TIME 2019-12-09 21:26:50
   IODev      gl.gw.Wemos
   LASTInputDev HMLAN1
   MSGCNT     2233
   NAME       ku.fk.Schiebetuer
   NOTIFYDEV  global
   NR         59
   NTFY_ORDER 50-ku.fk.Schiebetuer
   STATE      closed
   TYPE       CUL_HM
   chanNo     01
   gl.gw.Wemos_MSGCNT 1124
   gl.gw.Wemos_RAWMSG 040C0029F3800244257C301235000D4E5486
   gl.gw.Wemos_RSSI -41
   gl.gw.Wemos_TIME 2019-12-09 21:26:50
   lastMsg    No:F3 - t:02 s:44257C d:301235 000D4E5486
   protCmdDel 23
   protEvt_AESCom-ok 10 last_at:2019-12-09 21:26:50
   protLastRcv 2019-12-09 21:26:50
   protRcv    153 last_at:2019-12-09 21:26:50
   protRcvB   16 last_at:2019-12-08 18:07:37
   protResnd  12 last_at:2019-12-09 18:26:42
   protResndFail 4 last_at:2019-12-09 19:27:41
   protSnd    113 last_at:2019-12-09 21:26:49
   protState  CMDs_done
   rssi_at_HMLAN1 cnt:1109 min:-92 max:-54 avg:-68.66 lst:-77 
   rssi_at_gl.gw.Wemos cnt:1114 min:-52 max:-36 avg:-40.38 lst:-41 
   READINGS:
     2019-12-09 21:26:47   Activity        alive
     2019-12-09 21:26:50   CommandAccepted yes
     2019-12-09 21:26:47   D-firmware      1.0
     2019-12-09 21:26:47   D-serialNr      MEQ1723075
     2019-12-09 16:27:26   PairedTo        0x301235
     2019-12-07 10:52:45   R-cyclicInfoMsg on
     2019-12-07 10:52:45   R-eventDlyTime  0 s
     2019-12-07 21:41:26   R-ku.ht.Heizung_WindowRec-expectAES set_off
     2019-12-07 21:41:26   R-ku.ht.Heizung_WindowRec-peerNeedsBurst set_on
     2019-12-09 21:26:47   R-pairCentral   set_0x301235
     2019-12-07 10:52:45   R-sabotageMsg   on
     2019-12-07 10:52:45   R-sign          on
     2019-12-09 21:26:50   aesCommToDev    ok
     2019-12-09 21:26:50   aesKeyNbr       00
     2019-12-09 21:18:49   alive           yes
     2019-12-09 21:18:49   battery         ok
     2019-12-09 21:18:49   contact         closed (to VCCU)
     2019-12-07 10:46:50   powerOn         2019-12-07 10:46:50
     2019-12-09 21:18:49   recentStateType info
     2019-12-09 21:18:49   sabotageError   off
     2019-12-09 21:18:49   state           closed
     2019-12-08 18:07:37   trigDst_az.ht.Heizung noConfig
     2019-12-08 18:07:37   trigDst_ku.ht.Heizung noConfig
     2019-12-08 18:07:38   trigDst_wz.Ht.Couch noConfig
     2019-12-08 18:07:37   trigDst_wz.ht.Essecke noConfig
     2019-12-08 18:07:39   trigger_cnt     14
   helper:
     HM_CMDNR   243
     PONtest    0
     cSnd       0130123544257C000802010A300B120C35,0130123544257C0006
     getCfgList all
     getCfgListNo ,4
     mId        00C7
     peerFriend peerAct,peerVirt
     peerOpt    4:threeStateSensor
     regLst     0,1,4p
     rxType     28
     supp_Pair_Rep 0
     ack:
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newCh      1
       newChn     +44257C,00,00,00
       nextSend   1575923210.22873
       prefIO     
       rxt        2
       vccu       VCCU
       p:
         44257C
         00
         00
         00
     mRssi:
       mNo        F3
       io:
         HMLAN1:
           -77
           -77
         gl.gw.Wemos:
           -33
           -33
     prt:
       bErr       0
       sProc      0
       sleeping   0
     q:
       qReqConf   00
       qReqStat   
     regCollect:
     role:
       chn        1
       dev        1
     rssi:
       at_HMLAN1:
         avg        -68.663660955816
         cnt        1109
         lst        -77
         max        -54
         min        -92
       at_gl.gw.Wemos:
         avg        -40.3877917414722
         cnt        1114
         lst        -41
         max        -36
         min        -52
     shadowReg:
       RegL_00.    02:01 0A:30 0B:12 0C:35
       RegL_04.ku.ht.Heizung_WindowRec  01:01
     tmpl:
Attributes:
   IODev      gl.gw.Wemos
   IOgrp      VCCU:gl.gw.Wemos
   actCycle   002:50
   actStatus  alive
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.0
   icon       fts_window_1w
   model      HM-SEC-SCO
   peerIDs    
   room       Kueche
   serialNr   MEQ1723075
   subType    threeStateSensor

Otto123 · 09 Dezember 2019, 21:34:59

Der ist noch nicht ganz fertig:
2019-12-09 21:26:47 R-pairCentral set_0x301235

nochmal Taste drücken und Ruhe bewahren

Schalte vielleicht besser für den Pairing Vorgang den HMLAN aus. Nur ein IO ist meist besser

teichtaucher · 11 Dezember 2019, 09:50:42

So, hat leider alles nichts gebracht. Ich konnte aber in der Zwischenzeit mal die anderen FKs richtig konfigurieren. Und dabei ist mir folgendes aufgefallen:
- Wenn ein FK mit mehreren RTs gepeered wird meldet der FK relativ schnell den DutyCycle Error. Also muss man hier wirklich abwarten und dann weitermachen.
- Teilweise sehe ich jetzt auch bei den neuen FKs wenn sie mit einige RTs gepeered sind dass die PeerList nicht vollständig ist.
Kann es sein dass der FK ab einer kritischen Menge an RTs die getConfig-Daten gar nicht vollständig übertragen kann ohne in ein DutyCycle Fehler zu laufen? Dann wäre das ja ein generelles Problem und hmInfo kann man gar nicht sauber bekommen?

Sauber bekommt man es dann nur wenn man die FKs über einen virtuellen FK gruppiert.

teichtaucher · 11 Dezember 2019, 21:23:08

Meine Vermutung war richtig. Ich habe jetzt bei allen FKs das Peering mit den RTs aufgehoben. Und siehe da, auf einmal haben die FKs auch auf ein GetConfig (mit grün) geantwortet. Ich denke dass bei zu vielen Peerings die Funklast von den FKs schnell am Ende ist und die auf DutyCycle Error gehen. Jetzt wo die Peerings aufgehoben sind reagieren alle FKs total schnell und antworten auf jedes Kommando.
Ich habe mir statt direktem Peering einen virtuellen FK angelegt und den mit allen fünf RTs gepeered. Ein DoIf (mit 30s wait delay) löst jetzt den virtuellen FK aus sobald ein Fenster offen ist. Neben dem jetzt fehlerfreien Betrieb hat man noch andere Vorteile:
-Durch das wait löst nicht jede kurze Fensteröffnung ein Runterregeln aus.
-Ein nicht erkanntes geschlossenes Fenster führt trotzdem dazu dass die Heizung wieder hoch regelt.
-Es ist viel übersichtlicher da jedes offene Fenster in nur einem virtuellen FK gehändelt wird statt dass jeder FK mit jedem RT gepeered ist.
Und jetzt ist auch HmInfo sauber