mir ist nun schon seit ca. 2 Wochen aufgefallen, dass meine Alexa Lichtschaltbefehle, welche ich mit dem VSH-Node in Node-RED auslöse, nur noch mit einer längeren Verzögerung schalteten.
Ich habe mich nun aber erst dieses Wochenende mal näher mit dem Problem beschäftigt und dabei festgestellt, dass das Node-RED Addon dauerhaft mit höherer CPU-Last läuft.
Mein System ist ein Odroid-M1 mit 8 GB Ram, wo das aktuelle HAOS auf einer 16 GB EMMC installiert ist und die Daten auf einer 1 TB SSD liegen.
Hier nun erst mal 2 Screenshots, welche die CPU-Last anzeigen, welche im Schnitt bei ungewöhnlichen 25% liegt. Ich möchte noch anmerken, dass ich vor dem Anfertigen der Screenshots bereits sämtliche Flows deaktiviert hatte, also Node-RED macht nix, außer selbst zu laufen.
Alle anderen Addons haben eineunverdächtige CPU-Last von maximal 3%.
Zum Eingrenzen des Problems hatte ich erst versucht, verschiedene Flows oder Nodes zu deaktivieren, aber das führte zu keiner Besserung. Ich habe auch das Backup der Version 18.0.4 des Addons testweise wiederhergestellt. Komischerweise bleibt auch hier das Problem bestehen, obwohl zu der Zeit dieser Version vor über einem Monat kein ungewöhnliches Verhalten zu erkennen war. Das Problem tritt auch beim Core 2024.08.3, als auch bei 2024.09.1 auf.
Was ich mir noch vorstellen könnte, dass das Update vom HAOS auf v13.1 vor 2-3 Wochen damit zu tun haben könnte. Das käme zeitlich mit dem Einsetzen des Problems so ungefähr hin.
hast Du einfach mal das Add-on neu gestartet, ohne dass die Flows gleich gestartet werden.
Dann mal eine Zeit laufen lassen und beobachten, dann ein Flow nach dem anderen starten und immer schauen was passiert.
VG
Bernd
P.S.: ein mal noch das Add-on Glance installieren um da evtl. noch etwas tiefer ins System zu schauen.
Also wenn ich Node-RED mit bereits vorher schon komplett deaktivierten Flows neu starte, ist die CPU-Last direkt schon hoch. Das bleibt dann auch nach längerer Zeit so.
Glances habe ich nun installiert. Dort wird auch der node-red Prozess als auch der Container mit hohen Werten angezeigt, aber man kann nicht sehen, was diese verursacht. Im Protokoll vom Container sieht das Starten auch ganz normal aus:
s6-rc: info: service init-nodered successfully started
s6-rc: info: service nodered: starting
s6-rc: info: service nodered successfully started
s6-rc: info: service nginx: starting
s6-rc: info: service nginx successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
[12:54:23] INFO: Starting Node-RED...
> start
> node $NODE_OPTIONS node_modules/node-red/red.js --settings /etc/node-red/config.js
9 Sep 12:54:27 - [info]
Welcome to Node-RED
===================
9 Sep 12:54:27 - [info] Node-RED version: v4.0.2
9 Sep 12:54:27 - [info] Node.js version: v18.20.3
9 Sep 12:54:27 - [info] Linux 6.6.46-haos arm64 LE
9 Sep 12:54:28 - [info] Loading palette nodes
9 Sep 12:54:30 - [info] Node-RED Contrib Theme Collection version: v4.0.8
9 Sep 12:54:37 - [info] Settings file : /etc/node-red/config.js
9 Sep 12:54:37 - [info] Context store : 'default' [module=memory]
9 Sep 12:54:37 - [info] User directory : /config/
9 Sep 12:54:37 - [warn] Projects disabled : editorTheme.projects.enabled=false
9 Sep 12:54:37 - [info] Flows file : /config/flows.json
9 Sep 12:54:37 - [info] Server now running at http://127.0.0.1:46836/
[12:54:38] INFO: Starting NGinx...
9 Sep 12:54:38 - [info] Starting flows
9 Sep 12:54:38 - [info] Started flows
9 Sep 12:54:38 - [info] [alexa-remote-account:Alexa Odroid-M1] intialising "Alexa Odroid-M1" with the PROXY method and saved data...
9 Sep 12:54:43 - [info] [server:Home Assistant] Connecting to http://supervisor/core
9 Sep 12:54:43 - [info] [server:Home Assistant] Connected to http://supervisor/core
Ich hatte in den letzten Wochen auch eigentlich keine Veränderungen an meinen Flows vorgenommen, falls das jemand als mögliche Ursache vermutet.
PS: Ich habe jetzt mal den Loglevel vom Container in den versteckten Einstellungen auf Debug gestellt. Eventuell finde ich da was.
PS 2: Nein auch im Debug Modus keine Auffälligkeiten. Nur während der Initialisierung vom alexa-remote Node wird das Log für 5 Sekunden mit entsprechenden Meldungen geschwemmt. Danach aber nichts mehr.
Für den Node node-red-contrib-home-assistant-websocket gibt es schon eine Aktualisierung. Dieser Node ist aber Teil des Addons und deren Aktualisierungen werden vom Addon-Ersteller gemanaged. Also man soll diese vorinstallierten Nodes nicht manuell über die Palette updaten.
Hat denn sonst noch jemand das Node-RED Addon auf ARM64 (im Idealfall Odroid) am laufen, und kann bestätigen, dass es bei ihm keine Auffälligkeiten gibt?
Wo hast du denn das her? Du kannst natürlich die Nodes in der Palette selbst aktualisieren. Entweder über die Palette in NodeRed selbst, oder über die Option im Addon-Konfigurationsmenü.
Option: npm_packages
Allows you to specify additional NPM packages or Node-RED nodes to be installed to your Node-RED setup (e.g., node-red-dashboard, node-red-contrib-ccu)
ok, ich oute mich erst einmal als jemand, der keine Ahnung von Node-RED hat, dann hast Du zwar nach ARM64 gefragt, aber ich habe einmal in meiner HAOS VM unter Proxmox x86_64 das Add-on von Node-RED installiert, nach dem Start ist die CPU Auslastung minimal
Kann sein, aber auch nicht.
Tatsache ist, dass NR seit dem Update auf 2024.8.3 Zicken macht.
Meine SSH-Aurtomatisierungen laufen seit dem auch nicht mehr.
Eine Neuinstallation will ich erst mal vermeiden. Ich hatte ja schon testweise ein Backup der vorherigen Version eingespielt. Da war auch das Problem, aber vor ein paar Wochen war diese Version eben unauffällig gelaufen.
Ich habe weder mit dem NR-Addon, noch mit dem Standalone NR ein Problem trotz der Aktualisierung der Nodes. Und gerade weil ja im HA aus service → action wurde und node-red-contrib-home-assistant-websocket stark mit HA verknüpft ist, könnte ich mir vorstellen, dass es mit der, mit dem Addon gelieferten Version (alten Version), Probleme geben kann.
Was für Probleme hast du denn mit den SSH Automationen, bzw. was machen die?
Ich habe die o.g. Probleme, dass inject-node und node-status erst nach 20-30 Minuten angezeigt werden (s. verlinkten Beitrag).
Ich habe einen Flow, der mir jede Nacht die flows.json vom NR-addon-Ordner in den Config-Ordner kopiert, damit watchman auch die Flows auf fehlende Entitäten prüfen kann.
Seit 17.08. klappt das nicht mehr. Wenn ich in den Flow eine debug-node einbaue, kommt diese Meldung:
Wie gesagt, bis zum Update auf 2024.8.3 hat das alles super funktioniert.
Der 0.70.0-websocket ist ja brand aktuell, werde es evtl. später mal testen,
wobei ich weder in HA, noch im NR-Addon irgendwelche Fehlermeldungen zum websocket bekomme.
Ich hatte erst die Aktualisierung des websocket Nodes af v0.70.0 mit in die Konfiguration reingenommen. Nach dem Starten musste ich erst dessen Konfiguration der einzelnen Nodes auf die neue Version aktualisieren lassen, was auch funktionierte. Die CPU-Last hat sich jedoch mit v0.70.0 nicht verringert.
Als zweites habe ich deinen Vorschlag mit dem Start im Safe-Mode ausprobiert. Und tatsächlich, die CPU liegt dann bei 0-1%. Sobald ich deploye und die Flows starten, ist die CPU wieder am rödeln.
Was macht jetzt den Unterschied zu meinen komplett deaktivierten Flows?
Also irgendetwas, was beim Starten der Flows ausgelöst wird, ist noch faul. Ich muss das die Tage dann per Ausschlussverfahren nach und nach feststellen.
Ich habe jetzt noch mal getestet und kann nun behaupten, dass die hohe CPU Last am node-red-contrib-home-assistant-websocket Node liegen muss.
Erst habe ich ein Backup vom Node-RED Addon gemacht und dann alle Nodes des Websocket-Nodes aus den Flows gelöscht. Dann noch dessen Konfigurationsnode gelöscht und komplett in der Palette deaktiviert. Neustart und ab dann ist die CPU-Last nur noch bei 1-2%.
Jetzt muss ich nur noch herausfinden, ob es an Bugs des Websocket-Nodes liegt oder es an meiner Konfiguration gelegen hat. Es wäre auch möglich, diesen gar nicht erst zu nutzen und zum Beispiel mit MQTT zu ersetzen.
Ich habe das websocket Addon nun seit einigen Tagen deaktiviert und soweit fast vollständig mit API-Anfragen über den http-request Node und MQTT ersetzt.
Auf dem Screenshot kann man schön sehen, dass seitdem Ruhe ist und Node-RED wieder schön responsiv reagiert. Man sieht auch, dass das Problem am 24. August anfing.
