openhabforum.de

Hallo zusammen,

um zu vermeiden, dass Altasten durch einen Umstieg verbleiben, würde ich openHAB 4.x neu aufsetzen anstatt ein Upgrade zu machen.
Dazu habe ich einige Fragen

- Unterstützt openHABian bereits Bookworm?
- Reicht ein einspielen eines Backups durch openHABian zur Wiederhrstellung der Konfig?
- Welche Einstellungen sind für openHABian auf einem nicht-Raspberry Pi, ich würde mit den folgenden starten

Download, link and create config file
git clone -b openHAB3 https://github.com/openhab/openhabian.git /opt/openhabian
ln -s /opt/openhabian/openhabian-setup.sh /usr/local/bin/openhabian-config
cp /opt/openhabian/build-image/openhabian.conf /etc/openhabian.conf

Edit /etc/openhabian.conf to match my needs
nano /etc/openhabian.conf

Mandatory Setting:
system_default_locale="de_DE.UTF-8"
hwarch=amd64
osrelease=debian
java_opt=Zulu17-64
zraminstall=disable
hotspot=disable

Optional Settings
initialconfig=/tmp/MeinBackup.zip

Install openHABian
openhabian-config unattended

Den LXC würde ich mit den gleichen Parametern wie für openHAB 3.x erstellen, der dann natürlich herunter gefahren ist.

Habe ich etwas vergessen

Viele Grüße

Also, bei mir macht openHAB 4.0.1 unter LXC bookworm keinerlei Probleme Als Java Version musst Du 17 angeben, ob 32 Bit oder 64 Bit wird automatisch über die Architektur entschieden (amd64).

Allerdings möchte ich dazu raten, den Umstieg dennoch über ein Upgrade auszuführen, damit die automatischen Scripte greifen können. meines Wissens werden die nur ausgeführt, wenn openHAB ein Upgrade erkennt. Die Scripte nehmen z.B. Anpassungen an den Items vor (unit bei UoM ergänzen), was genau alles automatisch passiert, müsstest Du aber in den Sourcen nachschauen, da habe ich nie etwas Offizielles zu gelesen.

Falls Du ohnehin mit Textdateien zur Konfiguration arbeitest, spielt das aber keine Rolle, automatische Anpassungen erstrecken sich ausschließlich auf UI- (bzw. REST-)Konfiguration.

Wird denn beim upgrade über openhabian-config die alte JAva Version de- und Java 17 installiert?
Oder muss man dort manuell eingreifen?

Nein, Du musst jegliche Software um openHAB herum selbst auf den Stand bringen.

openHAB3.4 läuft ohne Probleme auch unter Java 17, so dass man diesen Schritt schon im Vorfeld erledigen kann.

udo1toni hat geschrieben: ↑16. Aug 2023 04:05 Nein, Du musst jegliche Software um openHAB herum selbst auf den Stand bringen.

Nun, habe ich versucht, wirklich aber irgendwie mag Linux mich nicht.

Java-11 will sich schon nicht gescheit deinstallieren lassen, daher wollte ich wie auf der Azul Seite beschrieben Java-17 installieren.
Habe die Anleitung befolgt, aber klappt natürlich nicht

[22:09:38] root@Skynet:~# sudo apt install gnupg ca-certificates curl
E: Widersprüchliche Werte gesetzt für Option Signed-By betreffend die Quelle https://repos.azul.com/zulu/deb/ stable: /usr/share/keyrings/zulu_enterprise.gpg != /usr/share/keyrings/azul.gpg
E: Die Liste der Quellen konnte nicht gelesen werden.
E: Widersprüchliche Werte gesetzt für Option Signed-By betreffend die Quelle https://repos.azul.com/zulu/deb/ stable: /usr/share/keyrings/zulu_enterprise.gpg != /usr/share/keyrings/azul.gpg
E: Die Liste der Quellen konnte nicht gelesen werden.

Evtl. hast Du oder jemand einen Schubs in die richtige Richtung?

Viele Grüße

Vergiss bitte Azul.

Du hast ja einen Debian Container laufen.
Um zunächst zu verhindern, dass openHAB upgedatet wird, setzt Du das Paket auf hold: Falls der Debian Container noch auf Buster basiert, musst Du nun zunächst ein Update vollziehen: Nun stellst Du apt auf Bullseye um: und aktualisierst das System auf (seit Juni) oldstable bullseye: Nach einem Neustart sollte das System mit bullseye laufen.
Danach sollte Java17 als openjdk-17-jre-headless zur Verfügung stehen.
Du kannst auch den Container noch nach bookworm updaten, aber vielleicht willst Du ja nach einem Upgrade auf openHAB4 und anschließendem Backup der Einstellungen einen komplett neuen Container erstellen.
Update von bullseye nach bookworm analog zum update oben, also zunächst Anschließend Paketquellen apassen: und nochmal GANZ wichtig: beim Upgrade werden diverse Dateien angefasst, die eventuell schon angepasst wurden. apt wird solche Dateien nie ohne Nachfrage ersetzen. Die Vorauswahl lautet immer N (nicht ersetzen), womit die "neue" Version dann als name.dpkg-dist im Verzeichnis landet. In vielen Fällen muss aber unbedingt die neue Version installiert werden, Du musst also aufmerksam lesen, bei welchen Dateien apt nachfragt und bewusst entscheiden, ob hier vielleicht Einstellungen nachträglich übernommen werden müssen. Y ersetzt die aktuelle Datei, legt aber eine Kopie an (mit dpkg-old als Endung), die Einstellungen gehen also nicht unrettbar verloren.

Ich gehe gewöhnlich davon aus, dass alle Dateien den neuen Stand bekommen sollen, vielleicht mit Ausnahme der smb.conf, in der die Freigaben für Samba definiert sind.

Wenn das System auf dem aktuellen Stand ist, kannst Du das hold von oben wieder auflösen: und mit dem nächsten Update kommt dann die aktuelle Version von openHAB auch noch auf das System. (aber vorher Java17 installieren...)

udo1toni hat geschrieben: ↑16. Aug 2023 23:04 Vergiss bitte Azul.

Du hast ja einen Debian Container laufen. Falls der Debian Container noch auf Buster basiert, musst Du zunächst ein Upgrade nach Bullseye vollziehen:

Ich hatte direkt (mit Deiner Unterstützung damals) auf Bullseye gestartet, aber dann auch Azul Java installiert.
War Azul nicht für openHAB empfohlen? Bekomme das aber gerade eh nicht de-installiert.

Ah. Nein, Azul macht gerne mal Probleme... openHAB empfiehlt schon lange kein Azul mehr, das ist quasi nur der Rettungsanker für Systeme, die kein OpenJDK mitbringen.

OK. Da ich Azul nicht mehr deinstalliert bekommen habe, habe ich heute Morgen mal etwas Zeit mit openHAB verbracht.

1. Versuch - Update der bestehenden Installation (OH 3.4.4 auf Bullseye)
Hier zu habe ich als Richtlinie diesen => Post genutzt.
Trotz Installation und Aktivierung als Default von openJDK 17 wurde bei java -version immer noch Azul angezeigt.
Habe dann trotzdem das Update auf OH4 über openHABian gestartet.

OH4 startetet, aber eine Menge Fehler und somit abgebrochen.

2. Versuch - Neuer Container direkt mit bookworm
Updates eingespielt, openJDK 17 installiert und openHABian gecloned und nach meiner alten Anleitung konfiguriert (ohne ZRAM, etc)
Dort ein frisches Backup als Konfig angegeben

OH4 startet, eine Menge weißer Schrift (so schnell kan mann nicht lesen) aber das kennt man auch von den Updates
Nach einem dritten Neustart von openHAB war das Log dann bis auf die Hinweise zum fehlenden "JS Transformation" sauber.
Sah erst gut aus und um die Transformation wollte ich mich heute Abend kümmern.

Aber: zu früh gefreut, openHAB (nicht der Container) starten willkürlich neu was natürlich ähnlich murks ist.

Also Logfiles gesichert, Container niedergefahren und den openHAB 3 Container wieder gestartet bevor die Frau nach Hause kommt

Mal sehen, was ob in den LogFiles etwas wegen den re-starts zu finden ist :-/
Dennoch seltsam, dass Azul nicht zu deinstallieren ist.

Du kannst die verwendete Java-Version mit update-alternatives umschalten. Notwendig sollte das gewöhnlich nicht sein, eventuell ist schon beim Installieren der Version ein Fehler passiert.

Das Update von 3.4 auf 4.0 kümmert sich um so einige Dinge, ich habe den Eindruck, dass die Upgrade Scripts dabei aber gerne auch mal hängen bleiben - wobei das bei mir nicht auftritt, da ich ohnehin reine Textkonfiguration betreibe...

Was die JS Transformation betrifft: Mit Version 4.0 werden die Script Transformation Services von der jeweiligen Scripting Engine mit übernommen, es gibt also keine separat zu installierende JS Transformation mehr, stattdessen musst Du JavaScript Scripting installieren (vorzugsweise GraalVM Nashorn ist alt).
Hast Du dem Container ausreichend RAM mitgegeben? Ich habe bei mir 3 GByte eingestellt, wobei der Container nach ein paar Stunden aber nicht mehr als 1,5 GByte nutzt (diesen Wert könnte man noch über die /etc/default/openhab.cfg beeinflussen, Startparameter für Java) Wichtig ist aber auf jeden Fall, dass Java sich erst mal frei entfalten kann - im Betrieb schlägt es dann nicht übermäßig zu.