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

[hmanfred]

Ich habe jetzt mal ganz neu angefangen - also auf einen erneut jungfräulichen Windows Installation.

Nach erfolgreicher Installation mit dem "iobroker-1.5.14.b-windows-installer.exe" lief ioBroker wieder als Basisinstallation.

Dann habe ich den Update des js-controller von 1.5.14 nach 2.2.9 gemacht. Dabei kamen einige Fehlermeldungen:

Spoiler

C:\Program Files\iobroker\SmartHome>iobroker upgrade self
Update js-controller from @1.5.14 to @2.2.9
NPM version: 6.9.0
npm install iobroker.js-controller@2.2.9 --unsafe-perm --production --save --prefix "C:/Program Files/iobroker/SmartHome" (System call)
npm WARN deprecated mkdirp@0.5.3: Legacy versions of mkdirp are no longer supported. Please update to mkdirp 1.x. (Note that the API surface has changed to use Promises in 1.x.)
npm WARN deprecated request@2.88.2: request has been deprecated, see https://github.com/request/request/issues/3142
gyp ERR! build error
gyp ERR! stack Error: `C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (C:\Program Files\iobroker\SmartHome\nodejs\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Windows_NT 10.0.18363
gyp ERR! command "C:\\Program Files\\iobroker\\SmartHome\\nodejs\\node.exe" "C:\\Program Files\\iobroker\\SmartHome\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Program Files\iobroker\SmartHome\node_modules\iobroker.js-controller\node_modules\unix-dgram
gyp ERR! node -v v10.16.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@~2.1.2 (node_modules\iobroker.js-controller\node_modules\chokidar\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: unix-dgram@2.0.3 (node_modules\iobroker.js-controller\node_modules\unix-dgram):
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: unix-dgram@2.0.3 install: `node-gyp rebuild`
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: Exit status 1

Host "Proxmox-WIN10n(SmartHome)" (win32) updated
Starting node restart.js

ioBroker läuft allerdings wieder. Restore habe ich noch nicht gemacht. Mich würde erst mal interessieren, was die Fehlermeldungen bedeuten und welche Relevanz sie haben.

Nächster Schritt wäre dann erneut ein Restore - ich werde berichten.

[hmanfred]

Jetzt habe ich noch mal ein wenig herumexperimentiert:

• Win10 neu aufgesetzt
• ioBroker mit dem Installer 1.5.14b installiert
• js-controller auf die 2.x aktualisiert (war noch 1.x)
• ioBroker läuft
• Backup des Basissytems
• Restore von meinem Produktivsystem
• ioBroker host this (mit Erfolgs-Rückmeldungen)
• Neustart der Maschine
• iobroker list instances (keine Instanz aktiv - nirgends ein "+")
• immer noch kein Zugriff auf die Admin-Webseite

Dann der Versuch, das ursprünglich installierte Basissystem wieder zu aktivieren:

• Restore des ursprünglich installierten Basissystems
• weiterhin kein Zugriff (Tests und Zwischenschritte spare ich mir hier)

Und um dem Verdacht vorzubeugen, der Backup könnte korrupt gewesen sein:
Ich habe einen Snapshot meines Produktivsystems (Debian 9.x) gemacht und dann den oben verwendeten backup restored. Mit Erfolg!

Sollte jemand Interesse daran haben, die Ursache(n) der geschilderten Probleme mit meiner Hilfe zu analysieren, stehe ich zur Verfügung.

Angesichts der Tatsache, dass dieser und auch andere meiner Threads bzgl. Windows-Installation letztendlich oder gar schon mit dem Eröffnungsbeitrag ins Leere laufen endet aber ansonsten nun erst mal mein Ausflug in die ioBroker-Windows-Welt.

Als erfahrener Windows-Anwender der ersten Stunde hatte ich gehofft, das "malen nach Zahlen", das für mich in LINUX-Umgebungen leider immer noch die Regel ist, hinter mir zu lassen. Ich bin jetzt nicht enttäuscht. Ich habe ein Stück weit Erfahrung gesammelt und werde mich nun eben weiter in die LINUX-Welt reinfuchsen.

Alles Gut!

[Homoran]

@hmanfred sagte in Nach Restore kein Zugriff auf WebUi:

js-controller auf die 2.x aktualisiert (war noch 1.x)

Das wird der Grund gewesen sein.
die aktuellen -nach dem Restore installierten- Versionen benötigen js-controller v2

[simatec]

@hmanfred
Ich weiß nicht genau, ob es hier gefragt wurde, aber nutzt du auf dem debian redis?
Wenn ja nur die states oder auch objects?

[hmanfred]

@Homoran sagte in Nach Restore kein Zugriff auf WebUi:

@hmanfred sagte in Nach Restore kein Zugriff auf WebUi:

js-controller auf die 2.x aktualisiert (war noch 1.x)

Das wird der Grund gewesen sein.
die aktuellen -nach dem Restore installierten- Versionen benötigen js-controller v2

Nein. Meine oben beschriebene Vorgehensweise war:

• Win10 neu aufgesetzt
• ioBroker mit dem Installer 1.5.14b installiert
• js-controller auf die 2.x aktualisiert (war noch 1.x)
• ioBroker läuft
• Backup des Basissytems
• Restore von meinem Produktivsystem

Die Aktualisierung des JS-Controllers war die allererste Maßnahme nach Installation von ioBroker!

[hmanfred]

@simatec sagte in Windows: Nach Restore kein Zugriff auf WebUi:

@hmanfred
Ich weiß nicht genau, ob es hier gefragt wurde, aber nutzt du auf dem debian redis?
Wenn ja nur die states oder auch objects?

Ich weiss nicht so recht, wie ich die Frage verstehen soll.

Es handelt sich um eine Windows Installation.

Ich habe den Titel des Threads jetzt mal angepasst.

[simatec]

@hmanfred sagte in Windows: Nach Restore kein Zugriff auf WebUi:

Produktivsystems (Debian 9.x)

du schriebst aber von debian?

[hmanfred]

@simatec
Ich schrieb ausführlich von meinen Test mit erfolglosem restore eines backups auf die Windows Maschine.

Damit dann aber keiner sagt "das backup ist sicher kaputt gewesen", habe ich geschrieben (jetzt anders und vllt. verständlicher formuliert):

"Ich habe ein Produktivsystem mit Debian. Darauf habe ich das (mit Windows) verwendete Backup eingespielt, um zu beweisen, dass es nicht kaputt ist.
Um Sicher zu gehen, habe ich vorher natürlich ein Snapshot des Produktivsystem erstellt."

[simatec]

@hmanfred
Und dein backup wurde unter Windows erstellt?
Welche js-controller Version hat das backup?

[hmanfred]

@simatec
Das verwendete Backup stammte aus dem Produktivsystem.

Testsystem: WIN10 js-controller 2.2.9
Produktivsystem: Debian js-controller 2.2.10

Kann es an diesem Unterschied gelegen haben?

Falls ja: warum hat dann das erneute Restore des vorher an der jungfräulichen WIN Installation erstellten Backups das Problem nicht behoben?

[simatec]

@hmanfred
Genau das sage ich doch die ganze Zeit.
Dein Backup welches du auf deinem WIN System restoren willst, kommt von debian.
Wenn du dort die objects über redis laufen hast, liegt genau hier dein Problem.
Darum die Frage nach Redis.

[hmanfred]

@simatec
Nein, kein Redis, File. Wusste bis jetzt gar nicht, was Redis ist...

[simatec]

@hmanfred
Zeige doch mal bitte, was du auf deinem Produktivsystem in „iobroker setup custom “ eingestellt hast

[hmanfred]

@simatec

Ääähm... wo finde ich das?

Auch nach Umstellung auf Systemsprache Englisch finde ich diese Begriffkombination nirgends.

Edit:
Durch die Forumssuche habe ich nun herausgefunden, dass es den Konsolenbefehl "iobroker setup custom" gibt.
Ergebnis:

Current configuration:
- Objects database:
  - Type: file
  - Host/Unix Socket: 127.0.0.1
  - Port: 9001
- States database:
  - Type: file
  - Host/Unix Socket: 127.0.0.1
  - Port: 9000
- Data Directory: ../../iobroker-data/

[simatec]

@hmanfred sagte in Windows: Nach Restore kein Zugriff auf WebUi:

@simatec

Ääähm... wo finde ich das?

Auch nach Umstellung auf Systemsprache Englisch finde ich diese Begriffkombination nirgends.

Edit:
Durch die Forumssuche habe ich nun herausgefunden, dass es den Konsolenbefehl "iobroker setup custom" gibt.
Ergebnis:

Current configuration:
- Objects database:
  - Type: file
  - Host/Unix Socket: 127.0.0.1
  - Port: 9001
- States database:
  - Type: file
  - Host/Unix Socket: 127.0.0.1
  - Port: 9000
- Data Directory: ../../iobroker-data/

Ist dies die Config deines Produktivsystems?

[hmanfred]

@simatec
Ja, das ist die Konfig meines Produktivsystems.

Das ist die Konfig des Systems (mein Produktivsystem, laufend unter DEBIAN 9.x), aus dem das verwendete Backup stammt.

[simatec]

@hmanfred
Dann poste noch mal bitte die Ausgabe „iobroker list instances“ von deinem Testsystem und die Logdatei

[hmanfred]

@simatec

Output ...list instances:

Spoiler

C:\Program Files\iobroker\SmartHome>iobroker list instances
 system.adapter.admin.0                 : admin                 -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
 system.adapter.backitup.0              : backitup              -  enabled
 system.adapter.chromecast.0            : chromecast            - disabled
 system.adapter.daikin.0                : daikin                - disabled
 system.adapter.daikin.1                : daikin                - disabled
 system.adapter.daswetter.0             : daswetter             - disabled
 system.adapter.deconz.0                : deconz                - disabled, port: 8080
 system.adapter.dwd.0                   : dwd                   - disabled
 system.adapter.harmony.0               : harmony               - disabled
 system.adapter.history.0               : history               - disabled
 system.adapter.hm-rega.1               : hm-rega               - disabled
 system.adapter.hm-rpc.2                : hm-rpc                - disabled, port: 0
 system.adapter.hm-rpc.3                : hm-rpc                - disabled, port: 0
 system.adapter.ical.0                  : ical                  - disabled
 system.adapter.icons-material-svg.0    : icons-material-svg    - disabled
 system.adapter.icons-mfd-png.0         : icons-mfd-png         - disabled
 system.adapter.icons-mfd-svg.0         : icons-mfd-svg         - disabled
 system.adapter.info.0                  : info                  - disabled
 system.adapter.iot.0                   : iot                   - disabled
 system.adapter.javascript.0            : javascript            - disabled
 system.adapter.mobile.0                : mobile                - disabled
 system.adapter.netatmo.0               : netatmo               - disabled
 system.adapter.ping.0                  : ping                  - disabled
 system.adapter.sayit.0                 : sayit                 - disabled, port: 0
 system.adapter.sayit.1                 : sayit                 - disabled, port: 0
 system.adapter.solarlog.0              : solarlog              - disabled, port: 80
 system.adapter.sonos.0                 : sonos                 - disabled
 system.adapter.tankerkoenig.0          : tankerkoenig          - disabled
 system.adapter.vis-bars.0              : vis-bars              - disabled
 system.adapter.vis-canvas-gauges.0     : vis-canvas-gauges     - disabled
 system.adapter.vis-fancyswitch.0       : vis-fancyswitch       - disabled
 system.adapter.vis-hqwidgets.0         : vis-hqwidgets         - disabled
 system.adapter.vis-jqui-mfd.0          : vis-jqui-mfd          - disabled
 system.adapter.vis-justgage.0          : vis-justgage          - disabled
 system.adapter.vis-metro.0             : vis-metro             - disabled
 system.adapter.vis-players.0           : vis-players           - disabled
 system.adapter.vis-timeandweather.0    : vis-timeandweather    - disabled
 system.adapter.vis-weather.0           : vis-weather           - disabled
 system.adapter.vis.0                   : vis                   - disabled
 system.adapter.web.0                   : web                   - disabled, port: 8082, bind: 0.0.0.0, run as: admin
 system.adapter.worx.0                  : worx                  - disabled

+ instance is alive

Und die Logdatei:
iobroker.2020-03-22.log

[hmanfred]

Neue Erkenntnis:

nach einem "iobroker start admin.0" läuft die admin Instanz und ich komme auf die Weboberfläche!

Gerade läuft ein Neustart der Maschine...

...weiter geht's:

ioBroker Dienst läuft zwar laut Computerverwaltung-Dienste. Aber "iobroker status" sagt "iobroker is not running on this host.".
Also erst mal "iobroker stop" und "iobroker start". Wird dann die nächste Baustelle...

Jetzt wurde die Admin Instanz auch gestartet, ich komme aufs Webinterface.

Dieses Problem ist also gelöst mit der Erkenntnis, dass nach einem restore (zumindest bei mir) die admin Instanz erst mal manuell gestartet werden muss.

Wenn's das war (wirklich?) bleibt die Frage: warum wird ioBroker nicht gestartet obwohl laut Computerverwaltung-Dienste der Dienst läuft?

[simatec]

@hmanfred
Und unter http://192.168.1.21:8081 ist admin nicht errechbar? Laut log werden gerade alle Adapter nach und nach installiert

Edit: Hatte deinen letzten Beitrag zu spät gesehen.
Du könntest in backitup den Hacken setzen, dass nach dem restore alle Adapter gestartet werden sollen.
Dies kann allerdings bei einigen Adaptern erstmal zum error führen.