Eben habe ich erst über KI in der openHAB-Entwicklung geschrieben, nun geht es an ein Thema, das ich nie gern gemacht habe: Updates von openHAB. Das war für mich immer ein grobes Lesen der Releasenotes, schauen, was andere für Probleme in den Foren berichtet hatten und zuletzt ein „Updaten und schauen, was geht, dann reparieren“…
Bei openHAB steht bei mir der Schritt auf 5.1.x noch aus – und das erledigt nun auch openAI codex für mich…
Das Setup und die KI-Integration ist bereits im anderen Blogartikel beschrieben:
Als Prompt für eine Prüfung möglicher Risiken bekommt codex folgende Anweisung:
Ich möchte auf openhab 5.1.2 upgraden. prüfe alle Update-Hinweise der Versionen nach der aktuell laufenden und prüfe die lokale Installation auf mögliche Probleme bei einem möglichen update, die dann Anpassungsbedarf erfordern oder die dann das update in ein Problem laufen lassen können.
Nun werkelt er recht intensiv, holt sich die nötigen Infos zusammen und bewertet anhand der lokalen Installation:
Ich prüfe zuerst sauber den Ist-Zustand deiner lokalen openHAB-Instanz (Version, installierte Add-ons, Rules/UI-Nutzung) und gleiche das dann mit den offiziellen Migrationshinweisen bis 5.1.2 ab. Danach bekommst du eine konkrete Risiko-/To-do-Liste vor dem Upgrade.
Ist-Stand ist klar: deine laufende Instanz meldet openHAB 4.2.3. Ich ermittle jetzt die tatsächlich genutzten Bindings/Features aus things, rules und UI-Widgets, damit wir gegen die 5.x-Breaking-Changes präzise prüfen können.
Ich habe die genutzten Bindings und Rule-Muster aufgenommen. Als Nächstes ziehe ich die offiziellen Migrations-/Breaking-Change-Hinweise von 4.3 → 4.4 → 5.0 → 5.1.2 und gleiche sie gezielt mit deinem Setup (Bindings + Rule-Syntax) ab.
Ich prüfe jetzt noch die offiziellen Detail-Release-Notes für 4.3.0, 5.0.0, 5.1.0, 5.1.1, 5.1.2 direkt auf GitHub-Tags, damit wir keine relevanten manuellen Migrationspunkte übersehen.
Ich prüfe jetzt konkret deine *.persist-Dateien und weitere lokale Konfiguration auf die zwei wichtigsten Migrationsfallen (5.0 Alias-Änderung, 5.1 Entfernen der default-Strategien). Das ist bei deinem Setup der wahrscheinlichste echte Stolperstein.
Ich prüfe jetzt die offiziellen Release-/Migrationshinweise (4.3 -> 5.0 -> 5.1.2) und parallel deine lokale OH-Installation auf konkrete Upgrade-Risiken. Danach bekommst du eine priorisierte Liste mit echten Blockern und nötigen Anpassungen vor dem Update.
Ich ziehe jetzt zusätzlich die offiziellen GitHub-Release-Texte per API, damit ich 5.0.1, 5.1.0, 5.1.1 und 5.1.2 vollständig und sauber gegeneinander prüfen kann. Danach gleiche ich das direkt mit deiner lokalen Konfiguration ab.
Als Nächstes prüfe ich lokal gezielt conf/persistence, conf/services, Rule-Dateien und relevante Logs auf bekannte 5.x-Fallen (insb. Java21, Persistenz-Defaults, Binding-Umbenennungen, Startlevel/Features).
Ich habe die laufende Konfiguration bestätigt: aktuell 4.2.3 und keine der umbenannten Alias-Bindings (applehomekit/cometvisu/deconz) ist in deinen Things aktiv. Jetzt prüfe ich gezielt, welche Add-ons/Rules durch 5.x betroffen sein könnten.
Ich habe den wichtigsten Blocker bereits klar identifiziert: deine file-basierten *.persist-Dateien verwenden noch default-Strategien, und genau das ist ab 5.1 nicht mehr zulässig wie bisher. Ich prüfe jetzt noch, ob du MQTT-HomeAssistant-Things hast (wegen Split in 5.1), dann bekommst du die finale Risiko-/Maßnahmenliste.
Ich bin mit der Analyse fast durch: es gibt keine offensichtlichen Binding-Alias-Blocker, aber einige bestehende Rule-/Log-Fehler und mindestens einen echten 5.1-Migrationspunkt in deiner Persistenz. Ich prüfe noch kurz, ob deine Instanz als Docker/Container vorbereitet ist, dann bekommst du die komplette Upgrade-Risikoübersicht.
…und lieferte dann folgende Zusammenfassung:
Analyse abgeschlossen: ein Upgrade von 4.2.3 auf 5.1.2 ist grundsätzlich machbar, aber es gibt einen echten Vorab-Anpassungspunkt.
Ergebnis
Aktueller Stand lokal: openHAB 4.2.3 (version.properties).
Zielversion 5.1.2 ist veröffentlicht am 09.02.2026.
Ich habe die Hinweise ab deiner Version geprüft: 4.3.0 bis 4.3.9, 5.0.0 bis 5.0.3, 5.1.0 bis 5.1.2.
Konkreter Anpassungsbedarf vor Update
5.1-Migration (wichtig): Default-Strategien in file-basierten Persistenzdateien.
Treffer bei dir:
influxdb.persist (line 3)
mapdb.persist (line 2)
rrd4j.persist (line 3)
Das ist der relevanteste Punkt, der nach Update sonst zu unerwartetem Persistenzverhalten führen kann.
Geprüft auf typische 5.x-Blocker
Binding-Alias-Umbenennungen (5.0, z. B. applehomekit -> homekit, cometvisu -> visu, deconz -> deconzng): bei dir kein Treffer in Things.
MQTT-Split (5.1: Home Assistant/Homie getrennt): bei dir MQTT-Thingtypen nur mqtt:broker und mqtt:topic, also voraussichtlich nicht betroffen.
Shelly-5.0 Umbenennung (shellypro2-relay): bei dir nicht verwendet.
Startlevel-Thema (Karaf 4.4.8 in 5.1): keine Hinweise auf manuell erzwungene Startlevel in deinen lokalen Karaf-Dateien.
Zusätzliche lokale Risiken (nicht zwingend Upgrade-Blocker, aber vorab sinnvoll)
Bestehende Rule-Fehler im Log:
openhab.log (line 105) (Could not cast NULL to java.lang.Number, Strom-Regel)
openhab.log (line 111) (publishMQTT is not a member, VirtuellerShelly)
Häufige Warnungen zu nicht existierenden Items:
openhab.log (line 72) (venus_battery_power, undefined)
Ältere DateTime-Zugriffe in Rules:
PIR_Lichtschaltung_Flur_OG.rules (line 30) (now.getHourOfDay/getMinuteOfHour)
Kurzfazit
Go/No-Go: Go, aber vorher Persistenzdateien bereinigen.
Danach Upgrade technisch realistisch mit überschaubarem Risiko.
Wenn du willst, mache ich als nächsten Schritt eine konkrete Pre-Upgrade-Checkliste + exakte Dateiänderungen (nur vorbereitend, noch ohne Upgrade-Ausführung).
Quellen:
https://github.com/openhab/openhab-distro/releases/tag/4.3.0
https://github.com/openhab/openhab-distro/releases/tag/5.0.0
https://github.com/openhab/openhab-distro/releases/tag/5.1.0
https://github.com/openhab/openhab-distro/releases/tag/5.1.2
https://next.openhab.org/docs/configuration/migration.html
OK, vermutlich muss ich bei meinen Items und Things irgendwann mal aufräumen, aber im Gern scheint ein Thema bei der Persistenz den Updates im Weg zu stehen. Diese lasse ich vorab bereits bereinigen. Die monierte alte Datetime-Nutzung wurde aber falsch erkannt, denn dabei handelt es sich tatsächlich um auskommentierten Code, der in der Rule gar nicht mehr aktiv zum Einsatz kommt. Das hätte codex eigentlich erkennen können.
Weiter gehts:
Sofern die nachfolgenden Änderungen kein Probleme mit der 4er Version haben künftig auch von der neuesten version untestützte Methoden und bereinige die Persistenz-Konfigurationen
Die Datetimenutzung muss nicht korrigiert werden, denn dabei handelt es sich um einen auskommentierten Teil der Rule, also lass die Rule unangetastet
und er arbeitet…
Ich ändere jetzt drei Persistenzdateien (nur default-Strategien entfernen, 4.x-kompatibel) und passe zusätzlich die MQTT-Action in VirtuellerShelly.rules auf eine klar typisierte, 5.x-feste Nutzung an. Die PIR-Rule bleibt unberührt.
(...)
Als letzten Schritt setze ich die MQTT-Action in der Rule auf einen explizit typisierten Aufruf mit Null-Check, damit sie stabil auf 4.x und 5.x läuft.
(...)
Umgesetzt, ohne die PIR-Datei anzufassen.
Geändert:
Persistenzbereinigung (default-Strategien entfernt, 4.x/5.x-kompatibel):
influxdb.persist (line 1)
mapdb.persist (line 1)
rrd4j.persist (line 1)
MQTT-Action auf klar typisierte, aktuelle Nutzung umgestellt (inkl. Null-Check):
VirtuellerShelly.rules (line 1)
VirtuellerShelly.rules (line 70)
Wichtig:
PIR_Lichtschaltung_Flur_OG.rules wurde nicht geändert, wie gewünscht.
In conf/persistence gibt es jetzt keine default = ...-Einträge mehr.
Wenn du willst, prüfe ich als Nächstes noch die restlichen Rules auf weitere 5.x-kritische Altaufrufe und mache nur sichere, 4.x-kompatible Anpassungen.
Na gut, dann lassen wir auch das schon einmal vorab Checken – aber nicht blind ändern…
Prüfe bestehende Rules und mache auf Probleme aufmerksam frage aber vor Korrektur nach und nenne dabei den Korrekturvorschlag
…und weiter gehts
Ich prüfe jetzt systematisch alle Rules auf bekannte Problemstellen (Laufzeitfehler, Null-Casts, blockierende Sleeps, doppelte Updates) und gleiche das mit den Logfehlern ab. Danach bekommst du eine priorisierte Liste mit konkretem Korrekturvorschlag je Fund, aber ohne Änderungen bis zu deinem Go.
(...)
Ich habe mehrere echte Laufzeitfehler im Log gefunden (u.a. in VirtuellerShelly, Strom_Netzbezug_und_Einspeisung, VenusAkkuPflege). Ich lese jetzt die betroffenen Rules mit Zeilennummern aus und formuliere dir je Fund einen konkreten Fixvorschlag zur Freigabe.
(...)
Nun werden tatsächlich einige Unsauberheiten meiner Rules aufgedeckt, die gar nicht wirklich mit dem Update zusammenhängen, die ich aber beheben lasse. Das erspare ich Euch hier einmal 😉
Nun lade ich das neue docker / Container-Manager-Image openhab 5.1.2 herunter und konfiguriere einen neuen Container. Die eingebundenen Pfade waren bisher U:\openhab4 und sind künftig U:\openhab5, dazu kopiere ich den aktuellen Stand hinein. Vorteil: Der alte Container bleibt damit unverändert erhalten (Container sowie eingebundene Dateien) und ein zurückgehen auf Version 4 wäre damit einfach möglich.
Anschließend wird in Visual Studio Code der neue Ordner openhab5 geöffnet und auch in der .codex/instructions.md der Pfad, der beschrieben werden darf, angepasst.
Die neue instanz wurde gestartet das projektverzeichnis hat sich geändert auf U:\openhab5\ Initialisiere neu die instructions.md in und beachte sie. Die openhab 5 Instanz ist eben hochgefahren. Prüfe das Logfile auf das erfolgte Update und korrigiere wenn nötig Fehler.
…und er prüft…
UI Fehler
venus_battery_power-Fehler im UI korrigiert (per REST, kein jsondb-Direktschreiben)
In ui:page/overview wurde die fehlerhafte Label-Referenz ersetzt:
von =items.venus_battery_power.displayState
auf =items.venus_battery_ac_power.displayState
Verifiziert: alte Expression ist nicht mehr vorhanden, neue ist aktiv.
Historie: overview_page_008_before.json, overview_page_009_after.json, overview_page_010_verify.json.
Influx-Startup-Last entschärft
restoreOnStartup aus Influx-Strategie entfernt in influxdb.persist (line 6) und Altwert kommentiert dokumentiert in influxdb.persist (line 7).
Aktive Zeile jetzt: influxdb.persist (line 8).
Backup vor Änderung: influxdb.persist.20260214_143738.bak.
Nebenfix
Beim ersten Speichern war kurz ein BOM drin; wurde direkt entfernt.
influxdb.persist wird wieder geladen (Parserfehler behoben).
Protokoll
Änderungen in changes.txt ergänzt.
…und das wars dann auch.
Fazit: Ich habe mich mit diesem „Assistenten“ schon sehr unterstützt gefühlt und hatte ein ziemlich reibungsloses Update damit…