Hallo
Habe einen Freund OH empfohlen der Freund ist aber sehr unerfahren mit den Raspi. Und Wohnen 300 KM auseinander.
Ich habe rausgefunden das er Raspi Desktop Version nutzt.
Und er benutzt Java openjdk 11.026.
Und Openhab Version 2 läuft.
Ich selber bin auch kein Profi am PC.
Ich würde empfehlen
1. Java 17 zu Updaten.
2. Dann OpenHab4.32 laut Anleitung neu zu installieren.
Frage Neu installieren oder geht ein Update.
Frage bei neu Installieren von Openhab 4.32
Frage Läuft dann auf den Raspi OH Version 2 und 4.
Wie funktioniert eine vorherige Datensicherung?
Update von OpenHab 2 auf OH 4
Moderator: seppy
- Detlef
- Beiträge: 190
- Registriert: 11. Dez 2019 21:50
- Wohnort: Recklinghausen
- Kontaktdaten:
Update von OpenHab 2 auf OH 4
Mit freundlichen Grüße aus Recklinghausen
- udo1toni
- Beiträge: 15240
- Registriert: 11. Apr 2018 18:05
- Wohnort: Darmstadt
Re: Update von OpenHab 2 auf OH 4
Die wichtigste Frage ist, wie groß die Installation ist.
Der "korrekte" Weg wäre ein Update auf OH2.5.12, danach ein Upgrade auf OH3.4.5 (wobei es vermutlich besser wäre, zunächst das Upgrade auf OH3.0.0 durchzuführen und anschließend auf OH3.4.5), danach das Upgrade auf Java 17, dann das Upgrade auf OH4.3.2 (gerne mit einem Zwischenschritt auf OH4.0.0)
Am Upgrade-Pfad kann man gut erkennen, dass man hier gerne ein ganzes Wochenende beschäftigt ist, und zwar nicht nur jeweils zehn Minuten pro Tag.
Das größte Problem ist dabei noch nicht mal angegangen, denn die OH2 Konfiguration ist fast sicher nicht vollständig kompatibel zu OH3.0.0, und es ist auch unwahrscheinlich, dass ein Übergang von OH3 auf OH4.3.2 danach keine Probleme bereitet.
Wie wurde die Konfiguration vorgenommen, evtl. in großen Teilen per Text Dateien? Das wäre tatsächlich von Vorteil, weil man dann zumindest die Items leicht hinüberretten kann.
Welche Bindings wurden eingesetzt? OH2 kennt den Compatibility Layer, um OH1 Bindings zu nutzen, und es gab einige Bindings nie offiziell als OH2-Version (z.B. http ist ein extrem häufig eingesetztes Binding, auf das dies zutrifft)
Solche Bindings sind daran zu erkennen, dass man sie ausschließlich über *.items Dateien und passende *.cfg Dateien im services Ordner konfigurieren kann, diese Bindings müssen durch eine aktuelle Version ersetzt werden, die dann thingbasiert funktioniert und komplett anders konfiguriert wird.
Falls Things per Textdatei konfiguriert wurden, bestünde zumindest eine Chance, diesen Teil der Konfiguration recht gut zu übernehmen, aber auch hier lauern Fallen, weil sich teilweise Parameternamen geändert haben (z.B. Hostname oder ip wurde zu host)
Spätestens bei den Rules wird es sicher knifflig, weil sich einfach extrem viel geändert hat - allem voran JavaTime statt Joda Time.
Man sollte sich also jeden Aspekt des Systems sehr genau anschauen, um anschließend zu überlegen, was einfacher ist - eine Upgrade-Orgie (und das beinhaltet fast zwingend auch mehrere Upgrades des Betriebssystems) oder eine komplette Neuinstallation, evtl. mit der (teilweisen) Übernahme der alten Konfiguration, aber definitiv mit viel Handarbeit.
Wenn es sich um ein kleines System mit wenigen dutzend Items und auch nur wenigen Things handelt, ist es fast sicher sinnvoller, alles komplett wegzuschmeißen und bei 0 anzufangen - Und weil es ziemlich sicher eine emotionale Abhängigkeit zu openHAB gibt
böte es sich an, dieses neu aufgesetzte System zunächst vorzubereiten - entweder auf einer neuen Hardware, oder in einem virtuellen System. Letztere Variante ist komplett kostenlos zu haben, allerdings muss man lernwillig sein, erstere Variante hat den Vorteil, dass man anschließend auch für die Zukunft gerüstet sein kann. openHAB5 wird nur noch auf 64-Bit-Betriebssystemen laufen (kommt im Juni).
Ob man dafür zu einem Raspberry Pi 5 mit mindestens 4 GByte greift oder z.B. zu einem (evtl. gebrauchten) NUC, ist vor allem Geschmacksache.
Bei der virtuellen Variante kann man anschließend den Raspberry Pi komplett neu aufsetzen, mit dem aktuellen openHABian, da das virtuelle System dann ebenfalls auf der aktuellen Version ist, ist ein Backup und Restore dann kein Problem.
Der "korrekte" Weg wäre ein Update auf OH2.5.12, danach ein Upgrade auf OH3.4.5 (wobei es vermutlich besser wäre, zunächst das Upgrade auf OH3.0.0 durchzuführen und anschließend auf OH3.4.5), danach das Upgrade auf Java 17, dann das Upgrade auf OH4.3.2 (gerne mit einem Zwischenschritt auf OH4.0.0)
Am Upgrade-Pfad kann man gut erkennen, dass man hier gerne ein ganzes Wochenende beschäftigt ist, und zwar nicht nur jeweils zehn Minuten pro Tag.
Das größte Problem ist dabei noch nicht mal angegangen, denn die OH2 Konfiguration ist fast sicher nicht vollständig kompatibel zu OH3.0.0, und es ist auch unwahrscheinlich, dass ein Übergang von OH3 auf OH4.3.2 danach keine Probleme bereitet.
Wie wurde die Konfiguration vorgenommen, evtl. in großen Teilen per Text Dateien? Das wäre tatsächlich von Vorteil, weil man dann zumindest die Items leicht hinüberretten kann.
Welche Bindings wurden eingesetzt? OH2 kennt den Compatibility Layer, um OH1 Bindings zu nutzen, und es gab einige Bindings nie offiziell als OH2-Version (z.B. http ist ein extrem häufig eingesetztes Binding, auf das dies zutrifft)
Solche Bindings sind daran zu erkennen, dass man sie ausschließlich über *.items Dateien und passende *.cfg Dateien im services Ordner konfigurieren kann, diese Bindings müssen durch eine aktuelle Version ersetzt werden, die dann thingbasiert funktioniert und komplett anders konfiguriert wird.
Falls Things per Textdatei konfiguriert wurden, bestünde zumindest eine Chance, diesen Teil der Konfiguration recht gut zu übernehmen, aber auch hier lauern Fallen, weil sich teilweise Parameternamen geändert haben (z.B. Hostname oder ip wurde zu host)
Spätestens bei den Rules wird es sicher knifflig, weil sich einfach extrem viel geändert hat - allem voran JavaTime statt Joda Time.
Man sollte sich also jeden Aspekt des Systems sehr genau anschauen, um anschließend zu überlegen, was einfacher ist - eine Upgrade-Orgie (und das beinhaltet fast zwingend auch mehrere Upgrades des Betriebssystems) oder eine komplette Neuinstallation, evtl. mit der (teilweisen) Übernahme der alten Konfiguration, aber definitiv mit viel Handarbeit.
Wenn es sich um ein kleines System mit wenigen dutzend Items und auch nur wenigen Things handelt, ist es fast sicher sinnvoller, alles komplett wegzuschmeißen und bei 0 anzufangen - Und weil es ziemlich sicher eine emotionale Abhängigkeit zu openHAB gibt

Ob man dafür zu einem Raspberry Pi 5 mit mindestens 4 GByte greift oder z.B. zu einem (evtl. gebrauchten) NUC, ist vor allem Geschmacksache.
Bei der virtuellen Variante kann man anschließend den Raspberry Pi komplett neu aufsetzen, mit dem aktuellen openHABian, da das virtuelle System dann ebenfalls auf der aktuellen Version ist, ist ein Backup und Restore dann kein Problem.
openHAB4.3.3 stable in einem Debian-Container (bookworm) (Proxmox 8.3.5, LXC), mit openHABian eingerichtet