Update von oH 3.2 auf 4.3

[Selter]

Hallo zusammnen,

wie kann man von oH 3.2 auf 4.3 updaten?

Aktuell läuft oH bei mir in einer VM (openhabian) unter Proxmox. Ich hatte die VM geclont, komme aber nicht weiter.

Was muss hier ausgewählt werden?


| You are currently using a custom version of openHABian. If you think this is an error, │
│ please report on Github (remember to provide a debug log - see debug guide).. │
│ │
│ You can switch openHABian version at any time by selecting this menu option again or │
│ by setting the 'clonebranch=' parameter in '/etc/openhabian.conf'. │
│ Note: this menu only changes the version of openHABian and not openHAB. To select the │
│ openHAB version, see the 'openHAB Related' menu item. │
│ │
│ ( ) release most recommended version that supports openHAB 4 (openHAB branch) │
│ ( ) latest the latest of openHABian, not well tested (main branch) │
│ ( ) legacy use for openHAB 2.x support (legacy branch) │
│ (*) openHAB3 some other version you fetched yourself │
│ │
│ │
│ <Ok> <Abbrechen> │
│

[udo1toni]

Erst einmal solltest Du openHAB auf die letzte 3er Version updaten, das wäre 3.4.5.
Das Problem: openHAB3 ist "schon was älter", da ist ein wenig mehr Arbeit angesagt.

Zunächst musst Du openHABian über die Datei /etc/openhabian.conf auf den Branch openHAB3 konfigurieren.
Anschließend sollte ein Start von openhabian-config zunächst ein self update auslösen.
Danach müsstest Du über die Oberfläche auf die letzte Version von openHAB3 updaten können.

Nun sollte das Update auf openHAB4 in ähnlicher Weise durchführbar sein (Branch auf openHAB4 ändern usw.).
Nicht vergessen, openHAB3 läuft mit Java11, openHAB4 benötigt Java17.

Sollte openHAB4 nur als Zwischenstation gedacht sein, wäre der nächste Schritt zu openHA5 mit Java21 (zwingend 64 Bit), wobei der Branch, weil es die aktuelle Version ist, dann openHAB heißt.

Eventuell wäre es zielführender, ein Backup der Daten vorzunehmen und anschließend ein Restore auf einem aktuellen openHAB5 auszuführen.
Wobei ich persönlich einen LXC vorziehe - der benötigt weniger Ressourcen. Und solange man keine Hardware durchreichen will, gibt es kaum Gründe für eine VM anstatt eines Containers. Aber selbst dann... Das Durchreichen von USB Geräten sollte auch mit LXC gehen, ist aber erfahrungsgemäß nicht trivial irgendwas ist ja immer.

[Selter]

Danke für die Tipps.
Insgesamt möchte ich mit mgl. wenig Aufwand eine neuere openHAB Version erhalten.
Bei mir läuft noch alles mit Textfiles, daher scheue ich mich vor dem Sprung auf oH5.

Der Bedarf eines relativ aktuellen Shelly-Bindings und aktuellerer MQTT sind der Grund, warum ich auf 4.x wechseln möchte.

Und genau - ich reiche einen Z-Wave USB-Controller durch.

[peter-pan]

Bei mir läuft noch alles mit Textfiles, daher scheue ich mich vor dem Sprung auf oH5.

Bei mir läuft OH5 fast ausschließlich mit Text-Files. Ich habe lediglich für Homematic eine Bridge, die durch die UI erstellt wurde.

[udo1toni]

Genau. Textfiles sind kein Problem, allenfalls muss man ab und zu schauen, wie neue Features im Textfile abgebildet werden.
Aber mit openHAB5 ist das recht einfach geworden, denn nun kann man testweise ein Item mit allen gewünschten Eigenschaften über die Main UI erstellen.
Anschließend kann man das Item als Textdefinition ausgeben lassen - wahlweise in yaml oder DSL.

So werden auch "speziellere" Konfigurationen zum Kinderspiel.

[Selter]

Also wäre es einen Versuch wert oH5 zu installieren und dann meine Textfiles/Rules einspielen.

Diese Bindings sind in meiner addons.cfg:
astro,mqtt,ntp,modbus,remoteopenhab,smaenergymeter,unifi,tr064,avmfritz,pushover,telegram,exec,max,mihome,network,zwave,openweathermap,systeminfo,amazonechocontrol,ipcamera

Kann ich die auch einfach einfügen und dann werden beim Start von oH5 die Bindings installiert?

[peter-pan]

Die Bindings musst du einfach über die Main-UI - Add-on-Store - installieren.
War das in OH3 nicht auch schon so ? Allerdings sind in meiner "/etc/openhab/services/addons.cfg" gar keine Bindings aufgelistet.

[udo1toni]

Das geht auch (immer noch) über die addons.cfg. Die Namen haben sich, soweit ich das sehe, nicht verändert.

Falls doch, wird openHAB den Misserfolg loggen und Du kannst es leicht korrigieren (Addon über die UI installieren, in der Karaf Konsole den gemeldeten Namen herausfinden, Addon wieder deinstallieren, Namen eintragen, openHAB neu starten)

Der Vorteil der addons.cfg: openHAB wird jederzeit vollständig wieder hoch kommen, mit allen Addons, unter allen Umständen.
Der Nachteil: openHAB wird bei jedem Neustart exakt die Addons einrichten, die auch in der addons.cfg angegeben sind.
openHAB wird notfalls aktiv Addons deinstallieren, falls diese nicht in der Liste stehen. Das gilt auch für Marketplace Addons (die bisher nicht ohne Umwege über die addons.cfg angegeben werden können). Einzige Ausnahme: *.jar Dateien im addons Ordner, der neben dem runtime Ordner liegt.

Es gibt ein bash script, welches genutzt werden kann, um die addons aus dem Marketplace ebenfalls in der addons.cfg dort listen zu können, 3rd-party-Addons sind allerdings (zumindest in dem Script, welches mit vorliegt) außen vor.