CCU3: Sporadische BidCos-RF-Verzögerungen, STICKY_UNREACH und verwaister XML-RPC-Subscriber (192.168.188.181)

[StefJo]

**CCU3: Sporadische BidCos-RF-Verzögerungen, STICKY_UNREACH und verwaister XML-RPC-Subscriber (192.168.188.181)**

Hallo zusammen,

ich versuche seit einiger Zeit eine sporadische Verzögerung in meiner CCU3-Installation zu analysieren und bin inzwischen an einem Punkt angekommen, an dem ich auf Expertenwissen hoffe.

**System:**

* CCU3
* Home Assistant Green mit Homematic(IP) Local Integration
* früher Home Assistant auf Raspberry Pi
* Umzug auf Home Assistant Green per Backup-Restore

**Beobachtung:**

Die Verzögerungen treten seit einigen Wochen sporadisch auf. Einen konkreten Auslöser konnte ich nicht identifizieren. Zeitlich könnte ein Zusammenhang mit dem Umzug von Home Assistant auf einen HA Green (Backup-Restore vom Raspberry Pi) bestehen, sicher belegen kann ich das aber nicht.

Die VErzögerungen dauern zwischen wenigen Sekunden und Minuten.

In der CCU3 erscheint dauerhaft folgender Fehler:

```
XmlRpcClient error calling event(...)
on http://192.168.188.181:2059/RPC2

XmlRpc transport error
```

Zusätzlich:

```
netstat -anp | grep 2059

tcp 0 1 192.168.188.165:xxxxx 192.168.188.181:2059 SYN_SENT 812/rfd
```

Die Adresse 192.168.188.181 existiert im Netzwerk nicht mehr.

Ping auf .181 ergibt:

```
100% packet loss
```

Home Assistant läuft heute auf einer anderen IP-Adresse.

In den HA-Konfigurationsdateien und der Entity-/Device-Registry konnte ich bisher keinen Verweis auf .181 finden.

Daher vermute ich eine alte XML-RPC-Registrierung aus der Zeit des Raspberry Pi.

**Symptome:**

Die CCU3 ist nicht ausgelastet:

* CPU meist 95–98 % idle
* Load Average meist nahe 0
* ausreichend RAM frei

Trotzdem treten gelegentlich Verzögerungen auf.

Auffällig ist:

* nicht immer dasselbe Gerät betroffen
* verschiedene BidCos-RF-Aktoren betroffen
* HM-LC-Sw1-PCB
* HM-LC-Sw2-FM
* verschiedene Tasterkanäle

Im Log sehe ich gelegentlich:

```
setValue failed
STICKY_UNREACH true
```

bei unterschiedlichen Geräten.

Ein HM-PB-6-WM55 zeigte zudem einmal eine rote statt grüne LED, obwohl der Aktor letztlich geschaltet hat.

**Fragen:**

1. Kann ein verwaister XML-RPC-Subscriber im rfd tatsächlich zu solchen sporadischen Verzögerungen führen?

2. Ist bekannt, dass rfd bei jedem BidCos-RF-Event auf den nicht mehr existierenden Subscriber wartet und dadurch Kommunikationsfenster verpasst werden können?

3. Gibt es eine dokumentierte Möglichkeit, alte Callback-Registrierungen aus rfd zu entfernen?

4. Wo werden diese Registrierungen gespeichert?

5. Ist ein manuelles Entfernen möglich oder muss man rfd/ReGa neu initialisieren?

6. Kennt jemand das Kennzeichen

`nr_Bz0p9l_BidCos-RF`

und weiß, wie man die zugehörige Registrierung auflösen kann?

7. Ist `nr_Bz0p9l_BidCos-RF` eine vom rfd erzeugte Subscriber-ID bzw. XML-RPC-Callback-ID oder stammt dieser Name ursprünglich vom registrierenden Client (z.B. Home Assistant)?

8. Falls es sich um eine alte Home-Assistant-Registrierung handelt: Gibt es eine Möglichkeit, die aktuell in rfd registrierten XML-RPC-Subscriber vollständig aufzulisten, um zu prüfen, welche Callback-Ziele derzeit überhaupt bekannt sind?

9. Kann man die Zuordnung

`nr_Bz0p9l_BidCos-RF → 192.168.188.181:2059`

irgendwo direkt einsehen oder gezielt löschen?

10. Gibt es bekannte Fälle nach einem Home-Assistant-Umzug (Raspberry Pi → neuer Host per Backup-Restore), bei denen alte XML-RPC-Registrierungen in der CCU3 zurückgeblieben sind?

11. Kann ein verwaister Subscriber dazu führen, dass bei unterschiedlichen BidCos-RF-Geräten sporadisch

* `setValue failed`
* `STICKY_UNREACH`
* rote LED am HM-PB-6-WM55 trotz erfolgreicher Schaltung

auftreten, obwohl die Geräte selbst gut erreichbar sind und die CCU3 praktisch keine CPU- oder Speicherlast zeigt?

Beispiel aus dem Log während einer beobachteten Verzögerung:

06:35:19
OEQ0163730:1 PRESS_SHORT

HSSParameter::SetValue() true Put failed

XMLRPC 'setValue' call failed
params: {"NEQ1631095:1","STATE",true}

06:35:52
STICKY_UNREACH true

Der betroffene Aktor war in diesem Fall ein HM-LC-Sw1-PCB.
An anderen Tagen waren jedoch andere BidCos-RF-Aktoren betroffen, weshalb ich aktuell nicht von einem einzelnen defekten Gerät ausgehe.

12. Würdet ihr die Ursache eher auf den verwaisten Subscriber eingrenzen oder sprechen die sporadischen setValue failed / STICKY_UNREACH Meldungen bei unterschiedlichen BidCos-RF-Geräten eher für ein separates Funk- oder rfd-Problem?

Über Hinweise zur internen Verwaltung von XML-RPC-Registrierungen, zur Interpretation des Eintrags nr_Bz0p9l_BidCos-RF sowie zur Bewertung der beobachteten setValue failed / STICKY_UNREACH Meldungen würde ich mich besonders freuen. Jeder technische Hinweis oder Erfahrungsbericht könnte mir helfen da ich leider nicht mehr weiterkomme .

Vielen Dank!

Stefan

[Baxxy]

Die RPC-Subscriber werden nicht gespeichert. Sie müssen sich nach jedem Zentralen-Start erneut registrieren.

Für mich sieht das wie eine NodeRed-Instanz aus wo die ccu-connection mit einer statischen (Callback)Adresse konfiguriert ist.

[StefJo]

Vielen Dank für die Hinweise!

Ich denke, ich bin damit der Ursache deutlich näher gekommen.

Die entscheidende Spur war der Hinweis auf Node-RED.

In Home Assistant war tatsächlich noch das Node-RED Add-on installiert. In der Konfiguration der ccu-connection habe ich folgende Einstellungen gefunden:

CCU address: 192.168.188.165

Init address: 192.168.188.181

XMLRPC listening port: 2059

BidCos-RF aktiviert

Die IP 192.168.188.181 stammt noch von einer früheren Installation (Raspberry Pi) und existiert heute nicht mehr.

Nach dem Stoppen des Node-RED Add-ons zeigt die CCU nun:

* keine Verbindungen mehr nach 192.168.188.181:2059
* keine Meldungen mehr mit nr_Bz0p9l_BidCos-RF
* sauberes Log ohne die bisherigen XmlRpc transport errors

Zusätzlich sind die zuvor sporadisch auftretenden Verzögerungen bislang nicht mehr reproduzierbar.

Das spricht aktuell sehr stark dafür, dass die verwaiste Node-RED-CCU-Connection mit der alten Callback-Adresse die Ursache war.

Meine aktuelle Vermutung:

Node-RED hat sich nach jedem Start korrekt als XML-RPC-Subscriber registriert, allerdings mit der nicht mehr existierenden Callback-Adresse 192.168.188.181:2059. Die CCU hat deshalb bei jedem Event versucht, diesen Subscriber zu erreichen und ist regelmäßig in Timeouts gelaufen.

Interessant finde ich dabei, dass die Symptome nicht nur auf virtuelle Geräte beschränkt waren, sondern sich teilweise auch durch verzögerte Schaltungen, STICKY_UNREACH-Meldungen und einmal sogar durch eine rote LED-Rückmeldung an einem HM-PB-6-WM55 bemerkbar gemacht haben.

Ich werde Node-RED nun entweder dauerhaft deaktivieren oder die CCU-Connection auf die aktuelle HA-Adresse umstellen und anschließend weiter beobachten.

Vielen Dank für die schnelle und kompetente Rückmeldung!!! Ohne den Hinweis auf Node-RED wäre ich wahrscheinlich weiter in Richtung CCU, BidCos-RF oder Aktoren gesucht.

[Baxxy]

Sehr gut.
Normalerweise sollte die Zentrale "tote" Subscriber rauskicken. Da dein NodeRed aber nicht tot war sondern sich (vermutlich) regelmäßig gemeldet hat (aber mit falscher Adresse) hat die Zentrale munter weiter versucht die Events zuzustellen.
Dabei kommt es dann zum "Datenstau" mit den Symptomen die du beobachtet hast.

Wenn du auf die Node-RED-CCU-Connection verzichten kannst dann tu das am besten auch.
Vor allem wenn du deine Zentrale auch per "Homematic(IP) Local for OpenCCU" in den HA integriert hast.