Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[smhrambo]

@homoran Kann gut sein, ich habe damals gelernt, das free der Speicher ist, der theoretisch aus dem System entfernt werden kann.
Aber wie du schon sagtest wären da immernoch 1,2GB.

Das die Skripte neu kompiliert werden sollten, wenn sie aktiviert sind, weiss ich.
Aber nochmal, alle Skripte sind deaktiviert, alle haben ein rotes Play-Symbol.
Demensprechend sollte sie doch nicht neu kompiliert werden.

Ich habe das gerade noch mal getestet, im aktuellen System ohne Backup, auf dem alles läuft.
Mit aktivierten Skripte finde ich mit Loglevel silly keine informationen ob die Skripte bei einem Neustart vom JS Adapter neu kompiliert werden.
Demenspechend kann ich darüber keine handfeste Aussage machen.

Im aktuellen System ohne Backup mit 19 aktiven Adaptern (20 Prozesse) läuft es.
Ich habe nur keine Lust alle Einstellungen wieder von Hand vorzunehmen.
Das Problem liegt irgendwo in den wiederhergestellten Daten/Einstellungen und kann dementsprechend jederzeit wieder auftreten, wenn man die Ursache nicht kennt.

[Homoran]

@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:

Das Problem liegt irgendwo in den wiederhergestellten Daten/Einstellungen und kann dementsprechend jederzeit wieder auftreten, wenn man die Ursache nicht kennt.

und deswegen hatte ich mich hier gemeldet und darauf hingewiesen dass die Meldung nicht unbedingt alleine durch den js-Adapter verursacht werden muss

[smhrambo]

Eine kleine Sache dir mir aufgefallen ist.
Mein kleiner Weihnachtskript vom ersten Post.
Weil setState sich gemeldet hat und gerne boolean statt integer haben wollte, habe
Ich die Variable State geändert, dass diese mit true/false läuft statt mit 1/0.

Daraus ergibt sich ein RAM Erspanis von ca. 100MB.
WTF

[smhrambo]

@homoran Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.
Kein anderer Adapter scheint diese Daten zu benötigen oder der JS Adapter interpretiert die Daten falsch.
Ich habe eine Idee, dehalb meine Frage wie ich die Objekte von bestimmten Daten befreien kann.

Ich habe versucht eine Art semantisches Modell meines Hauses zu erzeugen.

Den JS Adapter habe ich die letzten Monate nicht benutzt,
weil ich die Hardware für die ich die Skripte brauche reparieren musste.
Nun ist Weihnachten und der JS Adapter soll mein Weihnachtsprogramm laufen lassen und nun läuft er nicht mehr.
Also habe ich inzwischen den Verdacht, dass es an der Zuordnung in der ioBroker Aufzählungen liegen könnte.

Ganz wilde Theorie:
Vielleicht gibt es durch die Zuordnung eine Schleife, da ich mit Stockwerken und Räumen gearbeitet habe.

[Homoran]

@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:

Auf welche Daten greift der JS Adapter aber zu, dass er so RAM benötigt.

Ich kann vollkommen daneben liegen, aber ih denke hier liegt dein Denkfehler.
Wer sagt dir dass der Adapter so viel RAM benötigt, wenn der js HEAP für alle javascript Aktionen (auch im Grundsystem) gilt?

[smhrambo]

@homoran Kannst du mir deinen Gedankengang näher erläutern.

Also wenn ich den JS Adapter aktiviere, startet dieser nach ein paar Sekunden neu und im Log stehen die oben genannten Fehlermeldungen.
Die Log Meldungen wiederholt sich bei jedem Absturz und Neustart vom JS Adapter.
Dementsprechend habe ich für die Fehlermeldung den JS Adapter im Verdacht.
Ist der JS Adapter deaktiviert, kommt die Fehlermeldung nicht.

[Marc Berg]

@ro75 sagte in JS-Adapter startet ständig neu: heap out of memory:

Aus meiner Sicht:

wenn du weiterhin mit Docker arbeiten willst/musst dann brauchst du mehr RAM

Die 3 Punkte unter dem Gesichtspunkt, dass du mit Docker arbeiten willst. Alternativ verzichte auf Docker (zumindest ohne ioBroker, nur für andere Projekte).

Wenn der RAM knapp wird, hilft natürlich jeden Megabyte mehr. Trotzdem glaube ich, dass der Overhead durch Docker überschätzt wird.
Habe das gerade mal auf einer VM nachgestellt

1. ioBroker nativ installiert
2. ioBroker unter Docker installiert

Jeweils mit identischer Installation (frisch aufgesetzt mit Admin+Backitup Adapter) ergibt sich ein Unterschied von ca. 75 MB.

nativ

unter Docker

[OliverIO]

@smhrambo

Ich weiß es zwar nicht genau, aber der hohe speicherverbrauch beim Start ist nicht der Iobroker selbst sondern der jit Compiler der v8 Maschine.

Hat eigentlich mal jemand probiert Iobroker mit deno oder bun zu starten?

[smhrambo]

@marc-berg Deshalb glaube ich auch nicht das es an Docker liegt.
Besonders schon deswegen, das es nur beim einspielen des Backups auftritt.

Ich versuche so viel Strom wie möglich zu sparen und das System lief 3 Jahre ohne Probleme.
Beim Verbrauch ist ein Pi sehr optimal, besonders dann wenn man so wie ich über GPIO einiges an Zusatzmodulen dran hat.

Ich Betreibe mehrere Server die aber nur nach Bedarf aktiv werden.
Meine NAS (Synology), die infrage kommen würde, ist leider in ihrere Konfiguration und IO sehr eingeschränkt(Es sind keine VLANs mit VM Betrieb möglich).
Ich betreibe hier ein Netzwerk im ZeroTrust Verfahren mit 13 Subnetzen und VLANs. Aufgrund der eingesetzten Software kommt für mich nur MACVLAN per Docker infrage.
Es gibt leider Software, auch im IoT und Smarthome Bereich, die eine Änderung der Ports oder der IP nicht zulassen(Raspberrymatic, diyhue, ...). Um diese auf dem selben Host laufen zu lassen müssen diese entweder in einer VM laufen (absoluter overkill) oder eben in einem Container mit MACVLAN.
Zudem ist mein Pi komplett Autark, es ist für die Bereitstellung von WLAN, DHCP usw. im IoT Subnetz verantwortlich und hat seine eigene Stromversorgung gegen Netzausfall.
Das kann so Tage weiter operieren.
Bei einer NAS die 100W zieht, ist das nicht so einfach möglich.

[smhrambo]

@oliverio
Da bin ich leider raus, JS ist nicht meine Stärke.
Was ist bun bzw. deno und wie startet man ioBroker damit.

[OliverIO]

@smhrambo
Alternativen für Node
Deno wurde vom ursprünglichen Erfinder von Node gestartet.

[smhrambo]

@oliverio Ich glaube daraus wird leider nichts, da deno aktuell nur für Mac als arm64 vorliegt.
Ich müsste es erst für das Pi kompilieren.

[OliverIO]

@smhrambo

Sorry ich dachte du meinst es liegt nur für mac vor.

Ja für raspi muss man es wohl kompilieren. Geht aber wohl
Aber keine Ahnung ob das für Iobroker überhaupt geht.
Diese Maschinen haben wohl Performance Vorteile.
Evt nutzt Iobroker aber spezifisches von Node.
Daher hochexperimentiell

[smhrambo]

So ich konnte das Problem eingrenzen.
Ich habe den funktionierenden JS Adapter in silly loggen lassen.
Dabei ist mir aufgefallen, das der JS Adapter beim Start alle Objekte und alle State anfordert.

So wie es aussieht, werden dabei für jedes Objekt eine Art Callback erzeugt.
Beim loggen des JS Adapters ist mir aufgefallen, das dieser auf absolute jede Änderung in den Objekten reagiert, nicht nur für die die man in seinen Skripts benutzt.

Keine Ahnung ob das geht, aber ich würde den JS Adapter eher dazu bringen, bei Skripten mit on(["..."], function (data) {..." nur für nötigen Objekte einen Callback anlegen zu lassen.

Ich habe mir den Quellcode noch nicht angeguckt.

Beim Vergleich der Objekt Datenbanken von der Installation die funktioniert und die die nicht funktioniert ist mir aufgefallen, dass die die nicht funktioniert mehr als doppelt so viele Objekte besitzt und fast 3 mal so viele States hat.

Im meinem MQTT Adapter waren ca. 6000 Objekte drin.
Nach dem Löschen der Objekte, läuft der JS Adapter ohne Probleme.

Stellt sich immernoch die Frage wie es dazu gekommen ist.

[OliverIO]

@smhrambo
Da gibt es in den Einstellungen was damit der js Adapter nicht alle Datenpunkte abonniert

[smhrambo]

@oliverio Lol, danke.

Ich werde jetzt spaßeshalber noch mal das Backup einspielen, die Option aktivieren und gucken.

[ticaki]

@oliverio sagte in JS-Adapter startet ständig neu: heap out of memory:

@smhrambo
Da gibt es in den Einstellungen was damit der js Adapter nicht alle Datenpunkte abonniert

In dem fall mußt du aber die getStateAsync versionen verwenden oder mit callback arbeiten und die Aufrufe dürfen mehr Zeit/Rechpower brauchen.

[smhrambo]

Leider hat es nicht geholfen diese Einstellung im JS Adapter zu aktivieren.
Aber ich konnte das MQTT Topic ausmachen, welches diesen Fehler verursacht hat.
Es war der homeassistant Topic für die Bekanntmachung von Geräten usw.
Nachdem der gelöscht war, lief das System ohne Probleme.

Für mich ist das Thema damit eigentlich erstmal durch.
Ich werde die Sache auf jeden Fall beobachten,
wobei sich bei mir folgende Fragen stellen:

1. Warum steigt der homeasstant Topic auf über 3000 Objekte an.
   Es könnte sich um folgende Probleme handeln:
   • MQTT Adapter entfernt die Objekte nicht richtig, nachdem diese vom Broker gelöscht wurden (ich setze rabbitMQ ein und habe vor kurzem alles gelöscht gehabt)
   • ioBroker Objektsystem (unwahrscheinlich)
   • Implementierung von einem MQTT Client(ems-esp, esphome, valetudo, zigbee2mqtt)
2. "Warum"(Wenn kein RAM, dann kein RAM) reagiert das JS System von ioBroker so darauf, wenn der JS Adapter gestartet wird und gibt es Möglichkeiten dies zu verhindern bzw. abzudämpfen.

Das ganze passier auf jeden Fall zwischen diesen Aktionen vom JS Adapter:
requesting all states
requesting all objects
received all states
----UND----
received all objects

[Marc Berg]

@smhrambo sagte in JS-Adapter startet ständig neu: heap out of memory:

Warum steigt der homeasstant Topic auf über 3000 Objekte an.

das musst du wohl HA fragen

MQTT Adapter entfernt die Objekte nicht richtig, nachdem diese vom Broker gelöscht wurden (ich setze rabbitMQ ein und habe vor kurzem alles gelöscht gehabt)

So funktioniert das nicht, es gibt unter MQTT kein Löschen von Topics.

[paul53]

@smhrambo sagte: Das ganze passier auf jeden Fall zwischen diesen Aktionen vom JS Adapter:

requesting all states
requesting all objects
received all states
----UND----
received all objects

Das ist erforderlich, da der JS-Adapter alle Objekte und Zustände puffert, um die synchronen Versionen von z.B. getState(id) und getObject(id) zu ermöglichen.