Spaß und Sicherheit mit Automatisierung

Smart Home: Hands-on-Integration mit openHAB
2 Kommentare

Zeit für ein wenig Smart-Home-Praxis: Unter Verwendung von openHAB zeigen wir, wie sich eine individuelle Smart-Home-Lösung aufbauen lässt, die einfach erweiterbar ist und den Schutz der persönlichen Daten gewährleistet.

Bevor wir anhand eines praktischen Beispiels unser eigenes Smart-Home-System aufbauen, wollen wir uns zuerst einen Überblick über die einzelnen Komponenten des gesamten Systems verschaffen.

Im Zentrum des Geschehens steht die openHAB-Runtime. Sie läuft auf dem lokalen Server, der über die nötigen USB-, IP- und seriellen Schnittstellen verfügt und darüber die Verbindung zu den Geräten und Services herstellt. Er bietet auch die passenden Schnittstellen für User Interfaces (REST) an und betreibt eine sehr flexible Regel-Engine. Die Konfiguration erfolgt über Dateien, die mit gewöhnlichen Texteditoren oder dem openHAB Designer, einer Entwicklungsumgebung für openHAB, geändert werden können. Für den Fernzugriff kann der lokale openHAB-Server mit dem my.openHAB-Cloud-Dienst verbunden werden. Dieser hilft dabei, über das Internet auf die lokale Instanz zuzugreifen, ohne dabei Änderungen am Router vornehmen zu müssen. Hierüber können auch weitere Webdienste wie IFTTT in das System integriert werden. Abbildung 1 zeigt die beschriebene Übersicht (gestrichelte Linien symbolisieren Funkverbindungen).

Komponenten des openHAB-Systems

Abb. 1: Komponenten des openHAB-Systems

Ein sauberes openHAB-Beispiel

Zum besseren Verständnis, was sich alles mit einer offenen Smart-Home-Lösung realisieren lässt, stellen wir uns folgendes Szenario vor: In vielen Haushalten stehen Waschmaschine oder Trockner im Keller. Um zu wissen, wann die Maschine fertig ist, merkt man sich entweder die errechnete Endzeit, oder man läuft häufiger herunter und sieht nach. Üblicherweise wird die errechnete Endzeit des Trockners als Maximalzeit ausgelegt, da aus Energiespargründen nur so lange getrocknet wird, bis der Feuchtesensor den Vorgang abbricht. Besser wäre es doch, wenn die Maschinen aktiv mitteilen würden, wann sie ihre Arbeit beendet haben.

Philips-Hue-Lampe signalisiert fertige Waschmaschine

Abb. 2

Um das zu erreichen, kann man entweder in ein neues vernetztes Modell mit entsprechendem (lokalen) API investieren, oder man nutzt extern messbare Eigenschaften der Maschine für diese Zwecke. Tatsächlich kann man durch Beobachtung des jeweiligen Stromverbrauchs (und dem Wissen um das aktivierte Programm) eine sehr genaue Vorstellung davon bekommen, wie weit das jeweilige Programm schon abgearbeitet ist.

In unserem Beispiel wollen wir mithilfe eines Zwischensteckers mit Strommessfunktion den Stromverbrauch der Maschine in regelmäßigen Abständen prüfen. Der Fertigstatus soll anschließend mit einer Philips-Hue-Farblampe optisch signalisiert werden (Abb. 2).

Gesagt, getan

Bevor wir das Beispiel umsetzen können, müssen wir uns allerdings um eine Laufzeitumgebung für openHAB kümmern. Denkbar sind dafür aufgrund der Plattformportabilität viele Embedded-Systeme, das heimische NAS oder das ausrangierte Notebook bzw. der Server. Auch beim Betriebssystem gibt es viele Wahlmöglichkeiten. Als konkretes Beispiel soll hier der Raspberry Pi 2 mit einem Debian Linux (Raspbian) und dem Oracle JDK für Embedded-Devices genannt werden. Mit ihm steht ein erstaunlich leistungsstarker, platz-, kosten- und stromsparender Miniserver zur Verfügung.

Ist die Basisinstallation (Betriebssystem, JVM) des Servers erledigt, können die Binaries von der Projektwebseite geladen werden. Installiert wird die openHAB Runtime durch einfaches Entpacken in einen Ordner wie C:\openhab oder /opt/openhab. Das Add-ons-Archiv sollte in ein separates Verzeichnis wie addons_download entpackt werden. Aus der Liste aller verfügbaren Add-ons kopieren wir dann das für unser Beispiel nötige Fritz AHA Binding (org.openhab.binding.fritzaha-1.7.0.jar) und das Philips Hue Binding (org.openhab.binding.hue-1.7.0.jar) in das Add-ons-Verzeichnis unterhalb von openhab.

Als Nächstes laden und installieren wir den openHAB Designer (Abb. 3). Der Designer ist ein eigenständiges IDE-ähnliches Tool zur Bearbeitung der openHAB-Konfigurationsdateien. Zur Unterstützung des Nutzers bietet er Syntaxprüfungen und -highlighting an und liefert inhaltliche Vorschläge zur Erstellung der verschiedenen Konfigurationsdateien (Content Proposal). Zur Installation entpacken wir das Archiv auf unserem Desktoprechner in ein Verzeichnis C:\openhab-designer bzw. /opt/openhab-designer. Gestartet wird der Designer durch Ausführen der Datei openHAB-Designer.exe (bzw. openHAB-Designer auf Linux- und Mac-Systemen). Nachdem er gestartet ist, muss der configurations-Ordner der openHAB-Installation ausgewählt werden ‑ dann kann die Arbeit beginnen. Sollte der Designer auf einem anderen Rechner als die Runtime ausgeführt werden, muss der configurations-Ordner auf dem openHAB-Server über einen zusätzlichen Dienst wie Samba freigegeben werden.

Im nächsten Schritt nehmen wir die Basiskonfiguration des Systems in der Datei configurations/openhab.cfg vor. Dazu erzeugen wir eine leere openhab.cfg-Datei und übertragen alle nötigen Parameter aus der Datei configurations/openhab_default.cfg, die alle Parameter nebst ihrer Dokumentation enthält. In unserem Set-up sind im Wesentlichen die IP-Adresse der Hue Bridge, also das IP-Gateway von Philips und die Konfiguration des Fritz-AHA-Hosts vorzunehmen.

Für die Hue Bridge konfigurieren wir die IP-Adresse im Parameter hue:ip sowie ein individuelles Geheimnis, das hue:secret. Das Geheimnis darf ein beliebiger String (> 10 Zeichen) sein, durch den sich openHAB gegenüber dem Hue-System identifiziert und darüber autorisiert wird.

Beim Fritz-AHA-Binding ist zunächst lediglich ein Name für den AHA-Host mit Parameter fritzaha:fritzbox.host zu vergeben. Die anderen möglichen Einstellungen wie fritzaha:fritzbox.username und fritzaha:fritzbox.password lassen wir zunächst unverändert.

Um die Installation abzusichern, ist es empfehlenswert, den Parameter security:option auf ON zu setzen ‑ damit sind alle HTTP(S)-Zugriffe automatisch per Basic Auth geschützt. Benutzer und ihre Passwörter lassen sich in der Datei users.cfg in der einfachen Form <benutzername>=<passwort> eintragen. Listing 1 zeigt das Ergebnis unserer persönlichen Konfiguration in der openhab.cfg-Datei.

######################################################### 
#####          General configurations               #####
########################################################## 

security:option=ON

############### Philips Hue Binding ######################
hue:ip=192.168.0.42
hue:secret=meinGeheimnis

############## FritzAHA Binding ##########################
fritzaha:fritzbox.host=fritz.box

Abbildung der Wirklichkeit in openHAB

Nachdem wir die Basiskonfiguration des Systems abgeschlossen haben, können wir damit beginnen, unsere smarte Welt in openHAB zu modellieren. openHAB verfolgt dafür einen fähigkeitsbasierten Ansatz. Nur so viel zur Erinnerung: Geräte werden in openHAB in ihre einzelnen Funktionen zerlegt, die so genannten „Items“. Jedes Item kann „Commands“ empfangen und verfügt über einen „State“.

Eine so modellierte Waschmaschine könnte somit beispielsweise aus drei Items bestehen: einem Switch-Item, um das Gerät ein- und auszuschalten, einem Number-Item, um die Programmwahl zu adressieren und einem weiteren Number-Item für die Darstellung der Restlaufzeit.

Items werden in Dateien mit der Endung *.items definiert und im Order configurations/item gespeichert. Zur Konfiguration eigener Items beginnen wir damit, eine neue Datei meine.items zu erzeugen und mithilfe des Designers zu editieren. Wir erzeugen ein Item Licht des Typs Color, das fortan ein Licht mit Farbwechselfunktion repräsentieren soll. Darüber hinaus soll der Stromverbrauch der Waschmaschine mit dem Item Verbrauch des Typs Number angezeigt werden. Zur schöneren Darstellung und weil openHAB aus dem generischen Typen Number kein passendes Icon ableiten kann, konfigurieren wir das Icon . Zu guter Letzt benötigen wir noch ein Item Status des Typs Switch, das den aktuellen Betriebsstatus der Maschine aufnehmen wird. Die initiale meine.items-Datei zeigt Listing 2.

Color   Licht
Number  Verbrauch  <socket>
Switch  Status     <socket>

Die so modellierten Items müssen nun noch über die so genannten Binding-Konfigurationen an die reale Welt gekoppelt werden, indem den Items in geschweiften Klammern entsprechende Deklarationen hinzugefügt werden.

Für unsere Hue-LED-Birne brauchen wir lediglich { hue=”1” } hinter unser Color-Item zu schreiben. Die 1 gibt an, die wievielte Birne des Hue-Systems gemeint ist (alle Birnen sind bei Philips durchnummeriert). Beim Fritz AHA Binding referenzieren wir lediglich den AHA-Host, den wir zuvor in der openhab.cfg konfiguriert haben, sowie die Aktor-ID, die auf dem Gerät zu finden ist. Die fertige meine.items-Datei sieht man in Listing 3.

Color   Licht                { hue="1" }
Number  Verbrauch  <socket>  { fritzaha="fritzbox,01234567890" }
Switch  Status     <socket>

Nun ist es Zeit, sich um das User Interface zu kümmern. Hierzu beschreibt der Benutzer den Inhalt, der auf den unterschiedlichen Seiten angezeigt werden soll. Die verschiedenen openHAB-UI-Implementierungen sorgen dann ihrerseits für das entsprechende Layout und Rendering. Für diese Deklaration stehen die *.sitemap-Dateien zur Verfügung, die im Ordner configurations/sitemaps gespeichert werden. Mithilfe dieser Dateien können Struktur und Inhalt der Screens in wenigen Zeilen definiert werden.

Aufgebaut ist die Sitemap aus einem Label (z. B. „openHAB-Demo“) und einer Reihe von Widget-Deklarationen – die vollständige Liste der verfügbaren Widgets ist im GitHub-Wiki zu finden. Das Frame-Widget dient der optischen Trennung einzelner Blöcke. Das Item Licht steuern wir mit dem Colorpicker-Widget mit einem <slider>-Icon. Das Verbrauch-Item sowie das Status-Item werden durch ein Text-Widget repräsentiert, dessen Label weitere Formatierungsoptionen für ihren Status enthält. Abbildung 3 zeigt die resultierende Sitemap-Datei default.sitemap im openHAB-Designer.

Der openHAB-Designer mit der Beispiel-Sitemap

Abb. 3: Der openHAB-Designer mit der Beispiel-Sitemap

Spaß durch Automatisierung

Bisher haben wir alles dafür getan, um die angeschlossenen Geräte fernsteuern zu können bzw. deren Status am UI ablesen zu können. Wirklich smart wird ein Haus aber erst dann, wenn nicht die Benutzer selbst immer wieder die gleichen (langweiligen) Entscheidungen treffen müssen, sondern wenn das Smart-Home-System Aufgaben aufgrund bestimmter Zustände selbstständig ausführt. openHAB bietet als primäre Regelsprache eine Domain Specific Language (DSL) basierend auf Eclipse Xtext an. Diese DSL erwartet bei einer Regel immer zuerst die Angabe einer oder mehrerer Auslösebedingungen sowie anschließend den auszuführenden Codeblock. Auslösebedingungen können dabei eventbasiert sein, wenn sich z. B. der Zustand eines Items verändert, oder sie können per CRON-Definition zeitbasiert erstellt werden.

Zurück zu unserem Beispiel: Die Auslösebedingung ist hier einfach die Veränderung des Verbrauchswerts, was wir wie folgt formulieren können: Item Verbrauch changed. Sollte derzeit kein Strom verbraucht werden (verbrauch == 0), starten wir einen Timer, der in fünf Minuten die Farbe der Hue-Lampe auf Grün ändert. Sollte der Verbrauch zwischenzeitlich doch wieder über 0 steigen, weil das Programm z. B. doch noch nicht beendet war, wird der Timer abgebrochen und die Farbe der Hue-Lampe auf Rot geändert. Die fertige Regel speichern wir unter configuration/rules als Datei status.rules. Das Ergebnis ist in Listing 4 dargestellt.

import org.openhab.core.library.types.*
import org.openhab.model.script.actions.*

var Timer timer

rule "Visualisiere Waschmaschinenstatus"
when
  Item Verbrauch changed
then
  val verbrauch = (Verbrauch.state as DecimalType).intValue
  if (verbrauch == 0) {
    timer = createTimer(now.plusMinutes(5)) [|
      Licht.sendCommand(HSBType::GREEN) 
    ]
  } else {
    if (timer != null) timer.cancel
      Licht.sendCommand(HSBType::RED) 
    }
end

Neben der primären Xtext-basierten Regel-Engine steht seit dem Release 1.7 auch eine weitere Script-Engine zur Verfügung, die die Nutzung JSR-223-kompatibler Sprachen unterstützt. Derzeit existieren bereits ein Jython- sowie ein JavaScript-Interpreter.

Wir starten durch

Alle Konfigurationen sind nun durchgeführt, und wir können die Runtime nun durch Aufrufen der Datei start.sh (bzw. start.bat unter Windows) starten. Abbildung 4 zeigt die Ausgabe der Kommandozeile nach dem Start. openHAB scannt übrigens regelmäßig Dateiänderungen und aktualisiert sich umgehend man kann also problemlos Eingriffe am laufenden System vornehmen, ohne ständig Neustarts durchführen zu müssen.

Start der openHAB Runtime

Abb. 4: Start der openHAB Runtime

Darstellung des Beispiels in der Classic UI

Abb. 5

Jetzt können wir mit unserem Browser zur Adresse http://localhost:8080/openhab.app navigieren und damit das „Classic UI“, ein für Touch-Devices optimiertes Web-UI, aufrufen (Abb. 5). Um die Funktionalität der Regel zu testen, empfiehlt es sich übrigens, statt einer Waschmaschine einen Haartrockner an der Steckdose anzuschließen, da hiermit leicht ein ansehnlicher Verbrauch realisiert werden kann.

Alternativ kann auch eine der nativen Apps für Android oder iOS verwendet werden, die automatisch die laufende openHAB-Instanz im lokalen Netzwerk auffinden können die manuelle Eingabe des URL entfällt damit.

Zugriff aus der Ferne

So schön auch die vollständige lokale Installation ist es gibt Momente, in denen man nicht zu Hause ist, und entweder von seinem Haus informiert werden möchte oder man auf dieses von unterwegs zugreifen möchte. Beide Anwendungsfälle ermöglicht der kostenlose Zusatzdienst my.openHAB. Dieser Cloud-Service bewerkstelligt die Integration der nativen Android- und iOS-openHAB-Apps mit Google Cloud Messaging (GCM) sowie Apple Push Notification (APN), sodass von der lokalen openHAB-Instanz Push-Nachrichten geschickt werden können. openHAB benötigt dafür das my.openHAB-Add-on, das dafür sorgt, dass eine permanente Verbindung zwischen der lokalen Instanz und dem Cloud-Dienst gehalten wird. Diese Verbindung wird nicht nur für Push-Dienste genutzt, sondern erlaubt gleichzeitig auch den Remotezugriff. Da die Verbindung lokal initiiert wird, benötigt man keinerlei Portfreischaltung oder DynDNS-Service hierfür.
Die notwendigen Schritte für das Einrichten von my.openHAB sind im Getting Started Guide beschrieben. Nach der Installation des my.openHAB-Add-ons finden sich im webapps/static-Verzeichnis die beiden Dateien uuid und secret. Der Inhalt dieser Dateien dient der Authentifizierung beim Cloud-Service und muss daher bei der Accountregistrierung angegeben werden (Abb. 6).

my.openHAB-Registrierung

Abb. 6: my.openHAB-Registrierung

Ist das Konto erstellt, so ist man bereits am Ziel. Die lokale Instanz ist nun unter https://my.openhab.org/openhab.app erreichbar. Die Nutzung von Push-Nachrichten ist ebenso einfach. In Regeln verwendet man dafür die Aktion

sendNotification("user@email.com", "Meine Nachricht!")

Damit diese Nachrichten auf dem Smartphone ankommen, ist es wichtig, es bei my.openHAB bekannt gemacht zu haben. Das geschieht einfach dadurch, dass https://my.openhab.org als Remote-URL in der openHAB-App angegeben wird.

Integration mit Webdiensten

Durch den Fokus von openHAB auf das Intranet und die lokale Vernetzung adressiert der Großteil der verfügbaren Bindings Inhouseprotokolle und lokale IP-Verbindungen. Dennoch gibt es zahlreiche Anwendungsfälle, bei denen man auf die Offlinefunktionalität verzichten möchte, um die Chance zu haben, Webdienste mit in die Automatisierungslogiken einzubinden. Einer der populärsten Dienste für die Integration diverser Webservices ist zweifelsfrei If This Than That (IFTTT). Er bietet mit 200 Channels eine reichhaltige Auswahl an und ist damit eine perfekte Ergänzung zu openHAB.

Integration von openHAB mit IFTTT

Abb. 7

Ein sehr gutes Beispiel ist die Nutzung eines Wearables wie Jawbone UP: Es bietet keinen lokalen Zugriff an und ist lediglich per Cloud-Dienst erreichbar – ein IFTTT-Channel existiert aber bereits. Das Jawbone-Armband erfasst, ob man schläft oder nicht. Diese Information ist im Smart Home sehr nützlich: Die Türklingel kann deaktiviert, die Lichter abends ausgeschaltet werden, die Bewegungsmelder bleiben im Schlafzimmer deaktiviert usw. Was liegt also näher, als ein Item für den Hausnachtmodus an das Jawbone zu koppeln? Die openHAB-IFTTT-Integration macht genau dies möglich und hält bereits vorgefertigte Rezepte bereit (Abb. 7).

Für die Gestaltung persönlicher IFTTT-Rezepte stellt der openHAB-Channel verschiedene Trigger bereit, die entweder auf veränderte Item-Werte reagieren oder nur auslösen, wenn ein vorgegebener Schwellwert über- bzw. unterschritten ist. Zusätzlich bietet der Channel eine Action an, über die beliebige Kommandos an openHAB geschickt werden können. Die Integration von IFTTT in openHAB geschieht über den my.openHAB-Dienst und ist denkbar einfach: Man wählt auf IFTTT den openHAB-Channel und aktiviert ihn. Daraufhin wird man zu my.openHAB umgeleitet und dort aufgefordert, den Zugriff für IFTTT zu erlauben, was man akzeptiert. Ab sofort sind die Konten von IFTTT und my.openHAB verbunden.

Um dennoch die größtmögliche Privatsphäre beizubehalten, bekommt IFTTT nur zu sehen, was der Nutzer explizit dafür freigibt – per Default erst einmal gar nichts. Um einzelne Items für IFTTT zugänglich zu machen, greift die Integration auf den openHAB-Persistenzmechanismus zurück. So, wie man entscheiden kann, welche Informationen in einer lokalen Datenbank landen sollen, lässt sich hierüber auch definieren, welche Informationen an my.openHAB rausgeschickt und damit IFTTT zur Verfügung gestellt werden.

Der konkrete Schritt ist das Anlegen der Datei myopenhab.persist im Verzeichnis configurations/persistence mit folgendem Inhalt:

Strategies {
  default = everyChange
}
Items {
  * : strategy = everyChange
}

Das Anlegen der Datei bewirkt, dass jede Statusänderung eines Items an my.openHAB weitergeleitet wird. Ersetzt man den * durch eine kommaseparierte Liste von Item-Namen, so werden nur diese berücksichtigt. Jeder Nutzer kann also individuell für sich entscheiden, welche Items für seine IFTTT-Rezepte relevant sind und welche er lediglich lokal verwenden will.

Für diesen Artikel haben wir openHAB 1.7 als Grundlage genommen.

Fazit

In diesem Artikel haben wir gezeigt, dass es nicht schwer ist, sich mit frei verfügbarer Software wie openHAB eine individuelle Smart-Home-Lösung aufzubauen. Sicherlich ist der Schritt, sich einen eigenen Rechner für den Produktiveinsatz aufzusetzen, für manche Nutzer eine Einstiegshürde. Ist diese aber erst einmal genommen und hat man erste Erfahrungen mit dem System gesammelt, so bieten sich unbegrenzte Möglichkeiten, die die meisten kommerziellen Systeme in den Schatten stellen. Wie kein anderes System kann diese freie Lösung eine Zukunftssicherheit bieten: Es gibt keine Abhängigkeit vom Wohl und Wehe eines einzelnen Herstellers und keinen Cloud-Zwang, der ggf. bei Veränderungen des Businessmodells des Anbieters kostenpflichtig oder ersatzlos abgeschafft werden könnte. Nicht zuletzt bringt der Verzicht auf die Cloud in Zeiten der NSA-Affäre einen weitreichenden Schutz der Privatsphäre. Wer den Cloud-Verlockungen in Form von IFTTT nicht widerstehen kann, hat dennoch die Chance, nur sehr selektiv seine Daten durch das Internet zu leiten.

ML & Python Summit 2021

 

Aufmacherbild: smart house device illustration with app icons von Shutterstock / Urheberrecht: Alexander Kirch

Unsere Redaktion empfiehlt:

Relevante Beiträge

Abonnieren
Benachrichtige mich bei
guest
2 Comments
Inline Feedbacks
View all comments
trackback

[…] werden immer beliebter. Umsetzen lassen sie sich zum Beispiel mit openHab. In seinem Artikel Smart Home: Hands-on-Integration mit openHab erklärt Thomas Eichstädt-Engelen nicht nur anhand eines praktischen Beispiels wie sich ein […]

trackback

[…] zwei neue Versionen des quelloffenen Smart-Home-Projekts openHAB sind erschienen: openHAB 1.8 und die erste Beta für openHAB 2.0. Wie in den vorherigen Releases […]

X
- Gib Deinen Standort ein -
- or -