[Gelöst] HM-CC-RT-DN Funk-Heizkörperthermostat Pairing Problem

[Erich Fromm]

Hallo zusammen.

Vorab: bitte kurzen Hinweis sollte ich im falschen Forum unterwegs sein.

Ich habe hier einen neuen/weiteren HM-CC-RT-DN Funk-Heizkörperthermostat, der sich einfach nicht mit meinem Homematic LAN Gateway pairen lassen will.

Reproduzierbares Fehlverhalten:

• Homematic LAN Gateway via hmPairForSec in Pairing Modus versetzen.
• Boost Taste gedrückt halten.
• Der 30 Sekunden Countdown läuft durch.
• In FHEM wird ein neues Device angelegt.
• Das neue Device bleibt mit protState: CMDs_pending stehen und das Reading Activity geht über zu dead.
• Am HM-CC-RT-DN Funk-Heizkörperthermostat ist kein Antennensymbol zu sehen.

Auszug aus dem Log:

Code Auswählen Erweitern


2020.01.02 09:17:26 3: HMUARTLGW HMLANGW entered pairing-mode
2020.01.02 09:17:58 2: CUL_HM Unknown device HM_64999F is now defined
2020.01.02 09:17:58 2: autocreate: define HM_64999F CUL_HM 64999F
2020.01.02 09:17:58 2: autocreate: define FileLog_HM_64999F FileLog ./log/HM_64999F-%Y.log HM_64999F
2020.01.02 09:17:58 3: CUL_HM_update: HM_64999F add channel ID: 64999F01 name: HM_64999F_Weather
2020.01.02 09:17:58 3: CUL_HM_update: HM_64999F add channel ID: 64999F02 name: HM_64999F_Climate
2020.01.02 09:17:59 3: CUL_HM_update: HM_64999F add channel ID: 64999F03 name: HM_64999F_WindowRec
2020.01.02 09:17:59 3: CUL_HM_update: HM_64999F add channel ID: 64999F04 name: HM_64999F_Clima
2020.01.02 09:17:59 3: CUL_HM_update: HM_64999F add channel ID: 64999F05 name: HM_64999F_ClimaTeam
2020.01.02 09:17:59 3: CUL_HM_update: HM_64999F add channel ID: 64999F06 name: HM_64999F_remote
2020.01.02 09:17:59 3: Device HM_64999F added to ActionDetector with 000:10 time
2020.01.02 09:17:59 3: CUL_HM pair: HM_64999F thermostat, model HM-CC-RT-DN serialNr
2020.01.02 09:20:04 1: [Freezemon] myFreezeMon: possible freeze starting at 09:20:03, delay is 1.213 possibly caused by: no bad guy found :-(

... die Zeile des Freezemon habe ich ergänzt, da diese (scheinbar) bei jedem meiner Versuche zeitnah nach dem Pairing Versuch im Log zu finden ist.

Ein list von HM_64999F:

Code Auswählen Erweitern


Internals:
   CFGFN     
   DEF        64999F
   FUUID      5e0da736-f33f-508c-0bd1-bf290f80d12b24d3
   HMLANGW_MSGCNT 2
   HMLANGW_RAWMSG 0500002101840064999F0000001400954F4551323038363933375900FFFF
   HMLANGW_RSSI -33
   HMLANGW_TIME 2020-01-02 09:26:43
   IODev      HMLANGW
   LASTInputDev HMLANGW
   MSGCNT     2
   NAME       HM_64999F
   NOTIFYDEV  global
   NR         552
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_64999F_Weather
   channel_02 HM_64999F_Climate
   channel_03 HM_64999F_WindowRec
   channel_04 HM_64999F_Clima
   channel_05 HM_64999F_ClimaTeam
   channel_06 HM_64999F_remote
   lastMsg    No:01 - t:00 s:64999F d:000000 1400954F4551323038363933375900FFFF
   protCmdPend 3 CMDs_pending
   protLastRcv 2020-01-02 09:17:59
   protRcv    2 last_at:2020-01-02 09:17:59
   protState  CMDs_pending
   rssi_at_HMLANGW cnt:3 min:-33 max:-32 avg:-32.33 lst:-33
   READINGS:
     2020-01-02 09:37:59   Activity        dead
     2020-01-02 09:17:59   D-firmware      1.4
     2020-01-02 09:17:59   D-serialNr      OEQ2086937
     2020-01-02 09:17:59   R-pairCentral   set_0x051111
     2020-01-02 09:17:59   state           CMDs_pending
   cmdStack:
     ++A00105111164999F00050000000000
     ++A00105111164999F000802010A050B110C11
     ++A00105111164999F0006
   helper:
     HM_CMDNR   1
     PONtest    1
     mId        0095
     peerFriend
     peerOpt    -:thermostat
     regLst     0
     rxType     140
     supp_Pair_Rep 0
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +64999F,02,00,00
       nextSend   1577953603.25215
       prefIO     
       rxt        2
       vccu       
       p:
         64999F
         00
         00
         00
     mRssi:
       mNo        01
       io:
         HMLANGW:
           -25
           -25
     prt:
       bErr       0
       sProc      2
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
       prs        1
     rssi:
       at_HMLANGW:
         avg        -32.3333333333333
         cnt        3
         lst        -33
         max        -32
         min        -33
     shRegW:
       07         04
     shadowReg:
       RegL_00.    02:01 0A:05 0B:11 0C:11
     tmpl:
Attributes:
   IODev      HMLANGW
   actCycle   000:10
   actStatus  dead
   autoReadReg 4_reqStatus
   expert     2_raw
   firmware   1.4
   model      HM-CC-RT-DN
   room       CUL_HM
   serialNr   OEQ2086937
   subType    thermostat
   webCmd     getConfig:clear msgEvents:burstXmit


Was habe ich bisher versucht -> ohne Erfolg

• Factory Reset des HM_64999F.
• Batterien rein/raus am HM_64999F.
• Erneutes Drücken und Festhalten der Boost Taste. Hatte in einem Formusbeitrag gelesen, dass das evtl. helfen könnte. Hat es aber nicht.
• FHEM Update.
• FHEM Restart.
• Test mit einem weiteren HM-CC-RT-DN Funk-Heizkörperthermostat. Gleiches Fehverhalten.
• Versucht aus dem Log des Freezemon etwas abzuleiten. Leider erfolglos. Unten habe ich den zugehörigen Auszug angehängt.

Kontextinformation: Es gibt in meiner Umgebung bereits 6 HM-CC-RT-DN Funk-Heizkörperthermostate. Bei allen hat das Anlernen vor Monaten problemlos funktioniert.

Ein HMInfo ConfigCheck zeigt zu HM_64999F folgende Info:

Code Auswählen Erweitern


missing register list
    HM_64999F: RegL_00.
    HM_64999F_Clima: RegL_01.,RegL_07.
    HM_64999F_ClimaTeam: RegL_01.
    HM_64999F_Climate: RegL_01.
    HM_64999F_Weather: RegL_01.
    HM_64999F_WindowRec: RegL_01.
    HM_64999F_remote: RegL_01.

Register changes pending
    HM_64999F

peer list incomplete. Use getConfig to read it.
    incomplete: HM_64999F_Clima:
    incomplete: HM_64999F_ClimaTeam:
    incomplete: HM_64999F_Climate:
    incomplete: HM_64999F_Weather:
    incomplete: HM_64999F_WindowRec:
    incomplete: HM_64999F_remote:


Vorab vielen Dank für Eure Hilfe und Grüße,
Erich

Code Auswählen Erweitern


2020-01-02_09:20:04 myFreezeMon s:09:20:03 e:09:20:04 f:1.213 d:no bad guy found :-(
2020-01-02_09:20:04 myFreezeMon freezeTime: 1.213
2020-01-02_09:20:04 myFreezeMon fcDay: 15
2020-01-02_09:20:04 myFreezeMon ftDay: 448.58
2020-01-02_09:20:04 myFreezeMon freezeDevice: no bad guy found :-(
=========================================================
[Freezemon] myFreezeMon: possible freeze starting at 09:20:03, delay is 1.213 possibly caused by: no bad guy found :-(
2020.01.02 09:20:02.780 5: CUL/RAW: /N0190C
2020.01.02 09:20:02.797 5: CUL/RAW: N0190C/6112D1BAAAA0000789D94
H430300110245FF

2020.01.02 09:20:02.797 4: CUL_Parse: CUL_868 N0190C6112D1BAAAA0000789D94
2020.01.02 09:20:02.800 5: createNotifyHash
2020.01.02 09:20:02.856 5: rgBattery: not on any display, ignoring notify
2020.01.02 09:20:02.856 5: rgTemperatureHumidity: not on any display, ignoring notify
2020.01.02 09:20:02.857 5: End notify loop for CUL_868
2020.01.02 09:20:02.857 3: CUL_868: Unknown code N0190C6112D1BAAAA0000789D94, help me!
2020.01.02 09:20:02.857 4: CUL_Parse: CUL_868 H430300110245FF -74.5
2020.01.02 09:20:02.859 4: HMS Device 4303 (HMS100TF: T: 21.1  H: 45  Bat: ok)
2020.01.02 09:20:02.862 4: Connection accepted from WEB_192.168.0.107_49456
2020.01.02 09:20:02.864 4: WEB_192.168.0.107_49456 GET /fhem?room=CUL%5fHM; BUFLEN:0
--- log skips     1.348 secs.
2020.01.02 09:20:04.213 4: WEB: /fhem?room=CUL%5fHM / RL:31281 / text/html; charset=UTF-8 / Content-Encoding: gzip
/ Cache-Control: no-cache, no-store, must-revalidate

2020.01.02 09:20:04.213 5: [Freezemon] myFreezeMon: ----------- Starting Freeze handling at 2020.01.02 09:20:04.213 ---------------------


[Otto123]

Moin,

Was habe ich bisher versucht -> ohne Erfolg
Factory Reset des HM_64999F.
Batterien rein/raus am HM_64999F.
Erneutes Drücken und Festhalten der Boost Taste. Hatte in einem Formusbeitrag gelesen, dass das evtl. helfen könnte. Hat es aber nicht.
FHEM Update.
FHEM Restart.
Test mit einem weiteren HM-CC-RT-DN Funk-Heizkörperthermostat. Gleiches Fehverhalten.
Versucht aus dem Log des Freezemon etwas abzuleiten. Leider erfolglos. Unten habe ich den zugehörigen Auszug angehängt.

Meines Erachtens sind alle deine "versuche" kontraproduktiv.

Versuche es nach dem pairen einfach mal mit warten und Ruhe bewahren. Die Dinger senden nur alle paar Minuten und es braucht bei diesem Gerät mit Sicherheit mehrere Zyklen bis zum kompletten Abschluss.

Gruß Otto

[Erich Fromm]

Hallo Otto.

Danke für den Hinweis.

Versuche es nach dem pairen einfach mal mit warten und Ruhe bewahren. Die Dinger senden nur alle paar Minuten und es braucht bei diesem Gerät mit Sicherheit mehrere Zyklen bis zum kompletten Abschluss.

Ich hatte bereits über Nacht gewartet. Heute habe ich einen neuen Versuch gestartet, um die Daten für den Forums-Post zu haben.
Wie auch immer ... inzwischen sind ja einige Minuten vergangen und es sind immer noch Commands pending und Activity ist immer noch Dead.

Grüße, Erich

[Otto123]

Naja dann nach dem Warten einfach nochmal pairen, nichts löschen nichts zurücksetzen.
Eventuell nach ein paar Minuten nochmal getConfig absetzen wieder warten.
Eventuell mal clear msgEvents machen, getConfig absetzen und wieder warten

Aber alles immer mit Ruhe. Die Geräte mit mehreren Kanälen brauchen irgendwie immer etwas mehr Zeit.

Darauf achten das der IO nicht in Overload gerät.

Das Gerät ist aber montiert? Kalibrierfahrt ist gemacht? Weil das war glaub ich auch ein Problem. Ich habe die Dinger nicht, ich rede nur das nach was ich hier so lese

[Erich Fromm]

Hallo Otto.

Erneut Danke.

Naja dann nach dem Warten einfach nochmal pairen, nichts löschen nichts zurücksetzen.

Versucht. Keine Verbesserung.

Eventuell nach ein paar Minuten nochmal getConfig absetzen wieder warten.

Dann stehen nur noch mehr pending Commands.

Eventuell mal clear msgEvents machen, getConfig absetzen und wieder warten

Die pending Commands sind nach clear erst weg und dann wieder da.

Aber alles immer mit Ruhe. Die Geräte mit mehreren Kanälen brauchen irgendwie immer etwas mehr Zeit.

Ich hatte bereits längere Wartezeiten

Darauf achten das der IO nicht in Overload gerät.

Wie bzw. wo kann ich das überprüfen?

Das Gerät ist aber montiert? Kalibrierfahrt ist gemacht?

Ja und ja.

Mich irritiert immer noch, dass am Gerät das Funksymbol nicht dauerhaft leuchtet. Kennt das Gerät die Zentrale dann überhaupt schon?

... und ich habe bei den Readings ein

Code Auswählen Erweitern


R-pairCentral set_0x051111

Bedeutet dies nicht, dass das Setzen der ID auf dem Gerät noch nicht erfolgt ist?

Grüße, Erich

[Otto123]

Hallo Erich,

R-pairCentral set_0x051111

genau das bedeutet, dass er angefangen hat das pairing zum machen, Das heisst das Gerät ist angelegt, die hmId der Zentrale wurde gesendet. Die Zentrale wartet jetzt auf Bestätigung und die komplette Konfiguration.
Das set_ dort muss verschwinden.

Overload würdest Du im HMLANGW in den load Readings sehen.

Sorry, weitere Tipps hab ich nicht, wie gesagt ich habe keine praktische Erfahrung mit den Thermostaten.

Gruß Otto

[Pfriemler]

Hier tauchte im Forum gerade eine Handlungsempfehlung für RT-DNs auf, über die wir schon kontrovers disktutiert haben.

1. Das Verbindungssysmbol am RT-DN sollte schon aktiv sein. Nur dann können CMDs_pending irgendwann auch abgearbeitet werden. Bis dahin würde ich es mit gelegentlichem Pairing versuchen.
2. VOR jedem neuen Pairing-Versuch "clear msgEvents" machen!
3. Gern auch mal die Reihenfolge "set (vccuoderwasauchimmer) pairForSec" und das längere Drücken der Boost-Taste tauschen. Funktionieren sollte beides, wenn es zeitnah (<20s) zusammen erfolgt.
4. kein getConfig zu früh absetzen, wenn dann vorher immer "clear msgEvents".

Nachtrag: Entfernung beachten - Mindestabstand (>1m) einhalten ... ggf. temporär mehrere HM-Interfaces bis auf das nächste/beste/geeignetste deaktivieren ...
-33 dB rssi sind schon ziemlich "laut", irgendwas um -50 wäre optimal.

Jm2c...

[martinp876]

1) FHEM hat die Config message erhalten und die Channels angelegt. Das bitte nicht entfernen/löschen. Das muss immer wieder gemacht werden. Wenn es erledigt ist, wird das timing nicht schlechter
2) Vor dem nächsten Pairen wie vorab beschrieben ein  "clear msgEvents" machen. Es sollte zwar automatisch gemacht werden.... Damit wird verhindert, dass sich alte messages "vordrängeln"
3) Die Reihenfolge NICHT ändern. Erst muss FHEM bereit sein. Also ein "pairForSec" auslösen, dann am Device config (also boost lange drücken). Drückt man boost zu kurz, zurück nach 2). (FHEM würde evtl auf das Boost reagieren)

Also fast wie bei Pfriemler
Wenn es nicht klappt die rohmessages aufzeichnen - siehe sniffen.

[Pfriemler]

... "clear msgEvents" machen. Es sollte zwar automatisch gemacht werden....

Hm. Ernstlich? Woher soll die vccu wissen, welches Gerät ich gerade neu pairen will (bei hmPairForSec)? Dass messages verworfen werden, wenn mit hmPairSerial gearbeitet wird, wäre n.m.b.M. nur hier zu erwarten.

... Die Reihenfolge NICHT ändern.

Theoretisch ja. Vor allem wenn das Gerät noch nicht angelegt ist. Praktisch sind meine Erfahrungen leider anders ... und jeder Versuch einer Nachstellung ist von vornherein zum Scheitern verurteilt ... 
Für jede Form von Konfigurationsmitteilung nach dem Pairen ist die Reihenfolge "erst FHEM, dann Konfigtaste" natürlich unverzichtbar. Wobei man beim RT-DN allerdings lieber warten sollte, bis er sich von allein wieder meldet.

[martinp876]

Hm. Ernstlich? Woher soll die vccu wissen, welches Gerät ich gerade neu pairen will (bei hmPairForSec

Ganz einfach. Das, welches die config msg gesendet hat.
Pairforsec mode einstellen
Config empfangen, stack löschen, pairing msgs in die queue. Los gehts.

Wenn du config auslöst und fhem ist nicht bereit wird pairing nicht gesendet. Period!
Sollte es dennoch funktionieren ist etwas ganz anderes passiert. Du hast irgendwann vorher die korrekte reihenfolge eingehalten und das device ist schon gepairt. Maximale könnte die pairing msgs noch in der Q sein. In jedem Fall löst die config msg das abarbeiten der Q aus, da fhem damit u.a. signalisiert bekommt, dass das device bereit ist zum kommunizieren. Bspw kann dann die getConfig sequenz welche voraussichtlich i der Q ist abgearbeitet werden.

Das config auslösen ist also ok. Ein burstxmit hätte möglicherweise das gleiche erreicht. Oder auch einfach 5min warten.

Die Symptome deuten darauf hin. Die systematik schliesst es aber aus.

[Papaloewe]

Versuch mal einfach den Abstand zum HMFUNK Device zu vergrößern..
Das ist kein Witz!
Ich hatte auch Probleme, weil der Abstand zu gering war!
Zu guter Empfang war eindeutig schuld 

[Erich Fromm]

Hallo zusammen.

Ich habe gerade genau einen Versuch nach folgendem Hinweis von martinp876 durchgeführt. Danke hierfür.

1) FHEM hat die Config message erhalten und die Channels angelegt. Das bitte nicht entfernen/löschen. Das muss immer wieder gemacht werden. Wenn es erledigt ist, wird das timing nicht schlechter
2) Vor dem nächsten Pairen wie vorab beschrieben ein  "clear msgEvents" machen. Es sollte zwar automatisch gemacht werden.... Damit wird verhindert, dass sich alte messages "vordrängeln"
3) Die Reihenfolge NICHT ändern. Erst muss FHEM bereit sein. Also ein "pairForSec" auslösen, dann am Device config (also boost lange drücken). Drückt man boost zu kurz, zurück nach 2). (FHEM würde evtl auf das Boost reagieren)

Direkt nach dem langen Drücken der Boost Taste hatte ich im Display des Geräts ein "AC".

Danke Euch allen für Eure Hilfe.

Grüße,
Erich

[UweUwe]

Der Hinweis hat mich weitergebracht. Ich möchte es aber noch etwas detailierter beschreiben:

Homematic LAN via hmPairForSec in Pairing Modus versetzen.  ==>  korrekt
Boost Taste gedrückt halten.  ==> korrekt
Der 30 Sekunden Countdown läuft durch.  ==> falsch, zu kurz gedrückt, man muss , nachdem die 30 im disolay erschienen ist, den Finger auf der Boost Taste belassen bis die Anzeige "AC" erscheint"
In FHEM wird ein neues Device angelegt.  ==> korrekt
Das neue Device bleibt mit protState: CMDs_pending stehen und das Reading Activity geht über zu dead.  ==> dies passiert dann nicht, es wird korrekt gepairt
Am HM-CC-RT-DN Funk-Heizkörperthermostat ist kein Antennensymbol zu sehen   ==> Antennensymbol wird angezeigt

Vielen Dank für die Vorarbeit. Dies ist auch im Manual des Thermostatventils nicht so beschrieben, dass ich es verstehe.

[JWRu]

Ich habe einige Zeit rumprobiert, bis ich diesen Thread gefunden habe.
Bei mir hat's folgendermaßen funktioniert:

1. VCCU hmPairForSec ...
2. Boost Taste 3 Sekunden drücken.
3. Countdown 30...0 läuft am Themostaten -> kein AC im Display
4. In FHEM wird bei aktiviertem autocreate ein Device angelegt, aber Reading R-pairCentral steht auf "set_0x..." und "CMDs_pending"
5. Für das Device ein clear msgEvents ausführen.
6. Erneut VCCU hmPairForSec ...
7. Boost Taste nochmal 3 Sekunden drücken.
8. Countdown zählt runter, bis im Display "AC" erscheint.
9. Pairing ist abgeschlossen, alles ok.

[nofhem]

Hallo,
so hat es bei meinem LAN Gateway eQ3-HM-LGW funktioniert: 
1. GW hmPairForSec ...
2. Boost Taste 3 Sekunden drücken.
3. Countdown 30...0 läuft am Themostaten -> kein AC im Display
4. In FHEM wird bei aktiviertem autocreate ein Device angelegt, aber Reading R-pairCentral steht auf "set_0x..." und "CMDs_pending"
5. Für das Device ein clear msgEvents ausführen.
6. Erneut GW hmPairForSec ...
7. Boost Taste nochmal 3 Sekunden drücken.
8. Countdown zählt runter, bis im Display "AC" erscheint.
9. Pairing ist abgeschlossen, alles ok.

Dank an JWRu, war schon am verzweifeln.

Gruß
Norbert