Monatsrückblick Oktober 2026 ist online!

[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!