openhabforum.de

Hallo. Ich war schon lange nicht mehr hier.

Bei mir ist ein Shelly ausgefallen. Ich habe mir neue bestellt, diese sind leider von der Generation3. Ein einbinden in openHAB ist nicht möglich. Etwas gegoogelt und herrausgefunden, das openHAB 4.2.x nötig ist, damit das Shelly Binding die Shellys Generation 3 einbinden kann.

Jetzt habe ich versucht, openHAB zu updaten. Leider kommt ein Fehler. Auch ein upgrade auf 5 wirft ein Fehler.
Was kann ich tun?

System
## Release = Raspbian GNU/Linux 11 (bullseye)
## Kernel = Linux 6.1.21-v8+
## Platform = Raspberry Pi 4 Model B Rev 1.1
## Uptime = 0 day(s). 0:2:3
## CPU Usage = 1.25% avg over 4 cpu(s) (4 core(s) x 1 socket(s))
## CPU Load = 1m: 0.68, 5m: 0.43, 15m: 0.17
## Memory = Free: 2.61GB (70%), Used: 1.13GB (30%), Total: 3.75GB
## Swap = Free: 2.99GB (100%), Used: 0.00GB (0%), Total: 2.99GB
## Root = Free: 7.66GB (55%), Used: 6.03GB (45%), Total: 14.31GB

Wenn ich die Fehlermeldung vom Upgrade richtig verstehe, fehlt mir Java 21, und für Java 21 braucht man ein 64Bit System.
Beim update zur letzten stabielen Version (release), wird die Instalation abgebrochen und man solle es später nochmal versuche.

Vielleicht verstehe ich einiges auch nicht richtig.

N1d45 hat geschrieben: 14. Jan 2026 14:59 Wenn ich die Fehlermeldung vom Upgrade richtig verstehe, fehlt mir Java 21, und für Java 21 braucht man ein 64Bit System.

Korrekt.

openHAB5 setzt ein 64-Bit-System voraus (Java 21 gibt es durchaus auch für 32 Bit, aber openHAB will jetzt nur noch 64 Bit)

Vermutlich ist der "einfachste" Weg, ein Backup Deiner Konfiguration zu machen und trixie in 64 Bit zu installieren, dann kannst Du direkt auf openHAB5 wechseln.

Je nachdem, wie Du das System konfigurierst, kann es sogar sein, dass Du "relativ schmerzlos" updaten kannst.
Aber wie immer gibt es ein paar Dinge, die sich geändert haben, insbesondere die aktuelle Version OH5.1 bringt eine Änderung (zurück zu den Wurzeln...), und zwar, dass Items nur dann persistiert werden, wenn dies auch konfiguriert wurde. Es gibt kein "persistiere einfach erst mal alle Items, auch wenn der Anwender das nicht explizit so konfiguriert hat" mehr.
Du tust also (wie bei jedem Update...) gut daran, die Changelogs zumindest zu überfliegen.

Eine Alternative könnte sein, das Backup auf der gleichen Version zurückzuspielen und von dort upzudaten, also aus einer neuen "alten" Version. Allerdings bietet openHABian gewöhnlich keine Option, eine ganz bestimmte Version von openHAB zu installieren, allenfalls kannst Du in openhabian-config jeweils die letzte Version des konfigurierten Branches wählen.

Das heißt, Du müsstest dazu

• auf einer neuen SD-Karte openHABian installieren
• Die Karte in Betrieb nehmen (ohne irgendwas zu konfigurieren, es geht nur darum, dass der automatische Rollout gelaufen ist)
• anschließend mittels sudo apt purge openhab openhab-addons openHAB deinstallieren
• mit apt-cache madison openhab die Liste der verfügbaren Versionen anzeigen lassen
• mit sudo apt install openhab=4.0.1-M2-1 openhab-addons=4.0.1-M2-1 die gewünschte Version installieren (den exakten Namen findest über madison)
• das Backup wieder einspielen

Danach kannst Du dann einen weiteren Versuch unternehmen, auf die höhere 4er Version upzudaten.

So oder so solltest Du nach Möglichkeit ein 64-Bit Image verwenden, um entweder direkt OH5 nutzen zu können oder Dir zumindest die Option offen zu halten, updaten zu können.
Ganz dringend möchte ich empfehlen, nicht auf einer Milestone Version stehen zu bleiben, da sind immer ein paar ungefixte Fehler versteckt, auch wenn sie Dich vielleicht nicht betreffen, kannst Du irgendwann darüber stolpern.
Und weil es da auch immer unterschiedliche Aussagen gibt: Auch die addons sollte möglichst die gleiche Version haben. Es gibt immer mal wieder Fälle, wo ein Addon nicht in der passenden Version zur Verfügung steht, wenn die Version nicht stark abeicht, kann man eventuell auch mit der alten Version hinkommen, eine Garantie gibt es da aber nicht. Besonders problematisch ist das bei Marketplace Addons, weil dort bisher immer nur eine Version des Addons zur Verfügung gestellt werden kann.

Danke für deine Ausführliche Antwort.

Ein paar Fragen stellen sich mir.

Ein Backup erstellen, bekomme ich hin. Dieses wird in einem Ordner /var/lib/openhab/backups/ auf dem Raspberry abgelegt. Auch bekomme ich es hin, dieses Backup per WinSCP zu mir auf den Laptop zu holen. Aber vom Laptop zurück auf den Raspberry zu schreiben, scheitert immer, wahrscheinlich durch fehlende Rechte? Als Beispiel: Solange ich es also nicht hinbekomme, dieses Backup auf den Raspberry zu bringen, sind deine gezeigten Wege eigentlich nutzlos, da ich das backup nicht einspielen kann, richtig?
Was für ein Backup brauche ich für die von dir gezeigten Wege? Full oder Standart?
(Ich habe mir dann den Umweg über das Image spiegeln der SD-Karte gemacht, um ein funktionstüchtiges Backup zu haben)

Vermutlich ist der "einfachste" Weg, ein Backup Deiner Konfiguration zu machen und trixie in 64 Bit zu installieren

trixie, ich musste erst googeln was das ist, ist ja ein anderes "Betriebssystem" für den Raspberry, richtig? Also eine leere SD-Karte, dort das trixie installieren, dann openHAB instalieren, und dann das Backup aufspielen? Oder, wenn ich es richtig gelesen und verstanden habe, es gibt ein openHABian Image mit trixie. Aber dann habe ich ja wieder das Problem mit den backup Daten.

So richtig kann ich den Weg noch nicht nachvollziehen, und traue mich dadurch nicht den Weg zu beginnen.

Eine Alternative könnte sein, das Backup auf der gleichen Version zurückzuspielen und von dort upzudaten, also aus einer neuen "alten" Version. Allerdings bietet openHABian gewöhnlich keine Option, eine ganz bestimmte Version von openHAB zu installieren, allenfalls kannst Du in openhabian-config jeweils die letzte Version des konfigurierten Branches wählen.

Das heißt, Du müsstest dazu

• auf einer neuen SD-Karte openHABian installieren
• Die Karte in Betrieb nehmen (ohne irgendwas zu konfigurieren, es geht nur darum, dass der automatische Rollout gelaufen ist)
• anschließend mittels sudo apt purge openhab openhab-addons openHAB deinstallieren
• mit apt-cache madison openhab die Liste der verfügbaren Versionen anzeigen lassen
• mit sudo apt install openhab=4.0.1-M2-1 openhab-addons=4.0.1-M2-1 die gewünschte Version installieren (den exakten Namen findest über madison)
• das Backup wieder einspielen

Danach kannst Du dann einen weiteren Versuch unternehmen, auf die höhere 4er Version upzudaten.

Auch hier muss ich erst einmal einen Weg finden, die Backup-Datei auf den Raspberry zu bringen.

Die Backupdatei wird in dem Verzeichnis /var/lib/openhab/backups/ angelegt, weil das der default Pfad ist, wenn man kein explizites Ziel angibt. Beim Restore spielt es keine Rolle, wo die Datei liegt Du kannst sie z.B. einfach in /home/openhabian/ ablegen, falls Du per WinSCP mit dem User openhabian angemeldet sein solltest.

Das Backup macht man gewöhnlich über die Shell: Der Parameter --full sorgt dabei dafür, dass auch die interne Persistence mit gesichert wird (rrd4j und mapdb). Falls diese Daten nicht wichtig sind, kann man natürlich auch auf --full verzichten und hat dann ein entsprechend kleineres Backup.
Wahlweise könnte man auch ein Ziel mit angeben: Das ist aber vor allem sinnvoll, wenn man backups automatisiert generieren lässt, also über eine crond Regel. Gibt man hingegen keine Zieldatei an, so generiert das Backup Script die Datei im userdata Verzeichnis im Unterverzeichnis ./backups/ und benennt die Datei mit Datums-und Zeitstempel, so dass es nie zu Namenskollisionen kommen kann.

Den Restore erledigt man analog dazu, nur dass hier zwingend der Dateiname mit angegeben werden muss: Der erste Befehl stoppt ein evtl. laufendes openHAB (das ist essenziell - beim Restore muss - im Gegensatz zum Backup - openHAB angehalten sein)
Der zweite Befehl spielt das Backup von der gewählten Datei ein.
Der dritte Befehl leert den Cache von openHAB. Dieser Schritt ist zwingend, falls man ein Full Backup von einer anderen Version einspielt. Ist die Version identisch, kann clean-cache entfallen, schaden tut es aber auch nicht. Einzig ist der erste Start nach einem clean-cache ungewöhnlich langsam und es kommen diverse Fehlermeldungen wegen fehlender Abhängigkeiten, die openHAB erst wieder herunterladen muss.
Der vierte Befehl stellt die korrekten Besitzverhältnisse wieder her. Das ist essenziell, wenn das Backup nicht von der selben openHAB Instanz stammt (schließlich gibt es keine Garantie, dass die User- und Group-IDs sich nicht unterscheiden). Auch dieser Befehl kann keinen Schaden anrichten.
Der letzte Befehl schließlich startet openHAB.

openhabian-config hat im Menü auch für die Backupfunktionen Unterpunkte definiert, die machen aber auch nichts anders als diese Liste an Befehlen abzuarbeiten - und die notwendigen Schritte drum herum (wie kommt die Backupdatei auf das System...) muss der Anwender eh händisch erledigen.

trixie ist die aktuelle Version von Raspberry Pi OS Wenn Du mit dem Raspberry Pi Imager das aktuelle openHABian Image (64 Bit...) auf eine SD-Karte schreiben lässt, sollte es sich um Raspberry Pi OS lite (trixie) handeln.

Hintergrundinfo: Raspberry Pi OS setzt auf Debian auf (nicht auf Ubuntu...). Entsprechend verwendet Raspberry Pi OS auch die Nomenklatur von Debian.
Debian wiederum verwendet für jede Haupt-Version einen Charakter aus Toy Story, siehe auch https://en.wikipedia.org/wiki/Debian_re ... on_history
Sid hat dabei eine Sonderfunktion, dies ist immer die Entwicklerversion (die sollte man nicht als Produktivumgebung nutzen).
Trixie ist der "Name" von Debian Ver. 13.
Raspberry Pi OS ist gewöhnlich ein paar Wochen/Monate hinter Debian im Release Zyklus, Debian 13 wurde am 09. August 2025 stable.
Im Gegensatz zu bookworm (Ver. 12...) bringt trixie Java 21 nativ mit (OpenJDK 21), man muss dann nicht auf Zulu "Temurin" ausweichen.