OpenHAB – für Anfänger

OpenHAB ist eine offene Smarthome-Zentrale, welche bereits eine Vielzahl von Plugins bereitstellt um noch mehr Geräte unterschiedlicher Art und Hersteller in dein Smarthome einzubinden. Im Folgenden will ich dir kurz den logischen Aufbau erläutern.

Bindings

Die Grundlage jeder Hardware-Anbindung ist einerseits natürlich, dass du rein physisch mit der Hardware kommunizieren kannst (WLAN-Geräte brauchen einen WLAN-Router, Zigbee-Geräte ein Zigbee-Gateway usw.) zur anderen Seite muss deine Smarthome-Zentrale auch wissen, wie sie das Gerät ansprechen kann. Das geschieht über die Bindings in OpenHAB. Das Binding weiss, wie ein bestimmtes Gerät oder Protokoll anzusprechen ist und macht für OpenHAB daraus sogenannte „Things“, also Dinge.

Die Binding selbst werden in den allermeisten Fällen nicht weiter konfiguriert. Das geschieht erst im nächsten Schritt

Things (Bridges)

Es gibt zwei Arten von Things in OpenHAB: Die eigentlichen Things und die Bridges. Bridges sind übergeordnete Konfigurationen, die mehrere Things gemeinsam haben. Ein MQTT-Server wird erst als Bridge definiert und die verschiedenen Kanäle dann als zugehörige Things. Viele Bindings verzichten auf Bridges.

Things und Bridges können auf zwei Arten erstellt werden: über die GUI und als Textfile. Beide Arten sind miteinander nicht kompatibel und ich rate dir, dich einheitlich für eine Weise zu entscheiden.

Mit der GUI kannst du mal eben von überall ein Thing vom System unterstützt hinzufügen. Ich bevorzuge jedoch die Textfiles, weil ich damit eine Vielzahl von Änderungen schnell durchführen kann. Und du kannst noch ein paar Notizen anfügen.

Things

Die eigentlichen Things sind Dinge, die eine physische oder logische Präsenz in der wirklichen Welt haben. Intelligente Glühbirnen, Heizthermostate, Fenstersensoren, Fernseher aber auch Kalender, MQTT-Kanäle, Telegram-Bots oder Wetter-Dienste.

Beim Erzeugen eines neuen Things werden die notwendigen Konfigurationen abgefragt und wenn du alles richtig angegeben hast, ist dein SmartDevice danach auch schon in deiner Zentrale angebunden.

Channels

Things haben Channels. Channels bilden verschiedene Funktionen einen Things ab. Die Helligkeit oder Farbe eines Läutermittels, die Soll-Temperatur und der Ventil-Öffnungsgrad eines Heizthermostats, der Zustand eines Fenstersensors, die Lautstärke und das Programm des Fernsehers oder verschiedene Variablen aus einem JSON-File. Die Kanäle laufen dabei generell in beide Richtungen. Dabei gibt es Kanäle, die nur schreibend sein können oder nur lesend. Oder beides. Den Kontakt-Zustand eines Fenster-Sensors beschreiben zu wollen, macht keinen Sinn.

Auch die Channels können in einigen Fällen (MQTT-Things, HTTP-Things, …) weiter verfeinert werden. Vielleicht passt das Format oder der ausgegebene Wert nicht ganz zu dem, was danach damit passieren soll oder zu dem Datentyp, den wir für den Channel festlegen wollen. Dann lassen sich Transformationen oder automatische Reaktionen hier schon festlegen. Viele Binding, die genau für ein bestimmtes Gerät oder eine Gerätegruppe geschrieben wurden, lassen das nicht zu. Die Konfiguration ist bereits fest und die Entwickler dahinter haben die Arbeit der Spezifizierung bereits gemacht.

Items in OpenHAB

Der letzte Schritt um ein Gerät in OpenHAB zu verwenden sind die Items. Das sind die Objekte, mit denen wir später weiterarbeiten werden. Items repräsentieren einen einzelnen Wert eines bestimmten Typs.

[Welche Attribute haben Items?]

Gruppen

Gruppen fassen Items zusammen. Damit können bestimmte Verhalten ausgelöst oder zusammengefasst werden.

Es ist eine gute Idee, Gruppen-Items immer als „gGruppenname“ zu schreiben, um sie von normalen Items zu unterscheiden. Ich gehe dabei noch weiter und verwende:

• sgSemantischeGruppe um zu kennzeichnen, dass es sich hierbei um eine standardisierte semantische Gruppe handelt (weiter unten beschrieben)
• fgFunktionsgruppe um zu kennzeichnen, dass diese Gruppe eine komplexe automatische Funktion hat
• igItemgruppe um zu kennzeichnen, dass das Item logisch Teil eines gemeinsamen konkreten Things ist
• tgTriggergruppe um zu kennzeichnen, dass Items dieser Gruppe gemeinsam eine oder mehrere bestimmte Rule/s auslösen

Rules in OpenHAB

Rules sind der Grundstock der Automatisierung mit OpenHAB. Hier lassen sich Reaktionen auf Ereignisse definieren. Das kann die Änderung eine Items oder eines Items aus einer bestimmten Gruppe sein. Das kann ein Zeitpunkt sein. Rules können auch auf Things und deren Channels reagieren, ohne Item dahinter. Und natürlich können Rules auch auf Systemereignisse reagieren.

Ich verwende die Text-basierten Basis-Regeln in RulesDSL. Diese binden im Grunde die Java-Methoden aus der Dokumentation ein.

Inzwischen bietet OpenHAB allerdings auch andere Regel-Varianten an, sodass auf die Bedürfnisse vieler User eingegangen wird. So lassen sich Regeln auch in Javascript, Jython, jRuby oder grafisch auch mit Blockly schreiben. Weitere Varianten lassen sich nachinstallieren.

Transforms als einfache Alternativen zu Rules

Wo es möglich ist, will ich auf Regeln verzichten, da diese den Komplexitätsgrad des Systems erhöhen. Falls möglich, greife ich lieber auf Transforms zurück. Dabei handelt es sich um Übersetzer zwischen zwei Komponenten. Außerdem lassen sich Transforms gut wiederverwenden und finden Anwendung direkt in den Thing- oder Item-Files, sodass ich alles auf einen Blick habe.

Mit Transforms kannst du beispielsweise zwischen zigbee2mqtt und OpenHAB vermitteln, sodass übermittelte JSONs passend auf Items übersetzt werden. Du kannst auch Werte filtern, beispielweise wenn ein Sensor gelegentlich falsche Daten sendet und du einen gültigen Bereich festlegen willst. Du kannst aber auch einfach Einheiten umrechnen, wenn du Formeln in den Transforms hinterlegt.

Beispiel: Ich habe einen einfachen Geigerzähler im Netz. Dieser liefert mir alle 20 Sekunden die Klicks, die er gezählt hat. Mit einem transform rechne ich diese in Mikrosievert pro Stunde um.

Persistence in OpenHAB

Persistence speichert Werte über einen Zeitraum hinweg. Der rrd4j persistence service ist schon vorinstalliert und lässt sich am einfachsten benutzen. Je älter die Werte zurückliegen, desto mehr werden sie vereinfacht und zusammengefasst. Dadurch wird Speicherplatz auf Kosten der Genauigkeit gespart.

Um persistence für ein Item auf diese Weise zu aktivieren, musst du nur eine Datei anlegen: /etc/openhab/persistence/rrd4j.persist

Strategies {
	everyMinute	: "0 * * * * ?"
	everyHour	: "0 0 * * * ?"
	everyDay	: "0 0 0 * * ?"
}

Items {
	fgPersist* : strategy = everyMinute, restoreOnStartup
}

Hier verwende ich bereits ein Designmuster, was die Definition der zu speichernden Items vereinfachen soll. Jedes Item, dessen Werte kontinuierlich gespeichert werden soll, benötigt nun nur noch die Gruppe „fgPersist“. Ich habe mich bewusst gegen die vordefinierte Strategie „everyChange“ entschieden, da bei 500 Items die arme SD-Karte des Raspberry Pi schwer beschäftigt wird. Außerdem habe ich mich auch aufgrund der Vielzahl von Items dagegen entschieden, mit „*“ einfach alle Items generell nachzuverfolgen, auch um die Last des Raspberry Pi zu senken.

Bei selten sich ändernden Items ist „everyChange“ allerdings auch keine gute Idee, da die aus diesen Daten generierten Graphen erstmal seltsam aussehen und falsche Zwischenwerte berechnet werden.

Semantisches Modell

Das semantische Modell bringt einige tolle Funktionen mit sich, wenn man es konsequent anwendet. Hiermit werden bestimmte Orte, Gegenstände, Eigenschaften und Funktionen vordefiniert und können direkt an Items und Groups angefügt werden. Mit cleveren Rules lässt sich damit dann viel Arbeit bei großen System sparen, indem man bestimmtes Verhalten nicht mehr an Items, sondern an Gruppen und semantische Eigenschaften bindet.

Ein Beispiel: Ich möchte, dass meine Heizungen überall im Haus abschalten, wenn sich ein Fenster in dem Raum öffnet. Anstatt jeden Raum, Jede Heizung, jeden Fensterkontakt nun einzeln in Regeln zu schreiben, schreibe ich genau dieses Verhalten einmalig und allgemein. Ändert sich ein Fensterkontakt zu „Offen“, sollen alle Thermostate in diesem Raum abschalten.

Eine gute Übersicht über das semantische Modell ist bei OpenHAB dokumentiert.