HM-CC-RT-DN pairing funktioniert nicht.

[schmadde]

Ich wollte mein Setup mit bisher 4x HM-CC-RT-DN und diversen weiteren Homematic Geräten um vier weitere HM-CC-RT-DN erweitern. Dazu hatte ich vor ca. 1 Jahr mal 4 gebrauchte Thermostate gekauft und gestern erst versucht, sie in Betrieb zu nehmen.

Ich habe eine VCCU definiert die aus 1 HMLAN und 1 LGW besteht und nach einem Reset der Thermostate (nach Batterieeinlegen alle drei Tasten drücken bis "res" erscheint) die VCCU auf hmPairForSec <Sekunden> gesetzt und die mittlere Taste für 3 Sekunden gedrückt.

Beim ersten Gerät hat das Pairen problemlos funktioniert - bei den drei weiteren erkennt er zwar das Gerät, bleibt aber im STATE "CMDs_pending" hängen und zeigt keine Readings an. Readings sehen so aus wie im screenshot - also ausser FW-Release und Serialno nix. Firmware ist 1.5 bei allen 4 und 1.3 bei den alten.

Wie kann man die Geräte mit fhem erfolgreich pairen (die Einrichtung der alten ist sicher schon 7 Jahre her)?

Ich liefere gerne mehr logs, wenn Ihr mir sagt, welche gebraucht werden.

[Beta-User]

Klingt ähnlich wie im "Nebenthread" (warum nicht darauf Bezug nehmen und zumindest die Basisfragen beantworten?!?):

a) CUL_HM&Co ist aktuell?
c) commStInCh [...]?

Der Reihe nach: Aktuelle Module sind Pflicht, [...]
Wenn mit den aktuellen Modulen dann die Kommunikation zu einzelnen Devices nicht klappt, ist das meistens ein Timing-Thema, häufig verursacht durch sehr viele unnötige Events.

Die Infos zur Funkverbindung an die beiden IO's wären vermutlich auch noch interessant, ebenso, ob die VCCU wirklich funktional ist (wir hatten in letzter Zeit einige "kaputte").

[schmadde]

Ein uppate habe ich grade erst gemacht - dass sowohl das HMLAN als auch das HMUARTGW laufen hab ich verifiziert, sollte allerdings eh klar sein, da ja 19 Homematic Geräte problemlos funktionieren unter anderem auch 5 HM-CC-RT-DN, einer davon mit der selben Firmware vom selben ebayer gekauft.

Die vier "neuen" Thermostate sind alle im selben Raum eingerichtet worden, nicht weit vom HMUARTLGW - einer funktioniert, die anderen nicht.

Welche Infos genau bzgl. Funkverbindung kann ich liefern und wo finde ich die? RSSI gibts natürlich nicht, weil ja das Gerät nicht ausgelesen wird.

Deviceinfo ist wie folgt:

 Device name:HM_3F7182
   org ID      :0095  Model=HM-CC-RT-DN
   alias ID    :0095  Model=HM-CC-RT-DN
   mode      :config,wakeup,burstCond
   protState   : CMDs_pending pending: none

   HM_3F7182_Weather    state:
   HM_3F7182_Climate    state:
   HM_3F7182_WindowRec    state:last:trigLast
   HM_3F7182_Clima    state:
   HM_3F7182_ClimaTeam    state:
   HM_3F7182_remote    state:
 configuration check: updating

[schmadde]

Ich hab jetzt auf allen nochmal den Pairing Knopf gedrückt und direkt am LGW pairforsec getriggert. Einer von den dreien geht jetzt und zeigt alle Readings korrekt an die anderen beiden (liegen direkt daneben) haben ein paar Internals mehr (u.a. jetzt jeder auch ein RSSI) aber noch keine Readings. Ich warte jetzt mal ab, ob die sich irgendwann nochmal fangen. Oder sollte ich nochmal pairen versuchen? Nur am Device oder auch am lan gateway oder an der vccu?

rssi_at_HMLAN1     cnt:2 min:-75 max:-74 avg:-74.5 lst:-75
rssi_at_meinLGW.   cnt:2 min:-78 max:-53 avg:-65.5 lst:-78

[Beta-User]

Ich warte jetzt mal ab, ob die sich irgendwann nochmal fangen.

Das ist meistens eine gute Idee.

Oder sollte ich nochmal pairen versuchen? Nur am Device oder auch am lan gateway oder an der vccu?

Das kannst du auch versuchen. Immer an der vccu, und wenn, dann vorher dafür sorgen, dass nichts mehr "pending" ist (clear-Befehl).

rssi_at_HMLAN1     cnt:2 min:-75 max:-74 avg:-74.5 lst:-75
rssi_at_meinLGW.   cnt:2 min:-78 max:-53 avg:-65.5 lst:-78

Klingt soweit ok, der 2. min-Wert ist irritierend niedrig, kann aber ok sein, wenn das Ding irgendwie bewegt wurde (Empfang müßte trotzdem gehen).

Nachtrag: Das Stichwort "Code-Tag" sagt dir was?

[schmadde]

Ich habe nun alle nochmal einzeln an jedem LAN Gateway gepairt, dann ging es praktisch sofort. Schon komisch, aber ich betreibe jetzt keine Ursachenforschung mehr, bin froh, dass es jetzt geht.

[Beta-User]

...na dann...
[gelöst]?

Ansonsten würde ich unabhängig von gelöst nochmal das Stichwort "commStInCh" in den Raum werfen .

[schmadde]

Was ist das? Ich konnte nichts zu commStInCh finden - weder in google noch im FHEM Wiki

[Beta-User]

Was ist das? Ich konnte nichts zu commStInCh finden - weder in google noch im FHEM Wiki

...es steht z.B. in dem verlinkten Thread, den ich dir ganz am Anfang zur Lektüre anempfohlen hatte...

[schmadde]

...es steht z.B. in dem verlinkten Thread, den ich dir ganz am Anfang zur Lektüre anempfohlen hatte...

Ja, da steht es auch. Es steht aber nirgends was das bedeutet und was es tut. Oder ich sehe es einfach nicht.

EDIT: o.k. es gibt eine kurze Erklärung wenn man versucht das Attribut in der VCCU zu setzen. So recht schlau werde ich nicht draus aber mal probieren...

[Beta-User]

Es wurde leider bisher versäumt, eine Erklärung dazu in die commandref aufzunehmen.

Es geht dabei (wie nach der Lektüre der Ausführungen in dem anderen Thread vermutlich nicht wirklich überraschend sein sollte) um die allgemeine Frage, wie viele Events erzeugt werden und ob die alle nötig sind. Speziell dieses Attribut (genauer: dessen default, wenn nicht gesetzt) sorgt dafür, dass seit einiger Zeit auch die Kanal-Devices Events werfen, was also bei einem RT für jedem Mist 6 zusätzliche Events bedeutet.

Siehe dazu vielleicht noch https://forum.fhem.de/index.php/topic,120240.0.html.