openhabforum.de

Hallo Community,
da ich noch 32 Bit auf dem Raspi habe und wegen Java nicht auf dem RP4 auf Version 5 updaten konnte, habe ich mich entschlossen, OpenHab im Docker laufen zu lassen. Dazu möchte ich mein DXP4800Plus verwenden.
Auch bekomme ich in Alexa das Konto nicht mehr grün, obwohl die Items funktionieren.

Also habe ich in Docker einen neuen Container erstellt und openHAB 5.1.3 installiert. Soweit läuft alles.
Auch das Alexa Konto ist in 5.1.3 grün.
Eigentlich hatte ich vor, mal richtig aufzuräumen und alle Things und Items neu einzurichten. Hab gestern schon mal 12h investiert und bin bei 311 Items...
Allerdings ist es ein Wahnsinns Aufwand (862 Items) und da ich auch noch ioBroker und Apple Home nutze, ist es fast nicht machbar.
Auch würden mir die langen Statisktikdaten fehlen, nutze openHab seit Version 2...

Nun meine Fragen an die Profis:
Kann ich eine Backup von 4.35. in 5.1.3 einspielen? - (sind die Things, Items, Skripte kompatibel?)
Ein Backup auf dem Rp4 mit sudo openhab-cli backup --ful habe ich erstellt, aber wie spiele ich das auf dem Docker ein?

Vielen Dank im Voraus für eure Unterstützung.
Frank

Hallo Frank,

grundsätzlich kannst Du das Backup einspielen. Es wird mit Sicherheit ein paar Dinge geben, die Du anschließend anpassen musst, aber das kennst Du ja von jedem anderen Update

Die "saubere" Variante wäre, auf Docker die Version 4.3.5 einzurichten (kannst Du über das gewählte Image leicht bewerkstelligen), dann die Daten zu übernehmen und anschließend über alle Hauptversionen upzudaten, also auf die letzte 4er Version, dann auf die erste 5er Version und zum Schluss auf die aktuelle 5.1.3.
Um manuelle Korrekturen wirst Du dabei aber vermutlich auch nicht herum kommen.

Die Datenübernahme nach Docker ist einfach, Du entpackst das Backup, dort befinden sich zwei Verzeichnisse conf/ und userdata/. Den Inhalt fügst Du in die entsprechenden Docker Volumes ein.
Wichtig: achte auf die Besitzverhältnisse und korrigiere sie mittels chown Befehl (also vor dem Überschreiben der Dateien mit ls -ln den Ordner anzeigen lassen, die uuid und guid notieren (oder merken...), anschließend die Dateien verschieben und zum Abschluss mittels sudo chown -R uuid:guid /pfad/zu/den/openhab/volumes/* die Besitzrechte anpassen.

Es sollte klar sein, dass beim Einspielen des Backups der Container nicht gestartet sein darf.

Es gibt noch einen Pferdefuß: Wenn Du ein Backup mit Parameter --full erstellst, wird sehr viel mehr gesichert, als nur die Konfiguration.
Auf der einen Seite ist das gut - die interne Persistence (rrd4j und mapdb) wird mit gesichert - auf der anderen Seite funktioniert der Restore dann aber nur auf exakt der selben Version, selbst eine Abweichung an der letzten Stelle kann zu Problemen führen, ein Restore auf einer anderen Hauptversion geht definitiv schief.
Im nativen Umfeld kannst Du das recht leicht mit openhab-cli clean-cache reparieren, in docker ist das aber nicht so einfach.
Die "bessere" Option ist also, falls Du das Restore über die Versionsgrenze hinaus vornehmen willst, zwei Backups anzufertigen, eines mit, eines ohne Option --full.
Anschließend spielst Du die Version ohne --full ein. Aus dem Backup mit --full extrahierst Du anschließend nur das Verzeichnis userdata/persistence/ und verschiebst die Dateien an die entsprechende Stelle im Volume.

Wenn Du einigermaßen fit in der shell bist, ist Ganze innerhalb 5 Minuten erledigt also nicht sehr zeitraubend.

Der Pi4 sollte allerdings ohne Probleme auch mit dem 64-Bit-Image laufen, Du müsstest halt neu aufsetzen und anschließend das Backup einspielen, aber die Docker Variante ist ebenso eine vernünftige Option, gerade wenn das NAS "ehda" ist. Solange Du keine Pi Hardware Schnittstellen nutzt, solltest Du keinen großen Unterschied bemerken.

Schau wegen der breaking Changes unbedingt in die Dokumentation auf github, über alle Zwischenversionen.
Der vermutlich größte Stolperstein dürfte die Änderung in der Persistence sein. dort gab es eine default Strategy, diese ist seit 5.1 nicht mehr vorhanden und openHAB verweigert dann den Start der Persistence.
Deshalb musst Du die entsprechende Konfiguration aus den *.persist Dateien entfernen.
Falls Du die Konfiguration schon über die UI machst, könnte openHAB den Parameter eventuell selbst löschen, das habe ich aber nie ausprobiert

Hallo Udo,
vielen Dank für die schnelle Antwort.
Habe also die neue Installation platt gemacht und die 4.3.5 installiert.

Danach die Dateien aus den beiden Ordnern reinkopiert.
Soweit läuft auch alles. Bin dann auf Version 4.3.10 und hab mal bisschen rumgeschaut.
Alexa Konto ist auch wieder grün.
Im ioBroker habe ich die IP Adresse auf das NAS geändert und er konnte sich verbinden.

Nun merkte ich, das ich vom ioBrroker nicht in OpenHab schreiben kann. Liegt wahrscheinlich an den Rechten.
Die Basic Authentication Erlauben in der API-Sicherheit habe ich gesetzt.

Dachte ich, bis ich probehalber eine neue Instanz im ioBroker eingerichtet habe, Damit haben sie sich wieder unterhalten.
Da die neue Instanz eine andere Nummer hat, müsste ich alle Skripte im ioB anpassen.
Also die Instanz mit der richtigen Nummer gelöscht und nochmal mit der richtigen Nummer angelegt.
Aber wieder das selbe Problem.

Bin jetzt am Skripte anpassen und werde erst mal 4.3.10 testen, bevor ich auf die 5er Version update.

Noch mal vielen Dank.

Gruß Frank

PS,ich wollte vorhin schon schreiben, da hat der Spamschutz geblockt... Keine Ahnung wieso.

Diese Mitteilung wird untersagt. Daten wurden zu oft übermittelt. Bitte warte ein paar Minuten. Enthält die Kontaktinformationen. Die Antispam von CleanTalk.

Hallo Udo,
openhab ist jetzt soweit umgezogen, alles ist angepasst und läuft.
Allerdings bleibt die Weboberfläche immer wieder stehen, die Seite lädt zwar, aber die items haben keine Daten.
Wenn man ein paar Minuten wartet, kommen sie automatisch wieder. Per Alexa bleibt das System aber bedienbar.
Passiert aber häufig und ich steh komplett auf dem Schlauch.
Habe iobrocker deaktiviert, an diesen Zugriffen liegt es nicht.

Ich hänge mal das Log von heute an - ich hoffe es kann mir jemand die Ursache aufzeigen. Was bei mir nicht funktioniert hat, war die Anpassung der Rechte:
da kam invalid user

Dazu benötige ich wohl eine Schritt für Schritt Anleitung, falls das Problem damit zu tun hat..

Oder hat es was mit "Caused by: java.io.IOException: Broken pipe" zu tun

Keine Ahnung was hier passiert - Please help...

Vielen Dank im Voraus und schönes Wochenende,
Gruß Frank

Nachtrag - jetzt ist openHab plötzlich garnicht mehr erreichbar und im Log steht:

2026-03-27 23:09:17.209 [INFO ] [io.openhabcloud.internal.CloudClient] - Shutting down openHAB Cloud service connection
2026-03-27 23:09:17.215 [INFO ] [etvisu.internal.servlet.CometVisuApp] - Stopped CometVisu UI
2026-03-27 23:09:17.238 [WARN ] [io.openhabcloud.internal.CloudClient] - Socket.IO disconnected: io client disconnect
2026-03-27 23:09:17.238 [INFO ] [io.openhabcloud.internal.CloudClient] - Disconnected from the openHAB Cloud service (UUID = 5f...2a, base URL = http://localhost:8080)
2026-03-27 23:09:17.280 [INFO ] [basic.internal.servlet.WebAppServlet] - Stopped Basic UI

????

PS. habe eben /userdata/cache und tmp geleert - scheint zu helfen. Melde mich wieder.

Gruß Frank

ledies hat geschrieben: Gestern 22:55 Was bei mir nicht funktioniert hat, war die Anpassung der Rechte

Ja, Du hast Die Anweisung nur unvollständig ausgeführt...

[...] vor dem Überschreiben der Dateien mit ls -ln den Ordner anzeigen lassen, die uuid und guid notieren (oder merken...), anschließend die Dateien verschieben und zum Abschluss mittels sudo chown -R uuid:guid /pfad/zu/den/openhab/volumes/* die Besitzrechte anpassen.

uuid:guid musst du durch die notierten Zahlenwerte ersetzen, z.B.: Ich bin mir nicht sicher, kann sein, dass die Information in der Container Konfiguration als Environment Variable steht, ansonsten musst Du dich mit der Shell des Containers verbinden und nachschauen, welche uuid und guid der User openhab hat. Obacht! Es kann ein Mapping zwischen uuid/guid im Hostsystem und innerhalb des Containers geben. Außerhalb des Containers ist der User openhab unbekannt und es gibt auch nirgendwo eine Information über die uuid bzw. guid des Users. Es kann sein, dass die uuid/guid im Hostsystem durch einen anderen User belegt sind. Deshalb sollte man sie vor dem Einfügevorgang ermitteln...
Du kannst aber leicht einen zweiten openHAB Container erstellen (mit identischer Konfiguration bis auf die Volumes und das verwendete Netzwerk) und nachdem dieser Container gestartet ist kannst Du dort die uuid/guid für das Hostsystem herausfinden.

Hallo Udo,
vielen Dank für die Erklärung.

Mir kam wegen der schlechten Performance und der verzögerten Anzeige der Daten und des Webinterfaces eine Idee.
Die HDs der Ugreen sind ja deutlich langsamer als eine SSD und so habe ich eine M2 SSD eingebaut, als neues Volume eingerichtet und die Docker Container darauf installiert. Somit läuft jetzt alles super flüssig und die Daten sind sofort da. Große Freude ))

Nun habe ich laut Deiner Empfehlung auf dem ersten Volume (HDD) noch eine Test openHab Installation mit anderen Ports durchgeführt, die Grundkonfiguration ausgeführt und Openhab-Cloud installiert. Danach habe ich den Inhalt der UUID aus der Testinstanz bei ausgeschaltetem Container in die Instanz auf der M2 per Nano reingeschrieben. - Ich hoffe, ich hab das so richtig verstanden.

habe jetzt über SSH ohne Fehlermeldung ausgeführt:
In der Compose-Konfiguration steht das in environment:
CRYPTO_POLICY: "unlimited"
OPENHAB_HTTP_PORT: "8080"
OPENHAB_HTTPS_PORT: "8443"
TZ: "Europe/Berlin"

Allerdings kommt trotz tadelloser Funktion jede Minute dieser Eintrag ins log:
[WARN ] [io.openhabcloud.internal.CloudClient] - Error connecting to the openHAB Cloud instance: not authorized. Reconnecting after 60000 ms.

Noch ne Idee oder hab ich was falsch gemacht? Gruß Frank

PS: eine GUID finde ich in keinem der Ordner?

In userdata gibt es einen Ordner secrets mit einer Datei rsa_json_web_key.json
soll ich diese in die M2 Instanz kopieren?