Contents

Z-Wave-Based Smart Home Sensor and Actuator Communication

This project implemented an architecture to enable Loomo to communicate with smart home devices. This interface allows to subscribe to sensor data as well as to control actuators.

Z-Wave-Based Smart Home Sensor and Actuator Communication

Project Documentation

Integration of smart-home sensors and actors into the robot’s ecosystem to enable A3Bot to interact with its environmental gadgets. Student project by Christoph Kern.

Einführung

Motivation

Digitale Assistenten können Nutzern bei verschiedenen Aufgaben helfen. Dafür benötigen sie jedoch Zugriff auf eine große Menge von Daten. Je mehr Datenquellen zur Verfügung stehen, desto besser kann der Assistent unterstützen.

Eine dieser potentiellen Datenquellen ist das Smart Home. Genauer gesagt bündelt ein Smart Home eine ganze Reihe von Datenquellen – jedes einzelne im Smart Home integrierte Gerät mit Sensoren ist eine Datenquelle und liefert Daten. Um Zugriff auf diese Daten zu erhalten, muss der Assistent mit dem Smart Home kommunizieren können.

Solch ein digitaler Assistent, der unter anderem der Unterstützung hilfsbedürftiger Menschen dienen soll, soll perspektivisch auf der Plattform Loomo (siehe Abschnitt 1.2) umgesetzt werden. Komplexere Anwendungen für diesen Assistenten bauen auf einfachen Basisfunktionalitäten auf und verknüpfen diese. Eine dieser Basisfunktionalitäten ist die oben erwähnte Kommunikation mit Smart Home, um mit der Umgebung mittels SmartHome-Geräten (Sensoren und Aktoren) zu interagieren. Diese Funktionalität soll in dieser Arbeit untersucht und prototypisch implementiert werden.

Segway Robotics Loomo

Loomo is a smart machine that transforms between a mini personal transporter and an intelligent robot [Sega].

Segway Robotics Loomo ist ein zweirädriges Fahrzeug, das einerseits als persönliches Transportmittel dienen und andererseits als autonom agierende Einheit zur Erfüllung diverser Aufgaben eingesetzt werden kann. Loomo bringt dafür eine Reihe von Sensoren und Aktoren wie Kameras, Ultraschall- und Infrarotsensoren, Mikrofone, Motoren, Lautsprecher und ein Display mit und beherrscht die Kommunikationsstandards WiFi und Bluetooth [Segb].

Als Betriebssystem dient Loomo ein angepasstes Android 5.1, wodurch in Verbindung mit Loomo-eigenen Bibliotheken die Entwicklung einer Vielzahl von Anwendungen ermöglicht wird.

Z-Wave

Z-Wave ist ein drahtloser Kommunikationsstandard für die Heimautomatisierung. Entwickelt von der Firma Sigma Designs und der Z-Wave Alliance, zeichnet sich die Kommunikation über Z-Wave durch eine hohe Kommunikationssicherheit und eine geringen Energieverbrauch der beteiligten Geräte aus. Durch die umfassende Spezifikation von ZWave und die strenge Zertifizierung Z-Wave-fähiger Produkte wird eine Kompatibilität aller Geräte erreicht.

Innerhalb eines mit Z-Wave ausgestatteten Smart Homes bauen die einzelnen Sensoren, Aktoren und das Gateway ein vermaschtes Netzwerk auf, über das Nachrichten übertragen werden. Netzbetriebene Geräte sind ständig funkaktiv und können damit als Router dienen und die Reichweite und die Übertragungsgeschwindigkeit verbessern [ZWa].

Da Z-Wave nicht mit den verbreiteten Netzwerkstandards Ethernet und WiFi kompatibel ist, ist eine Vermittlungsschicht (Gateway) notwendig, die den Datenaustausch zwischen den Netzwerken ermöglicht. Damit wird eine Steuerung des Smart-Home-Systems per Computer, Smartphone, Tablet oder digitale Assistenten (auch andere Eingabegeräte sind denkbar) sowie der Fernzugriff via Internet möglich.

openHAB

openHAB (open Home Automation Bus) ist eine Software zur Integration verschiedener Heimautomatisierungssysteme und -technologien in einer einzigen Lösung, die systemübergreifende Automatisierungsregeln ermöglicht und einheitliche Benutzeroberflächen bietet [opea]. Durch die Implementierung in Java kann openHAB plattformunabhängig betrieben werden. openHAB stellt eine API bereit, um sogenannte Bindings für eine große Bandbreite von Heimautomatisierungslösungen, anderen Geräten und Diensten zu verwenden oder zu implementieren.

openHAB ist quelloffen [opec] und steht unter der Eclipse Public License, die das Recht zur freien Nutzung, Weiterverbreitung und Veränderung der Software gewährt [Ecl].

Eine umfangreiche Dokumentation zu openHAB ist unter http://docs.openhab.org/ zu finden.

In ein von openHAB gesteuertes Smart Home eingebundene Geräte werden als Thing bezeichnet. Ein Smart-Home-Gerät verfügt über verschiedene Items – physiche oder logische Sensoren oder Aktoren. In Sitemaps können diese Items ausgewählt werden und dienen einer benutzerfreundlichen Präsentation des Smart Homes.

Raspberry Pi

Der Raspberry Pi ist ein von der Raspberry Pi Foundation entwickelter Einplatinencomputer. Er verfügt über einen ARM-Mikroprozessor und zeichnet sich durch einen geringen Preis, eine Reihe von Anschlüssen (USB, HDMI, Ethernet), WiFi- und BluetoothFähigkeit sowie eine geringe Leistungsaufnahme aus [Rasa].

Seine geringe Leistungsaufnahme sowie der relativ leistungsfähige Prozessor sorgen dafür, dass er ein geeignetes System für Mediacenter, kleine Server sowie Smart-HomeAnwendungen darstellt.

Als Betriebssystem stehen für den Raspberry Pi verschiedene Linuxdistributionen und Windows 10 IoT Core zur Verfügung [Rasb].

Kommunikation von Loomo und Smart Home

Smart-Home-Steuerung über Z-Wave

Die Steuerung eines Smart Homes über Z-Wave erfolgt, indem Nachrichten zwischen den teilnehmenden Geräten übertragen werden. Nachrichten sind zum einen Steuerbefehle, die in der Regel von der Zentrale an Geräte mit Aktoren (z.B. Schaltsteckdosen oder Thermostate) gesendet werden, und zum anderen Informationen über aktuelle Zustände im Smart Home, die von Geräten mit Sensoren an die Zentrale gesendet oder von dieser abgefragt werden. Auch weitere Nachrichten sind möglich, sollen hier aber nicht weiter thematisiert werden. Die Kommunikation im Z-Wave-Netzwerk erfolgt grundsätzlich bidirektional, wobei nur bestätigte Pakete als versendet gelten. Dabei kann jedes im Netzwerk befindliche Gerät als Router dienen und Datenpakete weiterleiten (Eine detaillierte Dokumentation ist unter [Pät14] zu finden) . Dadurch wird eine hohe Ausfallsicherheit der Kommunikation gewährleistet [ZWa].

In Abbildung 1 ist das Z-Wave Netzwerk eines beispielhaften Smart Home mit Anbindung an das Internet und Steuerung via Smartphone, PC und Loomo schematisch dargestellt. Dabei enthält das Smart Home einen Fenstersensor, einen Thermostat, eine Zentrale/Gateway und eine Reihe von generischen Smart-Home-Geräten (in der Abbildung als SH-Device bezeichnet), die in diesem Beispiel keine festgelegte Aufgabe haben. Im lokalen Netzwerk sind ein PC und ein Smartphone sowie Loomo eingebunden und können mit passender Software auf das Smart Home zugreifen. Des Weiteren besteht die Möglichkeit, das Smart Home via Fernzugriff über Internet zu steuern.

Im Allgemeinen sendet ein Smart-Home-Gerät, wenn es eine Zustandsänderung bei eimem seiner Sensoren feststellt, eine Nachricht über diese Zustandsänderung an die Zentrale, die daraufhin auf Grundlage von zuvor definierten Regeln Befehle an andere Geräte schicken kann.

Umsetzung eines Z-Wave-Gateways

Für die Kommunikation eines auf Z-Wave aufgebauten Smart-Home-Systems mit WiFioder Bluetooth-fähigen Geräten wird eine Vermittlungsschicht (Gateway) benötigt. Dabei muss das Gateway verschiedene Anforderungen erfüllen: Das Gateway soll sowohl via Z-Wave als auch via WiFi oder Bluetooth kommunizieren können. Die auf dem Gateway laufende Software soll eine offizielle API für Fremdprogramme anbieten (Der Vorteil offizieller APIs gegenüber inoffiziellen ist die Beständigkeit und Abwärtskompatibilität bei Updates. Dies reduziert den Wartungsaufwand und erhöht die Stabilität und Kompatibilität von Drittprogrammen.) , über lange Zeit ohne Neustart stabil laufen (Eine weitgehend unterbrechungsfreie Ausführung gewährleistet die permanente Verfügbarkeit des Smart Homes) , dabei eine geringe Leistungsaufnahme haben und alle Funktionalitäten und Geräte des Smart-Home-Systems unterstützen. Das Gateway sollte einen (sicheren) Zugriff aus dem Internet unterstützen (beispielsweise für Fernwartungszwecke), aber primär lokal bedient werden können (Zugriff auf lokale Netzwerke eingeschlossen). Ein weiteres Kriterium für die Auswahl der Gateway-Software ist die lange Unterstützung durch den Hersteller oder Entwickler der Software.

Gateway-Software Es sind mehrere quelloffene Softwarelösungen zur Realisierung eines Smart-Home-Gateways beziehungsweise einer Smart-Home-Zentrale verfügbar. Prominente Beispiele sind openHAB 6 und FHEM 7 , wobei beide Programme plattformunabhängig sind. Alternativ könnte (mit relativ großem Aufwand) eine eigene GatewaySoftware geschrieben werden oder auf kommerzielle Gateways zurückgegriffen werden.

In diesem Projekt wird openHAB als Gateway-Software verwendet, da es eine große Bandbreite an Smart-Home-Systemen und weiteren Geräten unterstützt und eine gut dokumentierte REST-API 8 angeboten wird, wodurch die Kommunikation zwischen openHAB und Drittprogrammen im lokalen Netzwerk mit vergleichsweise wenig Aufwand realisiert werden kann.

Gateway-Hardware Aufgrund der breiten Verfügbarkeit, der Flexibilität und dem sparsamen Betrieb soll in diesem Projekt ein Raspberry Pi 3B als Plattform eingesetzt werden. Für die Kommunikation über Z-Wave wird ein entsprechender USB-Dongle als Funkschnittstelle (in Literatur häufig als Z-Wave Serial Stick bezeichnet) eingesetzt (Es gibt einige Z-Wave-USB-Sticks auf dem Markt, verwendet wurde der ZME E UZB1 USB Stick von Z-Wave.Me Smart Systems Ltd.) .

Der Vorteil dieser Lösung gegenüber verschiedenen fertig erhältlichen Lösungen ist die Zukunftssicherheit, die gute Dokumentation sowie die freie Konfigurierbarkeit und Kontrolle über den Datenverkehr von und zu dem Smart Home.

Von der Verwendung der zur Verfügung gestellten Basistation/Gateway von Devolo als Gateway für dieses Projekt wurde abgesehen, da keine offizielle API 10 für Drittprogramme zur Verfügung steht und für die Nutzung aller Features eine Verbindung mit Devolo-Servern via Internet hergestellt werden muss.

Kommunikation von Loomo mit dem Gateway

Wie bereits in Abschnitt 2.2 dargestellt, wird das Gateway softwareseitig durch das Programm openHAB realisiert, wodurch die direkte Kommunikation von Loomo mit dem Z-Wave-Netzwerk in den Part Kommunikation Loomo – openHAB und den Part Kommunikation openHAB – Z-Wave unterteilt wird. Aufgrund der Tatsache, dass der zweite Part bereits durch openHAB realisiert ist, muss nur der Erste betrachtet werden.

openHAB stellt für die Integration von Drittprogrammen eine REST-API bereit, über die durch HTTP-GET- und -POST-Requests Daten über das Smart Home abgerufen und manipuliert sowie Steuerbefehle gesendet werden können. Dadurch ist diese Schnittstelle ideal für die Kommunikation zwischen Loomo und openHAB geeignet. Anfragen an die REST-API liefern Daten in dem maschinenlesbaren JSON-Format 11 .

Kommunikation via HTTP Ein HTTP-Request besteht im Allgemeinen aus den Teilen Anfrage-Typ, Anfrage-URL, Header und Nachrichtenrumpf. Der Anfrage-Typ hängt vom Zweck des Requests ab: Sollen nur Daten abgerufen werden, ist ein GET-Request ausreichend, sollen hingegen an den Server Daten (zum Beispiel Steuerbefehle) übermittelt werden, kommt häufig ein POST-Request zum Einsatz.

Bei der Kommunikation mit der REST-API von openHab setzt sich die URL der Anfrage wie folgt zusammen:

< Protokoll >: // < server − ip >:< port > /rest/ < Anfrage − URL >

Die Teile < Protokoll > und < Port > erhalten bei der Kommunikation mit openHAB die Werte http beziehungsweise 8080 (ausgehend von der openHAB-StandardKonfiguration). Der Teil < Anfrage − URL > wird hängt vom Ziel und Zweck der Anfrage ab.

Das Feld < server − ip > enthält die IP des openHAB-Servers. Durch eine entsprechende Konfiguration des lokalen Netzwerks kann dafür gesorgt werden, dass sich die IP-Adresse des Servers nicht ändert. Da jedoch nicht davon ausgegangen werden kann, dass in jedem lokalen Netzwerk, in dem Loomo eingesetzt werden soll, statische IP-Adressen vergeben werden, ist es notwendig, eine Möglichkeit zur automatischen Bestimmung der IP-Adresse zu bieten. Ein Verfahren zu Suche von aktiven openHAB-Servern, das in der implementierten App eingesetzt wird, ist in Algorithmus 1 dargestellt.

In den Headern werden zusätzliche Parameter des HTTP-Requests übermittelt – im Falle eines POST-Requests unter anderem der Typ der im Nachrichtenrumpf enthaltenen Daten. In der verwendeten openHAB-Version 2.2.0 müssen für einen HTTP-Get-Request für den Datenabruf von der REST-API keine Parameter angegeben werden.

Im Nachrichtenrumpf können Daten wie zum Beispiel Steuerbefehle übermittelt werden. Im Falle von openHAB sind diese meist vom Typ text/plain. Um einem openHABItem vom Typ Switch den Befehl zum Anschalten zu senden, muss der Nachrichtenrumpf den Text ON enthalten (Korrektweise müsste davon gesprochen werden, dass der Zustand des Items auf ON gesetzt werden soll. Intuitiv entspricht dieser Vorgang einem Steuerbefehl.) .

Beispiel 2.1 (HTTP-Request) In einem beispielhaften Smart Home gibt es einen Lichtschalter mit der Bezeichnung Light_GF_Corridor_Ceiling, der dafür verantwortlich ist, das Licht im Korridor einer Wohnung an- und abzuschalten. Um die aktuellen Daten für dieses openHAB-Item von dem Server demo.openhab.org abzufragen, wird folgender HTTP-GET-Request gesendet:

Request-URLhttp://demo.openhab.org:8080/rest/items/ Light_GF_Corridor_Ceiling
Request-MethodGET

Die von openHAB gesendete Antwort auf den obigen GET-Request hat folgenden Inhalt:

Request-URLhttp://demo.openhab.org:8080/rest/items/Light_GF_Corridor_Ceiling
Response-Code200
Headerconnection: keep-alive content-length: 207 content-type: application/json date: Thu, 15 Mar 2018 08:39:49 GMT server: nginx/1.10.3 (Ubuntu)
Body{link: http://demo.openhab.org:8080/rest/items/Light_GF_Corridor_Ceiling, state: ON, type: Switch, name: Light_GF_Corridor_Ceiling, label: Ceiling, tags: [], groupNames: [ GF_Corridor, Lights ]}

Aufgrund der Tatsache, dass die REST-API alle Daten im JSON-Format ausgibt, gestaltet sich das Parsen der Daten durch die Verfügbarkeit verschiedener Java-Bibliotheken zur Verarbeitung und Generierung von JSON-Daten komfortabel. In diesem Projekt wird für diese Zwecke die Gson-Bibliothek 13 verwendet. Diese Bibliothek bietet die Möglichkeit, JSON-Daten direkt in Bezug auf eine angegebene Java-Klasse zu parsen und eine Instanz dieser Klasse zurückzugeben. Wichtig ist dabei, dass passende Klassen für die erwarteten JSON-Daten modelliert werden. Nach dem Parsen der Daten können diese je nach Bedarf weiterverwendet werden. In Bezug auf das obige Beispiel wäre eine Möglichkeit, dass Loomo nach Erhalt der Daten überprüft, ob das durch den Schalter gesteuerte Licht benötigt wird. Dazu könnten zum Beispiel Daten von anderen Sensoren in diesem Raum (zum Beispiel Bewegungssensoren) genutzt werden.

Echtzeit-Funktionalität Drittprogramme können von der zum Zeitpunkt der Arbeit aktuellen Version von openHAB (2.2.0) durch die nachfolgend beschriebenen Möglichkeiten über Zustandänderungen im Smart Home informiert werden:

Die erste Möglichkeit ist, eine asynchrone HTTP Verbindung aufzubauen (long polling) 14 , wobei eine Anfrage von Client-Seite vom Server erst beantwortet wird, wenn neue Daten vorliegen.

Des Weiteren bietet openHAB die Option, Updates durch sogenannte Server-SentEvents zu übermitteln. Auf der Client-Seite wird diese Variante folgendermaßen umgesetzt: Zunächst wird ein POST-Request gesendet, der eine Subscription-ID beziehungsweise eine entsprechende Subscription-URL liefert. Mit dieser URL kann ein GETRequest gesendet werden. Dadurch wird ein Stream geöffnet, in den openHAB Informationen zu den Events (beispielsweise Statusupdates von Smart-Home-Geräten) schreibt und die auf Client-Seite ausgelesen und verarbeitet werden können.

Eine dritte Möglichkeit ist es, jeweils nach einem festgelegten Zeitintervall (z.B. alle 10 Sekunden) die zu diesem Zeitpunkt aktuellen Daten abzurufen. Technisch entspricht diese Variante einem „normalen“ GET-Request. Der Vorteil gegenüber Variante 2 ist, dass keine permanente Verbindung besteht, der Nachteil allerdings, dass Zustandsänderungen im schlimmsten Fall ein Intervall zu spät erkannt werden – dieser Umstand kann durch ein hinreichend kleines Intervall abgemildert werden.

Integration weiterer Smart-Home-Systeme

Mittlerweile gibt es eine Vielzahl von Smart-Home-Lösungen auf dem Markt, die auf verschiedenen Technologien und Standards basieren. Durch die Verwendung unterschiedlicher Technologien und Standards sind oft die Systeme in sich abgeschlossen und mit Geräten anderer Lösungen inkompatibel. Dies führt dazu, dass die Konzeption eines Smart Homes einer der folgenden Wege verfolgen muss:

Der erste Weg besteht in der ausschließlichen Verwendung von Geräten eines Herstellers bzw. eines Standards (beispielsweise Z-Wave), wodurch Inkompatibilitäten weitgehend vermieden werden. Dies führt allerdings zur Abhängigkeit von den Herstellern.

Es kann allerdings erwünscht oder notwendig sein, Geräte aus verschiedenen SmartHome-Lösungen zu nutzen. In diesem Fall gibt es die Möglichkeit, unabhängige Teilsysteme aufzubauen oder aber es wird ein Weg gefunden, wie die einzelnen Teilsysteme miteinander kommunizieren können.

Vorteile eines Multisystem-Smart-Homes Die parallele Verwendung von Geräten aus verschiedenen Smart-Home-Lösungen bietet unter anderem Vorteile finanzieller Art bei der Beschaffung von Smart-Home-Komponenten, die für verschiedene Systeme angeboten werden, verringerte Herstellerabhängigkeit und vergrößerte Geräteauswahl (besonders durch die Nutzbarkeit systemexklusiver Geräte) für die Erfüllung spezieller Aufgaben.

Probleme bei der Umsetzung Für Anwender ist es also vorteilhaft, verschiedene SmartHome-Systeme einzusetzen. Bedingt dadurch, dass verschiedene Smart-Home-Systeme meist verschiedene Standards für die Kommunikation nutzen und dadurch meist inkompatibel sind, ergeben sich aber diverse Probleme:

  • Es ist keine direkte Kommunikation zwischen den Systemen möglich.
  • Ein einzelnes Gerät des einen Systems kann nicht direkt in das andere integriert werden.
  • Für jedes verwendete Smart-Home-System ist ein separates Gateway oder Zentrale notwendig, um durch Geräte wie beispielsweise Smartphones gesteuert zu werden.
  • Für jedes System gibt es vom jeweiligen Hersteller passende Steuerprogramme für gängige Betriebssysteme und Endgeräte, die häufig nur mit ebendiesem SmartHome-System kompatibel sind.

Daraus ergeben sich weitere Probleme: für jedes System muss eine passende Steuermöglichkeit separat vorgehalten werden. Außerdem können bei der Entwicklung einer Lösung zur zentralen Steuerung aller Systeme fehlende APIs oder eine ungenaue Dokumentation dieser zu Problemen führen. Alle diese Probleme lassen sich jedoch mit mehr oder weniger Aufwand lösen, wenn das Grundproblem der fehlenden oder erschwerten Kommunikationsmöglichkeit behoben ist.

Lösung Ein Ansatz für die Lösung des Kommunikationsproblem ist es, einen Kommunikationsstandard als kleinsten gemeinsamen Nenner zu bestimmen, der mindestens von den Gateways der jeweiligen Systeme verstanden wird. Zusätzlich ist eine Zentrale vonnöten, die von allen Systemen Informationen erhält und Steuerbefehle an beliebige Geräte in beliebigen Systemen senden kann.

WiFi ist ein solcher Standard, der als gemeinsame Basis für ein Multisystem Smart Home dienen kann. Für fast jedes Smart-Home-System, das nicht über WiFi kommuniziert, wird ein WiFi-fähiges Gateway angeboten. Es gibt allerdings auch weitere Möglichkeiten. Für Z-Wave beispielsweise kann – wie bereits in diesem Projekt – ein USB-Dongle genutzt werden, der der Zentrale ermöglicht, via Z-Wave zu kommunizieren.

Eine solche propagierte Multisystem-Zentrale ist hardwareseitig recht simpel, da prinzipiell jeder beliebige Computer dafür eingesetzt werden kann. Wichtiger ist es, eine leistungsfähige Software einzusetzen, die alle gewünschten Features mitbringt.

Es gibt mehrere quelloffene Softwarelösungen, die diese Aufgabe übernehmen können, darunter das in diesem Projekt verwendete openHAB. Ein großer Vorteil von openHAB ist die Möglichkeit, für noch nicht unterstützte Systeme sogenannte Bindings zu implementieren. Diese Bindings dienen als Schnittstelle zwischen openHAB und der API des jeweiligen Smart-Home-Systems.

Durch die Verwendung einer solchen Multisystem-Zentrale kann die Kommunikation von Loomo mit jedem einzelnen Smart-Home-System auf die Kommunikation zwischen Loomo und der Zentrale reduziert werden.

Anwendungsszenario

Für die Konzeption eines Anwendungsszenarios wird ein Raum mit einem Fenster angenommen, der mit einer mobilen elektrischen Heizung beheizt wird. Der Raum wird vor allem als Werkstatt genutzt, die nicht permanent beheizt werden soll. Zur Nutzungszeit ist je nach durchgeführter Arbeit eine gute Belüftung notwendig. Da jedoch Heizen bei offenem Fenster energetisch ungünstig ist, soll die Heizung bei offenem Fenster automatisch ab- und nach Schließen des Fenster wieder angeschaltet werden.

Zur Umsetzung dieses Szenarios werden eine Schaltsteckdose und ein Fensteröffnungssensor benötigt. Die Automatisierung wird in diesem Szenario durch openHAB und passend definierte Regeln übernommen. Loomo hat in diesem Szenario die Aufgabe, ein Übersicht über die genutzten Geräte sowie von den Geräten gelieferte Daten anzuzeigen und eine Möglichkeit zu bieten, die Heizung an- und abzuschalten, ohne die Werkstatt betreten zu müssen.

Dokumentation

Übersicht über die Benutzeroberfläche

Die im Rahmen dieses Projektes implementierte Android-App für Loomo ist in der Lage, die in einem durch openHAB gesteuerten Smart Home integrierten Geräte, Details zu Geräten sowie zu einzelnen Items anzuzeigen. Es können Steuerbefehle an die SmartHome-Geräte beziehungsweise die einzelnen Items gesendet werden. Zusätzlich ist eine Funktionalität zur Suche nach aktiven openHAB-Servern in einem lokalen Netzwerk integriert.

Beim ersten Start der App wird zunächst das Netzwerk auf aktive openHAB-Server gescannt und Auswahl einer der gefundenen Server gefordert. Die gewählte Server-IPAdresse wird im Speicher der App abgelegt und bei folgenden Starts genutzt. Nach der Auswahl einer Adresse wird eine Liste der integrierten Smart-Home-Geräte geladen. Der Netzwerkscan kann über den im nächsten Absatz erwähnten Menüpunkt Find openHAB servers erneut durchgeführt werden. Alternativ kann die IP-Adresse in den Einstellungen manuell geändert werden. Details zu den einzelnen Bildschirmen der App sind nachfolgend beschrieben.

Übersicht über Smart-Home-Geräte Dieser Bildschirm zeigt eine Übersicht über die im Smart Home bekannten Geräte. Für jedes angezeigte Gerät kann eine Detailansicht (vgl. Detailansicht für ein Smart-Home-Gerät) aufgerufen werden. Es ist ein Menü mit den Einträgen Settings (ruft den Bildschirm Einstellungen auf), Refresh (lädt die Liste der Geräte neu) und Find openHAB servers (Startet den Scan des lokalen Netzwerks auf aktive openHAB-Server) verfügbar. In Abbildung 2 ist dieser Bildschirm mit den in diesem Projekt zur Verfügung stehenden Geräten dargestellt.

Detailansicht für ein Smart-Home-Gerät Dieser Bildschirm (in Abbildung 3 dargestellt) dient dazu, die Items eines Smart-Home-Gerätes anzuzeigen. Es ist möglich, für ausgewählte Items Steuerbefehle zu senden (dies hängt davon ab, ob das Item von openHAB als readonly gekennzeichnet ist). In der vorliegenden App ist diese Funktionalität nur für den Item-Typ Switch implementiert 15 . Für jedes Item kann ebenfalls eine Detailansicht (vgl. Detailansicht für ein Item) aufgerufen werden. Im Vergleich zu dem Bildschirm Übersicht über Smart-Home-Geräte ist das Menü um einen Eintrag reduziert – der Eintrag Find openHAB servers wird nicht angezeigt. Dieser ist für diesen Bildschirm insofern irrelevant, als dass zu dem Zeitpunkt, zu dem dieser Bildschirm dargestellt wird, bereits auf einen Server zugegriffen wird und damit eine Änderung des Servers keinen Zusatznutzen bietet. Die angezeigten Daten werden im gewählten Synchronisationsintervall aktualisiert (vgl. Einstellungen).

Detailansicht für ein Item Der in Abbildung 4 dargestellte Bildschirm zeigt Detailinformationen wie Beschriftung, Zustand, Schaltflächen zum Senden von Steuerbefehlen sowie eine einfache Textanzeige mit allen Daten für ein Item an. In dieser App sind prototypisch nur Schaltflächen für Items der Typen Switch und Number implementiert, die in Abhängigkeit von der readonly-Eigenschaft des Items aktiviert werden. Das Menü enthält die gleichen Einträge wie bei dem Bildschirm Detailsansicht für ein Smart-Home-Gerät. Die angezeigten Daten werden im gewählten Synchronisationsintervall aktualisiert (vgl. Einstellungen).

Einstellungen In Abbildung 5 sind alle verfügbaren Einstellungsbildschirme dargestellt. In der vorliegenden Version der App können die IP-Adresse des openHAB-Servers und das Zeitintervall für die Synchronisation eingestellt werden.

Dokumentation des Quellcodes

Der Quellcode der App wurde in ein Modul app, das alle Funktionalitäten für die AndroidApp bündelt, und eine Android-Library SmartHomeConnection, die Funktionalitäten für die Kommunikation mit openHAB bereitstellt, aufgeteilt. Da ein großer Teil der Programmdokumentation als JavaDoc umgesetzt wurde, soll an dieser Stelle nur ein Überblick über die Module, die in ihnen enthaltenen Klassen und ihre Aufgaben gegeben werden.

Modul App

Dieses Modul enthält die für die Anzeige und Steuerung der App-Benutzeroberfläche verantwortlichen Klassen. Die Abbildung 6 zeigt vereinfacht die Abhängigkeiten dieser Klassen und der wichtigsten Klassen der Library SmartHomeConnection.

Main Die Klasse Main implementiert eine Android-Activity 18 , die der Anzeige der im Smart Home verfügbaren Things dient (vgl. Übersicht über Smart-Home-Geräte). Zur Bindung der Daten an die Benutzeroberfläche (durch die Layout-Datei activity_main.xml definiert) wird eine Instanz der Klasse ThingListAdapter verwendet.

Diese Klasse nutzt asynchrone Tasks 19 , um das lokale Netzwerk nach aktiven openHABServern zu scannen und eine Liste aller Things zu laden und aktuell zu halten.

SingleThing Durch die Klasse SingleThing wird eine Activity implementiert, die eine Detailansicht (in activity_single_thing.xml definiert) für ein Objekt der Klasse SHThing darstellen kann.

Es werden die Bezeichnung des Things sowie die mit dem Thing verknüpften Items (Objekte des Types SHItem) angezeigt. Dazu wird eine Instanz der Klasse ItemListAdapter verwendet.

In dieser Klasse sind asynchrone Tasks zum Laden des anzuzeigenden Things, der verknüpften Items sowie zur regelmäßigen Aktualisierung der angezeigten Daten im eingestellten Intervall enthalten.

SingleItem Die Klasse SingleItem implementiert eine Activity, die dazu dient, eine Detailansicht (in activity_single_item.xml definiert) für ein Objekt des Types SHItem anzuzeigen. In der vorliegenden Version der App ist das Senden von Befehlen für die Item-Typen Switch, Contact und Number möglich. Für alle anderen Typen ist aktuell nur eine Basis-Anzeige von Bezeichnung und Zustand aktiviert 20 .

In dieser Klasse sind asynchrone Tasks zum Laden eines Items sowie zur regelmäßigen Aktualisierung der Daten im eingestellten Intervall integriert.

ThingListAdapter Diese Klasse erweitert die Klasse android.widget.BaseAdapter und dient der Verknüpfung einer Liste von SHThing-Objekten mit einem UI-Objekt der Klasse android.widget.ListView.

Die Layout-Datei listviewentry_simple.xml bestimmt das Layout der Listenelemente, die jeweils die Bezeichnung des Things anzeigen kann.

ItemListAdapter Diese Klasse erweitert die Klasse android.widget.BaseAdapter und dient der Vernüpfung einer Liste von SHItem-Objekten mit einem UI-Objekt der Klasse android.widget.ListView.

Die Layout-Datei listviewentry_controls.xml bestimmt das Layout der Listenelemente, die jeweils die Bezeichnung des angezeigten Items sowie abhängig von dem Typ des Items einen Schalter zum Senden von An- und Abschaltbefehlen oder eine Textdarstellung des aktuellen Zustands anzeigen können.

Settings Die Klasse Settings implementiert eine PreferenceActivity, die der Eingabe und Anzeige von Einstellungsoptionen dient. In der vorliegenden Version der App kann in den Einstellungen die IP-Adresse des openHAB-Server und das Synchronisationsintervall verändert werden.

Util In der Klasse Util sind verschiedene Konstanten und UI-Funktionen zur Anzeige von einfachen Dialogen und Toasts 21 integriert, die von den anderen Activities verwendet werden.

AppCompatPreferenceActivity Diese Klasse dient der Kompatibilität der SettingsActivity mit älteren Android-Versionen und hat ansonsten keine besonderen Aufgaben.

Android-Library SmartHomeConnection

Die Android-Library SmartHomeConnection bietet Funktionalitäten zur Kommunikation mit der openHAB-Rest-API, Klassen zur Modellierung von über die Rest-API erhaltenen Objekte sowie Hilfsfunktionen zum Parsen von JSON-Daten. In Abbildung 7 sind die Abhängigkeiten zwischen den Klassen dieser Library vereinfacht dargestellt.

SHConnection In dieser Klasse sind Funktionalitäten zum Senden von HTTP-Requests und Empfangen der Antwort, zum Scan eines lokalen Netzwerks auf aktive openHABServer und verschiedene Hilfsfunktionen zum Parsen von JSON-Daten und zum Ermitteln der lokalen IP-Adresse enthalten.

Zusätzlich ist eine Methode getUpdateStream() 22 für die zweite Variante der Echtzeitfähigkeit (siehe Abschnitt 2.3) implementiert, deren Aufgabe es ist, einen Stream über eine HTTP-Verbindung zu öffnen, über den openHAB Statusänderungen senden kann. Der Aufruf dieser Methode gibt ein Objekt vom Typ java.io.BufferedReader zurück, über den die von openHAB gesendeten Daten mithilfe des Quellcodes in Algorithmus 2 zeilenweise gelesen und verarbeitet werden können. Die Methode getUpdateStream() benötigt folgende Parameter:

  • openHabIp: die IP-Adresse des openHAB-Servers
  • sitemap: der Name der Sitemap, für die Updates gesendet werden sollen
  • pageid: der Name der Page der Sitemap, für die Updates gesendet werden sollen
  • Die Parameter sitemap und pageid dürfen auch Strings der Länge 0 sein, dann werden Updates zu allen im Smart Home bekannten Items gesendet.

Bei einem Update-Event werden die folgenden zwei Zeilen von openHab gesendet (<json> symbolisiert die übermittelten Daten für ein Sitemap-Widget 23 ):

event: event 
data: <json>

Anmerkungen: Alle Aussagen zur oben beschriebenen Update-Funktionalität entstammen den Erfahrungen vor dem Versionssprung und konnten mit der verwendeten Kopie von openHAB nicht überprüft werden. Eine experimentelle Implementierung zur Umsetzung dieser Update-Funktionalität ist in UpdateReceiverTask gegeben. Vor der produktiven Verwendung dieser Funktionalität sollte überprüft werden, ob Daten empfangen werden. Eine Alternative zu dieser Methode ist durch die Klasse UpdateHelper implementiert.

LoadThingsBaseTask Diese Klasse implementiert einen asynchronen Task zum Laden einer Liste aller Things von openHAB.

Zur produktiven Nutzung dieser Klasse ist es notwendig, diese mindestens um eine Methode onPostExecute() zu erweitern, um die Ergebnisse des Tasks zu verarbeiten.

LoadSingleThingTask Diese Klasse implementiert einen asynchronen Task zum Laden eines Things von openHAB.

Zur produktiven Nutzung dieser Klasse ist es notwendig, diese mindestens um eine Methode onPostExecute() zu erweitern, um die Ergebnisse des Tasks zu verarbeiten.

LoadServerListBaseTask Diese Klasse implementiert einen asynchronen Task zum Scan des lokalen Netzwerks zur Suche von openHAB-Servern.

Zur produktiven Nutzung dieser Klasse ist es notwendig, diese mindestens um eine Methode onPostExecute() zu erweitern, um die Ergebnisse des Tasks zu verarbeiten.

LoadItemsBaseTask Diese Klasse implementiert einen asynchronen Task zum Laden einer Liste von Items von openHAB.

Zur produktiven Nutzung dieser Klasse ist es notwendig, diese mindestens um eine Methode onPostExecute() zu erweitern, um die Ergebnisse des Tasks zu verarbeiten.

UpdateHelper In dieser Klasse ist eine Funktionalität zur wiederholten Ausführung eines asynchronen Tasks zum Laden der aktuellen Daten von zuvor bestimmte Items. Es ist möglich, das Intervall und die Liste der zu ladenden Items zu ändern sowie den Task zu starten und zu stoppen.

UpdateReceiverTask Diese Klasse ist eine experimentelle Implementierung der in Abschnitt 2.3 erwähnten zweiten Variante der Echtzeitmöglichkeiten. Technisch gesehen implementiert diese Klasse einen asynchroner Task ausgeführt, der eine dauerhafte Verbindung mit openHAB öffnet und auf Updates zu zuvor definierten Items überwacht.

Bei erkannten Updates zu den bestimmten Items gibt der Task die gelesenen Daten über die Methode publishProgress weitergegeben.

Um die Klasse produktiv zu nutzen, ist es notwendig, diese mindestens um eine Methode onProgressUpdate(), die die Verarbeitung der erhaltenen Daten übernimmt, zu erweitern.

Mit Ausnahme der Klasse RequestFailedException implementieren alle nachfolgend aufgeführten Klassen für Android-Zwecke (Transfer von komplexen Objekten zwischen verschiedenen Activities) das Parcelable 24 -Interface.

SHItem Die Klasse SHItem modelliert ein Item im Sinne von openHAB und bietet eine Methode zum Senden von Steuerbefehlen.

Die Klassen SHItemStateDescription und SHItemStateDescriptionOptions dienen der erweiterten Beschreibung des Zustands des Items. Sie dienen als Hilfsklassen bei der Modellierung.

SHThing Diese Klasse modelliert ein Smart-Home-Gerät beziehungsweise Thing (vgl. 1.4). Die Klasse SHThingChannel modelliert die Verknüpfung mit einem Item (es können beliebig viele Items verknüpft werden).

SHSitemap Die Klasse SHSitemap modelliert eine openHAB-Sitemap (vgl. 1.4). Dazu werden die Hilfsklassen

  • SHSitemapHomepage,
  • SHSitemapHomepageWidget,
  • SHSitemapHomepageWidgetLinkedPage,
  • SHSitemapHomepageWidgetMappings und
  • SHSitemapHomepageWidgetItem

verwendet. Ein Widget bezeichnet dabei ein Element einer Sitemap-Homepage (modelliert durch die Klasse SHSitemapHomepage). Widgets können Item-Daten anzeigen, Schaltflächen zur Steuerung einzelner Things beziehungsweise Items bieten oder auf Unterseiten verlinken, die wiederum Widgets in beliebiger Zahl enthalten dürfen.

RequestFailedException Diese Klasse erbt von der Klasse java.lang.Exception, um für der Kommunikation mit openHAB auftretende Fehler eine aussagekräftigere Exception zu bieten.

Fazit

Fazit zu openHAB Durch die Erweiterbarkeit, die gute Dokumentation, die Unterstützung einer großen Bandbreite von Smart-Home-Lösungen, die Verfügbarkeit verschiedener Benutzeroberflächen und Schnittstellen für Drittprogramme erwies sich openHAB als sehr gute Softwarelösung zur Realisierung eines Multisystem-Smart-Homes. Installation, Einrichtung und Bedienung von openHAB sind weitgehend intuitiv und gut dokumentiert.

Allerdings traten bei der Nutzung von openHAB auf dem Raspberry Pi einige Probleme auf: Nach der Installation des Z-Wave-Serial-Sticks konnte openHAB zunächst nicht darauf zugreifen – das Problem lag an fehlenden Berechtigungen, die manuell eingetragen werden mussten 25 . Nach der Behebung dieses Problems ging der Aufbau des Smart Homes ohne weitere Hindernisse vonstatten.

Für ein weiteres Problem, dass im Rahmen der Nutzung von openHAB auftrat, ist die Ursache unbekannt: openHAB bietet, wie bereits in Abschnitt 2.3 erwähnt, die Möglichkeit, eine permanente HTTP-Verbindung für die Übermittlung von Zustandsänderungen in Echzeit aufzubauen. Nach einem Update der openHAB-Version von 2.0 auf

2.2.0 wurden über die aufgebaute Verbindung keine Daten mehr übermittelt. Dieser Fehler trat allerdings nicht bei Nutzung der offiziellen Weboberfläche auf, sondern nur mit Drittprogrammen wie cURL 26 und der in der Android-Library SmartHomeConnection implementierten Methode (vgl. Abschnitt 5.2.2) auf. Aufgrund der Tatsache, dass die Weboberfläche von openHAB ebenfalls auf die REST-API zugreift und an dieser Stelle die Echtzeitfunktionalität ohne Probleme funktioniert, ist davon auszugehen, dass das Problem nur lokal in dieser Kopie von openHAB auftritt und andere Installationen nicht betroffen sind. Eine Neuinstallation wird diesen Fehler vermutlich beheben. Als Workaround und Alternative wurde zusätzlich eine Variante in einigen Klassen des Moduls App implementiert, die auf einer intervallgesteuerten Datenabfrage basiert (siehe Abschnitt

2.3 und 5.2.2). Beide Methoden haben Vor- und Nachteile, wodurch die Wahl einer Variante abhängig von der Verwendung ist. Grundsätzlich kann durch die WorkaroundVariante mit einem hinreichend kleinen Intervall (beispielsweise jede Sekunde werden die aktuellen Daten angefordert) auch bei zeitkritischen Anwendungen zeitnah reagiert werden.

allgemeines Fazit Durch die gut dokumentierte und einfach zu benutzende REST-API von openHAB gestaltete sich die Entwicklung von Funktionalitäten zur Kommunikation von Loomo mit openHAB problemlos. Dadurch ist Loomo in der Lage, mit Smart-HomeGeräten in seiner Umgebung zu kommunizieren und eine App für das in Abschnitt 4 beschriebene Szenario auszuführen. Durch die Auslagerung in eine separate AndroidLibrary wird eine problemlose Verwendbarkeit in anderen Projekten ermöglicht.

Literatur