Neuer ioBroker-Blog online: Monatsrückblick März/April 2026

[Jan1]

Das war die falsche ;)

[mtbsteve]

@homoran
Ein screenshot von Top kurz bevor das System einfriert:

[mtbsteve]

@jan1 und was ist die richtige?

[Jan1]

@mtbsteve
die ohne Desktop und da am besten die lite.
Der 3er Pi hat 1GB RAM und der Desktop frisst da schon mal die Hälfte, also Probleme vorprogrammiert ;)

[Thomas Braun]

@jan1

Die Lite ist immer ohne Desktop.
Also die Empfehlung geht zu: 64bit Lite.

@mtbsteve
Da läuft dann kein Xorg, kein Chromium usw unnötig mit und du musst die Kiste nicht brutal vom Strom reißen. Schlächter!

[duejo]

@mtbsteve Moin, ich habe noch einen Rpi3 mit bullseye lite 32bit in aktuellem Zustand am laufen. Mit admin 5.3.8 funktioniert alles im Rahmen der Möglichkeiten des Gerätes. Ein Updateversuch auf admin 6.2.17 bzw. 6.2.20 führte bei mir jeweils zum beschriebenen einfrieren. Vielleicht hilft der Hinweis, ich bleibe mit dem Rpi3 erstmal auf admin 5.3.8.

[mtbsteve]

@duejo danke. Das erklärt es!! Ja ich bin auf Admin 6.2.20.

[Thomas Braun]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Das erklärt es!!

Nein, jedenfalls nicht vollständig.
Hast du jetzt ein System ohne Desktop laufen?

[Homoran]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Ein screenshot von Top kurz bevor das System einfriert:

als Text in code-tags wäre besser gewesen als ein angeschnittener Screenshot.
hier kann man nichts zitieren.

die Load average mit 2.5 geht noch
und auch die Prozesse due man sieht sind nicht wirklich arg.

allerdings geht es dem mickrigen RAM nicht wirklich gut, auch der SWAP ist bereits ziemlich verbraucht.
Ohne GUI Kram sollte da noch mehr Luft sein.

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Das erklärt es!! Ja ich bin auf Admin 6.2.20.

nicht wirklich! Auch für v6 müsste genug RAM da sein, wenn er nicht unnötig verpulvert würde.

TOP mal nach MEM sortieren!
so über den Daumen sieht man jetzt schon 58% RAM von chromium verbraucht.

[mtbsteve]

Vielen Dank euch allen!
Ich habe den iobroker jetzt auf der 64bit lite Version von Bullseye zum laufen bekommen.

Das Problem liegt nach meiner Analyse an zu wenig Memory des Raspi 3 den iobroker im Raspi Browser laufen zu lassen, zumindest in der aktuellen Version des Admin Adapters. Der Raspi Speicher läuft nach wenigen Sekunden nach Aufruf des Admin Adapters im Raspi Chromium (oder Firefox) Browser zu.

Wenn ich von einem anderen (leistungsfähigeren) Rechner via Browser auf den Raspi iobroker zugreife, funktioniert alles ohne Probleme.

[Jan1]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Wenn ich von einem anderen (leistungsfähigeren) Rechner via Browser auf den Raspi iobroker zugreife

Das versteh ich jetzt nicht wirklich. Was heißt da wie Browser? Du meinst du öffnest einfach die Admin Oberfläche des IOBoker und das bremst den Pi? Ich hatt den 3er Pi im Einsatz und wenn der richtig konfiguriert ist, dann läuft selbst der ohne Probleme, wenn nur die lite Version des OS auf dem Pi läuft.
Das hat mit dem Rechner von dem aus der Zugriff stattfindet aber nicht wirklich was zu tun ;)

[Thomas Braun]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Das Problem liegt nach meiner Analyse an zu wenig Memory des Raspi 3 den iobroker im Raspi Browser laufen zu lassen,

In der Lite-Version gibt es keinen Browser, der lokal auf dem Raspberry laufen würde.

[Homoran]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Das Problem liegt nach meiner Analyse an zu wenig Memory des Raspi 3 den iobroker im Raspi Browser laufen zu lassen

Das ist jetzt eine neue Info!
Hat ichts mit iob auf pi3 an sich zu tun.
Warum willst du auf dem selben pi3 auf dem der ioBroker Server läuft auch noch eine speicherfressende GUI mit Browser laufen lassen um dort lokal auf ioBroker zuzugreifen.

Dein Problem ist dann wie vermutet nicht ioBroker, sondern der Grafik Overhead, der 3x mehr Ressourcen brau ht als der ioBroker.

[mtbsteve]

ich würde es so formulieren - es ist der Grafik Overhead des ioBroker UIs, welches letztendlich den Raspi 3 in die Knie zwingt. :-)

Ich habe den IOB nun auf der Bullseye lite Version, ohne Desktop und Browser laufen und greife auf den IOB von einem anderen Rechner im Netz zu.
Das funktioniert soweit jetzt einwandfrei.

[Thomas Braun]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

es ist der Grafik Overhead des ioBroker UI

Nein, es ist der Overhead aus laufendem X-Server, Desktop Environment und diverser Chromium-Prozesse. Das passt nicht mehr sinnvoll in 1GB RAM.
Und unnötig ist es aus vielen weiteren Gründen auch noch.

[Homoran]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

es ist der Grafik Overhead des ioBroker UIs, welches letztendlich den Raspi 3 in die Knie zwingt.

Nein!

sieh dir doch unter TOP die Verbraucher deines RAM an.
alleine auf dem Screenshot, der nicht nach MEM sortiert ist, sieht man dass ca. 80% deines RAM alleine von Chromium verbraten werden!

[OliverIO]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Ich habe noch ein paar Anwendungen drauf die wahrscheinlich nicht so ohne weiteres auf Bullseye

Dann gäbe es da noch die Möglichkeit das unter Bullseye in einem docker-container mit einem der angebotenen stretch-images auszuführen.
https://hub.docker.com/_/debian/tags?page=1&name=stretch

[Thomas Braun]

Ich habe noch ein paar Anwendungen drauf die wahrscheinlich nicht so ohne weiteres auf Bullseye

Das wäre halt zu prüfen. Die Wahrscheinlichkeit halte ich aber für sehr gering.
Da wird es was aktuelles geben oder zumindest eine aktuelle Alternative.

[mtbsteve]

@homoran said in ioBroker läuft nicht auf RasperryPI3:

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

es ist der Grafik Overhead des ioBroker UIs, welches letztendlich den Raspi 3 in die Knie zwingt.

Nein!

sieh dir doch unter TOP die Verbraucher deines RAM an.
alleine auf dem Screenshot, der nicht nach MEM sortiert ist, sieht man dass ca. 80% deines RAM alleine von Chromium verbraten werden!

Nicht ganz. Der Screenshot entstand kurz nachdem der iobroker Admin Adapter im Browser aufgerufen wurde. Die Memory Allocation der Chromium Browser Prozesse steigen danach kontinuierlich weiter bis der Raspi wenige Sekunden später einfriert und nur noch hard-resettet werden kann.
Ich würde das mal als Limitation des iobroker UIs, speziell des Admin-Adapters, auf Rechnern die zuwenig Memory haben wie ein Raspi 3, klassifizieren.
Gut, man könnte auch sagen dass Chromium solche Fälle über eine Exception abfangen sollte. Die Entscheidung überlasse ich anderen :-)

[Homoran]

@mtbsteve sagte in ioBroker läuft nicht auf RasperryPI3:

Ich würde das mal als Limitation des iobroker UIs, speziell des Admin-Adapters, auf Rechnern die zuwenig Memory haben wie ein Raspi 3, klassifizieren.

nochmals die Frage

@homoran sagte in ioBroker läuft nicht auf RasperryPI3:

Warum willst du auf dem selben pi3 auf dem der ioBroker Server läuft auch noch eine speicherfressende GUI mit Browser laufen lassen um dort lokal auf ioBroker zuzugreifen?

Der RasPi für ioBroker stellt einen Server dar. Dafür ist ein Pi3 bis zu einer gewissen (geringen) Zahl an Instanten geeignet.

Wenn dein PC auch nur 1GB RAM hätte bekäme er auch Probleme Grafik darzustellen.
Warum meinst du dass Grafikkarten oft mehr Leistung haben als der PC selber.