Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[steckenpferd]

Hi,

von Bekannten die mit IoBroker angefangen und danach Home Assistant ausprobiert haben kommt die Rückmeldung das trotz 10-15 der gängigsten Adaptern (bzw. Components bei HASS.IO) in Home Assistant der RAM Verbrauch bei ca 250MB liegt und kaum CPU Power braucht - was sehr gut ist.

Dagegen bei 10-15 Adaptern aus den Top 20 IoBroker Adaptern war Ihre Erfahrung das sie an den Anschlag beim PI kamen mit 1GB.

Frage: Gibt es eine gute Übersicht/Tipps und Tricks was die gängigsten RAM Erhöher sind die man als Anfänger vermeiden sollte um nicht in diese Problematik zu laufen? Oder müssten Alternativ die Adapter Entwickler etwas an einigen Adaptern anpassen um “effizienter” mit den Ressourcen zu wirtschaften?

Danke für das Feedback.

[Jey Cee]

Ich weiss nicht wie HASS das macht, sieht aber so aus als würde das Single Threaded laufen. Bei ioBroker läuft (noch) jeder Adapter als eigener Thread, was den ganzen Overhead an RAM mitbringt. Dafür bedeutet halt ein Adapter absturz nicht gleich System absturz.

Momentan wird am Compact Mode gearbeitet, dann ist es möglich auch ioBroker Single Threaded laufen zu lassen. Nach den Aktuellen plänen wird das mit JS Controller 2.0 kommen. Termin steht noch keiner für den Release.

Bis dahin kann man nur versuchen so wenig wie möglich Adapter zu verwenden, für vieles gibt es Skript Lösungen.

Ich weiss nicht Optimal, zurzeit die einzige Möglichkeit.

[apollon77]

Korrekt, das ist das Thema.

HASS arbeitet mit einem Python Prozess wo alles drin läuft. Ein Fehler in irgendeinem Teil und alles stürzt ab/startet neu. Früher wurde bei HASS auch bei jeder Konfigurationsänderung alles neu gestartet.

ioBroker hat hier einen etwas anderen und verteilteren Ansatz, der auch eine bessere Skalierung auf mehrere CPU-Kerne und so erlaubt. Daher ist bei ioBroker aktuell jeder Adapter ein einzelner Prozess. Aber ja das hat den Effekt das mehr RAM gebraucht wird. Der Vorteil ist aber das es besser die heutigen CPU-Ressourcen nutzt und in Summe stabiler ist, da ein Fehler in einem Adapter keinerlei Auswirkungen auf den Rest hat.

Der Haupt-Speicherverbrauch kommt von nodejs selbst was die Grundlage der Adapter ist. Das ist bei den meisten Adaptern auch schon der Großteil des verbrauchten RAMs - die nodejs/JavaScript Ausführungsschicht. Ich denke nicht das im ersten Schritt hier die Entwickler so viel tun können. In der Regel wird sinnvoll mit Ressourcen umgegangen.

Was der User aktuell hier machen kann ist mindestens nodejs 8.12 nutzen (weil es darunter ein Memory Leak gibt) und ggf überlegen eine zweiten Raspi als Slave zu nutzen um nochmal so viele Adapterinstanzen am laufen haben zu können.

Wie oben geschrieben haben wir durchaus gemerkt das viele User gern mit günstiger Hardware, die damit aber auch RAM Limitierungen mitbringt, arbeiten wollen. Eine Lösung dafür das auch wir mehrere Adapter in einem Prozess laufen lassen (mit allen damit verbundenen Nachteilen) wird im Laufe des Jahres kommen.

Wonach jeder nun das "Smart-Home-System" seiner Wahl auswählt ist verschieden. Es gilt wie immer das jedes System seine Vor- und Nachteile hat. RAM-Verbrauch vs Stabilität, UI vs Konfigfiles, Abdeckung der benötigten Geräteanbindungen, Programmiersprache und und und. Die Frage ist auch was man damit machen will und so …

Meiner persönlichen Meinung nach sollte vor allem in der heutigen zeit RAM nicht mehr unbedingt limitierend sein ;-) Und ja es gibt Alternativen zum Raspi mit 1GB ... die auch erschwinglich sind...

Ingo

[steckenpferd]

Danke für die Rückmeldungen - bei mir läuft alles auf einem alten NUC mit 8GB und Proxmox daher hatte ich da bisher keine Probleme.

Vielleicht als günstige Alternative solange es noch keine Raspberry 2GB Version gibt der neue "Orange Pi 3" mit 2GB RAM für 40$ oder rock64 mit 4GB.