iob Master/Slave alt/neu

[RichieXX]

Ich habe hier einen
Master (JS-Controller 3.2.12, node.js 10.20.1, npm 6.14.4) ca. 30 Adapter verschienster Kategorien
und einen
Slave (JS-Controller 3.2.12, node.js 10.24.0, npm 6.14.11) ca. 10 Adapter darunter Zigbee 1.5.1 und ZWave (1) 2.0.1
laufen.

Ich möchte System nun eindlich mal auf einen neuen Stand bringen, da Neuanschaffungen von Geräten zu immer mehr Problemen führt.

Wie gehe ich am besten vor?

Mein erster Gedanke war: Einen komplett neuen iob installieren, den als Slave in das vorhandene integrieren und die Adapter einen nach dem Anderen auf den neuen Slave migrieren. Wenn alles erledigt den neuen Slave zum Master deklarieren. Würde das so funktionieren?

Mein zweiter Gedanke: Backup vom alten Master auf dem neuen iob wiederherstellen.

Wie würdet ihr das machen?

Ich möchte das Ganze erstmal testen und vorbereiten und nach der Heizperiode umsetzen. Ist also nichts Dringendes und kann erstmal theoretisch diskutiert werden.

[Thomas Braun]

@richiexx

Update die Kiste einfach. Und das ganze regelmäßiger/häufiger als du das bislang tust (Offenbar nämlich nie).

Zuerst Betriebssystem inkl. nodejs, danb musst du Mal schauen wie bei so alten js-controllern die Reihenfolge ist. Steht in den entsprechenden Ankündigungen des js-controller Updates dabei.

[RichieXX]

@thomas-braun
Ich habe aktualisiert, wenn es notwendig war. Warum sollte ich mir mit einem laufenden System Stress machen.

Ich würde gerne schon irgendwie ein neues System aufsetzen und gleich mal mit "durchfegen", wenn du verstehst, was ich meine.

Meine Vermutung ist, jetzt das System in diesem Zustand updaten, macht mehr Probleme, wie neu aufsetzen.

[Thomas Braun]

@richiexx sagte in iob Master/Slave alt/neu:

Ich habe aktualisiert, wenn es notwendig war.

Nein, hast du nicht. Die Versionen sind hoffnungslos veraltet.

[Thomas Braun]

@richiexx sagte in iob Master/Slave alt/neu:

Meine Vermutung ist, jetzt das System in diesem Zustand updaten, macht mehr Probleme,

Wenn du da so lange pennst werden die Versionssprünge immer größer und komplizierter, das stimmt natürlich. Deswegen schwimmt man ja auch regelmäßig bei stabilen Versionen mit.

[RichieXX]

@thomas-braun
Irgendwie hab ich geahnt, dass genau diese Diskussion losgeht. Können wir das bitte lassen. Ich habe nach gängigen Lösungen gefragt die mich weiterbringen. Meine Meinung zum Update hast du vernommen. Ich weiß genau, wie alt die Systeme sind.

[Homoran]

@richiexx sagte in iob Master/Slave alt/neu:

Mein erster Gedanke war: Einen komplett neuen iob installieren

nicht einen, sondern 2!

@richiexx sagte in iob Master/Slave alt/neu:

Backup vom alten Master auf dem neuen iob wiederherstellen.

bei korrekter Vorgehensweise bei der Multihost Einrichtung wird dann der (mit neuem Grundsystem und von allen Adaptern befreite) Slave automatisch mit konfiguriert.

[Thomas Braun]

@richiexx

Gängige Lösung: Updaten.

Andere Lösung: Systeme komplett neu aufsetzen, allerdings kannste dann mit Backups von dem Altsystem nix anfangen, weil Versionssprünge zu groß.

Also: Updaten

Künftig das System nicht versumpfen lassen.

[Homoran]

@richiexx sagte in iob Master/Slave alt/neu:

Ich habe nach gängigen Lösungen gefragt die mich weiterbringen

das versucht @Thomas-Braun ja gerade.
Weil dein System so überaltert ist und wir nicht wissen, wie es darin aussieht, ist der Weg über viele, viele Updateschritte der am ehesten erfolgversprechende

[RichieXX]

@homoran
Das klingt schonmal interessant. Also den Slave gleich mit neu aufsetzten und als Slave an den aktuellen master "anhängen" und Backup zurückspielen. Meinst du das so?

[Homoran]

@richiexx sagte in iob Master/Slave alt/neu:

Meinst du das so?

aber nur unter den genannten Bedingungen!

Außerdem hat mir

@richiexx sagte in iob Master/Slave alt/neu:

als Slave an den aktuellen master "anhängen"

wieder viel zu viele offene, interpretierbare Formulierungen.

[RichieXX]

bei korrekter Vorgehensweise bei der Multihost Einrichtung wird dann der (mit neuem Grundsystem und von allen Adaptern befreite) Slave automatisch mit konfiguriert.

Muss dabei die exakt gleiche Konfiguration (Name, IP etc) vorliegen? Wenn ja, müsste ich mir eine Testumgebung zusammenstellen und könnte das nicht zusammen mit dem Produktivsystem im gleichen Netz testen.

Ich glaube jedoch, dass auch dies zum Scheitern verurteilt ist, denn der laufende Backitup Adapter V2.1.17 kann noch kein Master/Slave.

[Homoran]

@richiexx sagte in iob Master/Slave alt/neu:

kann noch kein Master/Slave.

das brauchst du nur, wenn auf dem Slave eine externe Datenbank gesichert werden muss.

Bei einer korrekten Multihost Umgebung werden alle Instanzen im Master verwaltet

[RichieXX]

@homoran
Tatsächlich wäre das eigentlich die Zweitwichtigste DB: Zigbee.

[Homoran]

@richiexx kommen da jetzt nach und nach noch weitere essentielle Informationen, die bisher fehlen?

bei Zigbee kann ich nicht helfen.

[Thomas Braun]

@richiexx

Wie biste denn da jetzt konkret bei beiden System unterwegs?

sudo ln -s /usr/bin/node /usr/bin/nodejs &> /dev/null

uname -m && type -P nodejs node npm npx && nodejs -v && node -v && npm -v && npx -v && iob -v && whoami && groups && echo $XDG_SESSION_TYPE && pwd && sudo apt update &> /dev/null && sudo apt update && apt policy nodejs

iobroker update

Wenn man das weiß kann man auch was raten.

[RichieXX]

@homoran
Sorry homoran, für mich ist es schwierig, einzuschätzen, welche Informationen von Relevanz sind.

Ich versuch mal etwas Licht ins Dunkel zu bringen:

root@iobroker:/opt/iobroker# iobroker list adapters
system.adapter.admin                   : admin          - v4.2.1
system.adapter.backitup                : backitup       - v2.1.17
system.adapter.discovery               : discovery      - v2.7.2
system.adapter.dwd                     : dwd            - v2.7.7
system.adapter.enigma2                 : enigma2        - v1.0.0
system.adapter.feiertage               : feiertage      - v1.1.0
system.adapter.flot                    : flot           - v1.11.0
system.adapter.fritzbox                : fritzbox       - v0.2.1
system.adapter.g-homa                  : g-homa         - v0.5.3
system.adapter.harmony                 : harmony        - v1.2.2
system.adapter.homepilot20             : homepilot20    - v0.0.42
system.adapter.hs100                   : hs100          - v2.0.6
system.adapter.influxdb                : influxdb       - v1.9.4
system.adapter.info                    : info           - v1.9.10
system.adapter.iqontrol                : iqontrol       - v1.9.13
system.adapter.javascript              : javascript     - v4.11.0
system.adapter.km200                   : km200          - v2.0.3
system.adapter.material                : material       - v0.13.9
system.adapter.milight                 : milight        - v0.3.6
system.adapter.milight-smart-light     : milight-smart-light - v1.2.1
system.adapter.mqtt                    : mqtt           - v2.4.0
system.adapter.mqtt-client             : mqtt-client    - v1.3.1
system.adapter.node-red                : node-red       - v2.4.1
system.adapter.openweathermap          : openweathermap - v0.1.0
system.adapter.parser                  : parser         - v1.0.7
system.adapter.paw                     : paw            - v0.3.1
system.adapter.pi-hole                 : pi-hole        - v1.3.2
system.adapter.ping                    : ping           - v1.5.0
system.adapter.sayit                   : sayit          - v1.12.3
system.adapter.scenes                  : scenes         - v2.3.8
system.adapter.schoolfree              : schoolfree     - v1.0.1
system.adapter.shelly                  : shelly         - v4.1.2
system.adapter.simple-api              : simple-api     - v2.6.2
system.adapter.socketio                : socketio       - v3.1.5
system.adapter.sql                     : sql            - v1.15.7
system.adapter.telegram                : telegram       - v1.10.0
system.adapter.text2command            : text2command   - v2.1.1
system.adapter.vis                     : vis            - v1.4.4
system.adapter.vis-bars                : vis-bars       - v0.1.4
system.adapter.vis-canvas-gauges       : vis-canvas-gauges - v0.1.5
system.adapter.vis-colorpicker         : vis-colorpicker - v1.2.0
system.adapter.vis-fancyswitch         : vis-fancyswitch - v1.1.0
system.adapter.vis-history             : vis-history    - v1.0.0
system.adapter.vis-hqwidgets           : vis-hqwidgets  - v1.1.7
system.adapter.vis-map                 : vis-map        - v1.0.4
system.adapter.vis-material            : vis-material   - v0.1.3
system.adapter.vis-metro               : vis-metro      - v1.1.2
system.adapter.vis-rgraph              : vis-rgraph     - v0.0.2
system.adapter.vis-timeandweather      : vis-timeandweather - v1.1.7
system.adapter.vis-weather             : vis-weather    - v2.5.3
system.adapter.web                     : web            - v3.2.3
system.adapter.yeelight-2              : yeelight-2     - v1.1.2
system.adapter.zigbee                  : zigbee         - v1.5.1
system.adapter.zwave                   : zwave          - v2.0.1

Zigbee, Zwave, Shelly, Homepilot sowie Logitech laufen auf dem Slave.

Die Wichtigsten Adapter zur Gesamtfunktionalität sind

• Zigbee
• ZWave
• Homepilot
• ScriptEngine
• InfluxDB
• MySQL
• KM200

Apropos DBs: Werden die Datendanken wirklich korrekt zur Datenauswertung übernommen?

Master und Slave laufen in VMs (1x KVM (QNAP), 1x VMWare) unter Ubuntu 18.0.4. Das ist auch noch ein Grund zur Neueinrichtung: Die QNAP VM soll endlich umziehen auf den VMWare ESXi, da der deutlich leistungsfähiger und besser managebar ist (Backup etc).