HM-CC-RT-DN ersetzen

[PeMue]

Hallo zusammen,

ich habe im Bad einen HM-CC-RT-DN, der dummerweise einen zu hohen Stromverbrauch hat. Die Batterie hält nur ca. 6-8 Wochen. Da ich im Produktivbetrieb nicht testen kann, ohne es mir mit meiner besseren Hälfte zu verscherzen, habe ich mir einen neuen (Bausatz) gekauft, aufgebaut und möchte jetzt den alten rauswerfen.

Derzeit ist im Bad folgende Kombination:
- HM-CC-RT-DN gepeert mit Fensterkontakt
- HM-CC-RT-DN gepeert mit Wandthermostat
- alle drei gepaart mit der FHEM Zentrale

Gibt es eine Möglichkeit, den alten Thermostat durch den neuen zu ersetzen, ohne alles auf Werkszustand zu bringen und wieder neu anzulernen?

Danke + Gruß

Peter

[frank]

nicht so einfach, da du alle peerings zurücksetzen und neu setzen musst. das hier sollte helfen:
https://forum.fhem.de/index.php/topic,83496.msg757233.html#msg757233

aber: wenn du wirklich noch den "fehler" finden willst, solltest du zuerst die aktuelle konstellation untersuchen.

theoretisch könnten zb auch burst meldungen vom nachbarn die ursache sein.

[PeMue]

Hallo Frank,

danke für den Link. Habe den Thermostat mal ersetzt (um den WAF zu retten) und werde die Analyse des alten offline verfolgen.

Gruß Peter

[PeMue]

Hallo,

jetzt wird's ein bisschen off-topic. Ich habe den Fensterkontakt mit dem Heizungsthermostat gepeert.
In der Anleitung des Heizungsthermostates steht, dass bei offenem Fenster das Symbol D Fenster-auf-Funktion angezeigt wird (Anleitung v1.6, 11/2016). Ist aber bei mir nicht der Fall. Anbei ein List des Fensterkontakts:

Code Auswählen Erweitern

Internals:
   DEF        267F73
   IODev      PMCUL01
   LASTInputDev PMCUL01
   MSGCNT     2
   NAME       OG_Badfenster
   NOTIFYDEV  global
   NR         255
   NTFY_ORDER 50-OG_Badfenster
   PMCUL01_MSGCNT 2
   PMCUL01_RAWMSG A0C028441267F73000000010200::-56.5:PMCUL01
   PMCUL01_RSSI -56.5
   PMCUL01_TIME 2018-12-31 10:04:27
   STATE      closed
   TYPE       CUL_HM
   lastMsg    No:02 - t:41 s:267F73 d:000000 010200
   peerList   HM_Bad_HKT_WindowRec,
   protLastRcv 2018-12-31 10:04:27
   rssi_at_PMCUL01 cnt:2 min:-62.5 max:-56.5 avg:-59.5 lst:-56.5
   READINGS:
     2018-12-30 16:05:54   Activity        alive
     2018-12-27 13:31:32   D-firmware      2.4
     2018-12-27 13:31:32   D-serialNr      KEQ1096112
     2018-12-30 15:56:03   R-HM_Bad_HKT_WindowRec-expectAES set_off
     2018-12-30 15:56:03   R-HM_Bad_HKT_WindowRec-peerNeedsBurst set_on
     2018-12-30 16:02:44   alive           yes
     2018-12-31 10:04:27   battery         ok
     2018-12-31 10:04:27   contact         closed (to broadcast)
     2018-12-30 16:05:54   peerList        HM_Bad_HKT_WindowRec,
     2018-12-30 16:02:44   powerOn         2018-12-30 16:02:44
     2018-12-30 16:02:44   recentStateType info
     2018-12-30 16:02:44   sabotageError   off
     2018-12-31 10:04:27   state           closed
     2018-12-31 10:04:27   trigger_cnt     2
   helper:
     HM_CMDNR   2
     mId        0030
     regLst     ,0,1,4p
     rxType     20
     supp_Pair_Rep 0
     expert:
       def        1
       det        1
       raw        1
       tpl        1
     io:
       newChn     +267F73,00,00,00
       nextSend   1546247067.51838
       prefIO     
       rxt        2
       vccu       
       p:
         267F73
         00
         00
         00
     mRssi:
       mNo        02
       io:
         PMCUL01:
           -50.5
           -50.5
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       chn        1
       dev        1
     rssi:
       at_PMCUL01:
         avg        -59.5
         cnt        2
         lst        -56.5
         max        -56.5
         min        -62.5
     shadowReg:
     tmpl:
Attributes:
   IODev      PMCUL01
   actCycle   028:00
   actStatus  alive
   autoReadReg 4_reqStatus
   devStateIcon open:fts_window_1w_open@red tilted:fts_window_1w_tilt@orange closed:fts_window_1w@green
   expert     251_anything
   firmware   2.4
   model      HM-SEC-RHS
   peerIDs    00000000,6A1E3D03,
   room       1_Bad,1_Obergeschoss
   serialNr   KEQ1096112
   subType    threeStateSensor
Ist das so, oder habe ich irgendwo noch einen Fehler drin?

Danke, Gruß und einen guten Rutsch.

Peter

[Beta-User]

Das peering ist nicht vollständig durchgeführt: "set_on" bei needs burst...
Kurz-mobile Grüße.

[LuckyDay]

getConfig und knöpfen drücken

Code Auswählen Erweitern

2018-12-30 15:56:03   R-HM_Bad_HKT_WindowRec-peerNeedsBurst set_on

im Moment steht da erst was du gerne hättest set_on

und ob das Teil gepairt ist? ist auch noch die Frage (closed (to broadcast))

[PeMue]

Hallo zusammen,

danke für die Tipps. Muss leider eine Pause machen, da der Fensterkontakt dauern CMDs_pending liefert. Vermutlich brauchs da eine neue Batterie, obwohl die, die drin sind noch 1,5 V (Leerlauf haben). Ich werde berichten ...

Guten Rutsch allerseits.

Peter

[Pfriemler]

Dein Fensterkontakt ist nicht gepairt (insbesondere wenn er an Broadcast sendet, außerdem fehlt das Reading im list). Solange wirst Du CMDs_pending bei jedem Kommunikationsversuch haben.
Mach ein "set OG_Badfenster clear msgEvents" und paire ihn nochmal neu (vccu oder wenn nicht vorhanden CUL auf "hmPairForSec 60" und einmal den Knopf am Fensterkontat kurz drücken).
Erneure dann am besten das Peering des Kontakts mit dem RT-DN, damit der FK einen Burst sendet (peerNeedsBurst => on)

[PeMue]

Hallo zusammen,

vielen Dank für Eure Hinweise.
Ich habe jetzt gefühlte 100 mal angelernt und mit getconfig Knöpfchen gedrückt. Da kommt immer CMDs_pending. Mit einem zweiten (auch mit der Seriennummer KEQ1...) dasselbe. Ich probier's mal mit neuen Batterien, aber mir scheint, dass diese Serie irgendwie eine "Macke" hat. Ggf. tausche ich das Ding gegen einen Eigenbau-Sensor, dann ist Ruhe ...

Euch allen ein gutes Neues Jahr.

Gruß Peter

[martinp876]

mache ein
  clear msgEvents
stelle sniffen ein(siehe wiki sniffen) und logge mit

Versuche
a) pairForSec

Bei Versuch b) mache
- device config drücken (hält 30sec)
- hmPairSerial <seriennummer> abschicken

Die Logs posten, wenn es nicht klappt