Node-Red stützt ab wenn CCU nicht erreichbar

Node-RED als CCU3/RaspberryMatic Addon, WebApp, HomeKit, ...

Moderator: Co-Administratoren

Antworten
dewenni
Beiträge: 30
Registriert: 09.12.2019, 19:54
Hat sich bedankt: 1 Mal
Danksagung erhalten: 4 Mal

Node-Red stützt ab wenn CCU nicht erreichbar

Beitrag von dewenni » 20.11.2021, 08:42

Hallo,

ich habe seit kurzem ein Problem mit meiner Kombination von RaspberryMatic und einer getrennten Node-Red Installation im Docker auf dem NAS.
Das hat jetzt schon viele Monate prima funktioniert.

Aktuell gibt es aber ein Problem, dass Node-Red immer mal wieder abgestützt ist. Ich konnte lange keine Ursache oder Zusammenhang finden.
Leider hatte ich auch diverse Updates gemacht (Node-Re, Nodes, CCU, Netzwerkkomponenten, etc)

Heute ist mir aber ein Zusammenhang klar geworden. Die CCU war aufgrund eines Netzwerkproblems nicht erreichbar.
Ab dem Zeitpunkt ist Node-Red dann zyklisch gebootet und abgestürzt mit folgendem Log

Code: Alles auswählen

[red] Uncaught Exception:
[error] Error: read ETIMEDOUT
	at TCP.onStreamRead (internal/stream_base_commons.js:209:20)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! node-red-docker@2.1.3 start: `node $NODE_OPTIONS node_modules/node-red/red.js $FLOWS "--userDir" "/data"`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the node-red-docker@2.1.3 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
Es scheint also so, dass Node-Red abstürzt wenn es die Verbindung zu einer konfigurierten Gegenstelle verliert. Zumindest bei der CCU scheint das so zu sein. Das wundert mich schon.
Ich kann mir ja noch vorstellen, wenn es zu einem Fehler kommt wenn die Verbindung "unerwartet" und während einer laufenden Kommunikation abbricht. Aber danach hat Node-Red zyklisch gestartet und ist gleich nach dem Hochlauf wieder mit der Meldung abgestützt weil die CCU eben nicht erreichbar war.
Erst als die CCU wieder im Netzwerk war, lief auch Node-Red wieder.

Das ist vermutlich kein Problem wenn man Node-Red als "RedMatic" direkt auf der CCU laufen lässt, aber vielleicht hat das auch schon jemand anders beobachtet oder kann mir dennoch einen Hinweis geben wie man das in den Griff bekommt.

Danke und Grüße
Sven

ckohrt
Beiträge: 43
Registriert: 27.09.2018, 13:05
Hat sich bedankt: 2 Mal

Re: Node-Red stützt ab wenn CCU nicht erreichbar

Beitrag von ckohrt » 17.12.2021, 10:45

Hallo,
ist bei mir im Moment auch so - bin gerade über Deinen Thread gestolpert.

Meine Konfiguration (=deine Konfig):
* Aktuelle raspberrymatic auf Raspi3
* auf QNAP server läuft ein (latest) Node Red docker container mit CCU Erweiterungen

Leider stürzt der Container ab, und ich dachte es liegt evtl. am Docker Container. Fehlermeldung wie bei dir:

Code: Alles auswählen

[b]17 Dec 09:30:15 - [red] Uncaught Exception:
17 Dec 09:30:15 - [error] Error: read ETIMEDOUT
    at TCP.onStreamRead (internal/stream_base_commons.js:209:20)[/b]
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! node-red-docker@2.1.4 start: `node $NODE_OPTIONS node_modules/node-red/red.js $FLOWS "--userDir" "/data"`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the node-red-docker@2.1.4 start script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /data/.npm/_logs/2021-12-17T09_30_15_543Z-debug.log
Unter /share/CACHEDEV1_DATA/Container/container-station-data/lib/docker/volumes/NodeRedDashData/_data/.npm/_logs/2021-12-17T09_30_19_539Z-debug.log findet sich noch im Log:

Code: Alles auswählen

14 verbose stack Error: node-red-docker@2.1.3 start: `node $NODE_OPTIONS node_modules/node-red/red.js $FLOWS "--userDir" "/data"`
14 verbose stack Exit status 1
14 verbose stack     at EventEmitter.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/index.js:332:16)
14 verbose stack     at EventEmitter.emit (events.js:400:28)
14 verbose stack     at ChildProcess.<anonymous> (/usr/local/lib/node_modules/npm/node_modules/npm-lifecycle/lib/spawn.js:55:14)
14 verbose stack     at ChildProcess.emit (events.js:400:28)
14 verbose stack     at maybeClose (internal/child_process.js:1058:16)
14 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:293:5)
15 verbose pkgid node-red-docker@2.1.3
16 verbose cwd /usr/src/node-red
17 verbose Linux 4.14.24-qnap
18 verbose argv "/usr/local/bin/node" "/usr/local/bin/npm" "--no-update-notifier" "--no-fund" "start" "--cache" "/data/.npm" "--" "--userDir" "/data"
19 verbose node v14.18.1
20 verbose npm  v6.14.15
21 error code ELIFECYCLE
22 error errno 1
23 error node-red-docker@2.1.3 start: `node $NODE_OPTIONS node_modules/node-red/red.js $FLOWS "--userDir" "/data"`
23 error Exit status 1
24 error Failed at the node-red-docker@2.1.3 start script.
24 error This is probably not a problem with npm. There is likely additional logging output above.
25 verbose exit [ 1, true ]
Ich hab schonmal geschaut, aber ich finde keine Logs mit mehr Infos. Weder Docker, noch QNAP, noch Node Red.

Ich bin ratlos....
Wie ist es denn bei dir weiter gelaufen?

Für mich sieht deine Vermutung richtig aus, beim Senden geht was schief, also die CCU antwortet evtl. nicht und schwupps ist Node Red weg. Ich schau mal ob ich ein CUXD Log irgendwo finde...

VG
Christian

ckohrt
Beiträge: 43
Registriert: 27.09.2018, 13:05
Hat sich bedankt: 2 Mal

Re: Node-Red stützt ab wenn CCU nicht erreichbar

Beitrag von ckohrt » 18.12.2021, 20:08

Hat niemand eine Idee?

Zwischenzeitlich hab ich die Kommunikation zwischen Node-Red und der CCU so weit reduziert wie möglich, stürzt aber immer noch ab....

ckohrt
Beiträge: 43
Registriert: 27.09.2018, 13:05
Hat sich bedankt: 2 Mal

Re: Node-Red stützt ab wenn CCU nicht erreichbar

Beitrag von ckohrt » 20.12.2021, 00:48

Ich konnte eine Verbesserung erreichen, indem das "Rega poll interval (s)" des CCU Konfigurations-Node auf 60s gestellt habe. Ich teste gerade noch, aber seit Umstellung gestern kein Absturz mehr. Verdächtig auch, dass ich nichts in den Protokollen finden konnte. So ein Poll Intervall, wenn es denn zuschlägt, sollte eigentlich eine Nachricht hinterlassen, aber er weiß....
Ich gehe davon aus, dass es das wohl nicht tut und damit auch erklärt ist warum ich keine Fehler im log finde.
Das Verhalten der CCU Node ist meines Erachtens ein Bug, es darf deswegen nicht Node red abstürzen.
In einem Docker Container ist das natürlich 2 mal dumm, weil ich zumindest auf der QNAP kein crash recovery habe, also manuell den Container starten muss.

VG
Christian


ckohrt
Beiträge: 43
Registriert: 27.09.2018, 13:05
Hat sich bedankt: 2 Mal

Re: Node-Red stützt ab wenn CCU nicht erreichbar

Beitrag von ckohrt » 10.01.2022, 14:15

Hier noch mein aktueller Stand aus Git:

Hallo,
ich habe nun mein System nochmal angeschaut, hier kam ja leider keine weitere Antwort. Aber für evtl. weitere Fälle hier mein aktueller Stand.

Es sieht so aus, dass bei mir schlicht zu viel Kommunikation stattgefunden hat, sodass nicht immer ein RPC durchgeführt werden konnte, was dann zum Abruch führt. Daher hab ich die jeweiligen Hommatik Skirlt Programme um die Zeilen:

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:1.SYSLOG").State("MyProgramName: Wurde am "#system.Date("%d.%m.%y %H:%M Uhr") #" ausgefuehrt.");
bzw.

Code: Alles auswählen

dom.GetObject("CUxD.CUX2801001:1.SYSLOG").State("MyProgramName: Wurde am "#system.Date("%d.%m.%y %H:%M Uhr") #" beendet.");
ergänzt. Damit konnte ich im CUX Log sehen, welche Programme oft ausgeführt werden.
Diese habe ich dann soweit reduziert, dass die Kommunikationslast reduziert wurde. Zudem hatte ich ja noch den Timeout von CCU-Node-Red Konfig sehr weit hoch gesetzt. Die letzten Tage hatte ich keine Abbrüche mehr.

VG
Christian

PatrickM2201
Beiträge: 9
Registriert: 13.01.2017, 08:43

Re: Node-Red stützt ab wenn CCU nicht erreichbar

Beitrag von PatrickM2201 » 12.01.2022, 22:15

Hallo zusammen,

ich habe das selbe Problem, dass meine getrennte Node-Red-Installation abstürzt, wenn keine Verbindung zu CCU hergestellt werden kann.
Node-Red läuft bei mir in einem Debian Container (LXC) auf einem auf einem Proxmox-Server, die CCU wird auf einem Raspi 4 mit Raspberrymatic betrieben.

Ich bin aktuell in der Umstellung von Redmatic (auf dem o.g. Raspi 4 mit Raspberrymatic) auf die getrennte Node-Red-Instanz. Nachdem ich nun die Überwachung der Node-Red-Instanz implementiert habe, ist mit das von euch beschriebene Verhalten auch aufgefallen.

Hier der Auszug aus dem Syslog des Node-Red-LXC, in diesem Beispiel habe ich die CCU neugestartet.

Code: Alles auswählen

an 12 10:06:39 Node-Red Node-RED[4600]: 12 Jan 10:06:39 - [error] [ccu-connection:Raspberrymatic]     < CUxD ping Error: response timeout
Jan 12 10:06:39 Node-Red Node-RED[4600]: 12 Jan 10:06:39 - [info] [ccu-connection:Raspberrymatic] Interface CUxD disconnected
Jan 12 10:06:54 Node-Red Node-RED[4600]: 12 Jan 10:06:54 - [error] [ccu-connection:Raspberrymatic]     < CUxD ping Error: response timeout
Jan 12 10:07:00 Node-Red Node-RED[4600]: 12 Jan 10:07:00 - [info] [ccu-connection:Raspberrymatic] Interface ReGaHSS disconnected
Jan 12 10:07:00 Node-Red Node-RED[4600]: 12 Jan 10:07:00 - [error] [ccu-connection:Raspberrymatic] getRegaVariables Error: connect ECONNREFUSED 192.168.12.4:8181
Jan 12 10:07:00 Node-Red Node-RED[4600]: 12 Jan 10:07:00 - [error] [ccu-connection:Raspberrymatic] getRegaPrograms Error: connect ECONNREFUSED 192.168.12.4:8181
Jan 12 10:07:04 Node-Red Node-RED[4600]: 12 Jan 10:07:04 - [warn] [ccu-connection:Raspberrymatic] ping timeout CUxD 67
Jan 12 10:07:04 Node-Red Node-RED[4600]: 12 Jan 10:07:04 - [info] [ccu-connection:Raspberrymatic] init CUxD binrpc://192.168.12.201:2090 nr_MytSUE_CUxD
Jan 12 10:07:04 Node-Red Node-RED[4600]: 12 Jan 10:07:04 - [error] [ccu-connection:Raspberrymatic]     < CUxD init Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
Jan 12 10:07:04 Node-Red Node-RED[4600]: 12 Jan 10:07:04 - [error] [ccu-connection:Raspberrymatic]     < CUxD init Error [ERR_STREAM_DESTROYED]: Cannot call write after a stream was destroyed
Jan 12 10:07:04 Node-Red Node-RED[4600]: 12 Jan 10:07:04 - [error] [ccu-connection:Raspberrymatic] Cannot call write after a stream was destroyed
Jan 12 10:07:05 Node-Red Node-RED[4600]: 12 Jan 10:07:05 - [error] [ccu-connection:Raspberrymatic]     < BidCos-RF ping Error: connect ECONNREFUSED 192.168.12.4:2001
Jan 12 10:07:05 Node-Red Node-RED[4600]: 12 Jan 10:07:05 - [info] [ccu-connection:Raspberrymatic] Interface BidCos-RF disconnected
Jan 12 10:07:05 Node-Red Node-RED[4600]: 12 Jan 10:07:05 - [error] [ccu-connection:Raspberrymatic]     < BidCos-Wired ping Error: connect ECONNREFUSED 192.168.12.4:2000
Jan 12 10:07:05 Node-Red Node-RED[4600]: 12 Jan 10:07:05 - [info] [ccu-connection:Raspberrymatic] Interface BidCos-Wired disconnected
Jan 12 10:07:05 Node-Red Node-RED[4600]: 12 Jan 10:07:05 - [error] [ccu-connection:Raspberrymatic]     < BidCos-Wired ping Error: connect ECONNREFUSED 192.168.12.4:2000
Jan 12 10:07:11 Node-Red Node-RED[4600]: 12 Jan 10:07:11 - [red] Uncaught Exception:
Jan 12 10:07:11 Node-Red Node-RED[4600]: 12 Jan 10:07:11 - [error] Error: connect ECONNREFUSED 192.168.12.4:8701
Jan 12 10:07:11 Node-Red Node-RED[4600]:     at TCPConnectWrap.afterConnect [as oncomplete] (net.js:1138:16)
Jan 12 10:07:11 Node-Red systemd[1]: nodered.service: Main process exited, code=exited, status=1/FAILURE
Jan 12 10:07:11 Node-Red systemd[1]: nodered.service: Failed with result 'exit-code'.
Jan 12 10:07:11 Node-Red systemd[1]: nodered.service: Consumed 9.608s CPU time.
Jan 12 10:07:31 Node-Red systemd[1]: nodered.service: Scheduled restart job, restart counter is at 6.
Jan 12 10:07:31 Node-Red systemd[1]: Stopped Node-RED graphical event wiring tool.
Jan 12 10:07:31 Node-Red systemd[1]: nodered.service: Consumed 9.608s CPU time.
Jan 12 10:07:31 Node-Red systemd[1]: Started Node-RED graphical event wiring tool.
Jan 12 10:07:31 Node-Red Node-RED[4640]: 12 Jan 10:07:31 - [info]
Jan 12 10:07:31 Node-Red Node-RED[4640]: Welcome to Node-RED
Jan 12 10:07:31 Node-Red Node-RED[4640]: ===================
Nach etwas Testen konnte ich den Absturz von Node-Red bei einem Neustart der CCU verhindern, indem ich den RPC-Ping-Timeout im CCU-Connection-Config-Node von 60s auf 240s erhöht habe. In dieser Zeit schafft es die CCU neuzustarten, ohne dass der Connection-Node in einen Timeout läuft.
Ich muss mal sehen, ob ich den Timeout noch weiter erhöhe, um z.B. auch ein Neustart nach einem Update von Raspberrymatic abzufangen.

Meine aktuelle Vermutung ist, dass es ein Bug in "node-red-contrib-ccu" ist, und irgendwie der RPC-Timeout nicht richtig abgefangen wird. Leider kann ich aber den vermeintlichen Fehler in dem SW-Paket, mangels ausreichender Programmierkenntnisse, weder finden noch beheben.

Vielleicht helfen meine Infos aber anderen :-)
Wenn sonst jemand Ideen hat, gerne melden.

Danke
Patrick

Antworten

Zurück zu „RedMatic“