Update von openHAB 4.1.0.M2

[N1d45]

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.

Code: Alles auswählen

2026-01-14_14:32:23_CET [openHABian] Updating Linux package information... OK
2026-01-14_14:32:23_CET [openHABian] Beginning install of latest openhab release (stable repo)... OK
2026-01-14_14:32:25_CET [openHABian] Adding required keys to apt... OK
2026-01-14_14:32:26_CET [openHABian] Installing selected openHAB version... FAILED

Auch ein upgrade auf 5 wirft ein Fehler.

Code: Alles auswählen

openhabian@openhabian:~ $ sudo apt-get upgrade
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
Calculating upgrade... Done
The following package was automatically installed and is no longer required:
  raspinfo
Use 'sudo apt autoremove' to remove it.
The following packages will be upgraded:
  openhab openhab-addons
2 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/676 MB of archives.
After this operation, 172 MB of additional disk space will be used.
Do you want to continue? [Y/n] y
Reading changelogs... Done
(Reading database ... 54869 files and directories currently installed.)
Preparing to unpack .../openhab_5.1.1-1_all.deb ...
[openHAB] WARNING: We were unable to detect Java 21 on your system. This is needed before openHAB is unpacked.
[openHAB] Java 21 may not be available on 32-bit platforms.
dpkg: error processing archive /var/cache/apt/archives/openhab_5.1.1-1_all.deb (--unpack):
 new openhab package pre-installation script subprocess returned error exit status 1
Preparing to unpack .../openhab-addons_5.1.1-1_all.deb ...
[openHAB] WARNING: We were unable to detect Java 21 on your system. This is needed before openHAB is unpacked.
[openHAB] Java 21 may not be available on 32-bit platforms.
dpkg: error processing archive /var/cache/apt/archives/openhab-addons_5.1.1-1_all.deb (--unpack):
 new openhab-addons package pre-installation script subprocess returned error exit status 1
Errors were encountered while processing:
 /var/cache/apt/archives/openhab_5.1.1-1_all.deb
 /var/cache/apt/archives/openhab-addons_5.1.1-1_all.deb
Updating FireMotD available updates count ...
E: Sub-process /usr/bin/dpkg returned an error code (1)

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.

[udo1toni]

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.

[N1d45]

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:

Code: Alles auswählen

scp: /var/lib/openhab/backups/openhab-backup-24_11_20-17_58_06.zip: Permission denied

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.

[udo1toni]

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:

Code: Alles auswählen

sudo openhab-cli backup --full

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:

Code: Alles auswählen

sudo openhab-cli backup --full /pfad/zum/backup/mein-backup-name.zip

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:

Code: Alles auswählen

sudo systemctl stop openhab.service
sudo openhab-cli restore /pfad/zur/backupdatei.zip
sudo openhab-cli clean-cache
sudo openhab-cli reset-ownership
sudo systemctl start openhab.service

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.

[N1d45]

Danke. Das mit dem Backup hat schon mal geklappt. Ein nach dem FullBack angelegtes Item war nach dem Wiederherstellen nicht mehr da.

Beim Wiederherstellen kam aber folgende Meldung in PuTTY die mich aufhorchen lässt.

Code: Alles auswählen

Deleting old userdata folder...
rm: cannot remove '/var/lib/openhab/persistence': Device or resource busy

Ein Problem?

...
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
• ...

Egal welche Version von openHABian?

[udo1toni]

Beim Wiederherstellen kam aber folgende Meldung in PuTTY die mich aufhorchen lässt.

Code: Alles auswählen

Deleting old userdata folder...
rm: cannot remove '/var/lib/openhab/persistence': Device or resource busy

Ein Problem?

Hm. Muss man halt mal schauen, welche Datei er da löschen wollte... Es kann sein, dass diese Daten im ZRAM liegen (salopp gesagt eine Art RAM-Disk), falls da akuter Platzmangel herrscht, könnte es evtl. mal stocken. Wenn der Restore ansonsten durch läuft, kannst Du schauen, welche Dateien er nicht wiederherstellen konnte (Zeitstempel der *.rrd Dateien...) und ob es "nicht so tragisch" ist, wenn die Daten fehlen. Nach einem Neustart des Raspberry könntest Du das Verzeichnis auch händisch leeren und anschließend den Teil des Backups ebenfalls händisch einspielen, letztlich ist das ja nur ein Zip-Archiv, welches Du leicht auf dem Pi auspacken kannst. Die Ordnerstruktur ist identisch mit der unterhalb der jeweiligen openHAB-.Ordner ($OPENHAB_CONF bzw. /etc/openhab/ und $OPENHAB_USERDATA bzw. /var/lib/openhab/), so dass Du in einem entpackten Archiv lediglich das entsprechende Verzeichnis verschieben musst:

Code: Alles auswählen

cd ~/
unzip meine-datei.zip userdata/persistence/*
sudo systemctl stop openhab.service
sudo rm -r /var/lib/openhab/persistence/*
sudo mv userdata/persistence/* /var/lib/openhab/persistence/
sudo openhab-cli reset-ownership
sudo systemctl start openhab.service
rm -r userdata

Der erste Befehl wechselt ins home-Verzeichnis des angemeldeten Users.
Der zweite Befehl entpackt dort die angegebene zip-Datei. Dabei wird nur der Teil unterhalb userdata/persistence/ ausgepackt
Der dritte Befehl stoppt openHAB
Der vierte Befehl löscht alles unterhalb /var/lib/openhab/persistence/ (incl. Verzeichnisse... also VORSICHT)
Der fünfte Befehl verschiebt den Inhalt aus dem entpackten Verzeichnis userdata/persistence/ an die richtige Stelle.
Der sechste Befehl stellt die korrekten Besitzverhältnisse her.
Der siebte Befehl startet openHAB
Der achte Befehl beseitigt die unnötigen Reste im home-Verzeichnis des aktuellen Users

Egal welche Version von openHABian?

Es gibt unterschiedliche Branches von openHABian, über den Branch kann man beeinflussen, welche Hauptversion angeboten wird. Für openHAB4 heißt der Branch ~Trommelwirbel~ openHAB4. Das trägst Du in der openhabian.conf an der richtigen Stelle ein und startest anschließend openhabian-config, dann sollte openhabian-config automatisch ein self update auf den gewünschten Branch ausführen. Danach sollte openHAB4 installiert werden, wenn Du das entsprechend auswählst.

[N1d45]

...
Die Karte in Betrieb nehmen (ohne irgendwas zu konfigurieren, es geht nur darum, dass der automatische Rollout gelaufen ist)
...

Woran erkennt man, das der Rollout fertig ist?
Edit: Am verlieren der Verbindung von Putty. Was eine Weile dauert.

...
anschließend mittels sudo apt purge openhab openhab-addons openHAB deinstallieren
...

Das wirft Warnungen und Error

Code: Alles auswählen

REMOVING:
  openhab*  openhab-addons*

Summary:
  Upgrading: 0, Installing: 0, Removing: 2, Not Upgrading: 0
  Freed space: 690 MB

Continue? [Y/n] y
(Reading database ... 104295 files and directories currently installed.)
Removing openhab-addons (5.1.1-1) ...
Removing openhab (5.1.1-1) ...
dpkg: warning: while removing openhab, unable to remove directory '/var/lib/openhab/persistence': Device or resource busy - directory may be a mount point?
(Reading database ... 103023 files and directories currently installed.)
Purging configuration files for openhab (5.1.1-1) ...
userdel: group openhab not removed because it has other members.
groupdel: cannot remove the primary group of user 'openhabian'
fatal: `/sbin/groupdel openhab' returned error code 8. Exiting.
rm: cannot remove '/var/lib/openhab/persistence': Device or resource busy
dpkg: error processing package openhab (--purge):
 installed openhab package post-removal script subprocess returned error exit status 1
Errors were encountered while processing:
 openhab
Updating FireMotD available updates count ...
Error: Sub-process /usr/bin/dpkg returned an error code (1)

...
mit apt-cache madison openhab die Liste der verfügbaren Versionen anzeigen lassen
...

Leider gibt es die 4.0.1-M2-1
Ich probiere mal die 4.0.1-1

Edit 2:
Ein Einspielen des Backups und ein Upgrade auf 5.1.1 hat funktioniert. Mal schauen ob alles soweit funktioniert.

DANKE

[N1d45]

Leider funktioniert nicht mehr alles.

Es werden keine offenen Fenster mehr erkannt, und alle darauf reagierenden Regeln tun dann nicht, was sie tun sollten

Nun ja, jetzt geht es auf Suche, wo es klemmt.

Edit: MQTT-Broker scheint nicht mehr zu funktionieren. Er ist nicht über MQTT-fx erreichbar.

Edit 2: Mosquitto war noch nicht installiert. Im Nachhinein ist es natürlich klar.