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

[simatec]

@Homoran sagte in Nach Restore kein Zugriff auf WebUi:

@simatec sagte in Nach Restore kein Zugriff auf WebUi:

@hmanfred
Was gibt iobroker list instance aus?

da fehlt ein s

iobroker list instances

stimmt ...

[hmanfred]

@Homoran sagte in Nach Restore kein Zugriff auf WebUi:

Bitte iobroker start admin in der Konsole eingeben und beobachten was dann passiert

C:\Program Files\iobroker\SmartHome>iobroker start admin
[ca. 5 Sek. Pause bis der Prompt wieder kommt, kein Output]

C:\Program Files\iobroker\SmartHome>iobroker list instances
  system.adapter.admin.0                 : admin                 -  enabled, port: 8081, bind: 0.0.0.0, run as: admin
...

Das ist ja - meiner Unwissenheit folgend - der Knackpunkt: iobroker startet keine Instanzen.

[Homoran]

@hmanfred kommst du an das log?
Liegt auf Linux unter /opt/iobroker/logs/datumvonheute

[hmanfred]

@Homoran

2020-03-18 14:24:37.882  - info: host.Proxmox-WIN10 iobroker.js-controller version 2.2.9 js-controller starting
2020-03-18 14:24:37.896  - info: host.Proxmox-WIN10 Copyright (c) 2014-2020 bluefox, 2014 hobbyquaker
2020-03-18 14:24:37.896  - info: host.Proxmox-WIN10 hostname: Proxmox-WIN10, node: v10.16.3
2020-03-18 14:24:37.912  - info: host.Proxmox-WIN10 ip addresses: 2001:16b8:2891:dd00:1963:6bc9:2c04:4f2b 2001:16b8:2891:dd00:90d7:c9ca:64bd:36fd fe80::1963:6bc9:2c04:4f2b 192.168.1.178
2020-03-18 14:24:39.631  - info: host.Proxmox-WIN10 connected to Objects and States
2020-03-18 14:24:40.131  - info: host.Proxmox-WIN10 41 instances found
2020-03-18 14:24:40.178  - warn: host.Proxmox-WIN10 does not start any instances on this host

[Homoran]

@hmanfred stimmen die IP-Adresses?

192.168.1.178 kommt mir seltsam vor

[hmanfred]

@Homoran

C:\Program Files\iobroker\SmartHome>ipconfig

Windows-IP-Konfiguration


Ethernet-Adapter Ethernet:

   Verbindungsspezifisches DNS-Suffix: fritz.box
   IPv6-Adresse. . . . . . . . . . . : 2001:16b8:2891:dd00:1963:6bc9:2c04:4f2b
   Temporäre IPv6-Adresse. . . . . . : 2001:16b8:2891:dd00:90d7:c9ca:64bd:36fd
   Verbindungslokale IPv6-Adresse  . : fe80::1963:6bc9:2c04:4f2b%7
   IPv4-Adresse  . . . . . . . . . . : 192.168.1.178
   Subnetzmaske  . . . . . . . . . . : 255.255.255.0
   Standardgateway . . . . . . . . . : fe80::cece:1eff:fee2:bcac%7
                                       192.168.1.1

[Homoran]

@hmanfred alles gut, nur weil die Standard IP der Fritzbox 192.168.178.1 ist

[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