Der neue Monatsrückblick für September 2026 ist online!

[Asgothian]

@Leonie sagte:

Hallo zusammen,

da im Forum immer wieder Threads zu Problemen mit Debian-Updates, Node.js-Versionen, kaputten npm-Permissions oder vertauschten USB-Serial-Pfaden auftauchen, geistert mir seit ein paar Tagen ein Konzept durch den Kopf:

Ein fertiges "ioBroker OS" als Flash-Image für den Raspberry Pi Imager oder auch VMs und andere Hardware.

Die Idee dahinter kurz zusammengefasst:

• Basis: Schlankes Debian-Base-Image, das über die CI/CD gebaut und als fertiges Image (über Pi Imager flashbar) bereitgestellt wird.
• Kapselung: ioBroker läuft sauber in einer Docker-Umgebung (getestete Node.js-, Python- und Build-Tools-Kombination).
• Unter der Haube: Ein schlanker, performanter OS-Agent (in Go geschrieben) läuft auf dem Host.
• Kommunikation: Ein maßgeschneiderter ioBroker-Adapter kommuniziert über einen Unix Domain Socket direkt mit dem OS-Agenten.
• UX für Einsteiger:
  • USB-Sticks (Zigbee, Z-Wave, Homematic etc.) werden auf Host-Ebene via Udev erkannt und automatisch über saubere Symlinks/Verzeichnisse in den Container gereicht – ohne Terminal- / SSH-Kenntnisse.
  • System-Updates (Host & Container) und USB-Zuordnungen können direkt über die ioBroker-Admin-Oberfläche eingesehen/gesteuert werden.

Bevor ich hier tiefer in die Entwicklung vom Konzept, des OS-Agent oder des Image-Builds einsteige, würde mich eure Meinung interessieren:

1. An die Nutzer: Wäre ein solches vorgefertigtes "Plug-and-Play"-Image für euch interessant?
2. Welche Schmerzpunkte fehlen aus eurer Sicht bei aktuellen Pi-Setups am meisten?
3. An die Core-Devs / Erfahrenen: Seht ihr bei dem Konzept mit OS-Agent + Unix-Socket + Docker-Kapselung noch wesentliche Fallstricke im ioBroker-Kontext?

Als entwickler eines Hardwarenahen Adapters sehe ich dabei mehrere Fragezeichen.

• Warum ein vollständiges Image, wenn sowieso via Docker gekapselt werden soll ?
• Warum Docker, wenn das OS sowieso via OS-Agent vom ioBroker aus steuer- und verwaltbar gemacht werden soll ?
• Was ist der Benefit ausserhalb der direkten Verwendung dieses Setups ?
• Warum GO für den OS Agent ? Hier sollte denke ich die Frage gestellt werden in welcher Sprache dieser Agent für die Zukunft sauber wartbar erstellt werden sollte.
• wie wird die Wartung des gesamten Konzeptes sichergestellt, wenn Du (als Ersteller) irgendwann das nicht mehr machst (kannst, willst, etc. - kein Vorwurf, aber in der open source Community ein gängiges Problem)

Ich denke Entscheidend ist die Bereitstellung eines OS-Agents / Adapters zur Wartung des Grundsystems über den OS-Agent als Tool zur Installation auf frei installierten Systemen - das ist vollständig unabhängig vom Image.

Ansonsten würde ich gezielt nicht auf Docker setzen. Dafür ein fertiges OS Image mit installiertem basis-ioBroker. Das Image muss aktualisert werden, wenn eines der folgenden Ereignisse eintritt

• die empfohlene NodeJS Version wird angehoben
• eine neue major Version des JS-Controllers kommt ins Stable
• das Basis-OS des Images geht innerhalb der nachfolgenden 8 Wochen ins oldstable, und eine neue stable version ist verfügbar

Wichtig ist in diesem Zusammenhang, das Docker auf dem Basisimage installiert ist, damit der OS-Agent zusätzliche Dienste als Container installieren kann (Datenbank zur Datenspeicherung, Grafana, Z2M, und so weiter)

Unterm strich ist das erstellen und dokumentieren dieses Images der kleine Teil des Projektes. Auch das Erstellen des OS-Agents ist (trotz der Komplexität) eher ein kleinerer Teil. Die alles entscheidende Frage ist wer hält das wie und wie oft auf Stand.

A.

Nachtrag: der ioBroker kann inzwischen den JS-Controller selber aktualisieren. Ich denke über die gleiche Methode sollte es möglich sein, das der ioBroker auch das aktualisieren der Node-Version aus der Oberfläche heraus anbieten kann. Ob man das auch für OS Patches erlauben sollte weiss ich allerdings nicht.

Edit: Beim durchlesen ist mir noch etwas aufgefallen: Aus meiner Sicht sollte ein über Docker gekapselter Service gerade nicht in der Lage sein das OS auf dem der Container läuft nachhaltig zu modifizieren. Diese Trennung wird in dem Konzept über den OS-Agent aufgebrochen. Das halte ich nicht für Sinnvoll.

A.

[Thomas Braun]

@Asgothian sagte:

Dafür ein fertiges OS Image

Müssten ja schon mindestens zwei sein. Eins mit arm64 und eins mit amd64 als Basis.
Und dann davon je eine Version mit und ohne Graphic Stack.

Und wo kommen die regelmäßig eintrudelnden Security-Updates des OS her?

[Asgothian]

@Thomas-Braun sagte:

@Asgothian sagte:

Dafür ein fertiges OS Image

Müssten ja schon mindestens zwei sein. Eins mit arm64 und eins mit amd64 als Basis.

Das gilt immer, wenn das Image neben dem RPi auch auf klassischen PCs laufen soll, also auch für das Originalkonzpt.

Die OS updates werden über den OS-Agent vom iobroker Admin angestoßen, genauso wie das hinzufügen von docker Applikationen.

Ein GUI Image entfällt damit.

A.

Klarstellung zu gui und Updates

[OliverIO]

@Thomas-Braun

Und wo kommen die regelmäßig eintrudelnden Security-Updates des OS her?

die kommen vom verwendeten upstream os Layer. Buanet aktualisiert und generiert automatisch das Image immer wieder neu wenn sich was ändert

Nur bei Major Änderungen muss ggfs was gemacht werden

Kann man hier sehen. Jedes separate Image erhält einen eigenen Tag
https://hub.docker.com/r/iobroker/iobroker/tags
Wird alles bei GitHub gemacht und nach dockerhub hochgeladen
Das selbe bei nodejs.
Das Docker Dateisystem ist in Schichten aufgebaut die sich überlagern.
Also Iobroker nutz als Basis ein nodejs Image. Dieses nutzt dann als Basis ein os Image

[Thomas Braun]

@Asgothian sagte:

Die OS updates werden über den OS-Agent vom iobroker Admin angestoßen, genauso wie das hinzufügen von docker Applikationen.

Das möchte ich stabil und zuverlässig erstmal sehen. Das bekommen selbst die Distributionen selber nicht hin.
Schau dir nur mal den Tanz z. B. bei Ubuntu bei einem Release-Wechsel an.

Das wird der ioBroker nicht leisten können, da kannste 'abstrahieren' wie du willst, wenn es an's Eingemachte geht wird das regelmäßig zu Problemen führen. Und das wird dann noch mehr dem 'frickeligen ioBroker' angelastet werden. Der User kennt ja nicht anderes als dieses 'ioBrokerOS'.

[Thomas Braun]

@OliverIO sagte:

Buanet aktualisiert und generiert automatisch das Image immer wieder neu wenn sich was ändert

Und dieses Image zieht wer bei Bedarf beim User auf die Kiste?

[OliverIO]

@Thomas-Braun
Ich denke der besagte os Agent.
Da ist ein watchdog dann eingebaut. Der erkennt wenn ein neues Image vorliegt und führt ein Docker pull Befehl aus, also Download. Wenn das fertig ist startet man (automatisiert) den Container einfach neu, fertig. Genau so kann man das heute schon mit dem Iobroker Container machen.
Wenn fertig ist os und nodejs aktualisiert. Iobroker und Adapter laufen mit den normalen Mechanismen.
Alles User individuelle liegt in sogenannten volumes. Das kann man sich als mounts vom filesystem in den Container hinein vorstellen

Gibts auch schon
https://hub.docker.com/r/buanet/watchdog

[Thomas Braun]

Ich bleib dabei:
Ohne ein gewisses Basis-Wissen und Interesse daran, dieses Wissen zu erwerben wird das nicht funktionieren. Da kannste 'Abstrahieren' und irgendwelche Helferlein bereitstellen wie du willst. Sehe ich ja an meinen 'nodejs-update'-Helferlein. Da muss auch ständig nachgelegt werden, weil es dennoch zu irgendwelchen

Funktioniert in anderen Bereichen ja übrigens auch nicht. Niemand lässt dich ein Formel-Rennauto fahren, wenn du nicht in kleineren Klassen etwas Erfahrung über Fahrphysik und Rennregeln gesammelt hast. Da nutzt dir dein vor 30 Jahren erworbener 'Klasse III-Lappen' auch nix, trotz aller 'abstahierten Helferlein'.

Und du kommst ohne Nachweis der 'Platzreife' auch auf keinen Golfplatz. 'Minigolfplatz im Märchenpark' vielleicht ausgenommen.

Und es stellt sich mir dann auch immer noch die Frage, warum der bestehende Docker-Container nicht schon längst auf eine Debian 13-Basis setzt. In 12 Monaten wird Debian 14 'Forky' veröffentlicht werden, es wird also jetzt langsam Zeit da auf eine andere Basis zu setzen. Denn irgendwann wird Docker einen Kernel xyz verlangen werden. Und dann biste da wieder am 'frickeln'.

[OliverIO]

@Thomas-Braun

Irgendwo hab ich mal gelesen, dass buanet nicht mehr so viel Zeit hat.
Wer das Projekt übernehmen wollte, habe ich allerdings nicht mitbekommen.
Wahrscheinlich niemand.

[Thomas Braun]

@OliverIO

Womit wir dann wieder bei @mcm1957 wären:

Sofern sicherstellbar ist dass jemand das zumindest mittelfristig suppoerted,d.h. zumindest mehrmals wöchentlich hier im Forum reagiert kann man das dirchdenken.

Das Thema 'ioBrokerOS' ist für das Projekt mindestens zwei Schuhgrößen zu groß.

Und wenn ich mich recht entsinne gibt es doch heute schon im Admin ein Knöpsken für nodejs-Updates (zumindest innerhalb einer Major-Version) und auch für OS-Updates meine ich sowas schon mal gesehen zu haben.
Hat nur bei mir nicht funktioniert und ich hab es dann sicherer, bequemer und schneller per Terminal gemacht.

[OliverIO]

@Thomas-Braun

Gut, die Frage kann man sich bei jedem Adapter stellen.
Wenn man so argumentiert, darf man dann nie einen Adapter erstellen.
Allerdings sehe ich natürlich so ein Vorhaben schon als ein größeres Ding an.
Wenn dann mehrere Nutzer darauf vertrauen und eventuell in zwei Jahren, das nicht mehr gewartet ist, dann wird es schwierig.

[Bluefox]

Eigentlich sollte im Admin noch apt upgrade/update -y startbar sein. Dafür werden auch viele Danke sagen

[mcm1957]

@OliverIO said:

@Thomas-Braun

Gut, die Frage kann man sich bei jedem Adapter stellen.
Wenn man so argumentiert, darf man dann nie einen Adapter erstellen.
Allerdings sehe ich natürlich so ein Vorhaben schon als ein größeres Ding an.
Wenn dann mehrere Nutzer darauf vertrauen und eventuell in zwei Jahren, das nicht mehr gewartet ist, dann wird es schwierig.

ioBroker OS ist micht mit jedem Adapter vergleichbar. Wäre max mit admin javascript etc vergleichbar. Und js /ts Adapter können prinzipiell viele warten. Dass die Wartung bei vis* schon mässig ist zeigt die Erfahrung.

Wär von den Entwicklern würde sich prinzipiell dazu in der Lage sehen ind zumindest drüber nachdenken ein solches System (os nahe, docker, go,...)zu warten? Bin gespannt ob sich wer meldet.

[OliverIO]

@mcm1957

Allerdings sehe ich natürlich so ein Vorhaben schon als ein größeres Ding an.

was ich ja auch so geschrieben habe

[Homoran]

@OliverIO war ja auch dein Zitat 😉

[FernetMenta]

@mcm1957 sagte:

Wär von den Entwicklern würde sich prinzipiell dazu in der Lage sehen ind zumindest drüber nachdenken ein solches System (os nahe, docker, go,...)zu warten? Bin gespannt ob sich wer meldet.

Ich würde unterstützen. Ich würde auch bei der Pflege des aktuellen Docker Images helfen bzw. es auch ganz übernehmen, sollte Andre keine Lust mehr haben.

[Asgothian]

@mcm1957 sagte:

Wär von den Entwicklern würde sich prinzipiell dazu in der Lage sehen ind zumindest drüber nachdenken ein solches System (os nahe, docker, go,...)zu warten? Bin gespannt ob sich wer meldet.

Nicht Docker, nicht Go sondern C, C#, JS oder python, dann könnte ich mir das sogar vorstellen.

Bei Docker und Go ist dann bei mir aber schluss.

A.

[Leonie]

Hi,

Danke für eure Diskussion! :-)

Auch ich bin bei ioBroker, weil ich die Flexibilität schätze und das starre System von Home Assistant nicht zwingend bevorzuge. Zur Wahrheit gehört aber auch: Es gibt viele Nutzer, die genau diese Einfachheit suchen.

Ich möchte keineswegs „den einen neuen Weg“ für ioBroker aufzwingen. Meine Vision des ioBroker OS ist ein optionales Zusatzangebot. Primär soll und muss ioBroker genau das bleiben, was es ist: eine Node.js-Applikation, die auf jedem beliebigen System installiert werden kann. Das OS wäre eine schlüsselfertige Alternative für diejenigen, die schlicht keine Muße haben, sich mit Linux-Unterbau, Node-Updates oder Permissions auseinanderzusetzen.

Zur Wahl von Go für den OS-Agenten:
Eigentlich wollte ich die Sprache für den Agenten gar nicht festlegen, mir ist Go in der Diskussion nur als Beispiel herausgerutscht. Warum aber Go? Es ist extrem portabel, kompiliert in ein einziges statisches Binary (zero dependencies) und bietet native Leichtigkeit bei Concurrency (Goroutines). So kann eine Goroutine die Socket-Verbindung zum ioBroker-Adapter halten, während eine andere Kerneltasks oder Docker steuert.

Zu den Bedenken bzgl. OS- & Adapter-Wartung:

@Thomas-Braun sagte:

Schau dir nur mal den Tanz z. B. bei Ubuntu bei einem Release-Wechsel an.

Genau hier setzt das Container-Konzept an: Exakt dieser „Tanz“ entfällt für den Endanwender. Was auf dem Host passiert, ist vom Container entkoppelt. Solange der Linux-Kernel steht, läuft die definierte Container-Umgebung stabil durch.

@Asgothian sagte:

Als entwickler eines Hardwarenahen Adapters sehe ich dabei mehrere Fragezeichen.

Ich verstehe deine Argumentation und die Idee, den OS-Agenten entkoppelt auch für freie Debian-Systeme anzubieten, ist extrem gut.

Bei der Frage Docker vs. Nativ bin ich allerdings ehrlich: Ich bin ein absoluter Verfechter von Containern.

Der Grund, warum ich ioBroker trotz fertigem OS-Image zwingend in Docker sehe, ist die garantierte Immunität gegenüber dem Host:

• Unzerstörbare Runtime: Selbst wenn das Host-OS aktualisiert wird, bleibt die Node.js-Version, die Python-Umgebung und der ioBroker-Core im Container zu 100 % unangetastet und in einem definierten, getesteten Zustand.

• Sauberes Resetting / Rollback: Geht bei Adapter-Experimenten oder im Dateisystem etwas schief, zieht man das Container-Image neu hoch – ohne dass OS-Reste oder verwaiste npm-Pakete den Host zumüllen.

• Zusatzdienste: Wenn Docker für Grafana, InfluxDB oder Z2M sowieso auf dem Host läuft, ist der Schritt, auch ioBroker als Container laufen zu lassen, architektonisch nur konsequent.

Ein fertiges Image drumherum braucht es schlichtweg für Einsteiger und reine Anwender: Sie bekommen damit das Beste aus beiden Welten – ein vorbereitetes System mit passendem Handling auf Host-Ebene und eine echte Plug-and-Play-Erfahrung ohne SSH-Zwang.

Zum Thema Langzeit-Pflege & Bus-Faktor:
Dass ich irgendwann nicht mehr die Zeit oder Lust haben könnte, das Projekt alleine zu stemmen, sehe ich keineswegs als Vorwurf, sondern als realistischen Fakt. Kein Einzelner kann eine Applikation ewig alleine pflegen.

Genau deshalb habe ich diese Diskussion gestartet: Ich wollte abklopfen, ob überhaupt ein grundsätzlicher Bedarf in der Community besteht und ob sich Gleichgesinnte finden, die Lust haben, an einem solchen Konzept mitzuentwickeln. Ein Tool kann technisch noch so elegant sein – ohne Nutzer und Co-Maintainer macht es langfristig keinen Sinn.

Liebe Grüße

[Thomas Braun]

@Leonie sagte:

Genau hier setzt das Container-Konzept an: Exakt dieser „Tanz“ entfällt für den Endanwender.

Aber (wie bei allen dieser Tools) auch nur vordergründig. Der Docker/Container/was auch immer läuft genau wo angedockt? Die Basis muss ja auch aktuell gehalten werden.

Das ganz grundlegende 'Problem' und warum ich das eigentlich gar nicht gerne sehe und warum ich auch ganz lange mit dem 'iob nodejs-updater' gezögert habe ist:

Es wird eine Einfachheit vorgegaukelt, die nicht vorhanden ist und nur 'wegabstrahiert' wird.
Dann muss der user sich (vermeintlich) auch nicht mehr mit den absoluten Basics auseinandersetzen, fährt dann aber trotzdem irgendwann vor die Klippen.
Und deswegen sehe ich auch z. B. sowas hier durchaus kritisch:
https://forum.iobroker.net/topic/62489/proxmox-updater-host-lxc-vm-auch-iobroker-pihole-etc

In anderen Projekten wird das übrigens ganz ähnlich gesehen. Hier mal ein Thread zu dem von mir verwendeten Betriebssystem:

https://forum.endeavouros.com/t/introducing-neoarch-v3-a-unified-package-and-system-manager-for-arch-linux/81344

Da kommt auch jemand mit einer tollen 'einfach mal klicken - Fertig'-Lösung an.
Bewertung dazu:

Tools like this have their place but should be reserved for those who are already familiar with Arch and its Packaging system and Yet that will be the last group to use such a tool as this.

Und das ist auch für den ioBroker anwendbar. Solche Tools sind nur für Anwender sinnvoll, die ein Grundverständnis über das System und wie es funktioniert mitbringen oder zumindest erlangen wollen. Und wenn man das notwendige Grundverständnis hat braucht man die Tools nicht mehr. Im Gegenteil, die stehen dir dann eher im Weg.

Vermutlich wäre statt des nächste 'One-Klick-for-all'-Dings Arbeit an der Dokumentation sinnvoller.

[OliverIO]

@Thomas-Braun sagte:

Und das ist auch für den ioBroker anwendbar. Solche Tools sind nur für Anwender sinnvoll, die ein Grundverständnis über das System und wie es funktioniert mitbringen oder zumindest erlangen wollen. Und wenn man das notwendige Grundverständnis hat braucht man die Tools nicht mehr. Im Gegenteil, die stehen dir dann eher im Weg.

also dann auch für iobroker os? :)
sorry, polemisch.

ich sag meist, einfach probieren
wer weiß ob auf dem weg noch Fallstricke lauern
ein disclaimer rein, das das ein experiment ist (etwas softer formuliert, nicht das experiment gleich abschreckt)

evtl noch eine Ergänzung zu meiner Meinung oben:
Of hat sich gezeigt, das jemand über einen einfachen Weg den Einstieg in smart-home und auch iobroker findet. Evtl ist deswegen home-assistant auch so beliebt (neben der Bekanntheit)
So eine Möglichkeit, bei dem docker und installation web abstrahiert wird, könnte das schaffen.

Allerdings zeigt sich bei einigen Anwendern auch, wenn der Einstieg mal geschafft ist, dann wollen manche mehr. Solange das alles in Adaptergrenzen möglich ist, alles gut.
Kommt Hardware dazu und der OS-Agent bekommt die meisten Fälle hin, auch das einfachst zu konfigurieren. Auch gut.

Wenn noch mehr Anforderungen kommen, dann hilft jemanden sowas nicht mehr, dann muss er selbst frickeln und seine spezielle Lösung anpassen.

Man sieht das auch im Forum oft, wie viele ihren Raspi bis zu seinen Grenzen quälen, obwohl es eigentlich Zeit für ein größeres System wäre. Bei dieser Entscheidung tun sich einige schwer.

Wenn dann der Zeitpunkt kommt von der einfachen Lösung mit iobroker OS auf eine eigene Installation zu wechseln, kommt dann erst das lernen (und die Schmerzen).

Das sollte allen Nutzern klar sein, deswegen auch der Disclaimer.