gespiegelte SD startet nicht

[iTob]

Hallo,

ich habe nun doch parallel eine Kopie von meinem openhab 2 im docker gebaut. Mit influxDB, Grafana, Zugiff auf debmatic und auf MQTT.
Noch überlege ich, ob ich mir das Ganze noch mit docker compose ansehe...

Im Docker muss ich doch "nur" die Daten in ein Image von openhab 3, 4 oder 5 einhängen und dann in den logs nachsenen, was alles Probleme macht, oder? Sollte ich diese Updates wirklich schrittweise einzeln durch die Versionen gehen oder kann ich auch direkt den Sprung von der 2 auf die 5 probieren?

VG, Tobias

[udo1toni]

Wenn Du sämtliche Konfiguration bisher komplett über Textdateien erledigt hast, kannst Du tatsächlich leicht mehrere Versionen überspringen, weil Du eh alles von Hand korrigieren musst. Falls Du aber viele Geräte automatisch eingebunden hast (also über PaperUI AutoDiscovery), dann wäre der Weg durch die Versionen durchaus sinnvoller, weil ein Großteil der Konfiguration automatisch angepasst wird, wenn Du von der jeweilig vorhergehenden Hauptversion kommst. Die Upgradetools beherrschen aber keinesfalls Dinge, die schon vor zwei Versionen geändert waren.

Rules wirst Du ohnehin manuell überarbeiten müssen, weil sich dort über die Zeit einfach unheimlich viele Dinge geändert haben, insbesondere gibt es statt joda time nun JavaTime, welches an vielen Stellen gleich ist, aber an anderen Stellen fundamental anders funktioniert, z.B. now.plusSeconds(x) gibt es in beiden Welten, now.plusMillis(x) hingegen nicht, dafür aber now.plusNanos(x). Oder Man nutzt now.plus(x,java.time.temporal.ChronoUnit.MILLIS) - leider liegt ChronoUnit nicht standardmäßig als Import vor.
Also alle Rules, in denen Du now() oder einen engen Verwandten verwendest bedürfen genauer Betrachtung
Falls Du Rules geschrieben hast, in denen Du mehrere Items als Trigger verwendest und dann die implizite Variable triggeringItem als Objekt genutzt hast, wirst Du die Rule anpassen müssen, denn triggeringItem gibt es nur noch bei Rules, die mit Member of getriggert wurden. Stattdessen musst Du nun triggeringItemName verwenden, welches im Gegensatz zu triggeringItem lediglich ein String ist.

Natürlich gibt es enorm viele Verbesserungen, es lohnt also durchaus, weiterhin funktionierende Konfigurationen zu überarbeiten, z.B. die Units of Measurement können ziemlich hilfreich sein (obwohl sie auch zusätzliche Arbeit verursachen).

[iTob]

Hallo,
ich habe Homematic über die GUI in Verbindung zu debmatic konfiguriert. Der Rest ist MQTT per Scripte.
Aber da sollte ich vieleicht doch der Reihe nach 2,3,4,5 starten.
VG

[udo1toni]

Vermutlich, gerade wenn Du schreibst

per Scripte

Eventuell braucht es inzwischen (zumindest für einen Teil der Geräte) gar keine Scripte mehr.

[iTob]

Nun habe ich das Update im docker von 2 auf 3 durchgeführt.
Leider gibt es hier aktuell kein Basic UI mehr und ich kann es über die Bindings auch nicht installieren.
Gleich nach dem Start erhalte ich:

Code: Alles auswählen

[ERROR] [core.karaf.internal.FeatureInstaller] - Failed installing 'openhab-binding-http1, openhab-binding-exec, openhab-ui-homebuilder,
 openhab-binding-mail, openhab-transformation-javascript, openhab-binding-network, openhab-persistence-influxdb, openhab-transformation-regex, 
 openhab-ui-habpanel, openhab-binding-mqtt, openhab-transformation-map, openhab-ui-basic, openhab-binding-ntp, openhab-binding-homematic, 
 openhab-ui-paper': Unable to resolve root: missing requirement [root] osgi.identity; osgi.identity=openhab-ui-paper; type=karaf.feature; 
 version="[2.5.12,2.5.12]"; filter:="(&(osgi.identity=openhab-ui-paper)(type=karaf.feature)(version>=2.5.12)(version<=2.5.12))" [caused by: Unable to 
 resolve openhab-ui-paper/2.5.12: missing requirement [openhab-ui-paper/2.5.12] osgi.identity; osgi.identity=openhab-ui-dashboard; 
 type=karaf.feature]

In den addonns liegt openhab-addons-2.3.0.kar, 2.5.12 und 3.4.4.

Kann es sein, dass er sie wo ganz anders sucht?

[udo1toni]

Du nutzt die Text Konfiguration und hast diverse Bindings manuell installiert. Jedoch haben sich diverse Bindings geändert (z.B. gibt es kein http1 Binding mehr).
Kurz: Du musst alle Bindings, welche unter OH1 lauffähig gewesen wären, durch die "OH2-Variante" ersetzen.
Mit "OH2-Variante" meine ich hier die, welche mit Things und Channels arbeitet, statt das Binding direkt über die Itemkonfiguration anzusprechen.

In Wirklichkeit muss es natürlich das OH3-Binding sein, weil der Namespace von OH2 auf OH3 geändert wurde, die Bindings mussten also neu compiliert werden (statt org.eclipse.smarthome... ist es nun wieder org.openhab...), aber gewöhnlich installiert man Bindings ja ohnehin direkt aus der UI heraus.

Paper UI gibt es nicht mehr, die heißt nun MainUI. Die BasicUI gibt es nach wie vor, allerdings ist sie auch gewandert, sie wird nun mit "ui = basic" in der addons.cfg eingetragen (oder Du löschst die addons.cfg komplett und installierst die benötigten Addons samt Basic UI über die Main UI Administrationsoberfläche)

[iTob]

Ich glaube, ich nutze keine manuell installierten Bindings. In welcher Datei sind die denn überhaupt konfiguriert?
Unter services die Datei addons.cfg enthält keine Definition.

Die MQTT-Abfragen laufen bereits über Things und Channels. Aber nach dem Update gibt es kein MQTT Binding und ich kann es aktuell nicht installieren.
Einige Regeln nutzen noch sendHttpGetRequest für BSBLAN. Aber ich glaube, das würde auch über MQTT laufen.

Ich habe vom docker openhab2 die Ordner addons, conf und userdata wieder so im openhab3 eingebunden und dort wurde das Update durchgeführt.

Docker läuft auf einem debian bookworm in einer VM.

[udo1toni]

Reflexartig würde ich dazu raten, den Cache zu leeren. Das ist allerdings wegen Docker eventuell nicht trivial, aber Du könntest (bei gestopptem Container) im userdata-Volume alles unterhalb ./tmp/ und alles unterhalb ./cache/ löschen. Die Ordner selbst müssen bestehen bleiben!

Im gleichen (userdata) Ordner gibt es einen Ordner config/org/openhab/, dort sind die "echten" Konfigurationsdateien gespeichert (openHAB liest bei Änderungen in /etc/openhab/* den entsprechenden Inhalt ein und schreibt ihn automatisch in dieses Verzeichnis - der Unterschied besteht darin, dass der Inhalt dieser Dateien auch über die UI angepasst werden kann. Das Format ist ein anderes wäre sonst ja langweilig.

Du kann st also in diesem Zweig die jeweils passenden Dateien raussuchen z.B.
statt /conf/services/addons.cfg die Datei /userdata/config/org/openhab/addons.config und dort unterhalb der jeweiligen Schlüsselworte die jeweils ungültigen addons entfernen.
Neben den Bindings gibt es noch persistence, transformation, automation und ui, in jedem dieser Bereiche kann ein ungültiger Eintrag enthalten sein.

Mutmaßlich wird sich openHAB an einem oder mehreren ungültigen Einträgen stören und deshalb nicht korrekt starten - notfalls kannst Du alle genannten Listen leeren, dann müsste openHAB ohne installierte Addons starten.
Anschließend müsste es möglich sein, die Addons einfach über die Main UI neu hinzuzufügen.

Sollte das Hinzufügen nicht funktionieren, dann kann es sein, dass im addons-Verzeichnis eine falsche openhab-addons-x.y.z.kar liegt (z.B. weil irgendwas mit den Rechten durcheinander gekommen ist). In dem addons-Verzeichnis darf nur die zur installierten openHAB-Version passende Archivdatei liegen, ebenso dürfen dort nur zur installierten Version passende "manuell installierte" Addons liegen.
Im Zweifel könntest Du das addons-Volume ebenfalls leeren (natürlich indem Du vorhandene Dateien in ein anderes Verzeichnis verschiebst - nicht! innerhalb des Volumes) und den Container anschließend starten - openHAB sollte dann automatisch das richtige Archiv nachladen, spätestens wenn Du versuchst, ein Addon über die MainUI zu installieren. Wegen der manuell installierten Addons musst Du natürlich die passenden jar-Dateien selbst raus suchen, aber vielleicht gibt es die entsprechenden Bindings inzwischen schon über den Marketplace oder gar als offizielles Binding.

[iTob]

Vielen Dank.
Cache und temp hatte ich bereits vor dem Update gelöscht.
Die Einträge im /userdata/config/org/openhab/addons.config waren daran Schuld.
Ich habe die Bindings auskommentiert und ui="basic" gesetzt.

Ausserdem standen im /userdata/config/org/Apache/felix/fileinstall zwei Konfigs. Eine mit dem Pfad openhab2. Die Datei habe ich einfach umbenannt.

Nun hat openhab3 Probleme, die MQTT-Werte mit führendem Leerzeichen als NumberValue anzunehmen.

Code: Alles auswählen

[WARN ] [ab.binding.mqtt.generic.ChannelState] - Incoming payload ' 50.00' not supported by type 'NumberValue'

Beispiel-Konfig dazu:

Code: Alles auswählen

Type number:vlg "FBH Küche Vorlauf gesamt" [stateTopic="FBHK/VLG"]

Unter openhab2 funktionierte das noch. Leider habe ich dazu im Internet noch nix gefunden.
Kann ich denn die BasicUI auch als Standard festlegen? Der Pfad über pc:8080/basicui/app funktioniert.

[udo1toni]

MQTT String -> Number: eigentlich sollten Zahlen nicht als Strings übertragen werden, das ist also ein Problem des sendenden Geräts. Du kannst es aber mit einer Transformation lösen, auch wenn das natürlich nicht schön ist (aus programmlicher Sicht ist es so aber korrekt, ein String ist halt keine Zahl).

Was meinst Du mit "BasicUI als Standard"?
Die BasicUI kannst Du jederzeit gezielt direkt öffnen, Du musst lediglich die vollständige URL angeben. Die MainUI bietet viele Dinge, die in der BasicUI gar nicht zur Verfügung stehen, BasicUI ist ausschließlich für Anwender gedacht, MainUI dient auch der Administration, kann allerdings auch für Anwender konfiguriert werden - mit erheblich mehr Möglichkeiten als in der BasicUI.

Ich hoffe doch sehr, dass openHAB3 nur eine kurze Zwischenstation hin zu openHAB5 darstellt...