Monatsrückblick Juli / August 2026 ist online!

[Rico Sander]

Als Nutzer: Wäre für mich nicht interessant.

Ich möchte selbst entscheiden, was, wie und wo läuft. Ich sehe - zumindest für mich - auch keine unüberwindbaren Probleme im gegenwärtigen System:
OS via PI- Imager auf Card / Stick, iob über Kommandozeile installiert, fertig. Die individuelle ioB-Config muss ja eh so oder so vorgenommen werden.

Ich bin mir nicht sicher, ob man ioBroker als "Blackbox" betreiben kann oder soll, ohne wenigstens rudimentäre Linux-Kenntnisse zu haben.

Und:
Was tut die "Blackbox", wenn Probleme auftreten? Analysiert sie selbst und repariert? Bleibt der Nutzer wirklich komplett außen vor und muss sich um gar nichts mehr kümmern?

Wozu muss ich - z.B - Docker installieren (lassen), wenn ich nur ein schlankes System betreibe? Es sein denn, die Install bietet genau diese Auswahlmöglichkeit, was alles installiert werden soll.

Fazit:
Für diejenigen, die ioB ohne eigenes Engagement betreiben wollen, sicher interessant. Aber als einzige Möglichkeit zu einem ioB -System zu gelangen: nein.

PS:

Das schlimmste am ioBroker ist das "gefrickel" in irgendwelchen Kommandozeilen, was Update von Paketen, Betriebssystem, Node-Versionen oder Sonstiges angeht.

Ich respektiere diese Ansicht, kann sie aber nicht nachvollziehen.

Auf der einen Kommandozeile reichen doch zwei Befehle, um das OS aktuell zu halten. Darauf wird man auch über ioB aufmerksam gemacht. Damit wird schon mal einiges gleich mit geupdatet, muss also nicht zwingend separat gemacht werden. Die Adapter Updates werden im ioB eh gemeldet, ein Klick darauf kann nicht so schwer sein.

[mcm1957]

So wie ich es sehe - sorry wenn ich mich nochmal einmische - das Konzept "Fertigsystem" ist für nicht edv affine User durchaus von Interesse. Meine einzige Sorge ist nur, dass es nach ev. kurzer Zeit keinen Support mehr geben könnte. Und dann wär es für User die diesen Installationsweg gewählt haben noch frustrierender wenn sie nicht mehr aktualisiseren können oder bei Fehlern keine (sinnvolle) Antowrt bekommen.

Schon jetzt gibt's leider das Problem, dass das Docker Image nicht wirklich intensiv gewartet wird. Mal sehen ob / wann / wie das auf node.js 24 gehoben wird.

[Thomas Braun]

@mcm1957 sagte:

Mal sehen ob / wann / wie das auf node.js 24 gehoben wird.

Und auf eine auch sonst aktuellere Basis. Das Ding liegt wohl immer noch auf dem Bookworm-Release herum. Das ist aber schon nicht mehr das aktuelle stable. Auf so ollen Ranz hätte ich nämlich keinen Bock.

[Samson71]

@Leonie sagte:

• Basis: Schlankes Debian-Base-Image, das über die CI/CD gebaut und als fertiges Image (über Pi Imager flashbar) bereitgestellt wird.

Der PI ist sicherlich weit (oder sogar am weitesten) verbreitet. Docker selber deutlich weniger. Was ist z.B. mit den ganzen Proxmox-Installationen, die in einem LXC laufen? Bedeutet das dann, dass zukünftig statt eines LXC eine (ressourcenhungrigere?) VM statt eines LXC verwendet wird, in der dann in der VM erst noch ein Docker-System implantiert wird? Das wäre auch für mich ein klares NoGo.

[FernetMenta]

Ich finde die Idee gut. Nur so kann man die Anzahl der Nutzer und damit auch das langfristige Überleben von ioBroker sicherstellen.

Erstaunlich wie viele Angst haben, dass ihnen etwas weggenommen wird. Die Möglichkeit alles selber zu installieren ist durch diese Idee nicht gefährdet.

Was Docker angeht. Ich nutze das selber und das Image ist aktuell: letzter build vor 4 Tagen. Es ist aus Applikationssicht völlig egal, ob das noch bookwork ist, solange auch dieses Image noch gepfegt wird. Das ist ja die Idee von Containern.

[Marc Berg]

@mcm1957 sagte:

Schon jetzt gibt's leider das Problem, dass das Docker Image nicht wirklich intensiv gewartet wird

Was bringt dich zu dieser Annahme??

[Samson71]

@FernetMenta sagte:
Erstaunlich wie viele Angst haben, dass ihnen etwas weggenommen wird.

Ich glaube nicht, dass es wirklich darum geht, aber alle die länger dabei sind haben auch erlebt wie tolle Ansätze bzw. Adapter aus der Taufe gehoben worden sind und dann mangels Zeit/Interesse des Urhebers auch wieder eingeschlafen sind.

Bei einem System, das ausschließlich durch nicht bezahlte Entwickler in ihrer Freizeit gewartet, gepflegt und bereitgestellt wird, ist die Gefahr einfach sehr groß dass durch persönliche (Lebens-)Umstände der Beteiligten es irgendwann mal zu einem Ausfall kommt und die verwendete Basis dann nicht mehr gewartet wird.
Eine direkte All-in-One-Lösung als eine Art eigenständiges OS ist ja vergleichbar mit dem Konzept von HA, nur das dahinter ein Team aus bezahlten Entwicklern steht und die Pflege deswegen gesichert sein dürfte.

@FernetMenta sagte:
Die Möglichkeit alles selber zu installieren ist durch diese Idee nicht gefährdet.

Wenn dem so ist bzw. das so bleibt - nur zu.

@FernetMenta sagte:
Was Docker angeht. Ich nutze das selber

Ich z.B. nicht (mehr), weil ich mit der "Docker-Logik" irgendwie nie wirklich warm geworden. Egal wie viele wie oft gepredigt haben wie einfach und unkompliziert das ist.

[Thomas Braun]

@htrecksler sagte:

Das schlimmste am ioBroker ist das "gefrickel" in irgendwelchen Kommandozeilen

Übrigens dürfte die Verwendung eines Terminals zur Administration eines Servers durch den Einsatz von KI nur noch weiter Standard bleiben und nur noch verfestigt werden. Die entsprechenden Kommandos sind nämlich weitgehend standardisiert und unterscheiden sich nur marginal von Distribution zu Distribution, eine 'Klickibunti'-GUI ändert sich sehr viel häufiger und kommt mit den üblichen Einschränkungen. Hat der Entwickler die Funktion XYZ z. B. nicht mit einem Icon versehen kommst du per GUI einfach nicht dran. Eine KI sagt dir auch nicht so einfach, wo du denn da jetzt genau klicken musst und was dann da Auszuwählen ist. Für die KI ist die Ausgabe eines Kommandos sehr viel einfacher. Ein Text-Kommando funktioniert viel einfacher und mit höhere Wahrscheinlichkeit als ein Bilderroman.

Zum Thema zurück:

Wer pflegt denn dann kontunierlich diesen Stack:

Kommunikation: Ein maßgeschneiderter ioBroker-Adapter kommuniziert über einen Unix Domain Socket direkt mit dem OS-Agenten.
UX für Einsteiger:

Der ja jetzt bereits verfügbare Docker hinkt ja auch soweit ich das sehe hinterher. Wenn da jetzt noch mehr 'weg abstrahiert' und 'vom User ferngehalten' werden soll, dann muss das jemand für diese User ja übernehmen. Und dieses gepflegte Basis-Image muss dann aber ja auch genauso regelmäßig an user ausgerollt werden (Zwangsbeglückung? Auch keine gute Idee) oder wieder vom user aktiv gezogen werden.

[FernetMenta]

@Samson71 sagte:

Eine direkte All-in-One-Lösung als eine Art eigenständiges OS ist ja vergleichbar mit dem Konzept von HA, nur das dahinter ein Team aus bezahlten Entwicklern steht und die Pflege deswegen gesichert sein dürfte.

Es ist auch vergleichbar mit OpenCCU, was ich nebenbei bemerkt auch benutze:
https://openccu.de/de/start/
Dahinter steckt kein Team von lauter bezahlten Entwicklern. Dennoch bieten sie Images als eine mögliche Alternative für das Deployment an. Ich bin kurzem von debmatic nach OpenCCU (Container) migriert. Das Konzept von debmatic, also Intallation über Linux Pakete, konnte sich nicht lange behaupten.

P.S.
Genau wie bei CCU, welche Variante auch immer, ist das Deployment bei ioBroker auch keine Einbahnstraße. Durch das Backup/Restore Konzept kann man jederzeit einfach migrieren.

[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