openhabforum.de

Hallo zusammen,
ich hoffe ihr könnt mir weiterhelfen.
Ich probiere seit mittlerweile einer Woche mein OpenHab 2.5.11 vom Qnap Docker Container in eine Qnap VM mit Ubuntu 22.04 umzuziehen. Leider ohne Erfolg.
Im OH2 wurden die Bindings und etwa 100 Things über die PaperUI erstellt. Alles andere habe ich über Visual studio code textuell erstellt. Läuft alles perfekt und ist sehr umfangreich. Leider bin ich wegen dem Docker immer wieder auf Probleme gestoßen welche andere in einer Linux VM oder auf dem Rasperry sehr schnell gelöst haben.
Deswegen die Entscheidung ein paar Tage zu investieren um das OpenHab in eine VM umzuziehen. Das ganze wollte ich gleich mit einem Update auf OH3 verbinden wenn ich schon dabei bin.

OH2 Backup:
Als erstes habe ich mich informiert bezüglich der Backup Möglichkeiten meines OH2.
Diese Möglichkeiten habe ich gefunden:

1. sudo openhab-cli backup Dateiname.zip
--> Ich habe gelesen dieser Befehlt funktioniert im Docker leider nicht.
2. Backup script starten im Ordner openhab/runtime/backup
--> Es gibt bei mir keinen Unterordner mit dem Namen Runtime

Ich habe nur 3 Ordner gemounted aus dem Docker: addons, conf, userdata
Darin arbeite ich normalerweise mit visual studio code

3. Bleibt nur noch die letzte Möglichkeit welche ich gefunden habe. Einfach die Ordner conf und userdata kopieren


Wiederherstellung auf der Linux 22.04 VM:

Folgendes habe ich bereits versucht:

1. OH3 nach Anleitung installiert + Samba Freigaben und als Netzlaufwerke im Windows eingebunden
--> Zugriff auf /etc/openhab und /var/lib/openhab gegeben
--> OH3 ist erreichbar über <IPAdresse>:8080
Soweit alles gut.

Als erstes habe ich versucht einfach die order conf und userdata in die dementsprechenden neuen OH3 Ordner zu kopieren. --> OH3 startet nicht mehr

Also OH3 wieder neu installiert mit folgenden Befehlen:
sudo apt remove openhab
sudo apt purge openhab
sudo apt install openhab
--> Läuft wieder

Danach habe ich nur teilweise Ordner rüber kopiert in OH3. Verschiedene Varianten getestet und dazwischen immer wieder Neuinstalliert. Doch ich habe es nie geschafft das meine Things verfügbar sind. Die Rules und Items werden zwar angezeigt mit dem Wert NULL.
Das ganze habe ich mir anders vorgestellt. Rüber kopieren und alles funktioniert wieder wie zuvor.
Alles neu zu installieren und Things neu zu erstellen kommt für mich bei der Menge an Things und Bindings aus zeitlichen Gründen nicht in Frage.

2, Fazit für mich daraus war dann. OH2 und OH3 ist wahrscheinlich nicht 1:1 kompatibel. Deswegen neuer Ansatz,
im ersten Schritt erstmal die gleiche alte OH2 Version auf Ubuntu 22,04 VM installieren und funktionsgleich zum laufen zu bekommen --> Sollte doch funktionieren indem ich alle 3 Ordner addons , conf und userdata komplett
rüberzukopieren.

Soviel zu meiner Theorie.
Also wieder OH3 deinstalliert mi den Befehlen
sudo apt remove openhab
sudo apt purge openhab
Und danach versucht OH2 mit den Befehlen auf der offizielen Homepage zu installien.
Jedoch installiert er mir wieder OH3.3 anstatt OH2
Ich werde noch wahnsinnig
Was mache ich falsch

Log:
https://v2.openhab.org/download/

fabian@fabian-Standard-PC-i440FX-PIIX-1996:~$ wget -qO - 'https://openhab.jfrog.io/artifactory/api/gpg/key/public' | sudo apt-key add -
[sudo] Passwort für fabian:
Warning: apt-key is deprecated. Manage keyring files in trusted.gpg.d instead (see apt-key(8)).
OK

fabian@fabian-Standard-PC-i440FX-PIIX-1996:~$ sudo apt-get install apt-transport-https
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
apt-transport-https ist schon die neueste Version (2.4.8).
0 aktualisiert, 0 neu installiert, 0 zu entfernen und 4 nicht aktualisiert.

fabian@fabian-Standard-PC-i440FX-PIIX-1996:~$ echo 'deb https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable main' | sudo tee /etc/apt/sources.list.d/openhab.list
deb https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable main

fabian@fabian-Standard-PC-i440FX-PIIX-1996:~$ sudo apt-get update && sudo apt-get install openhab
Holen:1 http://security.ubuntu.com/ubuntu jammy-security InRelease [110 kB]
OK:2 http://de.archive.ubuntu.com/ubuntu jammy InRelease
OK:3 http://de.archive.ubuntu.com/ubuntu jammy-updates InRelease
OK:4 http://de.archive.ubuntu.com/ubuntu jammy-backports InRelease
OK:5 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable InRelease
Es wurden 110 kB in 2 s geholt (61,1 kB/s).
Paketlisten werden gelesen… Fertig
W: https://openhab.jfrog.io/artifactory/op ... /InRelease: Schlüssel ist im veralteten Schlüsselbund trusted.gpg gespeichert (/etc/apt/trusted.gpg), siehe den Abschnitt MISSBILLIGUNG in apt-key(8) für Details.
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden NEUEN Pakete werden installiert:
openhab
0 aktualisiert, 1 neu installiert, 0 zu entfernen und 4 nicht aktualisiert.
Es müssen noch 0 B von 98,2 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 109 MB Plattenplatz zusätzlich benutzt.
Vormals nicht ausgewähltes Paket openhab wird gewählt.
(Lese Datenbank ... 202651 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../openhab_3.3.0-1_all.deb ...
Entpacken von openhab (3.3.0-1) ...
openhab (3.3.0-1) wird eingerichtet ...
[openHAB] Please use the following commands to launch openHAB on a system restart.
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable openhab.service

[openHAB] You can start openHAB manually by executing the command:
sudo /bin/systemctl start openhab.service


Gruß
Fabian

Wichtig: zuerst mal etwas ruhiger an die Sache rangehen

Du schreibst ja, dass Deine Docker Installation wunderbar funktioniert. Mein Vorschlag wäre also, nicht von Docker wegzugehen, wenn es sich vermeiden lässt.
Größere Probleme mit Docker wären mir nicht bekannt. Was eventuell Schwierigkeiten macht: Das Netzwerk von Docker hat ein paar Besonderheiten, welche gerne auch Hürden darstellen, insbesondere falls man nicht im Host Mode arbeitet. Gewöhnlich werden Docker Container im Bridge Mode betrieben, was auch mit openHAB möglich ist, aber es gibt einige Addons, welche Multicast verwenden. Multicast wird grundsätzlich nicht geroutet, womit es in einem bridged Container witzlos ist.
Andere Herausforderungen sind das Hereinreichen von externer Hardware (USB-Sticks...) und viele Details aus der Doku, die sich immer auf eine normale Installation beziehen (z.B. Backup...) aber bei Docker per Definition nicht kompatibel sein können.

Umstieg von openHAB2 auf openHAB3: Das ist - vor allem bei einer umfangreicheren Installation - nicht mit einem einfachen Upgrade erledigt.
Folgende Punkte sind dabei zu beachten:

1. Unter openHAB2 werden potenziell noch Bindings vom Typ OH1 eingesetzt (erkennbar an einer separaten Datei <binding>.cfg unterhalb $OPENHAB_CONF/services/ und einer Verknüpfung auf Items, die nicht das Schlüsselwort channel verwendet, sondern pro Binding ein eigenes Schlüsselwort, wie z.B. http, die Items müssen in diesem Fall zwingend über eine Textdatei angelegt sein, anders geht es nicht.
   OH1-kompatible Bindings laufen nicht unter openHAB3, müssen also mindestens durch die OH3-Version ersetzt werden (z.B. http...) und damit gehen umfangreiche Änderungen in der Konfiguration für diese Bindings einher, das lässt sich auch nicht vermeiden.
   Es gibt auch einige exotische Bindings, für die es bisher keinen adäquaten Ersatz gibt.
2. Unter openHAB2 gibt es in den Rules für zeitbezogene Operationen Joda Time. Unter openHAB3 wird hier JavaTime verwendet, was bedeutet, dass hier diverse kleinere oder auch größere Anpassungen vorgenommen werden müssen, bis die Rules wieder fehlerfrei funktionieren.
3. Falls Du Rules mit mehreren Triggern einzelner Items verwendest und dann innerhalb der Rule mit triggeringItem arbeitest: Das geht nicht mehr. triggeringItem steht nur noch zur Verfügung, wenn die Rule durch Member of getriggert wurde. Für den Trigger Item gibt es triggeringItemName, welches aber auch nur den Namen als String enthält und kein genericItem Objekt darstellt.

Möchtest Du dennoch umsteigen, so wäre tatsächlich zunächst ein Update auf openHAB2.5.12 sinnvoll.
Wenn Du openHAB über apt installieren willst (das wäre ja der gewöhnliche Weg), must Du unbedingt darauf achten, nicht openhab als Paket anzugeben, sondern openhab2. Beide Versionen werden über das gleiche Repository ausgeliefert, wobei es gut sein kann, dass openhab2 ausschließlich über stable zur Verfügung steht.

Ubuntu ist übrigens nicht die bevorzugte Plattform für openHAB, es wurde verschiedentlich von seltsamen Effekten berichtet. Ich möchte stattdessen debian (bullseye) empfehlen, am besten ohne Schnickschnack, also kein Desktop, das kostet nur unnötig Speicher und Rechenzeit und bringt exakt gar nichts für openHAB.
openHAB2 braucht als Unterbau Java 8, openHAB3 braucht Java 11. Eventuell läuft OH2.5.12 auch unter Java 11, da gibt es unterschiedliche Aussagen Jedenfalls bietet bullsey kein OpenJDK 8 mehr an, also entweder es funktioniert unter Java 11 oder Du musst Dir das passende Paket manuell holen.

Umzug Docker -> VM: Es ist tatsächlich so, dass openhab-cli backup in Docker nicht zur Verfügung steht, aber das ist auch nicht sinnvoll, denn über Docker steht ja eine viel effizientere Backup Möglichkeit zur Verfügung, nämlich über die Volumes. Diese kann man notfalls auch gezielt in bestimmten Speicherbereichen anlegen, wo sie vollautomatisch repliziert und gesichert werden.
Für den Umzug bedeutet das aber in der Tat, dass Du die Daten händisch in die neue Verzeichnisstruktur kopieren musst.
Und ja, die Differenzen zwischen openHAB2.5.11 und openHAB3.3 sind so groß, dass openHAB3.3 zumindest mit einem Teil der alten Daten Probleme haben wird. Das erstreckt sich aber nicht auf die Dateien, in denen Things, Items und Rules gespeichert sind (und zwar sowohl die Textvariante als auch die UI Variante). Auch rrd4j sollte kein Problem darstellen. Anders sieht es aber mit diversen kleinen Konfigurationsdateien aus, z.B. die runtime.cfg, da können Dinge drin stehen, die openHAB3 aus dem Tritt bringen.