Monatsrückblick Oktober 2026 ist online!

[FernetMenta]

@Thomas-Braun sagte:

Wobei man natürlich die Frage stellen darf, ob man auf einem Raspberry auch noch mit Containern hantieren möchte.

Mein Pi5 mach nichts anders. Es ist der Host für 5 Container. Das macht auch ein Recovery extrem einfach und schnell.

Für einige Architekturen gibt es aber keine prebuilds und es muss dann selber gebaut werden

Richtig, aber ich konnte keine Adapter finden. Ehrlich gesagt habe ich eine KI suchen lassen. arm64 ist mittlerweile eine Wald-und-Wiesen-Architektur. Ich kann mich gar nicht mehr erinnern, wann ich das letzte Mal was gesehen habe, was dafür nicht vorbereitet gewesen wäre.

[Thomas Braun]

@FernetMenta

Ich meine canvas und pillow usw. gibt es nicht vorkompiliert.
Und puppeteer musste wohl auch immer von Hand gebaut werden.

[FernetMenta]

@Thomas-Braun

Die Frage ist welche Adapter verwenden solche Module und wie oft werden diese in iob Installationen verwendet. Wenn das nicht nur extreme Sonderfälle sind und Interesse besteht, könnte man sich überlegen Prebuilts dafür mit dem Image zu liefern.

[Thomas Braun]

@FernetMenta

Das kann ich dir so genau auch nicht sagen. Sind aber mehr 'als eine Hand voll'

[Bluefox]

@FernetMenta danke, sieht sauber gemacht aus. Rootless und Restore direkt über das Volume finde ich gut.

Ein paar Punkte, die mir beim Lesen eingefallen sind:

• Netzwerk: Viele Adapter brauchen Multicast/Broadcast für die Gerätesuche (mDNS, SSDP, UDP-Discovery, z. B. bei Sonos, Hue, Shelly CoAP oder Chromecast). Unter rootless Podman mit pasta/slirp4netns funktioniert das nicht oder nur eingeschränkt. Das sollte deutlich in der Doku stehen, mit dem Hinweis auf --network host oder macvlan.
• Native Module: Dass fast alles mit Prebuilds kommt, stimmt. Wenn sich die Node-Version im Image ändert und ein Adapter für die neue ABI bzw. für arm64 keinen Prebuild hat, fällt npm auf node-gyp zurück, und das schlägt dann ohne Build-Chain fehl. Das tritt typischerweise direkt nach einem Wechsel der Node-Major-Version auf. Eine klare Fehlermeldung oder ein Hinweis im Log wäre da hilfreich.
• Admin: Damit Admin den Upgrade-Button für den js-controller und die Hinweise zu Node/OS-Updates nicht anzeigt, muss das Image als Container erkannt werden. Bitte prüf, ob das bei dir sauber greift, sonst probieren die User es trotzdem über die UI.
• Restore: Wie gehst du mit einem BackItUp-Backup um, das von einer älteren js-controller-Version stammt? Und was passiert mit Adaptern, die im Backup stehen, aber nicht mehr im Repo sind?

Ansonsten würde ich mich an deiner Stelle mit buanet abstimmen. Vielleicht lässt sich einiges davon (rootless, Reconciliation) auch ins offizielle Image übernehmen, dann haben mehr Leute etwas davon.

[FernetMenta]

@Bluefox danke für das Feedback. Ich schaue mir die Punkte an.

Ich habe mich mit Andre (buanet) abgestimmt, siehe Discord. Er nutz ioBroker nicht mehr und entwickelt das Image nicht mehr weiter. Es laufen aktuell nur refresh-builds, die das Basis-Image updaten. Ich hatte angeboten, dass ich das übernhmen könnte. Das war der Grund warum ich das hier gestartet habe.

Zu einigen Punkten:

• Native Module
  Gibt es derzeit nur für den js-controller. Diese kommen mit dem Image und werden bei einem major Node upgrade in das node_modules Volume kopiert.

• Admin
  Der Container wird als solcher (nicht offiziell) erkannt. Es gibt keinen js-controller Upgrade-Button. Der Hilfetext dazu passt allerdings nicht dazu.

[obermolch]

@fernetmenta danke für Deine Arbeit, ich nutze Dein Image schon seit 2 Wochen mit docker-compose (x86). Der iob Container selbst läuft als user 1000. Alle Adapter und Updates laufen, auch diese mit Abhängigkeiten zu serialport.

[FernetMenta]

Ich habe die Dokumentation mit einem Kapitel über Netzwerke ergänzt.

Zu Restore:
Der Container selbst nimmt an der Version des Backups keine Anpassung vor – er ruft beim Start einfach iobroker restore <backup> --yes auf, bevor js-controller startet. Die eigentliche Migration übernimmt dabei die iobroker-CLI der laufenden (neuen) js-controller-Version: sie liest das Backup ein und schreibt Objects-/States-DB sowie iobroker.json in ihrem aktuellen Format neu. Ein Backup aus einer älteren js-controller-Version lässt sich also normalerweise einspielen, solange die CLI es versteht (Rückwärtskompatibilität liegt im Ermessen von js-controller, nicht des Images). Schlägt der Restore fehl, bricht der Containerstart ab (fail-safe) statt mit halb wiederherstellten Daten weiterzulaufen.

Adapter, die im Backup verzeichnet, aber nicht mehr im Repository verfügbar sind: Nach dem erfolgreichen Restore läuft die normale Reconciliation, die versucht, alle im Backup/Data_Volume verzeichneten Adapter zu installieren. Fehlt ein Adapter im Repo, schlägt dessen Installation fehl – was dann passiert, steuert IOB_ADAPTER_INSTALL_FAILURE_POLICY:

tolerate-no-instance (Standard): unkritisch, wenn der Adapter keine aktivierte Instanz hat; sonst fatal (Container bleibt „unhealthy“ stehen).
strict: jeder fehlgeschlagene Install ist fatal.
tolerate-all: wird nur als Warnung geloggt, Start läuft weiter.
Fatal heißt hier nicht Crash-Loop, sondern der Container bleibt laufend, aber „unhealthy“, bis man den Adapter entfernt/ersetzt oder die Policy lockert.

[Bluefox]

@FernetMenta danke, das klingt durchdacht. Die Policy mit tolerate-no-instance als Standard finde ich sinnvoll, und dass der Container "unhealthy" stehen bleibt statt in einen Crash-Loop zu laufen, ist gut.

Zum Admin: Welchen Hilfetext meinst du genau? Schick mir am besten einen Screenshot oder den Text, dann passen wir das im Admin für nicht offizielle Container an.

Zur möglichen Übernahme des offiziellen Images: Im js-controller hängt die Erkennung "offizielles Image" im Moment nur an /opt/scripts/.docker_config/.thisisdocker. Ab Version 8.1.0 des offiziellen Images ist damit auch das Controller-Upgrade über die UI wieder freigeschaltet. Außerdem wird die neueste Image-Version fest von iobroker/iobroker auf Docker Hub abgefragt. Bei deinem Konzept (Version des Images = Version des js-controllers, kein Upgrade aus dem Container heraus) passt das nicht. Wenn es so weit ist, sollten wir die Erkennung im js-controller gemeinsam anpassen.

Bei den nativen Modulen bleibt für mich der Punkt mit den Adaptern offen. Wenn ein Adapter nach einem Node-Major-Wechsel keinen passenden Prebuild hat, sollte im Log klar stehen, dass ohne Build-Chain nicht gebaut werden kann, statt nur des node-gyp-Fehlers.

[FernetMenta]

@Bluefox zum js-controller upgrade:

Die Plattform wird richtig erkannt (obwohl ich docker gegen Container tauschen würde):

Beim Aktualisieren kommen aber Standardanweisungen. Hier wäre es wahrscheinlilch besser, wenn man Benutzer anweist der Dokumentation des Images zu folgen.

[FernetMenta]

Bzgl. native Module:

Es war so, dass bei einem Fehlen von nativen Modulen ein Eintrag im reconcile.log erstellt wurde. Der Container hat aber gestartet.

Ich habe einen preflight-check hinzugefügt (opt-out). Der überprüft im Vorfeld, ob es bei einem Node Major-Upgrade zu Problemen kommen könnte und bricht den Containerstart je nach Setting ab. So haben Benutzer die Möglichkein das Imageupdate abzubrechen.

[Bluefox]

@FernetMenta danke, jetzt ist klar, was du meinst. Die Erkennung klappt also, nur der Dialog unterscheidet nicht und zeigt für jede Plattform die normale Anleitung mit iobroker upgrade self. In einem Container ist das falsch.

Ich passe den Dialog an: Bei "unofficial image" kommen die Befehle raus und stattdessen der Hinweis, dass der js-controller mit einem neuen Image aktualisiert wird und man der Doku des Images folgen soll. "docker" ersetze ich dort durch "Container", das passt bei podman und k8s ohnehin besser.

Noch eine Frage dazu: Soll ich fest auf dein Repo verlinken, oder legst du lieber im Image eine Doku-URL ab (z. B. als Datei oder Umgebungsvariable), die der js-controller in dockerInformation mitliefert? Die zweite Variante würde dann auch für andere inoffizielle Images funktionieren. Das müsste man im js-controller zusammen mit der Erkennung anpassen, über die wir oben gesprochen haben.

[FernetMenta]

@Bluefox sagte:

Noch eine Frage dazu: Soll ich fest auf dein Repo verlinken, oder legst du lieber im Image eine Doku-URL ab (z. B. als Datei oder Umgebungsvariable)

Gute Idee. Dann könnte es z.B. so aussehen:

Für das Upgrade des js-Controller fologen Sie bitte der Dokumentation des verwendeten Images.
<Doku URL> (falls vorhanden)

Sag mit einfach wo du die URL haben willst. Environment Variable ist wahrscheinlich flexibler.

[Bluefox]

@FernetMenta Dann nehmen wir eine Umgebungsvariable. Mein Vorschlag ist IOB_CONTAINER_DOCS_URL, das passt auch zu deinem IOB_-Präfix. Am besten setzt du sie im Image per ENV. Dann muss der User nichts machen und kann sie bei Bedarf trotzdem überschreiben.

Im js-controller lese ich sie in getDockerInformation() aus. Bei inoffiziellen Images kommt sie dann als docsUrl in dockerInformation mit. Ich nehme nur http:// bzw. https:// an, alles andere wird ignoriert. Admin zeigt dann deinen Text:

Für das Upgrade des js-controllers folgen Sie bitte der Dokumentation des verwendeten Images.

Darunter kommt der Link, wenn die Variable gesetzt ist. Ohne Variable kommt nur der Hinweis.

Der Admin-Teil (Befehle raus, "Container" statt "docker") geht auch ohne das und kommt zuerst. Der Link wird erst mit dem passenden js-controller angezeigt. Wenn dir der Name passt, verlinke ich die PRs hier.

[FernetMenta]

@Bluefox sagte:

Wenn dir der Name passt, verlinke ich die PRs hier.

Super!