Neuer Blogbeitrag: Monatsrückblick - Dezember 2025 🎄

[AndyGR42]

@crunchip Ja, hier bin ich auch einen Schritt weiter. Ich muss das aber nochmal sauber reproduzieren. Es scheint aber so, als ob man bei gestoppten iobroker mit "npm install iobroker.vis" einen Zustand herstellen kann, dass beim nächsten Start von iobroker VIS automatisch installiert wird. Wie gesagt, muss ich nochmal reproduzieren.

P.S.: zu früh gefreut. VIS Adapter lässt sich installieren, läuft aber nicht...

[Homoran]

@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:

Das ist leider inkorrekt:

was genau?

Der Hostname wird bei der Installation des OS vergeben.
Deswegen muss dieser bei Änderung zum Backup nach dem Restore und vor dem ersten Start von ioBroker diesem via iobroker host this mitgeteilt werden.

[AndyGR42]

@homoran Restore ändert den Hostname. Du meintest, dass würde nicht passieren. Passt der Hostname vom Zielsystem nicht zum Hostname aus dem Backup, dann schlägt der Restore fehl und kein Adapter startet. Dennoch wird der Hostname des Zielsystem geändert, so dass bei einem zweiten Restore alles (bis auf VIS) funktioniert. Wenn man das weiß, ist alles ok. Eine Abfrage beim Restore wäre perfekt, aber so geht's ja auch.

P.S.: oder natürlich man passt den Namen vorher an.

[Homoran]

@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:

Passt der Hostname vom Zielsystem nicht zum Hostname aus dem Backup, dann schlägt der Restore fehl und kein Adapter startet

das kann sein, wenn der neue Hostname der ioBroker Installation aus dem Backup nicht mitgeteilt wurde. (siehe letzten Post)
Das war schon immer so, zumindest gab es dann immer schon mal Probleme.

Das sieht man unter system.host.xxxx

@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:

Dennoch wird der Hostname des Zielsystem geändert,

im Betriebssystem??

kann ich nicht glauben

[apollon77]

@andygr42 AAaaalso wenn man tiefer reinschauen wollte ....

Den Hostnamen des Hosts ändern wir in keinem Fall beim Restore. Was aber sein kann ist folgendes:

Man kann im iobroker.json den Hostname quasi überschreiben. Wenn das bei einem System gemacht wurde und das dann gebackupped wird dann steht dieser Hostname im backup und wird beim Restore auch wieder hergestellt. Wenn dort keiner definiert ist dann kommt auch keiner in die Konfig und es gilt der Hostname des Systems.

Weiterhin gibt es beim backup eine Logik die "die Objekte von dem Host wo das Backup läuft" mit nem Patzhalter versieht und beim Restore wird der Platzhalter mit dem Hostname der nach obiger Logik dann gilt wieder geschrieben. Wenn aber noch andere Hosts im System sind (zb wegen Multihost) dann bleiben die auf Ihren Namen auch nach dem backup.

Lange rede kurzer Sinn: Das kann schnell etwas komplexig werden und ohne jetzt bei Dir hier genau zu schauen welche Kombination beim Backup war und was dann beim Restore galt kommen wir nicht weiter

[Einstein67]

@andygr42 said in VIS 1.14.5 lässt sich nicht installieren:

Starte ich nun den gleichen Restore nochmal, mit dem nun gleichen Hostname, funktioniert es einwandfrei:

Kann (muss) ich leider bestätigen. Das hat aber vor ein paar Tagen noch problemlos funktioniert.

Edit: Fehler tritt bei mir nur auf wenn das BackUp von einer SSL geschützten Iobroker-Installation gemacht wird. Ohne SSL gibts keine Probleme.

[AndyGR42]

@homoran Natürlich nicht der vom OS sondern von iobroker

@apollon77 Danke für die ausführliche Erklärung. Mein Quellsystem hatte den iobroker Host Namen vom OS übernommen. Da bin ich mir ziemlich sicher, da ich damals im Netzwerk noch mit dynamischen DNS Updates per DHCP gearbeitet habe und deshalb der OS Hostname wichtig war. Mache ich mittlerweile nicht mehr, weil zu aufwändig. Die 2-3 Systeme wo DNS Auflösung wichtig ist, bekommen halt eine feste IP und einen DNS Eintrag. Von daher bin ich ziemlich sicher, dass ich nix per Hand in eine config Datei geschrieben haben. Multihost hab ich auch nicht.

[Homoran]

@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:

Natürlich nicht der vom OS sondern von iobroker

klar!
weil backitup nach dem restore ein iobroker host this macht, bevor iobroker wieder gestartet wird.

[AndyGR42]

@homoran sagte in VIS 1.14.5 lässt sich nicht installieren:

klar!
weil backitup nach dem restore ein iobroker host this macht, bevor iobroker wieder gestartet wird.

Also ändert ein Restore doch den iob Host Name, wenn dieser zwischen Ziel- und Quellsystem unterschiedlich ist? Egal, wie man dieses Problem löst ist ja bekannt und einfach.

Ich habe aber immer noch Probleme mit VIS nach dem Restore. Das passiert jedes Mal, wenn ich versuche die Instanz zu starten:

2022-06-22 10:50:40.071  - info: host.gt-iob01 "system.adapter.vis.0" disabled
2022-06-22 10:50:42.226  - info: host.gt-iob01 "system.adapter.vis.0" enabled
2022-06-22 10:50:43.979  - debug: vis.0 (21503) Redis Objects: Use Redis connection: 127.0.0.1:9001
2022-06-22 10:50:44.088  - debug: vis.0 (21503) Objects client ready ... initialize now
2022-06-22 10:50:44.092  - debug: vis.0 (21503) Objects create System PubSub Client
2022-06-22 10:50:44.094  - debug: vis.0 (21503) Objects create User PubSub Client
2022-06-22 10:50:44.258  - debug: vis.0 (21503) Objects client initialize lua scripts
2022-06-22 10:50:44.271  - debug: vis.0 (21503) Objects connected to redis: 127.0.0.1:9001
2022-06-22 10:50:44.276  - silly: vis.0 (21503) redis psubscribe cfg.o.system.user.*
2022-06-22 10:50:44.338  - silly: vis.0 (21503) redis psubscribe cfg.o.enum.*
2022-06-22 10:50:44.348  - silly: vis.0 (21503) objectDB connected
2022-06-22 10:50:44.353  - debug: vis.0 (21503) Redis States: Use Redis connection: 127.0.0.1:9000
2022-06-22 10:50:44.433  - debug: vis.0 (21503) States create System PubSub Client
2022-06-22 10:50:44.436  - debug: vis.0 (21503) States create User PubSub Client
2022-06-22 10:50:44.625  - debug: vis.0 (21503) States connected to redis: 127.0.0.1:9000
2022-06-22 10:50:44.627  - silly: vis.0 (21503) statesDB connected
2022-06-22 10:50:44.977  - info: vis.0 (21503) starting. Version 1.4.15 in /opt/iobroker/node_modules/iobroker.vis, node: v16.15.1, js-controller: 4.0.23
2022-06-22 10:50:45.035  - silly: vis.0 (21503) States system redis pmessage system.adapter.vis.0.logLevel/system.adapter.vis.0.logLevel:{"val":"silly","ack":true,"ts":1655895045019,"q":0,"from":"system.adapter.vis.0","lc":1655299810220}
2022-06-22 10:50:45.229  - info: vis.0 (21503) vis license is OK.
2022-06-22 10:50:46.135  - info: vis.0 (21503) Terminated (NO_ERROR): Without reason
2022-06-22 10:50:46.784  - info: host.gt-iob01 instance system.adapter.vis.0 terminated while should be started once

VIS läuft aber! Damit habe ich im Prinzip den gleichen Zustand wie in meinem prod System, was ich wohl irgendwie durch eine Installation einer VIS Version während des Restore bzw. Neustart hingebastelt habe. So wirklich überzeugend ist das aber nicht :(

Das System (Ubuntu 20.04.4 LTS auf Odroid C4) habe ich wie folgt vorbereitet:

• iobroker entfernt:

sudo rm -fR /usr/lib/node_modules
sudo rm -fR /opt/iobroker
sudo apt remove --purge nodejs
sudo systemctl disable iobroker.service

• iobroker per Script neu installiert (node 16.15.1, npm 8.11.0)
• Host Name per Admin geändert
• VIS 1.14.5 per CLI installiert (läuft, wenn auch ohne Lizenz)
• Restore per CLI (funktioniert einwandfrei, alle Adapter werden installiert)

[Homoran]

@andygr42 sagte in VIS 1.14.5 lässt sich nicht installieren:

So wirklich überzeugend ist das aber nicht

auch richtig.
Das issue mit vis ist temporär und bekannt.

Hat (fast) nichts mit dem Rest zu tun

[AndyGR42]

@homoran Gut, dann warte ich auf ein VIS Update bevor ich das prod System noch mal restore oder andere Adapter aktualisiere.