Steigender Ram/Swap nach update auf nodejs24
-
keine Ahnung was mir da den Ram wegfrißt
EDIT: der js controller mit fast 40% :(
-
Habe mein Problem mit der Claude KI untersucht und durch wechsel auf node 22 behoben.
KI Antwort:
Nach dem Wechsel auf Node 24 hatte ich massive RAM-Probleme bis hin zu OOM-Kills. Mit einem A/B-Vergleich konnte ich es eingrenzen, vielleicht hilft das anderen.System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0,
mem_limit4 GB, js-controller 7.2.2, States/Objects als jsonl. 14 aktive Instanzen: admin, javascript, node-red, 3× influxdb, 2× modbus, openknx, viessmannapi (~15.000 Objekte), telegram, web, wled, energiefluss-erweitert.Was passiert ist: Ein Re-Pull von
latestbrachte einen neuen Build von v11.1.0 mit Node 24.21.0 statt 22. Das Tag bleibt dabei gleich, weil die Build-Pipeline die empfohlene Node-Version erst beim Bauen einsetzt. Docker Hub führt v11.1.0 noch unter „Node 22 versions“. Danach wurde js-controller beim Start mehrfach gekillt, und der Container hing in einer Startschleife:Memory cgroup out of memory: Killed process … (iobroker.js-con) … anon-rss:1874176kBNODE_OPTIONS="--max-semi-space-size=16"plusMALLOC_ARENA_MAX=2haben nicht geholfen, js-controller lag beim Start trotzdem bei ~1,9 GB.A/B-Vergleich (gleiches Volume, gleiche Adapter, nur anderer Image-Build):
Node 24.21.0 Node 22.23.2 Container, Spitze beim Start ~5 GB 2,5 GB Container nach ~10 min 3,7–4,2 GB 2,2 GB js-controller memRss ~2.060 MB 583 MB (nach 20 min ~410 MB) js-controller memHeapTotal ~345 MB ~388 MB Der Unterschied liegt fast komplett außerhalb des JS-Heaps.
Mögliche Ursache: https://github.com/nodejs/node/issues/61967
Mit V8 13.6 (ab Node 24) werden kurzlebige Buffer erst per Mark-Compact statt per Scavenge freigegeben. Das Issue misst Durchsatz, nicht RAM, der Mechanismus würde aber zu js-controller als DB-Server passen. Der dort genannte Workaround--scavenger-max-new-space-capacity-mb=8ist inNODE_OPTIONSnicht erlaubt, Node startet dann gar nicht.Workaround für Docker: Auf ein festes Build-Tag mit Node 22 pinnen:
image: buanet/iobroker:v11.1.0-build.20260920.013345 # Node 22.23.2Die Node-Version eines Tags lässt sich vorher prüfen (der Build 20260924 hat schon Node 24):
docker run --rm --entrypoint node buanet/iobroker:v11.1.0-build.20260920.013345 -vNach dem Wechsel liefen alle Instanzen ohne Rebuild-Fehler.
Selbst prüfen: In
system.host.<name>den WertmemRssmitmemHeapTotalvergleichen. Ist RSS unter Node 24 ein Vielfaches davon, ist man wahrscheinlich betroffen.Fragen:
- Kann das jemand bestätigen, auch bei nativer Installation? Gibt es schon ein Issue bei js-controller?
- Mag jemand mit nativer Installation testen, ob js-controller mit
--scavenger-max-new-space-capacity-mb=8direkt amnode-Aufruf wieder normal läuft?
System: Raspberry Pi 5 (8 GB, NVMe), Docker mit dem offiziellen buanet-Image v11.1.0, mem_limit 4 GB, js-controller 7.2.2, States/Objects als jsonl. 14 aktive Instanzen: admin, javascript, node-red, 3× influxdb, 2× modbus, openknx, viessmannapi (~15.000 Objekte), telegram, web, wled, energiefluss-erweitert.
Was passiert ist: Ein Re-Pull von latest brachte einen neuen Build von v11.1.0 mit Node 24.21.0 statt 22. Das Tag bleibt dabei gleich, weil die Build-Pipeline die empfohlene Node-Version erst beim Bauen einsetzt. Docker Hub führt v11.1.0 noch unter „Node 22 versions“. Danach wurde js-controller beim Start mehrfach gekillt, und der Container hing in einer
Wenn man node major updated, änder sich die ABI. Das erfordert ein npm rebuild auf die node_modules. M.W. macht das das buanet Image aber nicht eigenständig. Der js-controller hat native module die compiliert werden müssen.
-
Nachtrag nach 24 Stunden, gleiches System, gleiche Adapter, nur Node getauscht:
memRss memHeapTotal Node 24, nach ~24 h 1.749 MB 271 MB Node 22, nach ~26 h 313 MB 218 MB Unter Node 24 hat sich also nichts eingependelt.
@OliverIO: Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.
Die Plattform-These nehme ich zurück: crunchips Produktivsystem (x86, 52.000 Objekte) liegt unter Node 24 ebenfalls bei rund 1,3 GB außerhalb des Heaps. Bei paul53, Marc (jsonl) und crunchips Testsystem sind es 200–300 MB, bei Michael wächst es über den Tag von rund 420 auf 640 MB. Es scheint eher mit der Größe bzw. der DB-Last zu wachsen.
@crunchip: Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
@Marc-Berg: Danke fürs Gegentesten mit jsonl!
Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.
leider ist das kein indiz
der oom killer berechnet für jeden prozess einen oom score, anhand dessen entschieden wird welcher prozess beendet wird.
da der js-controller bei vielen aktivitäten mit beteiligt ist, kann auch ein adapter die ursache sein. da der js-controller prozess mehr speicher benötigt, wie ein adapter prozess, hat er einen höheren score.
in dem von mir verlinkten prozess war bspw der history adapter der verursacher, da der nutzer viele diagramme in vis eingebunden hat. der history adapter hat sehr kurzzeitig (das wäre wahrscheinlich in top gar nicht sichtbar gewesen) viele threads gestartet, die jeder für sich wieder RAM benötigt. Jeder dieser Sub-Threads haben aber nur sehr kurz gelebt.
ich will nicht sagen, das das bei dir die ursache ist, aber wie oben schon erwähnt, einmalige screenshots mit augenblickaufnahme werden wahrscheinlich nicht die ursache offenbaren.da einige über verlaufsdaten gezeigt haben, das ein wechsel von 22 auf 24 sogut wie keine auswirkungen hatte, könnte es bei dir auch etwas anderes sein.
leider ist jedes system, mit unterschiedlicher Anzahl und zusammensetzung von Adaptern sehr individuell. Wenn ein generelles Problem vorliegen würde, wären hier im Forum auch noch einige mehr threads dazu (gut die Umstellung auf v24 läuft auch erst gerade an)schau mal nochmal in den verlinkten thread rein. da sind analyse scripts drin (die leider sehr große outputs erzeugen), mit dem man tiefer analysieren könnte.
aber ich würde mal immer noch auf die aufzeichnung der memory werte von adaptern verweisen (1h dürfte reichen) idealerweise im vergleich zu v22 basis.
bspw habe ich auch diesen thread gesehen, leider ohne reaktion von irgendjemanden.
matter hatte ich glaube ich bei dir auch gesehen.
https://forum.iobroker.net/topic/85474/steigender-ram-beim-matter-adapter?_=1790863527158 -
Nachtrag nach 24 Stunden, gleiches System, gleiche Adapter, nur Node getauscht:
memRss memHeapTotal Node 24, nach ~24 h 1.749 MB 271 MB Node 22, nach ~26 h 313 MB 218 MB Unter Node 24 hat sich also nichts eingependelt.
@OliverIO: Eingegrenzt ist es auf den js-controller. Den hat der OOM-Killer unter Node 24 mehrfach beendet, der Rest des Containers ist unter beiden Versionen etwa gleich groß.
Die Plattform-These nehme ich zurück: crunchips Produktivsystem (x86, 52.000 Objekte) liegt unter Node 24 ebenfalls bei rund 1,3 GB außerhalb des Heaps. Bei paul53, Marc (jsonl) und crunchips Testsystem sind es 200–300 MB, bei Michael wächst es über den Tag von rund 420 auf 640 MB. Es scheint eher mit der Größe bzw. der DB-Last zu wachsen.
@crunchip: Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
@Marc-Berg: Danke fürs Gegentesten mit jsonl!
Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
Müsst ich nachschauen.
Letztendlich läuft bei mir ein spezielles Script, der das System überwacht.
Und seit der Umstellung auf v24(aber auch ein paar Updates verschiedener Adapter) wurde ich in unregelmäßigen Abständen benachrichtigt das mein RAM überschritten ist.
Sa dann so aus
Eigentlich lag ich immer so bei 8-9Gb incl Spitzenumgestiegen von Proxmox auf Unraid
-
Hast du von deinem Produktivsystem noch memRss-Werte aus der Node-22-Zeit? Dann sieht man, ob die 1,8 GB neu sind.
Müsst ich nachschauen.
Letztendlich läuft bei mir ein spezielles Script, der das System überwacht.
Und seit der Umstellung auf v24(aber auch ein paar Updates verschiedener Adapter) wurde ich in unregelmäßigen Abständen benachrichtigt das mein RAM überschritten ist.
Sa dann so aus
Eigentlich lag ich immer so bei 8-9Gb incl Spitzendie veränderungen bei deinen 3 top verbrauchern ist allerdings nur sehr gering oder das gesamtsystem ist schon sehr nahe an deinen 10gb
größere veränderungen bei anderen adaptern die dann zum überschwappen führen sieht man da nicht.Meine Adapter und Widgets
TVProgram, SqueezeboxRPC, OpenLiga, RSSFeed, MyTime,, pi-hole2, vis-json-template, skiinfo, vis-mapwidgets, vis-2-widgets-rssfeed
Links im Profil -
Hm, ich muss das mal eine längere Zeitspanne beobachten.
Hier meine Werte der letzen 30 Tage. Am 27.09. habe ich die Proxmox VM (8G) und den Raspberrypi (Version B, 8G) auf nodejs 24 gebracht.
Es hat sich tatsächlich etwas getan, aber als dramatisch würde ich es nicht bezeichnen.
VM
RPI
-
ich hab nun mal eine iob stop und iob start gemacht. Warum geht der js-controller mit der Zeit im Ram so hoch ? (Der kleinere Wert von 16,3% ist nach dem Neustart und die 39,5% davor)
-
die veränderungen bei deinen 3 top verbrauchern ist allerdings nur sehr gering oder das gesamtsystem ist schon sehr nahe an deinen 10gb
größere veränderungen bei anderen adaptern die dann zum überschwappen führen sieht man da nicht.@OliverIO wie oben geschrieben lag ich konstant zwischen 8-9Gb incl Spitzen, also noch 1-2Gb Luft bevor die Meldung kommt, da ich mir eine Schwelle 10GB gesetzt hatte.
Allerdings:
Neuste Beobachtungen steigt auch der Admin mal auf rund 550Mb, genauso der Web Adapter, das wiederum schiebe ich allerdings darauf, daß ich den aura Adapter incl KI kürzlich eingebunden habe.
Hatte anderweitig auch schon angefangen unnötige Adapter zu deinstallieren bzw zu deaktivieren, stellt allerdings ja keine Lösung dar.Muss mir das in Ruhe mal ansehen, Fliesen ja genug Daten in die Datenbänke
EDIT:
hier sieht man den Anstieg
anders Aufgelöst im history Adapter
sieht man seit der Umstellung ab dem 25. 09 immer 2 Spitzen, einmal Vormittags ca um 11Uhr und einmal abends gegen 23Uhr, jetzt müsste ich nur herausfinden woher das kommtEDIT:
@jippsydigger
hab nun Testhalberbuanet/iobroker:v11.1.0-build.20260902.012040eingespielt
zu Beginn war memRss bei ca 1700, dacht ok, hat dann doch nichts damit zu tun, 8min nach Neustart hat sich das dann allerdings beruhigt und pendelt um die 1200mb, also ca 500mb weniger als mit dem latest image, zum Vergleich sieh oben https://forum.iobroker.net/post/1356937
und ebenfalls beim Testsystem ausgeführt, allerdings läuft da noch js-controller 7.2.2
EDIT:
und weil ich mir noch die Host-Basiseinstellung zwecks Objekte und Zustände angesehen habe, stellte ich fest, das ich auf meinem doch schon sehr alten Produktiv System abweichende Werte hatte, im Vergleich zum Test System, dort waren andere Faktoren und Intervalle hinterlegt. Hab diese nun mal angepasst und neu gestartet.Aktuell sieht es so aus:
da sieht man den Abfall nach der Umstellung
EDIT:
Fazit,
nachdem sich das System nun eingependelt hat, läuft es mit nodejs 22 bei rund 8GB , die Tage zuvor mit nodejs24 lag es bei gut 9GB.
Die Frage WARUM ist dadurch allerdings noch nicht geklärt
-
Auch bei mir nach Upgrade von Nodejs 22 auf Nodejs 24 erhöhter RAM-Verbrauch.
Bei Nodejs 22 - RAM: ca. 3-3.5 GB
Bei Nodejs 24 - RAM: ca. 5-7.5 GBIOB läuft dediziert auf einem Odroid-M1 (nix Container ...).
Keine Änderungen am System nur Upgrade auf Nodejs 24.PS: Auf meinem Testsystem das selbe. RAM geht nach oben :-(
-
Hallo,
bevor ich ein eigenes Thema aufmache, wollte ich hier meine Erfahrungen zeigen: Ich habe meinen Raspi 4 (4 GB. 64bit bookworm) gestern geupdatet und danach nodejs von 20.20.2 auf 24.21.0, anschließend iob von 7.0.7 auf 7.2.2. Danach ging so gut wie nichts mehr. Der RAM scheint vollgelaufen zu sein, PI war nicht mehr erreichbar über SSH, ping ging noch und ich konnte den PI nur noch durch Kabel ziehen wieder beleben. Mit htop konnte ich kurz sehen, dass der RAM ziemlich voll ist, bis dann nichts mehr ging.
Das hatte ich 2x versucht, da ich Fehler in der Reihenfolge der Updates vermutet hatte. Es hat aber keinen Unterschied gemacht.
Jetzt bin ich den Zwischenschritt über nodejs 22.23.3 gegangen und iob 7.2.2
Das läuft aktuell stabil.
Meine Frage: War der Sprung zu groß von 20 auf 24 ? Soll ich jetzt auf v24 hoch gehen oder erst abwarten (aktuell wird ja v22 empfohlen) ?
Meine Adapter habe ich noch nicht aktualisiert, soll ich das zuerst machen? Danke!
Viele Grüße
Thomas -
Hallo,
bevor ich ein eigenes Thema aufmache, wollte ich hier meine Erfahrungen zeigen: Ich habe meinen Raspi 4 (4 GB. 64bit bookworm) gestern geupdatet und danach nodejs von 20.20.2 auf 24.21.0, anschließend iob von 7.0.7 auf 7.2.2. Danach ging so gut wie nichts mehr. Der RAM scheint vollgelaufen zu sein, PI war nicht mehr erreichbar über SSH, ping ging noch und ich konnte den PI nur noch durch Kabel ziehen wieder beleben. Mit htop konnte ich kurz sehen, dass der RAM ziemlich voll ist, bis dann nichts mehr ging.
Das hatte ich 2x versucht, da ich Fehler in der Reihenfolge der Updates vermutet hatte. Es hat aber keinen Unterschied gemacht.
Jetzt bin ich den Zwischenschritt über nodejs 22.23.3 gegangen und iob 7.2.2
Das läuft aktuell stabil.
Meine Frage: War der Sprung zu groß von 20 auf 24 ? Soll ich jetzt auf v24 hoch gehen oder erst abwarten (aktuell wird ja v22 empfohlen) ?
Meine Adapter habe ich noch nicht aktualisiert, soll ich das zuerst machen? Danke!
Viele Grüße
Thomasaktuell wird ja v22 empfohlen
Nein.
https://forum.iobroker.net/topic/85466/offizielle-empfehlung-nodejs-24
-
@obstbauer eigentlich nicht, aber vllt waren noch Adapter dabei, "die sich nicht mit v24" vertragen haben
-
Hallo,
bevor ich ein eigenes Thema aufmache, wollte ich hier meine Erfahrungen zeigen: Ich habe meinen Raspi 4 (4 GB. 64bit bookworm) gestern geupdatet und danach nodejs von 20.20.2 auf 24.21.0, anschließend iob von 7.0.7 auf 7.2.2. Danach ging so gut wie nichts mehr. Der RAM scheint vollgelaufen zu sein, PI war nicht mehr erreichbar über SSH, ping ging noch und ich konnte den PI nur noch durch Kabel ziehen wieder beleben. Mit htop konnte ich kurz sehen, dass der RAM ziemlich voll ist, bis dann nichts mehr ging.
Das hatte ich 2x versucht, da ich Fehler in der Reihenfolge der Updates vermutet hatte. Es hat aber keinen Unterschied gemacht.
Jetzt bin ich den Zwischenschritt über nodejs 22.23.3 gegangen und iob 7.2.2
Das läuft aktuell stabil.
Meine Frage: War der Sprung zu groß von 20 auf 24 ? Soll ich jetzt auf v24 hoch gehen oder erst abwarten (aktuell wird ja v22 empfohlen) ?
Meine Adapter habe ich noch nicht aktualisiert, soll ich das zuerst machen? Danke!
Viele Grüße
ThomasMeine Frage: War der Sprung zu groß von 20 auf 24 ? Soll ich jetzt auf v24 hoch gehen oder erst abwarten (aktuell wird ja v22 empfohlen) ?
Bei Deinem Gerät (Raspi4 /4GB) würde ich zunächst auf Node22 bleiben.
Da wirst Du mittelfristig eher nach einem anderen Raspi Ausschau halten müssen.
(mind. 8GB/eher mehr)
Node24 ist erst seit ein paar Tagen die Empfehlung, aber es scheint, dass man dafür
mehr als 4GB Ram für einen stabilen Betrieb braucht. -
Meine Frage: War der Sprung zu groß von 20 auf 24 ? Soll ich jetzt auf v24 hoch gehen oder erst abwarten (aktuell wird ja v22 empfohlen) ?
Bei Deinem Gerät (Raspi4 /4GB) würde ich zunächst auf Node22 bleiben.
Da wirst Du mittelfristig eher nach einem anderen Raspi Ausschau halten müssen.
(mind. 8GB/eher mehr)
Node24 ist erst seit ein paar Tagen die Empfehlung, aber es scheint, dass man dafür
mehr als 4GB Ram für einen stabilen Betrieb braucht. -
Meine Frage: War der Sprung zu groß von 20 auf 24 ? Soll ich jetzt auf v24 hoch gehen oder erst abwarten (aktuell wird ja v22 empfohlen) ?
Bei Deinem Gerät (Raspi4 /4GB) würde ich zunächst auf Node22 bleiben.
Da wirst Du mittelfristig eher nach einem anderen Raspi Ausschau halten müssen.
(mind. 8GB/eher mehr)
Node24 ist erst seit ein paar Tagen die Empfehlung, aber es scheint, dass man dafür
mehr als 4GB Ram für einen stabilen Betrieb braucht. -
-
@rscsb [sagte]: mehr als 4GB Ram für einen stabilen Betrieb braucht.
Mein Produktivsystem mit Node.js v24 hat nur 4 GB RAM.
-
@rscsb [sagte]: Sende mal ein "iob diag"
*** BASE SYSTEM *** Operating System: Debian GNU/Linux 13 (trixie) Static hostname: iob Icon name: computer-vm Chassis: vm 🖴 Virtualization: kvm Kernel: Linux 6.12.107+deb13-amd64 Architecture: x86-64 Hardware Vendor: QEMU Hardware Model: Standard PC _i440FX + PIIX, 1996_ Firmware Version: rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org Firmware Date: Tue 2014-04-01 Firmware Age: 12y 6month 1d OS is similar to: model name : QEMU Virtual CPU version 2.5+ Docker : false Virtualization : kvm Kernel : x86_64 Userland : 64bit System was installed 174 days ago (on 2026-04-10). Systemuptime and Load: 12:52:41 up 7 days, 21:56, 1 user, load average: 0.00, 0.00, 0.00 CPU threads : 3 *** LIFE CYCLE STATUS *** Operating System is the current Debian stable version codenamed 'trixie'! *** TIME AND TIMEZONES *** Local time: Fri 2026-10-02 12:52:41 CEST Universal time: Fri 2026-10-02 10:52:41 UTC RTC time: Fri 2026-10-02 10:52:41 Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: yes NTP service: active RTC in local TZ: no *** Users and Groups *** User that called 'iob diag': fred HOME=/home/fred GROUPS=fred cdrom floppy sudo audio dip video plugdev users netdev iobroker User that is running 'js-controller': iobroker HOME=/home/iobroker GROUPS=iobroker tty dialout audio video plugdev *** DISPLAY-SERVER SETUP *** Display-Server: Unknown Display-Manager: Not found Desktop: Session: tty Boot Target: multi-user.target *** MEMORY *** total used free shared buff/cache available Mem: 4.1G 1.9G 1.0G 1.7M 1.4G 2.2G Swap: 1.8G 0B 1.8G Total: 5.9G 1.9G 2.8G Active iob-Instances: 11 3921 M total memory 1812 M used memory 1527 M active memory 1161 M inactive memory 986 M free memory 150 M buffer memory 1219 M swap cache 1721 M total swap 0 M used swap 1721 M free swap *** top - Table Of Processes *** top - 12:52:42 up 7 days, 21:56, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 125 total, 1 running, 124 sleeping, 0 stopped, 0 zombie %Cpu(s): 3.0 us, 0.0 sy, 0.0 ni, 93.9 id, 3.0 wa, 0.0 hi, 0.0 si, 0.0 st MiB Mem : 3921.5 total, 986.6 free, 1812.5 used, 1369.8 buff/cache MiB Swap: 1722.0 total, 1722.0 free, 0.0 used. 2109.1 avail Mem *** FAILED SERVICES *** UNIT LOAD ACTIVE SUB DESCRIPTION 0 loaded units listed. *** DMESG CRITICAL ERRORS *** No critical errors detected *** FILESYSTEM *** Filesystem Type Size Used Avail Use% Mounted on udev devtmpfs 1.9G 0 1.9G 0% /dev tmpfs tmpfs 393M 504K 392M 1% /run /dev/sda1 ext4 30G 4.7G 24G 17% / tmpfs tmpfs 2.0G 0 2.0G 0% /dev/shm tmpfs tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/systemd-journald.service tmpfs tmpfs 2.0G 836K 2.0G 1% /tmp tmpfs tmpfs 1.0M 0 1.0M 0% /run/credentials/getty@tty1.service tmpfs tmpfs 393M 8.0K 393M 1% /run/user/1000 Messages concerning filesystems in dmesg (Last 15 lines only): [Thu Sep 24 14:56:14 2026] EXT4-fs (sda1): orphan cleanup on readonly fs [Thu Sep 24 14:56:14 2026] EXT4-fs (sda1): mounted filesystem ef8cd6f8-54de-4f9b-b2f8-50489c0e4114 ro with ordered data mode. Quota mode: none. [Thu Sep 24 14:56:15 2026] EXT4-fs (sda1): re-mounted ef8cd6f8-54de-4f9b-b2f8-50489c0e4114 r/w. Show mounted filesystems: TARGET SOURCE FSTYPE OPTIONS / /dev/sda1 ext4 rw,relatime,errors=remount-ro Files in neuralgic directories: /var: 719M /var/ 321M /var/cache 313M /var/cache/apt 221M /var/cache/apt/archives 202M /var/log Hint: You are currently not seeing messages from other users and the system. Users in groups 'adm', 'systemd-journal' can see all messages. Pass -q to turn off this notice. Archived and active journals take up 42.2M in the file system. /opt/iobroker/backups: 4.0K /opt/iobroker/backups/ /opt/iobroker/iobroker-data: 373M /opt/iobroker/iobroker-data/ 132M /opt/iobroker/iobroker-data/backup-objects 110M /opt/iobroker/iobroker-data/files 106M /opt/iobroker/iobroker-data/history 30M /opt/iobroker/iobroker-data/files/javascript.admin The five largest files in iobroker-data are: 18M /opt/iobroker/iobroker-data/objects.jsonl 9.5M /opt/iobroker/iobroker-data/states.jsonl 6.8M /opt/iobroker/iobroker-data/files/javascript.admin/custom/assets/_virtual_mf___mfe_internal__ConfigCustomJavascriptSet__mf_owner__1__loadShare___mf_0_iobroker_mf_1_gui_mf_2_components__loadShare__.js-DMefPDeL.js 6.8M /opt/iobroker/iobroker-data/files/backitup.admin/custom/assets/_virtual_mf___mfe_internal__ConfigCustomBackItUpSet__mf_owner__1__loadShare___mf_0_iobroker_mf_1_gui_mf_2_components__loadShare__.js-Bs-T0f9g.js 6.8M /opt/iobroker/iobroker-data/files/admin.admin/custom/assets/_virtual_mf___mfe_internal__AdminComponentEasyAccessSet__mf_owner__1__loadShare___mf_0_iobroker_mf_1_gui_mf_2_components__loadShare__.js-5dJPNbX2.js USB-Devices by-id: USB-Sticks - Avoid direct links to /dev/tty* in your adapter setups, please always prefer the links 'by-id': No Devices found 'by-id' No nvbackup.json found. *** NodeJS-Installation *** /usr/bin/nodejs v24.21.0 /usr/bin/node v24.21.0 /usr/bin/npm 11.19.0 /usr/bin/npx 11.19.0 ✓ Node.js installation is correct nodejs: Installed: 24.21.0-1nodesource1 Candidate: 24.21.0-1nodesource1 Version table: *** 24.21.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 100 /var/lib/dpkg/status 24.20.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.19.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.18.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.18.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.17.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.16.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.15.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.14.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.14.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.13.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.13.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.12.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.11.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.11.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.10.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.9.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.8.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.7.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.6.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.5.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.4.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.4.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.3.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.1.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.0.2-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.0.1-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 24.0.0-1nodesource1 1001 500 https://deb.nodesource.com/node_24.x nodistro/main amd64 Packages 20.19.2+dfsg-1+deb13u3 500 500 http://security.debian.org/debian-security trixie-security/main amd64 Packages 20.19.2+dfsg-1+deb13u2 500 500 http://deb.debian.org/debian trixie/main amd64 Packages Temp directories causing deletion problem: 0 No problems detected Errors in npm tree: 0 No problems detected Checking for nodejs vulnerability: No known Vulnerabilities detected! *** ioBroker-Installation *** ioBroker Status iobroker is running on this host. Objects type: jsonl States type: jsonl Hosts: iob iob (version: 7.2.2, hostname: iob , alive, uptime: 150667) Core adapters versions js-controller: 7.2.2 admin: 8.0.11 javascript: 10.1.3 nodejs modules from github: 0 Adapter State + system.adapter.admin.0 : admin : iob - enabled, port: 8081, bind: 0.0.0.0, run as: admin system.adapter.backitup.0 : backitup : iob - disabled + system.adapter.echarts.0 : echarts : iob - enabled + system.adapter.email.0 : email : iob - enabled system.adapter.feiertage.0 : feiertage : iob - enabled + system.adapter.fritzdect.0 : fritzdect : iob - enabled + system.adapter.history.0 : history : iob - enabled + system.adapter.hm-rega.0 : hm-rega : iob - enabled + system.adapter.hm-rpc.0 : hm-rpc : iob - enabled, port: 0 system.adapter.hm-rpc.1 : hm-rpc : iob - disabled, port: 0 + system.adapter.javascript.0 : javascript : iob - enabled system.adapter.midea.0 : midea : iob - disabled + system.adapter.proxmox.0 : proxmox : iob - enabled system.adapter.simple-api.0 : simple-api : iob - disabled, port: 8087, bind: 0.0.0.0, run as: admin system.adapter.vis.0 : vis : iob - enabled + system.adapter.web.0 : web : iob - enabled, port: 8082, bind: 0.0.0.0, run as: admin + instance is alive Enabled adapters with bindings + system.adapter.admin.0 : admin : iob - enabled, port: 8081, bind: 0.0.0.0, run as: admin + system.adapter.hm-rpc.0 : hm-rpc : iob - enabled, port: 0 + system.adapter.web.0 : web : iob - enabled, port: 8082, bind: 0.0.0.0, run as: admin ioBroker-Repositories ┌─────────┬──────────┬─────────────────────────────────────────────────────────┬──────────────┐ │ (index) │ name │ url │ auto upgrade │ ├─────────┼──────────┼─────────────────────────────────────────────────────────┼──────────────┤ │ 0 │ 'stable' │ 'http://download.iobroker.net/sources-dist.json' │ false │ │ 1 │ 'beta' │ 'http://download.iobroker.net/sources-dist-latest.json' │ false │ └─────────┴──────────┴─────────────────────────────────────────────────────────┴──────────────┘ Active repo(s): stable Upgrade policy: none Installed ioBroker-Adapters ┌─────────┬─────────────────────────────┬──────────────┬──────────┬────────────────┐ │ (index) │ id │ name │ version │ upgrade policy │ ├─────────┼─────────────────────────────┼──────────────┼──────────┼────────────────┤ │ 0 │ 'system.adapter.admin' │ 'admin' │ '8.0.11' │ 'none' │ │ 1 │ 'system.adapter.backitup' │ 'backitup' │ '4.0.3' │ 'none' │ │ 2 │ 'system.adapter.echarts' │ 'echarts' │ '4.0.0' │ 'none' │ │ 3 │ 'system.adapter.email' │ 'email' │ '3.0.0' │ 'none' │ │ 4 │ 'system.adapter.feiertage' │ 'feiertage' │ '1.4.0' │ 'none' │ │ 5 │ 'system.adapter.fritzdect' │ 'fritzdect' │ '2.6.2' │ 'none' │ │ 6 │ 'system.adapter.history' │ 'history' │ '4.0.0' │ 'none' │ │ 7 │ 'system.adapter.hm-rega' │ 'hm-rega' │ '5.1.0' │ 'none' │ │ 8 │ 'system.adapter.hm-rpc' │ 'hm-rpc' │ '3.0.1' │ 'none' │ │ 9 │ 'system.adapter.javascript' │ 'javascript' │ '10.1.3' │ 'none' │ │ 10 │ 'system.adapter.midea' │ 'midea' │ '1.8.5' │ 'none' │ │ 11 │ 'system.adapter.proxmox' │ 'proxmox' │ '2.6.3' │ 'none' │ │ 12 │ 'system.adapter.simple-api' │ 'simple-api' │ '3.0.7' │ 'none' │ │ 13 │ 'system.adapter.socketio' │ 'socketio' │ '7.1.3' │ 'none' │ │ 14 │ 'system.adapter.vis' │ 'vis' │ '1.5.6' │ 'none' │ │ 15 │ 'system.adapter.web' │ 'web' │ '8.0.0' │ 'none' │ │ 16 │ 'system.adapter.ws' │ 'ws' │ '4.1.0' │ 'none' │ └─────────┴─────────────────────────────┴──────────────┴──────────┴────────────────┘ ioBroker-Adapter Versions and update status Used repository: stable Adapter "admin" : 8.0.14 , installed 8.0.11 [Updatable] Adapter "backitup" : 4.0.3 , installed 4.0.3 Adapter "echarts" : 3.1.0 , installed 4.0.0 Adapter "email" : 3.0.0 , installed 3.0.0 Adapter "feiertage" : 1.4.0 , installed 1.4.0 Adapter "fritzdect" : 2.6.2 , installed 2.6.2 Adapter "history" : 4.0.0 , installed 4.0.0 Adapter "hm-rega" : 5.1.0 , installed 5.1.0 Adapter "hm-rpc" : 3.0.1 , installed 3.0.1 Adapter "javascript" : 10.1.3 , installed 10.1.3 Controller "js-controller": 7.2.2 , installed 7.2.2 Adapter "midea" : 0.0.7 , installed 1.8.5 Adapter "proxmox" : 2.6.3 , installed 2.6.3 Adapter "simple-api" : 3.0.7 , installed 3.0.7 Adapter "socketio" : 7.1.3 , installed 7.1.3 Adapter "vis" : 1.5.6 , installed 1.5.6 Adapter "web" : 8.0.0 , installed 8.0.0 Adapter "ws" : 4.1.0 , installed 4.1.0 Objects and States Please stand by - This may take a while Objects: 1989 States: 1455 *** OS-Repositories and Updates *** Hit:1 http://security.debian.org/debian-security trixie-security InRelease Hit:2 http://deb.debian.org/debian trixie InRelease Hit:3 http://deb.debian.org/debian trixie-updates InRelease Hit:4 https://deb.nodesource.com/node_24.x nodistro InRelease Reading package lists... Pending systemupdates: 10 *** Listening Ports *** Netid State Recv-Q Send-Q Local Address:Port Peer Address:PortProcess udp UNCONN 0 0 0.0.0.0:sunrpc 0.0.0.0:* users:(("rpcbind",pid=507,fd=5),("systemd",pid=1,fd=45)) udp UNCONN 0 0 [::]:sunrpc [::]:* users:(("rpcbind",pid=507,fd=7),("systemd",pid=1,fd=47)) tcp LISTEN 0 4096 0.0.0.0:sunrpc 0.0.0.0:* users:(("rpcbind",pid=507,fd=4),("systemd",pid=1,fd=44)) tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* users:(("sshd",pid=703,fd=6)) tcp LISTEN 0 511 127.0.0.1:9000 0.0.0.0:* users:(("iobroker.js-con",pid=13995,fd=29)) tcp LISTEN 0 511 127.0.0.1:9001 0.0.0.0:* users:(("iobroker.js-con",pid=13995,fd=23)) tcp LISTEN 0 511 192.168.253.14:2001 0.0.0.0:* users:(("io.hm-rpc.0",pid=14104,fd=30)) tcp LISTEN 0 511 *:http *:* users:(("apache2",pid=15856,fd=4),("apache2",pid=15855,fd=4),("apache2",pid=705,fd=4)) tcp LISTEN 0 4096 [::]:sunrpc [::]:* users:(("rpcbind",pid=507,fd=6),("systemd",pid=1,fd=46)) tcp LISTEN 0 128 [::]:ssh [::]:* users:(("sshd",pid=703,fd=7)) tcp LISTEN 0 511 *:8082 *:* users:(("io.web.0",pid=14184,fd=30)) tcp LISTEN 0 511 *:tproxy *:* users:(("io.admin.0",pid=14014,fd=35)) *** Log File - Last 25 Lines *** 2026-10-02 00:15:49.614 - info: javascript.0 (14066) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-10-02 00:15:51.632 - info: javascript.0 (14066) script.js.common.Solarflow: Verbindung wieder OK 2026-10-02 02:37:54.917 - info: javascript.0 (14066) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-10-02 02:37:56.930 - info: javascript.0 (14066) script.js.common.Solarflow: Verbindung wieder OK 2026-10-02 05:15:00.248 - info: javascript.0 (14066) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-10-02 05:15:02.270 - info: javascript.0 (14066) script.js.common.Solarflow: Verbindung wieder OK 2026-10-02 07:59:05.657 - info: javascript.0 (14066) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-10-02 07:59:07.673 - info: javascript.0 (14066) script.js.common.Solarflow: GET Fehler (2): connect ECONNREFUSED 192.168.253.115:80 2026-10-02 07:59:11.677 - info: javascript.0 (14066) script.js.common.Solarflow: Verbindung wieder OK 2026-10-02 10:27:10.939 - info: javascript.0 (14066) script.js.common.Solarflow: GET Fehler (1): timeout of 2000ms exceeded 2026-10-02 10:27:13.972 - info: javascript.0 (14066) script.js.common.Solarflow: Verbindung wieder OK
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden345
Online33.1k
Benutzende84.0k
Themen1.4m
Beiträge