Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Andersmacher]

Systemdata	Bitte Ausfüllen
Hardwaresystem:	Pi 4B
Arbeitsspeicher:	8GB
Festplattenart:	SD-Karte
Betriebssystem:	Debian Buster
Node-Version:
Nodejs-Version:	12.22.4
NPM-Version:	6.14.14
Installationsart:	weiß ich nicht mehr, läuft aber von Anfang an stabil
Image genutzt:
Ort/Name der Imagedatei:

In meinem Netzwerk gibt es eine CCU2, die seit Jahren eigentlich problemlos läuft und auf der CUxD-"Geräte" eingerichtet sind.
Weiterhin einen Raspi 192.168.X.Y auf dem ioBroker ebenfalls problemlos läuft und auf dem u. a. eine rpc-Instanz für CUxD mit Protokoll BIN-RPC eingerichtet ist.
Ich habe vor kurzem festgestellt, daß die CCU2 in unregelmäßigen Abständen zu verschiedenen Tageszeiten alle paar Tage folgende Fehlermeldung an meinen Syslog-Server sendet:

ccu2 daemon.err cuxd[480]: sendbinrpc(192.168.X.Y:Z) connect(7s) Connection timed out

Für X, Y und Z stehen real die korrekten Werte aus meinem Netzwerk.

Bisher habe ich keine negativen Effekte auf die Funktion der CCU bzw. ioBroker feststellen können, würde jedoch gerne die Ursache der Fehlermeldung ermitteln/beheben, weil sie mein NAS, auf dem der Syslog-Server läuft, immer "unnötig" aufweckt.

Hätte jemand Hinweise für mich, um folgende Fragen zu klären?:

Müßte anstelle von BIN-RPC hier XML-RPC als Protokoll aktiviert werden?
Bedeutet die Fehlermeldung, daß die CCU 7s connected war und dann nach 7s ein timeout auftrat oder daß sie nach 7s connect-Versuch wegen timeout abbricht?
Was löst überhaupt den Befehl sendbinrpc auf der CCU aus?

Weder in den Protokollen (CCU, iobroker, Syslog) noch im Internet habe ich dazu weitere Infos gefunden.

Ich hoffe, ich habe alle wichtigen Details genannt.

[paul53]

@andersmacher sagte: Müßte anstelle von BIN-RPC hier XML-RPC als Protokoll aktiviert werden?

CUxD spricht nur BIN-RPC.

[Andersmacher]

@paul53 Dann ist diese Einstellung also schon ´mal richtig und ich kann sie als Fehlerquelle ausschließen. Danke!

[Andersmacher]

OK,... das scheint ja ein sehr spezielles Thema zu sein" (;-).

Ich frage ´mal anders:
Benutzt jemand im Zusammenhang mit ioBroker eine CCU(2) mit CUxD-"Geräten" und hat im Log (egal ob auf der CCU oder auf einem separaten SysLog-Server auch ab und zu sendbinrpc-Timeout-Meldungen, ähnlich wie:

ccu2 daemon.err cuxd[480]: sendbinrpc(192.168.X.Y:Z) connect(7s) Connection timed out

[Andersmacher]

@andersmacher Für den Fall, daß das irgendwann für jemanden hilfreich ist, oder doch noch jemand weitere Ideen daraus entwickeln kann:

Ich habe das weiter beobachtet aber bisher keinerlei Zusammenhang mit irgendwelchen Vorgängen im Netzwerk herstellen können.

Eine Idee von mir war, daß es mit Neuvergabe von IP-Adressen im LAN zu tun hat, weil ich dem Raspi via statischem DHCP eine IP-Adresse gegeben hatte. Das schließe ich inzwischen aus, da die Neuvergabe eigentlich regelmäßig nach einer bestimmten Anzahl von Tagen erfolgte, die Meldungen jedoch unregelmäßig und zu ganz anderen Zeiten kamen und die Meldungen auch weiterhin auftreten, obwohl der Raspi inzwischen eine feste IP-Adresse hat.

Gerade heute kam die Meldung um 4:47 Uhr. Daher schließe ich auch hohe Netzwerkbelastung als Ursache aus.

Die Syslog-Meldung taucht auch jedesmal im cuxd-Log auf, allerdings ändert sich die [480] von Zeit zu Zeit. Ich vermute, das ist eine Art "Instanz- oder Prozeßnummer", die durch Neustart der CCU2 neu vergeben wird.

Bedeutet die Fehlermeldung, daß die CCU 7s connected war und dann nach 7s ein timeout auftrat oder daß sie nach 7s connect-Versuch wegen timeout abbricht?

Da in jeder dieser Meldungen immer 7s drin steht und ich es seltsam fände, wenn der Abbruch einer bestehenden Verbindung immer nach exakt der gleichen Verbindungszeit aufträte, denke ich, daß die Meldung bedeutet, daß nach 7s connect-Versuch wegen timeout abgebrochen wird.
Da es nach einer solchen Meldung zeitnah keine weiteren gibt, scheint das (zu der jeweiligen Zeit) auch kein "Dauerproblem" zu sein.

Falls noch jemand Ideen oder Hinweise hat, sind sie mir herzlich willkommen.