hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?

[maduuto]

Hallo. Urplötzlich konnte hm-rpc keine Verbindung aufbauen, was ich nur gemerkt habe weil ein Skript hätte anlaufen müssen. Blöderweise habe ich die Logfile gelöscht. Nun versuche ich aber das einzuschränken. Was ich allgemein gemerkt habe, wenn hmrpc abstürzt, kann ich es erst wieder verbinden, wenn ich javascript stoppe.

Meine Vermutung, dass einer meiner Skripte einen üblen Anfragensturm an die CCU sendet, z.b. aktor immer ausschalten, ausschalten, ausschalten obwohl aus. Frage: Kann ich das Rausfiltern, was Javascript ständig macht?

Nun habe ich RPC auf Debug und bekomme im Sekundentakt eine Meldung ähnlicher Art:
hm-rpc.0.00175A498C5CBA.6.STATE ==> UNIT: "undefined" (min: undefined, max: undefined) From "false" => "false"

Ist nicht immer der gleiche Aktor. Hat die Meldung was zu sagen oder irrelevant?

Danke
MfG

[MarkusK]

@maduuto Ich habe auch seit geraumer Zeit (entweder nach Update der CCU3 oder des RPC Adapters) Probleme mit dem Adapter. Bei mir Crashed ein Prozess in der CCU3, welcher Verbindungen annimmt. Das geht soweit, dass man in der CCU3 keine Einstellungen mehr an den virutellen Gerätem mehr machen kann (z.B. in der Gruppen). Außerdem meldest die CCU3 kurz nach dem Login eine internen Fehler. Gelöst bekommt man das Problem nur wenn man die CCU3 neu startet und den RPC Adapter abschaltet. Aktuell kann ich den Adapter deshalb leider nicht mehr nutzen. EQ-3 (Homematic) schiebt den Fehler auf den IOBroker, bzw. sagen, die unterstüzten Fehler durch externe Software nicht. Ich habe bereits bei GIT-Hub einen Fehler bei dem Adapter aufgemacht.

[MarkusK]

@maduuto Ich habe jetzt die auf der CCU3 die Version 3.65.11 installiert und parallel die Abfrageintervalle und Timeouts beim Adapter verdoppelt, wobei die Timeouts sicherlich keine Rolle spielen. Es läuft auch nach einem Tag noch und die CCU3 bringt im moment auch keine Fehlermeldung. Teile der CCU3 stürzte wieder nach über ein Tag ab. Gruppen ließen sich aufgrund eines "internen Fehlers" wieder nicht bearbeiten.
Ich habe in den Releasenotes der CCU3 Firmwares gesehen, dass an der Version bevor ich die Probleme bekommen habe zur darauffolgenden Version mit dem Problem am crashenden rfd Deamon Änderungen gemacht wurden. Das könnte natürlich Fehler reingebracht haben. Allerdings gab es in den darauffolgenden Releasenotes keine Hinweise auf den Bug oder einem möglichen Fix.

Scheinbar werden aber jetzt die Datenpunkte trotz laufender Instanzen nicht mehr regelmäßig aktualisiert. Eine Aktualisierung findet nur noch beim Instanzenstart statt. Debug bringt keine relevanten Infos.

Edit:

[Piemur]

Das Verhalten kann ich bestätigen.
Schalte ich den HM-RPC.0 RFD (XML-RPC) Port 42001 dazu, stürzt meine CCU3 kurz danach ab.
Die Instanz selbst ist "grün" und das Protokoll unauffällig.

HM-RPC.0 HM-IP (XML-RPC) ist grün, aber Geräte in den Objekten sind angelegt, allerdings finde ich nur im Kanal0 Datenpunkte.
Alle anderen sind leer.

[Homoran]

@piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

HM-RPC.0 HM-IP (XML-RPC) ist grün, aber Geräte in den Objekten sind angelegt, allerdings finde ich nur im Kanal0 Datenpunkte.
Alle anderen sind leer.

auch hm-rpc.0? selbe Instanz für RF undIP?
Das geht nicht!

[Piemur]

@homoran Nein, sorry hab mich gestern abend vertippt. Bin neu hier und hab mich grad erst gestern registriert.
Aber danke für den Hinweis

Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports
hm-rpc.0 RFD (XML-RPC) auf Port 42001
hm-rpc.1 HomeMaticIP (XML-RPC) auf Port 42010
hm-rpc.2 CuxD (BIN-RPC) auf Port 8701
hm-rpc.3 VirtualDev auf Port 49292
Ports sind in der CCU3 (3.65.11) freigegeben und die ioBroker-IP/WinLaptop ebenfalls.
(CCU-Firewall: Ports blockiert, alles andere eingeschränkt, Ports freigegeben, 3x IPs freigegen IP/WinLaptop, CCUselbst und fritzbox)
Die CallBack-Id sind auf IObroker WinLaptop (hab leider keinen RapsberryPi mehr bekommen)

Alle Instanzen hm-rpc.1-3 werde bei Start auch "grün", von da her sollte es passen.

IM hm.rega.0 sind die Instanzen konfiguriert und aktiviert.
Wenn ich hm.rega.0 alleine laufen lasse oder mit hm-rpc.1-3, hängt sich die CCU3 nicht auf.

Schalte ich hm-rpc.0 dazu, hängt sich die CCU auf. (Schön zu sehen, wenn auf der Startseite der CCU3 keine Firmware Version angezeigt wird. Hier hilft nur ein Reset der CCU3
Im Protokoll hm-rpc.0 wird die Verbindung gestartet, mal kommt ein Connect mal nicht,
je nachdem wann sich die CCU aufhängt.

Wie gesagt, das passt zu dem beschriebenen Fehlerbild und ich wollte es bestätigen.

Warum mir keine Datenpunkte unter hm-rpc.1 angezeigt werden (nur Kanal 0, von hm.rega.0 geschrieben) ist, denke ich ein anderes Thema. Hierzu bin ich noch am suchen, aber da rpc.0 meine CCU aufhängt, hab ich noch keine Idee woran dies liegen kann.

[Homoran]

@piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports

bitte zeigen!
https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1

@piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

Alle Instanzen hm-rpc.1-3 werde bei Start auch "grün", von da her sollte es passen.

nicht unbedingt.
Instanz (!) auf debug stellen und neu starten.

@piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

Schön zu sehen,

auch im syslog der ccu?

@piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

denke ich ein anderes Thema.

achso. das wollte ich eigentlich gerade angehen

[bahnuhr]

@piemur sagte in hm-rpc unerklärliche Abstürze, evtl zu hohes Anfragevolumen?:

Meine Instanzen sind soweit IO eingestellt und ich verwende die Standard-Ports
hm-rpc.0 RFD (XML-RPC) auf Port 42001
hm-rpc.1 HomeMaticIP (XML-RPC) auf Port 42010
hm-rpc.2 CuxD (BIN-RPC) auf Port 8701
hm-rpc.3 VirtualDev auf Port 49292

Standard Ports sind dies aber nicht.
Lt. Anleitung:

Folgende Fragen:
warum https?
cuxd auf 8701 dürfte nicht funktionieren (vgl. Anleitung)

Und das Übliche:
screenshot von:

• ccu3 mit Original FW oder raspberrymatic
• firewall von ccu
• hm-rega
• alle hm-rpc

weiter:
hast du viele Scripts auf der ccu3 (gab früher mal Probleme), etc.

Einfach halten: Standard Ports, etc.
Aus meiner sicht gab es seit mehreren jahren keine Probleme mit ccu2 oder ccu3 und hm-rega, etc.
(wenn man es richtig einstellt).

Und zu guter letzt; das was @Homoran schon schrieb:
https://forum.iobroker.net/topic/51555/hinweise-für-gute-forenbeiträge/1