Automatisierung durch textbasierte Konfiguration

Da fragt sich sicherlich der ein oder andere, warum. Nun ich möchte testen können. Das kann ich am einfachsten, indem ich meine Konfiguration oder vor allem Teile (z.B. nur ein bestimmtes Binding) der Konfiguration in meiner Testumgebung bearbeiten kann. Wenn die Änderung dort läuft, wird es in die produktive Umgebung übertragen.
Ich bin überzeugt, das ein Elektriker oder jemand der am "Fließband" solche Installationen umsetzen soll, sehr effektiv mit dieser Methode seine Arbeit effektiver erledigen kann.

Dieses Script mit dem ich die Konfiguration verteile bzw. dieser Ansatz soll eine einfache und automatisierte Installation für openHAB ermöglichen. Das dann ohne immer wieder das Betriebssystem auf einer PI neu installieren zu müssen. Idee dahinter war ursprünglich eine schnelle und effektive Installation einer Testumgebung. Um eine Testumgebung bereit zu stellen, müssen natürlich die Daten der „produktiven“ Installation übernommen werden (backup).  

Vorbereitung der Umgebung

Damit ein Einlesen und späte die automatische Installation möglich ist, müssen einige Regeln beachtet werden.

a) Jedes .item und jedes .things file hat den Namen z.b. des Binding (der Name ist aber beliebig).

b) Je Binding gibt es einen Unterordner mit den Namen „binding-<name>“

c) In den Ordner der jeweiligen Bindings gibt es eine install.bash und eine backup.bash Datei. Dort müssen die Namen der zugehörigen Dateien angegeben werden. Um Ordnung zu schaffen, sollten alle Dateien mit den Namen des Bindings Anfangen. Das bringt dann auch eine gewisse Übersicht über die ggf. vielen Bindings die man nutzt. 

d) Aus dem Verzeichnis /var/lib/openhab/config/org/openhab/addons.config sollte die Datei addons.cfg gesichert bzw. in das Verzeichnis "config" abgelegt werden. Die Datei sieht z.B. so aus:

binding=astro,squeezebox,tr064,avmfritz,modbus,lcn,comfoair,mail,mqtt,network
misc=package=standard
persistence=jdbc-mariadb,rrd4j
service.pid=org.openhab.addons
transformation=xslt,xpath,scale,regex,map,jsonpath,exec,javascript
ui=basic,habpanel,habmin

In meinem Fall nutze ich für die Langzeitspeicherung die Maria DB als persistence. rrd4 ist nur für Daten die ich nicht "ewig" speichern möchte.

e) Analog zur addons.cfg, kann auch die runtime.cfg als Default verteilt werden. Dazu diese auch in das config Verzeichnis ablegen.

f) Auch die Einstellungen für Pages etc. in openhab 3 können "übertragen" werden. Das ist jedoch explizite nicht von openhab supported! Ich habe es getestet und bislang geht es. Dazu nehmen ich aus dem Ordner /var/lib/openhab/jsondb die Datei uicomponents_ui_page.json mit und packen diese in den Ordner config.

e) Auch die Einstellungen für "habmin" in openhab 3 können "übertragen" werden. Auch das ist nicht von openhab supported! Ich habe es getestet und bislang geht es. Dazu nehmen wir aus dem Ordner /var/lib/openhab/jsondb die Datei uicomponents_habpanel_panelconfig.json mit und packen diese in den Ordner config.

g) In der Installation wird als persistenz mit MariaDB bzw RRD4 gearbeitet. Dazu wird ein Datenbank mit dem Namen "openhab3" verwendet. Diese kann mit inst-db installiert werden. 

1-setup.bash

Diese Datei ist das primäre Script, welches gestartet wird. Ohne Angabe von Parametern, wird nur die Hilfe ausgegeben.

Am besten setzt man über die /etc/profile die beiden folgenden Variablen:

export OPENHAB_SETUP_CONF=/etc/openhab
export OPENHAB_SETUP_SOURCE=/data/install/openhab

Das Verzeichnis "OPENHAB_SETUP_SOURCE" ist das Verzeichnis, wo das Script selbst und die andern Daten "binding-..." usw. liegen

Hier mal ein Stand (März 2023) http://www.berhorst.net/files/openhab-text-install.tgz den Ihr als Grundlage nutzen könnt. Natürlich ist alles ohne Gewähr. Am bessten fangt Ihr mit dem "astro" Binding an und schaut mal wie das so tickt.

openHAB über die Jahre im Einsatz

Mit openHAB bin ich für mein Smarthome erst später gestartet. Über den LCN-BUS habe ich in 2014 eine "Visualisierung" (Grundriss vom Haus mit Schaltern etc.) und somit die Steuerung über den Browser ermöglicht. Grund für openHAB war, neben dem LCN-Bus auch andere Komponenten aus dem Haus integrieren zu wollen. Mittlerweile (Okt 2023) habe ich alle (!) möglichen Komponenten über die Zeit integriert.

Gestartet bin ich mit openHAB 1.8.x im Jahr 2016. Viele der Einstellungen und Konfigurationen habe ich mir aus Beispielen im Internet zusammengesucht. Zu der Zeit wurden alle Objekte (items, sitemap und co.) per Texteditor eingestellt. Teilweise hatte ich beim Übernehmen Namen für items vergeben, die ich selbst später nicht auf anhieb verstand. Heute sind diese Namen sprechend sodas ich auch nach 2 Jahren verstehe, wie dieser genutzt werden bzw. wofür sie genutzt werden. Man lernt mit der Zeit.

Von der Version 1.8.x bin ich dann nach 2.5.1 gewechselt. Das wahr ohne großen Aufwand möglich und hat fast ohne Anpassung der items für die verschiedenen Bindings geklappt.

openHAB 3.x (Februar 2021)

Mit dem Erscheinen von openHAB 3.0 habe ich mich dazu entschlossen, mit der Umstellung zu beschäftigen. Das war im Frühjahr 2021. Schnell habe ich gesehen, daß meine alten „Textdateien“, welche ich für die Konfiguration nutze, nicht immer 1:1 übernommen werden konnten. Daher war klar, ich kann nicht einfach ein Upgrade machen, sondern muss eine Migration durchführen. D.h. das ich bei allen aktiven Bindings die jeweilige Konfiguration Schritt für Schritt übernehmen und dabei überprüfen musste. Es lag viel Arbeit vor mir 😉
Dann im Februar 2022 wagte ich den Wechsel. Es gab für mich folgende Stolpersteine:

Die MYSQL DB

Die Übernahme der Sensordaten war mir sehr wichtig. Vor allem die Temperatur wollte ich mitnehmen. Ich habe mich am Ende des Tages für ein "manuelles" Kopieren der Daten via SQL Quere entscheiden. Das habe ich dann per Cut & Past für gut 60 Werte gemacht. Der Rest war nicht relevant.

Den Umgang mit things

Von OH 1.8 auf OH 2.5 hatte ich mich nicht mit den neuen Methoden von openHAB beschäftigt. Das hat mich eingeholt und ich mußte erst einmal lernen, wie das alles funktioniert. Das war vor allem beim LCN-Binding eine große Aufgabe. Irgendwann hat es dann klick gemacht.

Vorgehensweise

Eine Installation zum Testen, habe ich zunächst auf einer PI und später dann unter Docker aufgebaut. Bis auf das ComforAir Binding, welches über RS232/USB läuft, konnte ich alle anderen Bindings parallel testen. Nur bei den Rules macht das keinen Sinn diese parallel laufen zu lassen. Es sei denn, diese werden zum Aggregierten von Daten benutzt. 
Die Berechnung von Durchschnittswerten von Temperaturen mußte ich anpassen. Diese Werte benutze ich beim Sonnenschutz. Das war etwas aufwendig, da ich mich mit dem Umsetzen der Werte beschäftigen musste.

Automatische Installation

Die Testumgebung ist einfach nötig, weil man neue "Funktionen" nicht immer in der aktiven und laufenden Installation ausprobieren möchte oder kann. Daher gilt es eine Testumgebung zu nutzen. Darin habe ich immer wieder "meine" Einstellungen getestet. Ich habe mir daher eine Lösung mittels Scripts gebaut, die mir eine teilweise "Automatische Installation" ermöglicht. Hier der Link zur Doku.

openHAB 4.x (September 2023)

Mit dem Erscheinen der Version 4 habe ich wahrgenommen, daß ich die „Pages“ besser gestalten kann indem ich Sensordaten wie Temperatur einbinde. Durch die Erfahrungen beim Umstieg von 2.5 auf 3.x hab ich mir wieder Zeit gelassen. Gleichzeitig habe ich auf eine "Docker" Installation gewechselt. D.h. vorher war alles (openHAB, MariaDB, Grafana, phpAdmin, etc) direkt installiert. Mit dem Umzug auf Docker möchte ich einfacher von einem Server auf einen anderen Server wechseln und somit unabhängig von der Hardware und den Softwarekomponenten im Betriebssystem sein. 

Please publish modules in offcanvas position.