Praxisprojektbericht

im Studiengang Master Informatik

Herstellerubergreifende¨ Heim-/Geb¨audeautomatisierung beim Einsatz von openHAB

von Peter Manheller (9016802)

Erstprufer:¨ Prof. Dr. Karl Jonas Zweitprufer:¨ M.Sc. Michael Rademacher

Zeitraum: 30.03.2015 - 24.07.2015 Eingereicht am: 26.06.2015 Inhaltsverzeichnis

1 Einleitung1 1.1 Aufgabenstellung ...... 2 1.2 Zielsetzung ...... 2 1.3 Vorgehensweise ...... 3

2 Die OSGi-Service-Platform4 2.1 OSGi-Framework ...... 5 2.1.1 Bundles ...... 5 2.1.2 Services ...... 8 2.2 OSGi-Schichtenmodell ...... 10 2.3 OSGi-Implementierungen ...... 12 2.3.1 Eclipse Equinox ...... 13 2.3.2 Sonstige ...... 13

3 openHAB 14 3.1 Architektur ...... 15 3.1.1 OSGi-Framework Komponenten ...... 15 3.1.2 openHAB Kernkomponenten ...... 18 3.1.3 openHAB Erweiterungen ...... 19 3.2 openHAB Runtime ...... 22 3.3 openHAB Designer ...... 23 3.4 Automation ...... 23 3.4.1 Regeln, Skripte und Aktionen ...... 23 3.4.2 Jobmanagement ...... 24 3.5 Bindings ...... 24 3.6 Persistenz ...... 25 3.7 Sonstiges ...... 26

4 Bewegungserkennung von Personen 27 4.1 Eingesetzte Hard- und Software ...... 29 4.2 Installation und Konﬁguration ...... 30 4.3 Implementierung ...... 32 4.4 Aufbau und Durchfuhrung¨ ...... 36

5 Ergebnisse und Alternativen 38 5.1 Ergebnisse ...... 38 5.2 Alternative Ans¨atze ...... 40

6 Zusammenfassung und Fazit 42

II Inhaltsverzeichnis

7 Anhang 44 7.1 Lex Uno Station - Leitrechner mit openHAB ...... 44 7.1.1 Konfiguration - openHAB mit Hue-Binding ...... 44 7.1.2 Deklaration - openHAB-Items ...... 44 7.1.3 Realisierung - openHAB-Sitemap ...... 45 7.1.4 Konfiguration - openHAB-Persistence ...... 46 7.1.5 Realisierung - openHAB-Rules ...... 47 7.1.6 Remote-Zugriff - Bash-Skript ...... 50 7.2 TP-Link WLAN Router - Receiver ...... 52 7.2.1 Konfiguration - Netzwerk ...... 52 7.2.2 Konfiguration - Wireless ...... 52 7.2.3 Konfiguration - Lua Skript ...... 53 7.2.4 Profil erstellen - Lua Skript ...... 54 7.2.5 Bewegung erkennen - Lua Skript ...... 55 7.2.6 Kommandos fur¨ openHAB REST-API - Lua Skript ...... 56 7.2.7 REST-API Kommando fur¨ openHAB-Items - Lua Skript ...... 57 7.3 TP-Link WLAN Router - Sender ...... 58 7.3.1 Konfiguration - Netzwerk ...... 58 7.3.2 Konfiguration - Wireless ...... 59 7.3.3 Multi-Generator Skript ...... 59 7.4 openHAB-GUI fur¨ realisierte Sitemap ...... 60 7.5 Ergebnisse und Messwertvisualisierung ...... 61

8 Eidesstattliche Erkl¨arung 66

Literaturverzeichnis 73

III Abbildungsverzeichnis

2.1 Beziehungen zwischen Bundles [Fil12, S. 74] ...... 8 2.2 Zusammenhang Bundles und Services [Fil12, S. 78] ...... 9 2.3 OSGi-Schichtenmodell [i.A.a. All15c, S. 2] ...... 10 2.4 Interkation Bundles und Framework-Schichten [Web+10, S. 17] ...... 11 2.5 Bundle-Lebenszyklus [i.A.a. All15c, S. 86] ...... 11

3.1 openHAB Architektur [Uh15i, i.A.a.] ...... 15 3.2 UML-Klassendiagramm des Philips Hue-Bindings ...... 21

4.1 Eingesetzte Hard- und Software [ope15] ...... 30 4.2 UML-Sequenzdiagramm - Proﬁl erstellen ...... 33 4.3 UML-Sequenzdiagramm - Bewegungserkennung starten und stoppen ...... 34 4.4 UML-Sequenzdiagramm - Zus¨atzliche UDP-Pakete senden ...... 35 4.5 Aufbau des Szenarios in der Hochschule Bonn Rhein Sieg (Raum C060) [ope15] 36

5.1 Messergebnisse fur¨ den Anwendungsfall ”Proﬁl erstellen” ...... 38 5.2 Messergebnisse fur¨ den Anwendungsfall ”Bewegung erkennen” (Ruhe-Phase) . 39 5.3 Messergebnisse fur¨ den Anwendungsfall ”Bewegung erkennen” (Bewegungs- Phase) ...... 39

7.1 Main-Menu¨ der Benutzeroberfläche [Uh15u] ...... 60 7.2 Sub-Menu¨ der Benutzeroberfläche - Steuerung der Leuchten [Uh15u] . . . . . 61 7.3 Visualisierung fur¨ Messdurchlauf #1 ...... 61 7.4 Visualisierung fur¨ Messdurchlauf #2 ...... 61 7.5 Visualisierung fur¨ Messdurchlauf #3 ...... 62 7.6 Visualisierung fur¨ Messdurchlauf #4 ...... 62 7.7 Visualisierung fur¨ Messdurchlauf #5 ...... 62 7.8 Visualisierung fur¨ Messdurchlauf #6 ...... 63 7.9 Visualisierung fur¨ Messdurchlauf #7 ...... 63 7.10 Visualisierung fur¨ Messdurchlauf #8 ...... 63 7.11 Visualisierung fur¨ Messdurchlauf #9 ...... 64 7.12 Visualisierung fur¨ Messdurchlauf #10 ...... 64 7.13 Visualisierung fur¨ Messdurchlauf #11 ...... 64 7.14 Anmerkungen zu den einzelnen Messdurchläufen ...... 65

IV Quelltextverzeichnis

2.1 Manifest - Ausschnitt ”openHAB Core” ...... 6

3.1 Ausschnitt - OSGILogListener.class - Delegation an den SLF4J-Logger [Uh15m, Kreuzer K.] ...... 17 3.2 Ausschnitt der ”execute”-Methode der ”HueBinding”-Klasse [Uh15m, Hart- mann R., Schering J.] ...... 21 3.3 Ausschnitt des MySQL-Services - Datentypen [Uh15m, Sj¨ostrand H., Eichst¨adt- Engelen T., Jackson C.] ...... 25

7.1 Ausschnitt der openHAB-Konfiguration ...... 44 7.2 Deklaration der openHAB-Items ...... 44 7.3 Konfiguration der openHAB-Sitemap ...... 45 7.4 rrd4j-Persistenz fur¨ Visualisierung der Signalstärken ...... 46 7.5 Konfiguration der MySql-Persistenz ...... 47 7.6 MySql-Query fur¨ Auswertung der Ergebnisse ...... 47 7.7 openHAB-Rules fur¨ Reaktion auf Nutzer- und Systeminteraktion ...... 47 7.8 Bash-Skript fur¨ Remote-Zugriff auf Sender und Receiver ...... 51 7.9 Ausschnitt der Netzwerk-Konfiguration ...... 52 7.10 Wireless-Konfiguration ...... 52 7.11 Lua-Konfiguration ...... 53 7.12 RSSI-Profil erstellen ...... 54 7.13 Bewegung anhand der absoluten RSSI-Differenz erkennen ...... 55 7.14 REST-API Kommandos (POST / GET) ...... 56 7.15 openHAB-Items auf dem Receiver verarbeiten (optional) ...... 57 7.16 Ausschnitt der Netzwerk-Konfiguration ...... 58 7.17 Wireless-Konfiguration ...... 59 7.18 Multi-Generator Skript fur¨ 10 Pakete/s ...... 59

V Abkurzungsverzeichnis¨

BatiBUS Industrielles Feldbussystem des BCI ...... 1 BCI BatiBUS Club International ...... 1 CENELEC ComitéEuropéende Normalisation Electrotechnique´ ...... 1 DDC-GA Direct-Digital-Control-Gebäudeautomation...... 2 Drools Rule Management System Solution der JBoss Community ...... 14 EHS European Home Systems ...... 1 EHSA European Home Systems Association...... 1 EIB Europäischer Installationsbus...... 1 EIBA European Installation Bus Association ...... 1 EnOcean Technologie batterieloser Funksensorik Fhem Hausautomations-Server auf Basis von Perl ...... 2 FS20 Protokoll fur¨ Funksysteme GA Gebäudeautomatisierung bzw. Gebäudeautomation ...... 1 HA Heimautomatisierung bzw. Heimautomation ...... 1 HomeMatic Produktfamilie der eQ-3 AG fur¨ Hausautomation IANA Internet Assigned Numbers Authority...... 6 IDE Integrated Development Environment ...... 13 IFTTT If This Then That ...... 20 IHC Intelligent Home Control ...... 16 INSs Inertial Navigation Systems ...... 27 Instabus Installation Bussystem ...... 1 IoT Internet of Things...... 42 J2ME Java 2 Micro Edition ...... 10 JDBC Java Database Connectivity - Standard ...... 9 JPA Java Persistence API ...... 9 JVM Software-Platform - Java Virtual Machine ...... 4 KNX Konnex-Bus ...... 1 LON Local Operating Network ...... 1 LOS Line-Of-Sight ...... 28 Lua Imperative und funktionale Skriptsprache ...... 30 MA Management Agent ...... 5 Maven Software fur¨ den Erstellungsprozess von Softwareprodukten ...... 14

VI Quelltextverzeichnis mDNS multicast Domain Name System ...... 20 MisterHouse Open-Source Home Automation Software (Perl) ...... 14 openHAB open Home Automation Bus ...... 2 OpenRemote Open Source Automation Platform...... 14 ORM Object Relational Mapping ...... 9 OSGi-Alliance Non-Profit-Organisation - Grundung¨ März 1999...... 4 OSGi-Framework Softwareplattform mit Komponentenmodell auf Basis von Java . . . . . 2 PBX Private Branch Exchange ...... 26 POJOs Plain Old Java Objects ...... 8 RCP Rich Client Platform ...... 23 ROS Robot Operating System ...... 26 RSSI Received Signal Strength Indicator ...... 29 SDK Software Development Kit ...... 20 SHSs Step-and-Heading Systems ...... 27 SLF4J Simple Logging Facade for Java ...... 17 SMTP Simple Mail Transfer Protocol ...... 24 SQL Structured Query Language...... 25 SSH Secure Shell ...... 31 Telnet Teletype Network ...... 31 TTS Text-To-Speech ...... 20 UDP User Datagram Protocol...... 31 UIs User Interfaces...... 20 URI Uniform Resource Identifier ...... 10 UX User Experience ...... 2 SMI Standard Motor Interface ...... 1 WAN Wide Area Network ...... 31 WAPs Wireless Access Points ...... 28 Xbase Expression Language fur¨ Java implementiert in Xtext...... 14 XMPP Extensible Messaging and Presence Protocol...... 24 Xtend flexibler und expressiver Dialekt von Java ...... 19

VII 1 Einleitung

Im Jahre 1970 erfolgt aus der Unternehmensgrundung¨ der Insta Elektro GmbH, einer Fusion der Unternehmer Berker, Gira und Jung, die Entwicklung des Instabus (Installation Bussystem) [Gmb15b]. Das Instabus wird im Jahre 1994 von dem CENELEC (ComitéEuropéende Nor- malisation Electrotechnique)´ als europäische Norm unter der Bezeichnung EIB (Europäischer Installationsbus) fur¨ die EIBA (European Installation Bus Association) ratifiziert [CEN15]. Et- wa zeitgleich zur Einfuhrung¨ von EIB wird der BatiBUS (Industrielles Feldbussystem des BCI) von dem BCI (BatiBUS Club International) und das EHS (European Home Systems) von der EHSA (European Home Systems Association) vermarktet [Com15]. Erst durch das Bundnis¨ der oben genannten Organisationen zur KNX-Association, wird bei gleichzeitiger Zusammen- legung der Bussysteme EIB, BatiBUS und EHS, der internationale Grundstein fur¨ die heutige GA (Gebäudeautomatisierung bzw. Gebäudeautomation) gelegt [Ass15b]. Der daraus entstan- dene KNX (Konnex-Bus) wird im Fruhjahr¨ 2002 veröffentlicht und letztendlich im November 2006 als internationaler Standard (ISO/IEC 14543-3) verabschiedet [Ass15a].

Wenn auch neben KNX weitere leitungsgebundene Standards, wie z. B. LON (Local Operating Network) und SMI (Standard Motor Interface) , im Bereich der GA wiederzufinden sind, geht der heutige Trend in Richtung kabelloser Systeme, z. B. EnOcean, HomeMatic und FS20, deren Anwendung vermehrt in der HA (Heimautomatisierung bzw. Heimautomation) anzutreffen ist [Jur15]. Dabei stehen die GA und HA nicht synonym fur¨ Anwendung eines speziellen Standards oder Installation einer konkreten Technologie, sondern eine Abgrenzung findet vielmehr durch die Art der Bauten und die nutzerspezifischen Einsatzbereiche statt [Mer+10, S. 17]. So ist die HA beschränkt auf den privaten Wohnungsbau mit Einsatzbereichen aus Energieeinsparung, Komfort und Sicherheit [Mer+10, S. 18]. Hingegen ist die GA konzentriert auf Zweckbauten, z. B. Buroh¨ äuser oder Einkaufszentren, deren Einsatzbereiche uber¨ die der HA hinaus gehen und zudem die Faktoren der Flexibilität und Kommunikation der Bussysteme betrachten [Mer+10, S. 19].

Trotz der internationalen Standardisierung weist die Interoperabilit¨at der Technologien, sowohl Hard- als auch Software, Lucken¨ auf. Dies fordert die Hersteller fur¨ die Zusammenfuhrung¨ der Vorteile ihrer Kommunikationsstandards zur (Weiter-)Entwicklung neuer Vernetzungssysteme (Gateways) auf [Gmb15a]. Da die Kosten fur¨ Anschaﬀung und der Aufwand fur¨ die Instal- lation und die Vernetzung der Gateways quadratisch ist, verliert der Ansatz an Bedeutung.

1 1 Einleitung

Um die Defizite zu decken, sieht der verbesserte Top-Down-Ansatz nur noch eine einzige Hardware-Komponente, den zentralen Leitrechner, auf der Management-Ebene vor. Auf der darunter folgenden Automationsebene sind dann letztendlich die Komponenten der DDC-GA (Direct-Digital-Control-Gebäudeautomation) wiederzufinden. Den Abschluss bildet die Felde- bene - der Aktoren und Sensoren zugehörig sind [Mer+10, S. 22-26]. Die Symcon GmbH bietet bereits mit ihrer proprietären Software ”IP-Symcon” und dem zugehörigen Web-Service ein Produkt an, das einige Hardware-Module unterschiedlicher Hersteller vernetzt [Ohl15]. Mit Fhem (Hausautomations-Server auf Basis von Perl) ist bereits die Grundlage fur¨ eine Open- Source-Software (GPL v2) fur¨ den Anwendungsbereich der GA bzw. HA geschaffen [Wil15]. Mit openHAB (open Home Automation Bus) bietet die openHAB UG (haftungsbeschränkt) eine Open-Source-Software (EPL) auf Basis des OSGi-Framework (Softwareplattform mit Kom- ponentenmodell auf Basis von Java) an. Der Schwerpunkt der Entwicklung strebt neben der herstellerubergreifenden¨ Vernetzung zudem im aktuellen Stadium die Verbesserung der UX (User Experience) an [Uh15u].

1.1 Aufgabenstellung

Der Auftrag des Projektes besteht in der Ausfuhrung¨ eines realit¨atsnahen Szenarios der Au- tomatisierung beim Einsatz der ”openHAB”-Software und der Vernetzung verschiedener Her- stellerkomponenten. Zudem soll die Software im Hinblick auf umgesetzte Modularisierung und verwendete Architekturen der OSGi-Service-Platform analysiert werden.

Fur¨ obigen Auftrag sind folgende Teilanforderungen durchzufuhren:¨

• Die OSGi-Service-Platform bildet die Kernkomponente von openHAB: Neben Funktions- weise und Architektur des OSGi-Framework sind benötigte und umgesetzte Plattform- Restriktionen in openHAB zu klären. • Fur¨ das realitätsnahe Szenario sollen hinreichende Hardwarekomponenten und Software erarbeitet werden, die im Zusammenhang mit dem Oberbegriff der Bewegungserkennung von Personen stehen. Eine anschließende Realisierung der Installation ist obligatorisch. • Des Weiteren soll die Implementierung beim Einsatz von openHAB fur¨ das Szenario verwirklicht und die Gute¨ der Bewegungserkennung bei variierender Parametrisierung analysiert werden.

1.2 Zielsetzung

Das Ziel des vorliegenden Projektes ist es, eine herstellerubergreifende¨ L¨osung fur¨ das Anwen- dungsszenario der Bewegungserkennung von Personen im Rahmen der GA und HA beim Einsatz

2 1 Einleitung von openHAB auszuarbeiten. Außerdem ist die eingesetzte Hard- und Software zur Umsetzung des Szenarios im Hinblick auf mögliche auftretende Fehler in der Erkennung zu validieren. Ab- schließend sollen die gewonnenen Erkenntnisse in Abgrenzung zu weiteren Lösungsansätzen analysiert werden.

1.3 Vorgehensweise

In Kapitel 2 - ”Die OSGi-Service-Platform” wird neben einer allgemeinen Vorstellung der OSGi- Service-Platform das OSGi-Framework vorgestellt. Fokus liegt hier sowohl auf der Struktur und dem Aufbau der Framework Module als auch deren Services und Kommunikation untereinan- der. Im Abschluss des Kapitels wird auf konkrete Implementierungen des OSGi-Standards hingewiesen. Im Kapitel 3 - ”openHAB” wird das Softwareprodukt openHAB, in Hinblick auf die zugrundeliegende Softwarearchitektur als auch die Umsetzung der notwendigen Paradig- men des OSGi-Frameworks, analysiert. Aufbauend auf den Erkenntnissen der Kapitel 2 und 3 stellt Kapitel 4 - ”Bewegungserkennung von Personen” das Szenario vor. Dazu wird neben dem Realitätsbezug auch die verwendete Hard- und Software näher betrachtet und eine an- schließende Durchfuhrung¨ stellt das Proof of Concept dar. Die Ergebnisse werden im Anschluss in Kapitel 5 - ”Ergebnisse und Alternativen” genutzt um die eingesetzten Technologien gegen alternative Lösungsansätze abzugrenzen. Das Kapitel 6 - ”Zusammenfassung und Fazit” weist, neben abschließenden Worten, auf Forschungsgebiete im Zusammenhang mit der HA und GA hin, deren Thematik weitere wissenschaftliche Arbeiten befurworten.¨

3 2 Die OSGi-Service-Platform

In diesem Kapitel wird ein Uberblick¨ der ”OSGi-Service-Platform” präsentiert. Aufgrund des umfangreichen OSGi-Standards, der von der OSGi-Alliance (Non-Profit-Organisation - Grundung¨ März 1999) entwickelt und verbreitet wird [Web+10, S. 30], greift dieses Kapitel lediglich die Hauptbestandteile des Release 4 in Version 4.3 der OSGi-Service-Platform auf. Die Dokumen- tation des Standards teilt sich in die ”OSGi Service Platform Core Specification” und das ”OSGi Service Platform Service Compendium” auf. Erstere beinhaltet neben den zentralen Bestandteilen des OSGi-Framework - die in diesem Kapitel näher betrachtet werden - auch die ”OSGi Service Platform Mobile Specification”, die speziell fur¨ mobile Endgeräte definiert ist [vgl. Web+10, S. 29; Wut08,¨ S. 15 f.]. Letztere beinhaltet die Spezifikationen der Standard- Services von OSGi wie zB. der Log-, Http-, IO Conntector- und der JNDI-Service [All15d]: Die OSGi-Service-Platform ist demnach eine quelloffene Software-Architektur deren Augen- merk auf der Verwaltung, Entwicklung und Kommunikation von bzw. zwischen Services liegt. OSGi ist zwar durch die Spezifizierung auf der JVM (Software-Platform - Java Virtual Ma- chine) nicht sprachunabhängig, jedoch plattformunabhängig und erfreut sich deshalb großer Beliebtheit und Anwendung rund um das Smartphone, den Automobilbereich, der Unterhal- tungselektronik, reinen Desktop-Applikationen aber auch serverseitige Anwendungen und vor allem der HA [vgl. Web+10, S. 1 f.; Wut08,¨ S. 14 f.] - auf konkrete Implementierungen von OSGi wird im Abschnitt 2.3 eingegangen. Der Vorteil und damit auch die Befurwortung¨ zur Nutzung des OSGi-Framework liegt in der Beurteilung als bestbewertetes dynamisches Modulsystem im Vergleich zu Laufzeitsystemen, wie z. B. ”DDL/COM” und ”Shared Librari- es” [Fil12, S. 68 ff.]. Die fur¨ die Bewertung betrachteten Kriterien behandeln dazu sowohl den Aufbau bzw. die Struktur als auch die Umsetzung der Bestandteile, die fur¨ eine korrekte Modu- larisierung, also das Brechen der Komplexität einer Software durch Dekomposition in Module, nötig sind [vgl. Fil12, S. 67 f.; Wut08,¨ S. 16 f.]. Das sind zum einen die Module und Services und zum anderen die Registry und Versionierung eines Frameworks. Der folgende Abschnitt 2.1 behandelt die Komponenten, die OSGi als dynamisches Modulsystem kennzeichnen.

4 2 Die OSGi-Service-Platform

2.1 OSGi-Framework

Das OSGi-Framework ist eine Laufzeitumgebung die einen Container fur¨ die Softwarekom- ponenten (Module und Dienste) bereitstellt. Neben diesen Komponenten enth¨alt das Frame- work den MA (Management Agent) als zentrale Verwaltungsstelle, dessen Hauptaufgabe die Uberwachung¨ des Lebenszykluses der Module und deren Dienste ist [Wut08,¨ S. 12 f.] - Der Lebenszyklus wird in Abschnitt 2.2 behandelt.

Das Modul als abgeschlossene Einheit der Software ist im OSGi-Framework mit dem Begriﬀ Bundle gleichzusetzen und wird in Abschnitt 2.1.1 beschrieben. In Abschnitt 2.1.2 sind die Services, die zur bundle-ubergreifenden¨ Kommunikation verwendet werden, charakterisiert.

Gr¨oßere Softwareprodukte tendieren mit der Zeit dazu, dasss ihre innere Struktur mehr einem Irrgarten ¨ahnelt als einer geplanten Entwicklung. Das wird allgemein als ”Architecture Erosion” bezeichnet [Fil12, S. 59].

Um der ”Architecture Erosion” bereits zu Beginn der Entwicklung entgegenzuwirken, nutzt das Framework zur Kopplung der Bundles neben statischen auch dynamische transitive Abhängig- keiten, die in Abschnitt 2.1.1.2 erörtert werden. Im Anschluss daran zeigt der Abschnitt 2.2 das Schichtenmodell des OSGi-Framework das von den Services bis zum Betriebssystem definiert ist. Als Abschluss dieses Kapitels (Abschnitt 2.3) werden sowohl zertifizierte Produkte als auch Open-Source-Lösungen, die konkrete Implementierungen des OSGi-Framework darstellen, genannt. Der Fokus liegt auf der Vorstellung der ”Eclipse Equinox”, die als Kernkomponente der openHAB-Software anzusehen ist.

2.1.1 Bundles

Wie bereits erwähnt, ist ein Bundle mit dem Begriff Modul gleichzusetzen und beinhaltet neben Java-Archiven, Java-Klassen und anderen Ressourcen (z. B. Icons als Bilder) ein Manifest, in dem ergänzende Metadaten aufgelistet sind [All15c, S. 25] - was ein Bundle letztendlich auch als ein Java-Archiv kennzeichnet [vgl. Fil12, S. 72 f.; Web+10, S. 16 ff.]. Nach [Web+10, S. 126] ist die Migration von jedem konventionellen Java-Archiv in ein OSGi-Bundle möglich. In einem bundle-zugehörigen Manifest ist beschrieben, welche externen Archive das Bund- le benötigt (import), bzw. ob es seine Funktionalität anderen Bundles zur Verfugung¨ stellt (export). Damit ein Bundle die benötigten Abhängigkeiten aufschlusseln¨ kann, erhält es vom OSGi-Framework-Container einen eigenen Class-Loader der die benötigten Java-Archive bzw. Java-Klassen sowohl aus dem Boot- und Framework-Class-Path als auch aus dem Bundle- Space nachladen kann. Die Gesamtheit aller Class-Loader wird als ”Class Loading-Delegation- Netzwerk” bezeichnet [vgl. Fil12, S. 74 f.,138; Web+10, S. 6]. Grundsätzlich unterscheidet die Spezifikation drei Arten von Bundles:

5 2 Die OSGi-Service-Platform

• Requiring Bundles [All15c, S. 66 ff.] - Requiring Bundles setzen eine direkte Kom- munikation bzw. Verbindung mit dem Require-Mechanismus um und werden in Ab- schnitt 2.1.1.2 detaillierter beschrieben. Der Einsatz des Mechanismus birgt die Gefahr von statischen Abhängigkeiten zwischen Bundles. • Fragment Bundles [All15c, S. 69 ff.] - Bundles, die von der Laufzeitumgebung des Frameworks einem oder mehreren ”Host”-Bundles zugewiesen werden - z. B. ein Sub- Jar-Archive, das nach Auflösung als Bestandteil des ”Host”-Bundles angesehen wird, jedoch keinen eigenen Class-Loader besitzen muss, wird Fragment Bundle genannt. • Extension Bundles [All15c, S. 72 f.] - Diese Bundles verwenden wie die Requiring Bund- les nicht den ”Import/Export”-Mechanismus (Abschnitt 2.1.1.2), sondern mussen¨ direkt dem Boot-Class-Path beigelegt werden. Zwar bieten diese Bundles framework-eigene Services an, wie z. B. den Permission Admin Service, sollten aber nicht fur¨ die Implemen- tierung anwendungsspezifischer Bundles verwendet werden, um statische Abhängigkeiten zu vermeiden.

Zudem ist das OSGi-Bundle von den IANA (Internet Assigned Numbers Authority) als gultiger¨ MIME-Type ”vnd.osgi.bundle” klassiﬁziert [Aut15].

2.1.1.1 Manifest

Das Manifest ”META-INF/MANIFEST.MF” beinhaltet eine Auﬂistung von Metainformatio- nen, die ein OSGi-Bundle individuell kennzeichnen. Zudem enth¨alt es Informationen fur¨ den Lebenszyklus und die verwendete Laufzeitumgebung [Fil12, S. 73].

1: Manifest-Version: 1.0 2: Bundle-Name: openHAB Core 3: Bundle-RequiredExecutionEnvironment: J2SE-1.5 4: Bundle-Vendor: openHAB.org 5: Bundle-Version: 1.7.0.qualifier 6: Bundle-Activator: org.openhab.core.internal.CoreActivator 7: Bundle-ManifestVersion: 2 8: Bundle-License: http://www.eclipse.org/legal/epl-v10.html 9: Bundle-SymbolicName: org.openhab.core 10: Bundle-DocURL: http://www.openhab.org

Quelltext 2.1: Manifest - Ausschnitt ”openHAB Core”

Der Quelltext 2.1 zeigt einen Ausschnitt des Manifestes der Kernkomponente von openHAB. Dabei ist ”SymbolicName” eine Pﬂichtangabe, die das Bundle, zusammen mit der Angabe der ”Version”, eindeutig bezeichnen - gleichbedeutend dazu die ”ManifestVersion”. Die Na- mensgebung folgt keiner direkten Konvention. Sollte die Namensgebung allerdings ”schwer”

6 2 Die OSGi-Service-Platform fallen, enthält das Bundle wahrscheinlich Funktionalität aus semantisch unabhängigen Berei- chen, wodurch dann die Paradigmen der OSGi-Schichtenarchitektur nicht eingehalten werden [Fil12, S. 137]. Mit ”RequiredExecutionEnvironment” wird die minimal benötigte Laufzeitum- gebung gekennzeichnet. Der openHAB-Core benötigt mindestens die Java Plattform in der Standard Edition Version 5. Aufgrund der Ruckw¨ ärtskompatibilität von Java können demnach auch höhere Versionen fur¨ den openHAB-Core genutzt werden [All15c, S. 35 f.]. Die Angabe ”Activator” dient dem MA, damit er weiß, welche Java-Klasse er verwenden muss, um das Bundle in den Lebenszyklus einzubinden. Die ”Activation Policy” gibt an, wie bzw. wann das Bundle gestartet werden soll [All15c, S. 91 ff.]. Ist sie ”lazy”, wird das Bundle erst geladen, wenn dessen Funktionalität abgerufen wird. Ist die ”Activation Policy” nicht angegeben, ist sie standardmäßig auf ”directive” gesetzt und das Bundle wird direkt beim Start der Laufzeitumgebung mit initialisiert. Fur¨ selbst-definierte Header-Angaben, die nicht dem OSGi-Namespace folgen, können diese mit dem Prefix ”x-” gekennzeichnet werden [All15c, S. 29]. Auf Header-Angaben, die fur¨ eine Kommunikation von Bundles benötigt werden, wird in Abschnitt 2.1.1.2 näher eingegangen - fur¨ Weitere sei auf die auf OSGi-Service-Platform Core Specification [All15c, S. 26-31] verwiesen.

2.1.1.2 Import, Export und Require

Neben den in Abschnitt 2.1.1.1 erwähnten, können die Header-Angaben ”Export-” und ”Import- Package” genutzt werden, um Abhängigkeiten zwischen den Bundles zu erzeugen. Um externe Funktionalitäten anderer Bundles nutzen zu können, kann das Bundle diese explizit in der Import-Anweisung auflisten. Umgekehrt wird die Export-Anweisung im Manifest angegeben, um die eigene Funktionalität anderen Bundles bereitzustellen [Fil12, S. 73]. Die Abbildung 2.1 zeigt die mit der Angabe von Import und Export geschaffenen Beziehungen der Bundles. Als Beigabe der Import-Anweisung kann optional eine Version mit Semikolon getrennt angegeben werden - standardmäßig wird die aktuellste Version vom MA geladen. Neben einer spezifischen Version können auch Version-Ranges durch die mathematische Intervall-Notation vermerkt werden [vgl. All15c, S. 29 f.; Fil12, S. 79; Web+10, S. 7]. Um statische Abhängigkeiten zu vermeiden, sollten Bundles fur¨ den Export nie die direkten Implementierungen weiterreichen, sondern nur solche Packages angeben, die ausschließlich Schnittstellen beinhalten: Das ”Class Filtering” ermöglicht die flexible Einschränkung der Sichtbarkeit von Bestandteilen des Bundles [All15c, S. 49 f.].

Bei der Verwendung von Import und Export greift der Standard-Resolving-Mechanismus des MA und verhindert gleichzeitig auch mögliche Zyklen in der Abhängigkeitskette der Bundles. Mit ”Require-Bundle” können Bundles direkt miteinander verbunden werden. Die mit Require geschaffenen statischen Beziehungen bergen Risiken, die den Standard-Resolving-Mechanismus umgehen und dadurch ”Split Packages”, ”Mutable Exports” und ”Shadowing” verursachen

7 2 Die OSGi-Service-Platform

[All15c, S. 68 f.]: Fur¨ eine dynamische Kopplung der Bundles ist somit der Import und Export zu bevorzugen.

Abbildung 2.1: Beziehungen zwischen Bundles [Fil12, S. 74]

2.1.2 Services

A service is a normal Java object that is registered under one or more Java interfaces with the service registry [All15c, S. 111]

OSGi-Services sind Instanzen von POJOs (Plain Old Java Objects) die durch die ”Bund- le Context”-Objekte von Bundles genutzt werden können, um eigene Services zu registrieren (bundleContext.registerService), fremde Services zu nutzen (bundleContext.getServiceReference und bundleContext.getService) oder sogar uber¨ mögliche Anderungen¨ der Services informiert zu werden (bundleContext.addServiceListener) [All15c, S. 111 f.]. Als zentrale und bundle- ubergreifende¨ Stelle dient die ”Service Registry” der Verwaltung der registrierten Services und regelt Anfragen oder Anderungen¨ der Services uber¨ ”Service Events”. Wie in Abbildung 2.2 dargestellt, ist es es anderen Bundles nach Instanziierung der Services möglich, auf die Schnitt- stelle zuzugreifen und dadurch die Funktionalität zu nutzen. Summa Summarum bedeutet dies:

OSGi l¨ost die Diskrepanz zwischen Komponenten und Diensten auf sehr elegante Weise: Ein Bundle entspricht nicht einem Service, sondern ein Bundle kann einen oder mehrere Services zur Verf¨ugung stellen [Web+10, S. 24].

Bei Verwendung von Import und Export erm¨oglicht das OSGi-Framework, mit den Services als Softwareartefakt, eine dynamische Kommunikation innerhalb der Bundles. Wenn in der

8 2 Die OSGi-Service-Platform

Entwicklung eine statische Kopplung mit ”Require” umgesetzt wird, sind die Vorteile der Ser- vices, ihrer Registry und die Reaktion auf Events mit den Listenern hinf¨allig [Fil12, S. 78 f.]. Einige der Events sind in Abbildung 2.5 dargestellt und sind speziell dem Lebenszyklus eines Bundles bzw. der Objektinstanz, dem Service, zuzuordnen. Alle ubrigen¨ Events sind den Kategorien von Fehlermanagement (z. B. ERROR, WARNING oder INFO) oder der erweiterten Package-Verwaltung (z. B. PACKAGES REFRESHED oder WAIT TIMEOUT) zugeordnet [All15c, S. 105 f.]. Der MA nutzt die Service-Registry, um auf Anderungen¨ zu reagieren bzw. diese einzuleiten - dazu mehr in Abschnitt 2.2.

Abbildung 2.2: Zusammenhang Bundles und Services [Fil12, S. 78]

Die OSGi-Service-Platform bietet ca. 20 Standard-Services fur¨ unterschiedliche Anwendungsf¨alle an. Im Folgenden sind die sechs interessantesten Services erw¨ahnt: [All15d]

• Log Service - Der Log-Service besteht aus zwei Services: Der ”LogService” erm¨oglicht das Aufzeichnen eines Protokolls (bestehend aus: Nachicht, Level, Fehlermeldung, Service- Referenz und dem Bundle-Objekt) und der ”LogReaderService” kann die Informationen der gespeicherten Protokolle abrufen [All15d, S. 5]. • HTTP Service - Der HTTP-Service erm¨oglicht dem Entwickler die Standard-Technologien, wie z. B. HTTP, HTML, XML und Servlets, zu nutzen. Dieser Service ist demnach ge- eignet, um das Abrufen oder Zusenden von Informationen durch den Anwendungsnutzer zu bewerkstelligen [All15d, S. 15]. • JDBC Service - Der JDBC-Service bietet eine Schnittstelle, um mittels JDBC (Ja- va Database Connectivity - Standard) mit relationalen Datenbanken zu kommunizieren [All15d, S. 701]. • JPA Service - Der JPA-Service dient der Persistenz von Objekten in einer Datenbank. Die JPA (Java Persistence API) bietet dazu die Technik des ORM (Object Relational Mapping) an [All15d, S. 727].

9 2 Die OSGi-Service-Platform

• IO Connector Service - Der IO-Connector-Service ist eine Kommunikationsinfrastruk- tur, die auf der Implementierung der J2ME (Java 2 Micro Edition) basiert: Notwendige Kommunikationen werden uber¨ den URI (Uniform Resource Identiﬁer) realisiert [All15d, S. 191].

Bis jetzt können die Bundles nur die Funktionalität von Services innerhalb ihrer Laufzeitumge- bung nutzen. Mit Einfuhrung¨ des OSGi-Standards 4.2 (März 2010) arrangiert der ”Remote Service Admin Service” die Konnektivität fur¨ ”Distributed Services” externer Laufzeitum- gebungen in einem Netzwerk [Web+10, S. 19 f.].

2.2 OSGi-Schichtenmodell

Ausgehend von den Begriﬄichkeiten der vorherigen Abschnitte sind die Zusammenh¨ange der Framework-Komponenten, wie in Abbildung 2.3 dargestellt, zu betrachten. Das OSGi- Framework als Basiskomponente der OSGi-Service-Platform ist in mehrere logische Schichten eingeteilt.

Abbildung 2.3: OSGi-Schichtenmodell [i.A.a. All15c, S. 2]

Die Schnittstelle einer logischen Schicht ist die Menge der exportierten Java-Interfaces der ihr zugeh¨origen Bundles [Fil12, S. 139].

Bundleschicht: Auch wenn in Abbildung 2.3 die Bundles als unabhängige Komponente eingezeichnet sind, so können sie dennoch auf jede logische Schicht zugreifen und von der Le- benszyklusschicht noch zusätzlich gesteuert werden - siehe Abbildung 2.4.

10 2 Die OSGi-Service-Platform

Abbildung 2.4: Interkation Bundles und Framework-Schichten [Web+10, S. 17]

Diensteschicht: Der Diensteschicht sind alle in Abschnitt 2.1.2 er¨orterten Komponenten zugeteilt. Fur¨ die Verwaltung und Nutzung der Services verwendet das OSGi-Framework das Publish-Find-Bind-Modell. Die Schnittstellen der Dienste sind Java-Interfaces [Web+10, S. 14 f.];

Lebenszyklusschicht: In der Lebenszyklusschicht wird der Lebenzyklus eines Bundles mit all seinen Zust¨anden festgelegt. Der MA reguliert bzw. manipuliert die Bundle-Zust¨ande.

Abbildung 2.5: Bundle-Lebenszyklus [i.A.a. All15c, S. 86]

11 2 Die OSGi-Service-Platform

Ein Bundle kann somit nach seiner Installation direkt wieder deinstalliert werden. Andern- falls folgt auf den INSTALLED-Zustand der RESOLVED-Zustand, von dem ausgehend der MA dann das Bundle startet und der Modulschicht als ACTIVE zur Verfugung¨ stellt. Das OSGi-Framework verwirklicht dadurch Hot Deployment - das Aktualisieren, Installieren und Deinstallieren von Bundles und Services w¨ahrend der Laufzeit.

Modulschicht: Der Modulschicht sind alle Objektinstanzen der Bundles hinterlegt. Zudem k¨onnen die vom Bundle ben¨otigten Klassen uber¨ den Class-Loader aus der Modulschicht geladen werden.

Sicherheitsschicht: Die Funktionalität der Sicherheitsschicht basiert auf der Java-2-Sicherheits- Architektur und ist in ”Fine-grained” (Die Umsetzung von Sicherheit wird von der Anwendung realisiert.), ”Manageable” (Die Tätigkeit wird an die Lebenszyklusschicht delegiert.) und ”Op- tional” unterteilt. Die OSGi-Service-Platform unterstutzt¨ die Authentifizierung von Programm- code nach Herkunft oder einer digitalen Signatur. Der Permission-Admin-Service verwaltet die Berechtigungen auf Basis von Location-Strings, dem Conditional-Permission-Admin-Service unterliegt ein umfangreiches Berechtigungsmodell [All15c, S. 11]. Die Sicherheitsschicht ist vertikal eingezeichnet um den schichten-ubergreifenden¨ Wirkungsgrad zu verdeutlichen.

2.3 OSGi-Implementierungen

Die OSGi-Service-Platform ist eine Ansammlung von Speziﬁkationen die ein Komponenten- system mit einer modularen Softwarearchitektur auf Basis der Programmiersprache Java be- schreiben [All15e]. Die OSGi-Allianz gruppiert ihre Teilnehmer in (1) ”Strategic Members”, (2) ”Principal Members”, (3)”Contributing Associates” und (4)”Supporters” [All15b].

Mitgliedschaft...

(1) mit Wahlrecht und Sitz im OSGi-Alliance Ausschuss, aktive Beteiligung an der Weiter- entwicklung der Spezifikationen und einer jährlichen Gebuhr¨ von USD $ 25,000. (2) mit Teilnahme an Experten-Zirkeln und einer jährlichen Gebuhr¨ von USD $ 20,000 (≥ 250 Beschäftigte) oder USD $ 10,000 (≤ 249 Beschäftigte). (3) ohne Sitz im Ausschuss oder Teilnahme an Zirkeln, mit technisch-unterstutzenden¨ Hin- tergrund und einer jährlichen Gebuhr¨ von USD $ 5,000 (4) mit der Berechtigung das Logo der OSGi-Alliance auf der firmeneigenen Website zu fuhren.¨

Um die Funktionalität der OSGi-Service-Platform nutzen zu können, sind mehrere Varianten denkbar. Eine Mitgliedschaft in der OSGi-Alliance mit eigener Realisierung und Implementie- rung der Spezifikationen und anschließender Zertifizierung des Softwareproduktes - intensiv in

12 2 Die OSGi-Service-Platform der Investition von Zeit und Finanzen, oder auf bereits zertiﬁzierte kommerzielle oder Open- Source L¨osungen zugreifen - eine Mitgliedschaft ist nicht notwendig.

2.3.1 Eclipse Equinox

Eine der bekanntesten Implementierungen des OSGi-Frameworks im Bereich der Desktop- Applikationen ist die Eclipse Equinox - in der Version 3.2 fur¨ die OSGi-Service-Platform R4 zertifiziert [All15a]. Fur¨ die Eclipse IDE (Integrated Development Environment) stellt die Eclip- se Equinox, neben Texteditoren, Compiler und Debuggern, eine Kernkomponente der Anwen- dung dar [Fou15d]. Equinox besitzt Eigenheiten, wie z. B. das Buddy-Class-Loading und die Extension Points, die in der OSGi-Spezifikation nicht vorgesehen sind [Web+10, S. 33]. Das Buddy-Class-Loading beschreibt einen Mechanismus der es Bundles ermöglich, mit Hilfe von Class-Loadern anderer Bundles, Java-Ressourcen zu binden, die der eigene Class-Loader nicht verknupfen¨ kann. Die Buddy-Policy beschreibt, fur¨ die Auswahl der ”Helfer-Bundles”, funf¨ Richtlinien [Fou15a]. Extension Points sind Bundle-Schnittstellen die nicht das Konzept der OSGi-Services umsetzen, sondern eigens dafur¨ Schnittstelleninformationen in einer XML-Datei festhalten [Fou15b].

2.3.2 Sonstige

Neben der Eclipse Equinox existieren noch weitere zertiﬁzierte L¨osungen [All15a]:

Kommerziell:

• Makewave Knopﬂerﬁsh Pro 3 (www.makewave.com) • ProSyst Software mBedded Server 7 (www.prosyst.com) • Hitachi Solutions SuperJ Engine Framework V4 (www.hitachi-solutions.com) • Samsung OSGi R4 Solution (www.samsung.com) • KT OSGi Service Platform (KOSP) 1.0 (http://www.kt.co.kr/)

Open-Source:

• Makewave Knopﬂerﬁsh (www.makewave.com) • Apache Felix Framework 3.0.0 (http://felix.apache.org)

13 3 openHAB

Mit openHAB bietet die openHAB UG (haftungsbeschränkt) - Firmengrundung¨ am 06.01.2014, Grundungsmitglieder:¨ Kai Kreuzer, Thomas Eichstädt-Engelen und Victor Belov - eine Soft- warelösung fur¨ die GA und HA an, deren Hauptziel eine herstellerubergreifende¨ Kopplung von Hard- und Software ist. Die openHAB UG ist Mitglied der EnOcean Allicance, AllSeen Alliance und Eclipse Foundation. Durch den Einsatz der Programmiersprache Java ist openHAB nicht nur plattformunabhängig, sondern kann durch die Verwendung von der Eclipse Equinox auf die dem OSGi-Framework (Abschnitt 2.1) zugrundeliegende Softwarearchitektur zuruckgreifen¨ [Uh15e]. Aus Sicht des Endanwenders verfolgt openHAB das Prinzip des ”Intranet Of Things” - alle Endgeräte sind im eigenen Netzwerk verbunden und fur¨ den lokalen und externen Zugriff durch eine Firewall abgesichert. Die historische Entwicklung von openHAB ist wie folgt zu sehen:

Trotz seiner Erfahrungen mit MisterHouse (Open-Source Home Automation Software (Perl)) [Con15] fur¨ die Steuerung seiner KNX-Komponenten, entscheidet sich Kai Kreuzer im No- vember 2009 zur Entwicklung einer eigenen Softwarel¨osung fur¨ die HA unter dem Namen ”SmartKNX” - wegen evtl. Markenrechtsverletzungen ab Februar 2010 fortan openHAB genannt. Er entscheidet sich zudem explizit gegen eine Projektbeteiligung und Weiterentwick- lung der OpenRemote (Open Source Automation Platform) [Inc15c]: Seiner Meinung nach, ist durch die dort fortgeschrittene ”Architecture Erosion” die Umsetzung einer zukunftsweisen- den Softwarearchitektur nur durch einen ”Rewrite” des Programmcodes zu bewerkstelligen. Fur¨ das Build-Management von openHAB wird Maven (Software fur¨ den Erstellungsprozess von Softwareprodukten) in der Version 3 und das Plugin ”Tycho” verwendet. Drools (Ru- le Management System Solution der JBoss Community) wird anf¨anglich als ”Rule Engine” eingesetzt und im Mai 2012 durch eine Kombination aus dem Quartz-Framework, der Xbase (Expression Language fur¨ Java implementiert in Xtext) und der Joda-Time Bibliothek ersetzt [Kre15].

Looking back at this evolution of the project, I am perfectly sure that if I had designed openHAB as a normal Java application instead of an OSGi application, it would not have prospered as it did. It is really the choice of the software architecture that made it happen [...] [Kre15, 17. Dezember 2012].

14 3 openHAB

Zu dem Zeitpunkt der von Kai Kreuzer getroffenen Aussage, weist openHAB bereits eine zwei- einhalbjährige Entwicklung (Release Version 1.0) auf und mit dem Release Version 1.2 (April 2013) veröffentlicht die openHAB UG sämtliche Implementierungen zur Kopplung der HA- Produkte von HomeMatic, Philips Hue, DMX und Kouchbachi. Noch im selben Jahr folgen Implementierungen fur¨ Z-Wave, EnOcean, Fritz AHA und Tinkgerforge. Mit dem Entwick- lungszweig (Release Versionen 2.x) verfolgt openHAB den ”User Comfort”, also vorwiegend die Gebrauchstauglichkeit der Software - als Teildisziplin der UX [Kre15]. Die Analyse der Architektur und Programmcode in den Folgeabschnitten basiert auf dem openHAB Release Version 1.6.

3.1 Architektur

Die Abbildung 3.1 zeigt die Softwarearchitektur von openHAB und ist in drei Sektionen unterteilt: Die Komponenten des OSGi-Frameworks (grun),¨ die Kernkomponenten (blau) und die Erweiterungen (gelb) von openHAB.

Abbildung 3.1: openHAB Architektur [Uh15i, i.A.a.]

3.1.1 OSGi-Framework Komponenten

OSGi Runtime: Das Fundament der openHAB-Software in der Version 1.6.2 stellt die Eclip- se Equinox in der Version 3.8.2 (04.02.2013) und die zugeh¨origen Services in der Version 3.3

15 3 openHAB dar. Damit alle anderen Architektur-Komponenten die Programmierparadigmen des OSGi- Standards berucksichtigen,¨ stellt jede Komponente eine Plug-in Abh¨angigkeit zur Eclipse Equinox und den Services her. Mit der Equinox bietet Eclipse nicht nur ein Framework fur¨ den OSGi-Standard an, sondern verwirklicht eine Laufzeitumgebung mit folgenden Funktiona- lit¨aten [Uh15m, Kreuzer K. et al.]:

• Die Bereitstellung einer Konsole sowohl fur¨ die Eingabe und Interpretation von Kom- mandos als auch die Ausgabe von Informationen. • Die Darstellung allgemeiner Statistiken und Informationen zu aktivierten Bundles und die vom Class-Loader geladenen Klassen. Zudem bietet das Package ”runtime.internal.stats” den Haupteinstiegspunkt fur¨ die Protokollierung der Bundle-Aktivitäten. Der ”StatsMa- nager” verbindet die Informationen der Bundles ohne die Bundle-Registry zu beeinflussen. • Die Verwaltung von Berechtigungen und Erweiterungen fur¨ die Protokollierung der Bundle-Aktivitäten. Eine Protokollierung in Abhängigkeit einzelner Berechtigungen ist dadurch realisierbar. • Das Aufstellen einer Trace fur¨ eine evtl. Fehlerbeseitigung. • Das Einhängen von zusätzlichen Funktionen mittels der Hook-Registry und der Verwal- tung der Hooks durch den Hook-Konfigurator (osgi.baseadapter). • Einen Event-Manager der mit den Event-Listeners die eintreffenden Events abarbeiten kann. • Und weitere Dienstprogramme wie z. B. die Handler von Streams und Multiplexern oder Parser fur¨ einzelne Manifest-Elemente (”internal.core” oder ”osgi.util”).

Von den ca. 20 Standard-Services des OSGi-Standards verwendet die openHAB-Software die folgenden funf¨ Services:

Declarative Services: Mit den ”Declaratice Services” stellt der OSGi-Standard ein ”publish- find-bind”-Modell fur¨ die Verwendung der Dienste zur Verfugung.¨ Mit dem Modell können Applikationen erstellt werden, die das Arbeiten und die Kommunikation der Bundles unterein- ander realisieren. Dabei simplifizieren die ”Declarative Services” die Verwaltung der Dienste indem sie die Registrierung und Abhängigkeiten von anderen Diensten ubernehmen.¨ In dem Modell ubernimmt¨ die ”Service Component Runtime” die Instanziierung der ”Components” und die Kontrolle der ”Component Configuration(s)” [All15d, S. 245 f.]. Die einzelnen Klassen bzw. Schnittstellen fur¨ dieses Modell sind in den Packages ”org.osgi.service.component” und ”org.osgi.service.component.annotations” wiederzufinden.

Zwar importieren die Action-, Binding- und Core-Komponenten der openHAB-Software die ”Declarative Services” durch die Import-Package Angabe in ihrem Manifest, dennoch nutzt nur die Twitter-Action, das IHC (Intelligent Home Control) -, KNX-, PulseAudio- und das Withings-Binding und die Core-Komponente den ”ComponentContext” um die Services zu (de-

16 3 openHAB

)aktivieren und eine Protokollierung vorzunehmen. Alle ubrigen¨ Komponenten implementieren nur den ”Conﬁguration Admin Service”.

Logback/SLF4J: Der ”Logback/SLF4J” - Dienst ist in [All15d, S. 5 f.] unter der Bezeich- nung ”Log Service” wiederzufinden und wird bereits in Abschnitt 2.1.2 erörtert. Die Klasse ”OSGILogListener”, als Bestandteil der Core-Komponente, implementiert den ”LogListener” und ”LogReaderService” und dient als Adapter um die Protokolleinträge an die SLF4J (Simple Logging Facade for Java) zu delegieren [QOS15].

1: private static class NLogListener implements LogListener { 2: public void logged(LogEntry entry) { 3: Logger logger = LoggerFactory.getLogger("OSGi"); 4: Marker marker = MarkerFactory.getMarker(entry.getBundle(). getSymbolicName()); 5: switch(entry.getLevel()) { 6: case LogService.LOG_DEBUG: logger.debug(marker, entry. getMessage(), entry.getException()); break; 7: case LogService.LOG_INFO: logger.info(marker, entry. getMessage(), entry.getException()); break; 8: case LogService.LOG_WARNING: logger.warn(marker, entry. getMessage(), entry.getException()); break; 9: case LogService.LOG_ERROR: logger.error(marker, entry. getMessage(), entry.getException()); break; 10: } 11: } 12: }

Quelltext 3.1: Ausschnitt - OSGILogListener.class - Delegation an den SLF4J-Logger [Uh15m, Kreuzer K.]

Event Admin: Der ”Event Admin Service” erm¨oglicht die Kommunikation zwischen Bund- les auf Grundlage eines ”Event-Publish-Subscribe”- Modells. Fur¨ die Kommunikation sendet der ”Event Publisher” mithilfe des ”Event Admin Service” einen Event an den ”Event Handler” der wiederum das Event an den ”Event Comsumer” weiterleitet [All15d, S. 295 f.]. In der openHAB-Software implementiert die Core-Komponente in der ”EventPublisherImpl”- Klasse einen solchen ”Event Publisher” der dann mit dem ”Event Admin Service” und der ”sendEvent”-Methode das Event fur¨ den speziﬁschen ”Event Comsumer” (Binding) ausruft [Uh15m, Kreuzer K.]. Um ein Bindung als ”Event Consumer” zu deklarieren, muss neben dem Import im Manifest auch die Referenz zum ”Event Publisher” in der XML-Datei des ”OSGI-INF” Ordner angegeben werden.

Das ”Event-Publish-Subscribe”- Modell ist somit exakt einmal in der openHAB-Software implementiert: Die Core-Komponente stellte eine zentrale Broadcast-Einheit dar und leitet die

17 3 openHAB eintretenden Ereignisse an die Bindings weiter. Die openHAB UG tituliert dieses Modell und dessen Implementierung als ”openHAB Event Bus” [Uh15i].

Configuration Admin: Der ”Configuration Admin Service” ermöglicht die Konfiguration von installierten ”ManagedService(s)”. Damit notwendige Anderungen¨ in der Konfiguration eines ”ManagedService” bereits vor Aktivierung durch den MA vorliegen, reagiert der ”Configu- ration Admin Service” sofort auf eingehende Kommandos [All15d, S. 57]. In der openHAB- Software ist der ”Configuration Admin Service” als eigenständiges Binding (configadmin) in der Klasse ”ConfigAdminBinding” implementiert. Bei Aufruf der ”bindingChanged”-Methode wird die Konfiguration fur¨ den entsprechenden ”ManagedService” angepasst [Uh15m, Eichstädt- Engelen T.]. Als ”ManagedService” sind in der openHAB-Software alle Bundles (Action, Binding, Persistence, etc.) gekennzeichnet, die die Service-Schnittstelle in der XML-Datei im ”OSGI-INF” Ordner und im Manifest auflisten und zudem die ”updated”-Methode der ”ManagedService”-Schnittstelle implementieren.

HTTP Service: Der ”HttpService” wird uberall¨ dort eingesetzt wo die Bundles die Stan- dardtechnologien wie z. B. HTTP, HTML, XML oder Servlets nutzen m¨ochten. Der ”HTTP Service” registriert mit dem ”HttpContext” die Servlets, in denen dann auf den geforderten ”Request” ein ”Response” folgt [All15d, S. 15 f.]. In der openHAB-Software wird der ”HTT- PService” prim¨ar in der Klasse ”RESTApplication” des REST-Bindings umgesetzt [Uh15m, Kreuzer K.]. Fur¨ die Realisierung nutzt openHAB den Web-Server und Servlet-Container von Jetty in der Version 8.1.3 [Fou15c] und das Jersey Framework fur¨ die RESTful Web-Services in der Version 2.2.5 [Cor15] ein. Neben dem REST-Binding implementiert z. B. das Weather- Binding den ”HttpService” und nutzt den Servlet-Container um die Wetterinformationen dar- zustellen.

3.1.2 openHAB Kernkomponenten openHAB Core: Der ”openHAB Core” ist die Kernkomponente der openHAB-Software und implementiert den ”Event Admin Service” um eingehende Ereignisse weiterzuleiten und eine Kommunikation der Bundles zu ermöglichen. Neben dieser Kernfunktionalität bietet der ”open- HAB Core” die Dienste an, die es Bundles erlauben selbst auf eingehende Events zu reagieren, z. B. das Wake-on-Lan-Binding sendet bei Ausfuhrung¨ der ”receiveCommand”-Methode das zum ”Wecken” entfernter Clients notwendige Paket. Ein weiterer Dienst ist die ”ItemRegis- try”. Sie dient als zentrale Stelle um die Items (Elemente aktiver Bundles) und ihre Status in einer ”ConcurrentHashMap” im fluchtigen¨ Speicher der Laufzeitumgebung abzulegen. Die Items können hinzugefugt,¨ initialisiert und aus der Registry entfernt werden.

Neben den oben und in Abschnitt 3.1.1 genannten Realisierungen der OSGi-Services bietet der openHAB-Core weitere Features an [Uh15m, Kreuzer K. et al.]:

18 3 openHAB

• Der ”PersistenceManager” dient der persistenten Speicherung der Items und deren Sta- tus in Verbindung mit einer Datenbank-Software (z. B. db4o, rrd4j, mysql und mongodb) [Uh15n]. • Das ”AutoUpdate”-Feature ermöglicht es Bundles automatisch auf eingehende Ande-¨ rungen zu reagieren (openhab.core.autoupdate). • Der ”SchedulerActivator” ist eine Erweiterung des OSGi-Bundle-Activator der in Ver- bindung mit dem Bundle-Context steht. Um geplante Jobs rechtzeitig oder in gewissen Zeitabständen abzuarbeiten, verwendet die openHAB-Software den Quartz-Scheduler in der Version 2.1.7 [Inc15e] • Die openHAB-Skripte sind wiederverwendbare Zusammenstellungen von openHAB-Regeln und werden in Abschnitt 3.4.1 beschrieben. Um diese Skripte auszufuhren¨ stellt der openHAB-Core eine Script-Engine zu Verfugung¨ (openhab.core.scriptengine). Da die openHAB-Skripte in Xtend (flexibler und expressiver Dialekt von Java) geschrieben sind, verwendet der openHAB-Core zur Komposition und dem Parsen der Skripte das Xtext- Framework in der Version 2.3.0 [Uh15q]. • Letztendlich bietet der openHAB-Core neun unterschiedliche Transformation-Services an, um eingehende Dokumenttypen zu verarbeiten (z. B. JavaScript, JSonPath, Map, RegEx, XPath oder Xslt). openHAB Base Library: Zu der ”openHAB Base Library” gehören alle Funktionalitäten die unter dem openHAB-Core als Features aufgelistet sind. Zwar liegt in der Darstellung der Architektur eine Trennung zwischen diesen beiden Komponenten vor, programmatisch sind diese Features jedoch als Subpakete des openHAB-Core aufzufassen. openHAB Repository: In [Uh15i] wird das ”openHAB Repository” als Softwarekomponente beschrieben, die mit dem ”openHAB Event Bus”, der ”Automation Logic” und dem ”User Interface” interagiert. Das ”openHAB Repository” ist eine Schnittstelle die in der openHAB- Software als ”ModelRepository” wiederzufinden ist (org.opehab.model.core). Neben einer Im- plementierung im REST-Binding ist das ”ModelRepository” im ”PersistenceManager” und den Klassen zur Erzeugung der Benutzeroberfläche (org.openhab.ui) realisiert. openHAB REST Service - Der ”openHAB Rest Service” ist das REST-Binding (openhab.io.rest) welches den OSGi-HTTP-Service implementiert.

3.1.3 openHAB Erweiterungen openHAB Add-on Libraries: Da in [Uh15i] keine weiteren Informationen vorliegen, welche Komponenten der openHAB-Software den ”openHAB Add-on Libraries” zugeh¨orig sind, ist an- zunehmen, dass die nach dem Ausschlussverfahren verbleibenden Bundles (org.openhab.io.*) den erweiterten Bibliotheken zuzuordnen sind [Uh15m, Kreuzer K. et al.]:

19 3 openHAB

• .console - Eine Schnittstelle fur¨ eine Konsole die mithilfe des Interpreters einfache Kom- mandos (items, send, update, status, say und >) umsetzt. • .cv - Hier sind alle Schnittstellen der Web-basierten Echtzeitvisualisierung ”CometVisu” wiederzufinden [May15]. • .dropbox - Ermöglicht die Nutzung des Filehosting-Dienst ”Dropbox”. Zur Realisierung wird das Dropbox Core SDK (Software Development Kit) in der Version 1.7.3 verwendet [Inc15a]. • .gcal - Es können Google Kalender Einträge heruntergeladen und dazu genutzt werden um mit dem Quartz-Scheduler die relevanten Aktionen durchzufuhren¨ [Uh15f] • .gpio - Eine Implementierung des Linux GPIO Frameworks [Uh15g]. • .multimedia.* - Hierunter fallen die TTS (Text-To-Speech) Dienste wie z. B. der Google Translate Service, die PlainTalk fur¨ Mac OS und MaryTTS die genutzt werden können um openHAB mit der eigenen Stimme zu kontrollieren [Uh15c]. • .net - Dieses Paket enthält Realisierungen um z. B. in openHAB-Skripten die Konsolen- Kommandos oder einen HTTP-Request auszufuhren.¨ • .servicediscovery - Eine Realisierung des Netzwerkprotokoll mDNS (multicast Domain Name System) bei Verwendung der JmDNS Implementierung in der Version 3.4.1 [JmD15]. • .squeezeserver - Der Squeezeserver regelt die Kommunikation zwischen der openHAB- Software und den Netzwerk-Musikplayern ”Squeezebox” [Uh15r]. openHAB User Interfaces: Grundsätzlich bietet die openHAB UG sowohl Mobile- als auch Desktop-UIs (User Interfaces) an. Zu den Mobile-UIs existieren fur¨ die Betriebssysteme Andro- id, iOS und Windows Phone eigenständige Applikationen. Fur¨ die Standard-Desktop-UI wird das WebApp.Net Framework eingesetzt, ansonsten kann eine UI auch als GreenT (Sencha Ja- vaScript Framework) oder mit CometVisu gestaltet werden [Uh15s]. Um die Gestaltung der UI fur¨ den Endanwender möglichst einfach zu halten, wird die Konfiguration uber¨ die deklarativen UI-Definitionen der Sitemaps realisiert. Die Sitemaps sind wie die Skripte in Xtext geschrieben [Uh15d]. Fur¨ die Darstellung bzw. Ubertragung¨ der Dokumente an die Clients wird der Servlet-Container des Webservers ”Jetty” in der Version 8.1.3 [Fou15c] verwendet. openHAB Automation Logic: Als die ”openHAB Automation Logic” ist ein Zusammenspiel der Script-Engine und der Scheduler zu bezeichnen. Also die Verarbeitung der openHAB-Regeln bzw. openHAB-Skripte bei Verwendung des Quartz-Scheduler. Obwohl Kai Kreuzer anfänglich dieses Zusammenspiel als die perfekte Funktionseinheit tituliert, ...

Xtext + Xbase + Quartz + Joda Time = Perfect Rule Engine [Kre15, 20. Mai 2012].

... stehen fur¨ die openHAB-Software Versionen 2.x die IFTTT (If This Then That) Rezepte als alternative Nutzung zu Auswahl [Inc15b]:

20 3 openHAB

Its vision is to make rule (or parts of them) easily sharable and reusable by others. Again, this should empower average users to set up automation logic through simple UIs - think of something like IFTTT. [Kre15, 24. November 2014] openHAB Protocol Bindings: Ein ”openHAB Protocol Binding” ist eine konkrete Imple- mentierung eines OSGi-Bundles fur¨ eine Technologie bzw. ein Protokoll. Derzeitig verfugt¨ die openHAB-Software uber¨ mehr als 120 Bindings. Repr¨asentativ fur¨ die Umsetzung namhafter Protokolle steht das DMX-, EnOcean-, FritzBox-, FS20-, HomeMatic-, Hue-, KNX-, Koubachi- , SamsungTV-, XBMC- und ZWave-Binding [Uh15i]. Exemplarisch soll die Implementierung des Hue-Binding genauer betrachtet werden.

Abbildung 3.2: UML-Klassendiagramm des Philips Hue-Bindings

Die Abbildung 3.2 zeigt das UML-Klassendiagramm des Philips Hue-Bindings. Aufgrund der Komplexität sind in dem Diagramm keine Attribute oder Methoden dargestellt. Die ”HueBinding”- Klasse ist die zentrale Komponente des Bindings. Sie verwirklicht die Schnittstellenfunktiona- lität des ”HueBindingProvider” und des ”ManagedService” um die registrierten Hue-Items (Lampen) aufzulisten und auf mitgeteilte Anderungen¨ der Konfiguration durch den ”Configu- ration Admin Service” zu reagieren. In der ”HueBinding”-Klasse interpretiert die ”execute”- Methode die eingehenden Events (Licht an/aus, Lichtintensität, Farbe), informiert den ”Event Publisher” und nimmt die Anderungen¨ an der Konfiguration vor [Uh15m, Hartmann R., Sche- ring J.]. Der folgende Quelltext zeigt einen Ausschnitt der ”execute”-Methode indem die Lichtintensität einer Lampe reguliert wird.

1: ... 2: if (deviceConfig.getType().equals(BindingType.brightness)) { 3: if ((bulb.getIsOn() == true) && (bulb.getIsReachable() == true)){

21 3 openHAB

4: // Only postUpdate when bulb is on, otherwise dimmer item is not retaining state and shows to max brightness value 5: PercentType newPercent = new PercentType((int)Math.round(( bulb.getBrightness() * (double)100) / (double)255)); 6: if ((deviceConfig.itemStatePercentType == null) || ( deviceConfig.itemStatePercentType.equals(newPercent) == false)){ 7: eventPublisher.postUpdate(hueItemName, newPercent); 8: deviceConfig.itemStatePercentType = newPercent; 9: } 10: } 11: ...

Quelltext 3.2: Ausschnitt der ”execute”-Methode der ”HueBinding”-Klasse [Uh15m, Hartmann R., Schering J.]

Vor der Ausfuhrung¨ des Events ist eine Plausibilitätsprufung¨ der ”HueSettings” vorangestellt, die möglichen Aufschluss uber¨ eine fehl-konfigurierte bzw. nicht initialisierte Hue-Bridge gibt. Ein Objekt der ”HueBulb”-Klasse stellt eine konkrete Lampe dar und bietet zahlreiche Metho- den an, um die Lampen-Parameter einzustellen oder auszulesen. Die ”SsdpDiscovery”-Klasse wird dazu verwendet, die IP-Adresse der Hue-Bridge aufzulösen. Die ”HueActivator”-Klasse ist eine Implementierung des OSGi-Bundle-Activator und stellt eine Protokollierung fur¨ die ”start”- und ”stop”-Methode des Bundle-Lebenszykluses dar [Uh15m, Hartmann R., Schering J.]. openHAB Item Provider: Der openHAB-Core bietet die ”ItemProvider”-Schnittstelle an, die in der ”GenericItemProvider”-Klasse implementiert wird. Der ”openHAB Item Provider” kann Items aus den Konfigurationsdateien (*.items) erstellen, in der Item-Factory abspeichern und verwalten. Neben logischen Verknupfungen¨ (AND, OR, NAND und NOR) kann der ”openHAB Item Provider” auch einige Aggregatfunktionen (AVG, SUM, MIN und MAX), fur¨ Items die einer Gruppe angehören, ausfuhren¨ [Uh15m, Kreuzer K., Eichstädt-Engelen T.].

3.2 openHAB Runtime

Der ”openHAB Runtime” werden in [Uh15i] alle in Abschnitt 3.1 beschriebenen Komponenten der Architektur zugeordnet. Um dem Endanwender eine ausfuhrbare¨ Software fur¨ die Betriebs- systeme Windows, Mac OS X und Linux anzubieten, wird die Build-Management Software Maven 3 eingesetzt. Dabei wird die Versions- und Abh¨angigkeitsverwaltung der Bundles in den XML-Files (pom.xml) festgelegt [Kre15, 27. April 2008]. Letztendlich steht dem Endanwender

22 3 openHAB eine Software zu Verfugung¨ die er in den in [Uh15h] beschrieben Schritten auf seinem Be- triebssystem installieren kann. Die dort aufgefuhrten¨ Addons sind die Jar-Archive der Bindings und mussen¨ explizit vom Endanwender installiert und konﬁguriert werden. Fur¨ den schnellen Einstieg bietet die openHAB UG einen Demo-Setup inklusive Sitemap und Items an.

3.3 openHAB Designer

Der ”openHAB Designer” ist eine Eclipse RCP (Rich Client Platform) Desktop-Applikation die fur¨ die Konfiguration der ”openHAB Runtime” genutzt werden kann. Die Funktionalität der Applikation ist zu vergleichen mit der eines einfachen Text-Editors der zusätzlich eine Syntaxuberpr¨ ufung,¨ Syntaxhervorhebung und Autovervollständigung fur¨ die Sitemaps, Items, Skripte und Regeln anbietet [Uh15i].

3.4 Automation

Die in Abschnitt 3.1.3 getroﬀenen Aussagen zur ”openHAB Automation Logic” sollen durch eine Betrachtung der Umsetzung von Skripten, Regeln und Aktionen weitergehend verdeutlicht werden.

3.4.1 Regeln, Skripte und Aktionen

Regeln: Die Regeln sind eine der wichtigsten Komponenten um die openHAB-Software nicht nur als zentrale Web-basierte und herstellerubergreifende¨ Verwaltungstelle sondern als Heim- automatisierungssoftware zu bezeichnen. Die Regeln dienen der Automatisierung von Hard- warekomponenten und Web-Technologien. In den Regeln wird z. B. definiert, dass Fenster geschlossenen und Rollläden heruntergelassen werden, wenn durch die am Haus angebrach- te Sensorik schlechtes Wetter signalisiert bzw. triggert wird. Die Regeln sind in Xtext ver- fasst und deren Aufbau und Strukturblöcke gleichen denen von Java-Dateien: 1. Import, 2. Variablen-Deklarationen und 3. Regeln (when-then-Block). Um Regeln auszulösen bietet die openHAB-Software drei unterschiedliche Varianten von Triggern an [Uh15p]. Dabei können Regeln ausgefuhrt¨ werden wenn...

• ... sich der Status eines Items geändert hat oder selbiges ein Kommando erhält (item- based. • ... eine Uhrzeit erreicht ist oder der mit dem Quartz-Scheduler definierte Ausdruck zutrifft (time-based).

23 3 openHAB

• ... die openHAB-Software gestartet oder gestoppt wird (system-based).

Skripte: Die Skripte sind in Xtend geschrieben und dienen dazu redundanten Programmcode in den Regeln zu vermeiden. Sie werden innerhalb des Then-Blocks einer Regel aufgerufen - vergleichbar mit einem Methodenaufruf jedoch ohne Ein- und Ausgabeparameter [for15, Eichst¨adt-Engelen T. al. teichsta].

Aktionen: Die Aktionen sind Java-Methoden deren Funktionalit¨at den Regeln und Skripten zur Verfugung¨ steht. Die openHAB-Runtime bietet bereits Aktionen an [Uh15a]:

• Die dem ”openHAB Event Bus” zugeh¨origen Aktionen zum Senden eines Events, aktualisieren eines Item-Status und speichern oder wiederherstellen von Status eines oder mehrerer Items. • Alle audio-relevanten Aktionen fur¨ die Steuerung der Lautst¨arke, das Abspielen von Audio-Dateien oder Streams und die TTS-Wiedergabe. • Und zudem Aktionen zur Protokollierung und fur¨ die Ausfuhrung¨ eines HTTP-Request oder einem Befehl auf der Konsole.

Die oben aufgelisteten sind die Aktionen die nach der Installation der ”openHAB Runtime” serienm¨aßig verfugbar¨ sind. Alle weiteren Aktionen mussen¨ vom Endanwender als Add-on nachinstalliert werden - hierzu z¨ahlen [Uh15a]:

• Die Aktionen um SMTP (Simple Mail Transfer Protocol) Dienste zu nutzen oder eine Kommunikation mit dem XMPP (Extensible Messaging and Presence Protocol) zu realisieren. • Und zudem Aktionen um Nachrichten an iOS oder Android Ger¨ate zu schicken.

3.4.2 Jobmanagement

Fur¨ das Jobmanagement wird der Quartz-Scheduler eingesetzt. Der Quartz-Scheduler kann Trigger erzeugen die einem Job zugeordnet und planmäßig ausgelöst werden. Fur¨ die planmäßi- ge Ausfuhrung¨ bietet der Quartz-Scheduler die ”Cron-Expressions” an [Inc15f]. In den Regeln sind sie den ”time-based” Triggern zuzuordnen. Zudem werden die Cron-Expressions in der Konfiguration der Persistenz verwendet [Uh15n].

3.5 Bindings

Ein openHAB-Binding ist eine konkrete Implementierung die auf der Struktur eines im Ab- schnitt 2.1.1 und 3.1.3 beschriebenen Bundles basiert:

24 3 openHAB

As openHAB allows adding support for a new system by implementing a single OS- Gi bundle (a so-called ”binding”), we have seen a great activity in the community during the past months [Kre15, 17. Dezember 2012]

Bei Instanziierung der Bundles (openHAB-Bindings) k¨onnen die Services uber¨ die Java-Interfaces genutzt und uber¨ die Methoden des Lebenszykluses modiﬁziert werden (start, stop, de-activate).

3.6 Persistenz

Mit den Persistenz-Bindings der openHAB-Software kann der Endanwender die Status der Items speichern - eine Koexistenz mehrerer Persistenz-Bindings ist m¨oglich. Da lediglich die Status der Items persistiert werden, ist keine Erfahrung in der SQL (Structured Query Lan- guage) notwendig. Die Persistenz-Logik ist in den Dateien (*.persist) abgelegt und in zwei Sektionen unterteilt: Die Strategien-Sektion in denen die Trigger zur Speicherung eines Items aufgefuhrt¨ und die Items-Sektion in denen die Items mit zugeh¨origer Strategie aufgelistet sind. Die SQL wird in den Bindings realisert und bleibt dem Anwender verborgen. Die derzeitig unterstutzen¨ Datenbank-Dienste sind [Uh15n]:

• DB4o (http://www.db4o.com/) • RRD4J (http://code.google.com/p/rrd4j/) • MySQL (http://www.mysql.com/) • MongoDB (http://www.mongodb.org/) • Open.Sen.Se (http://open.sen.se/) • InﬂuxDB (http://inﬂuxdb.org/) • und JPA

In der Implementierung des MySQL-Bindings wird z. B. automatisch die Konnektivit¨at zur MySQL-Datenbank hergestellt und die Tabelle ”Items” angelegt. Auf Anfrage werden die Items mit ihrem Namen abgespeichert. Des Weiteren werden die openHAB-Typen auf die MySQL-Datentypen abgebildet.

1: ... 2: public void activate() { 3: // Initialise the type array 4: sqlTypes.put("COLORITEM", "VARCHAR(70)"); 5: sqlTypes.put("CONTACTITEM", "VARCHAR(6)"); 6: sqlTypes.put("DATETIMEITEM", "DATETIME"); 7: sqlTypes.put("DIMMERITEM", "TINYINT"); 8: sqlTypes.put("GROUPITEM", "DOUBLE");

25 3 openHAB

9: sqlTypes.put("NUMBERITEM", "DOUBLE"); 10: sqlTypes.put("ROLERSHUTTERITEM", "TINYINT"); 11: sqlTypes.put("STRINGITEM", "VARCHAR(20000)"); 12: sqlTypes.put("SWITCHITEM", "CHAR(3)"); 13: } 14: ...

Quelltext 3.3: Ausschnitt des MySQL-Services - Datentypen [Uh15m, Sj¨ostrand H., Eichst¨adt- Engelen T., Jackson C.]

Fur¨ jedes openHAB-Item, das in der Item-Sektion aufgelistet ist, legt openHAB automatisch eine Tabelle an, in der die Entitäten der Items als (Time, Value)-Paare gespeichert sind. Der Endanwender hat somit keinen Einfluss auf die Tabellenstruktur oder Aufbau der Entitäten.

3.7 Sonstiges

Neben den in Abschnitt 3.1.2 er¨orterten Transformation-Services, dem REST-Binding und den TTS Diensten in Abschnitt 3.1.3, bietet die openHAB-Software die Integration von derzeitig neun Applikationen an [Uh15b].

Erw¨ahnenswert ist das Astersik Framework (http://www.asterisk.org/) fur¨ die Umsetzung von IP PBX (Private Branch Exchange) Systemen und VoIP Gateways und das ROS (Robot Operating System) (http://www.ros.org/).

26 4 Bewegungserkennung von Personen

In Kapitel 3 wird erörtert, inwieweit openHAB die Programmierparadigmen des OSGi-Standards aus Kapitel 2 umsetzt bzw. verfolgt. Auf dieser Wissensbasis aufbauend, soll nun ein realitätsna- hes Anwendungsszenario aus dem Bereich der Bewegungserkennung erarbeitet werden, welches Hardwarekomponenten unterschiedlicher Hersteller einsetzt und somit eine herstellerubergrei-¨ fende HA bzw. GA beim Einsatz von openHAB realisiert. Dazu wird in den Folgeabschnitten neben dem Aufbau, eingesetzter Hard- und Software auch die Implementierung und die eigentliche Durchfuhrung¨ des Szenarios beschrieben. Eine detaillierte Ergebnisauswertung und alternative Lösungsansätze sind in Kapitel 5 - ”Ergebnisse und Alternativen” wiederzufinden. Zwar ist das hier beschriebene Szenario explizit auf die Bewegungserkennung von Personen zugeschnitten, dennoch ist eine Detektion der Bewegung von Tieren oder Gegenständen bei den eingesetzten Technologien und Verfahren gleichermaßen anzuwenden. Neben möglichen Anwendungsbereichen der Bewegungserkennung von Personen in Zweckbauten, wie z. B. die Uberwachung¨ von Arbeitnehmern in Burogeb¨ äuden oder die Auswertung von Verbraucherver- halten in Einkaufszentren, verfolgen die Einsatzbereiche im privaten Wohnungsbau eine effizi- ente Steuerung der Hausautomatik, eine Angriffserkennung und eine Gesundheitsvorsorge der Personen [vgl. Han+14, S. 271; Kos+12, S. 181]. So wird z. B. beim Betreten/Verlassen einer Räumlichkeit das Licht automatisch an/aus geschaltet, das Eindringen von unerwunschten¨ Per- sonen oder ein kritischer Gesundheitszustand fruhzeitig¨ erkannt und hilfestellende Maßnahmen eingeleitet.

Die Erkennungssysteme fur¨ die erw¨ahnten Anwendungsbereiche sind in zwei Klassen zu unter- teilen - (1) device-based und (2) device-free. [Han+14] unterscheidet vier Klassen die (1) und (2) wie folgt zuzuweisen sind:

(1) device-based - Hierunter fallen die Systeme, bei denen die notwendige Sensorik zur Bewegungserkennung direkt an den Personen angebracht ist.

a) wearable sensor based - [Har13] zeigt Systeme, die eine Sensorik an Händen, Fußen¨ oder am Oberkörper der Personen vorsehen. Die INSs (Inertial Navigation Systems) verwenden neben Trägheits- und Beschleunigungssensoren auch Gyroskope und Magnetometer, die neben der Lokalisierung auch eine Navigation ermöglichen - die SHSs (Step-and-Heading Systems) nutzen zudem Barometer und Funkschnittstellen. Zwar liegt der Fokus der

27 4 Bewegungserkennung von Personen

Anwendung dieser Systeme in der Lokalisierung und der Navigation von Personen, eine Bewegungserkennung ist aber durch eine mehrfache Lokalisierung gegeben. b) smart-{phone | watch} based techniques - Diese Systeme gleichen den ”wearable sensor based” Systemen. Einziger Unterschied ist, dass die vorliegende Infrastruktur nicht erweitert, sondern auf die vorhandene Sensorik von Smartphone oder Smartwatch zuruck-¨ gegriffen wird - Je nach verwendeten Endgerät stehen Barometer, Bluetooth, WLAN, GPS, Gyroskop, Beschleunigungs- und Helligkeitssensor zur Auswahl. [Iwa+13] zeigt einen Lösungsansatz der auf der Wi-Fi Sensorik beruht.

(2) device-free - Die Bewegung wird anhand von Sensoren erkannt, die nicht von Personen mitgefuhrt¨ werden, sondern explizit in der R¨aumlichkeit verbaut bzw. installiert sind.

a) vision based -Fur¨ die Bewegungserkennung werden Bilder von hochauflösenden Kameras ausgewertet. Die Präzision der Systeme reicht bis hin zur fingergenauen Gestenauswer- tung [Uts+02]. b) ambient device based - Diese Systeme benötigen fest installierte Bewegungs-, oder Präsenzmelder, werten Audio-Signale von Mikrofonen oder Daten von Piezo-Sensoren aus. [Alw+06] beschreibt ein Verfahren zur Erkennung von gesturzten¨ Personen beim Einsatz von Piezo-Sensoren und deutet zudem auf eine mögliche Auswertung der Fort- bewegung von Personen hin.

Fur¨ (1) ist nachteilig zu erwähnen, dass - bis auf ein evtl. vorhandenes Smartphone - alle Endgeräte und Sensoren explizit fur¨ den Anwendungsfall erworben werden und zu jeder Zeit an der Person angebracht sein mussen¨ - was auf Dauer eine hohe Belastung fur¨ die Person darstellt. Die Klasse ”device-free” besitzt neben den hohen Anschaffungskosten weitere Defi- zite, die eine korrekte Bewegungserkennung verhindern: Die ”vision based” Systeme scheitern oft an der notwendigen LOS (Line-Of-Sight) zur Person (z. B. tote Ecken / Winkel), sind nur auf bestimmte Räumlichkeiten des privaten Wohnraums begrenzt oder können nicht in der Dunkelheit ausgewertet werden. Bei (1b) bedarf es zudem einer Planung vor Fertigstellung der Lokalität - z. B. die Piezo-Sensoren werden meist vor Montage des Fußboden installiert. Somit ist fur¨ die Einrichtung der obigen Systeme die vorhandene Infrastruktur zu erweitern.

Grundsätzlich könnten diese Systeme fur¨ eine korrekte Szenariodurchfuhrung¨ angewendet werden, dennoch soll aufgrund der genannten Defizite die Klasse (2) um ”rf device based” Systeme ergänzt und fur¨ das in diesem Kapitel beschriebene Szenario verwirklicht werden: Darunter fallen alle Systeme, die keine Sensorik an den Personen vorsehen, einen funkbasierten Ansatz (Radiowellen) verfolgen und die vorhandene Infrastruktur nutzen. Die Radiowellen benötigen keine direkte LOS zu den Personen [Kos+12, S. 181] und die Auswertung der Bewegungserken- nung kann auf bereits installierten WAPs (Wireless Access Points) des konfigurierten WLAN stattfinden. Stellvertretend fur¨ die eingefuhrte¨ Klasse stehen folgende Ansätze: In [Han+14] wird ”WiFall” vorgestellt - ein System das den Sturz einer Person mit 87% Wahrscheinlichkeit

28 4 Bewegungserkennung von Personen erkennt und eine Fehlerrate von 18% besitzt [Han+14, S. 278]. Zwar unterscheidet die refe- renzierte Literatur die Falltypen in Fallrichtungen, Endpositionen und Rotationen [Nou+07, S. 1665], WiFall zeigt jedoch keine typenspezifische Auswertung die Aufschluss uber¨ die er- zielte Ungenauigkeit und Fehlerraten geben könnte. Ein weiteres System ist ”RASID”, das die Erkennung einer Bewegung anhand der aufgezeichneten RSSI (Received Signal Strength Indicator) im WLAN realisiert [Kos+12]. In [Kos+12, S. 182 ff.] wird statistischer Mittelwert und Varianz der gemessenen RSSI zur Berechnung verwendet. Weitere Erkenntnisse der Aus- wirkung der menschlichen Bewegung auf die Varianz der RSSI wird in [EK+11] gezeigt. In [Kas+12] wird die Implementierung eines Systems vorgestellt, das die Präsenz von Vehikel erkennt und deren Geschwindigkeit abschätzen kann. Die oben genannten Systeme sehen neben dem zentralen Leitrechner zumeist einen Rechner fur¨ die Auswertung der gemessenen RSSI vor, d.h. die Analyse der Bewegungserkennung wird nicht direkt von einem WAP ubernommen.¨

Fur¨ die Realisierung des Projektziels soll ein ”rf device based” System umgesetzt werden, das in Verbindung mit openHAB ein Szenario der herstellerubergreifenden¨ HA bzw. GA kennzeichnet.

4.1 Eingesetzte Hard- und Software

Die Abbildung 4.1 zeigt die im Projekt eingesetzte Hard- und Software, die in diesen Abschnitt genauer betrachtet wird. Der Kontext fur¨ die Implementierung bei Verwendung der Software ist in Abschnitt 4.3 beschrieben.

Im Top-Down-Ansatz der Automatisierung ist die ”Lex Uno Station” als zentraler Leitrechner anzusehen [Gmb15c]:

• Hardware: Der Leitrechner verfugt¨ uber¨ ein Mainboard ”UNO-3I270D-V4G-H16-00” mit einer Intel Atom NN270 1.6Ghz CPU, 1GB DDR2 SDRAM, einer VGA, einer SATA (128GB Intenso SSD) und vier Realtek GB LAN Schnittstellen. • Software: Das installierte Betriebssystem ist Ubuntu Desktop in der Version 14.04.2 (i386). Die fur¨ den Einsatz der openHAB-Software eingesetzte Laufzeitumgebung ist OpenJDK-Java-7. Sowohl die openHAB-Runtime, der openHAB-Designer als auch die zugeh¨origen Bindings ”org.openhab.binding.{hue, http}, org.openhab.persistence.{rrd4j, mysql}” liegen in der Version 1.6.2 vor. Fur¨ die Ausfuhrung¨ der Skripte werden ”sshpass” und die Bash-Shell genutzt.

Die erste herstellerabh¨angige Hardwarekomponente ist das ”Philips Hue Living-Colors Bloom” Starter Kit [V15]:

• Hardware: Die Hue-Bridge (1xLAN) dient als Controller fur¨ die Hue Bloom Leuchten.

29 4 Bewegungserkennung von Personen

• Software: Zur Kommunikation des Controllers mit den Leuchten, implementiert das Produkt die ZigBee Speziﬁkation als Erweiterung der IEEE802.15.4 Norm.

Als letzte Hardwarekomponente werden fur¨ das Szenario zwei ”TP-Link WLAN Router N750” (Model TL-WDR4300 Version 1.7) eingesetzt [wik15a]:

• Hardware: Die Router sind mit einer Atheros AR9344 CPU mit 560Mhz, 8MB ROM, 128MB RAM, vier LAN, einem WAN, zwei USB 2.0 und zwei Radios (Atheros AR9344 bgn, AR9580 an) ausgestattet. • Software: Statt der TP-Link Firmware wird auf beiden Routern das OpenWrt Betriebs- system ”Barrier Breaker” in der Version 14.07 installiert [wik15b]. Auf dem Sender wird das Paket ”mgen” (Multi-Generator) und auf dem Receiver werden die Pakete ”tcpdump” (inkl. libpcap) und ”luasocket” installiert. In der Grundinstallation von OpenWrt ist der Lua (Imperative und funktionale Skriptsprache) Interpreter verfugbar.¨

Abbildung 4.1: Eingesetzte Hard- und Software [ope15]

4.2 Installation und Konﬁguration

Nach Installation des Ubuntu-Betriebssystems und der Laufzeitumgebung auf dem Leitrechner, ist die openHAB-Software nach den in [Uh15h] beschriebenen Schritten zu konﬁgurieren. Im Anhang 7.1.1 sind die notwendigen Zeilen fur¨ eine openHAB und Hue-Bridge Konﬁguration aufgelistet. Die genannten Bindings sind im Ordner ”addons” hinterlegt. Fur¨ den Start von openHAB ist das Shell-Skript (start.sh) auszufuhren.¨ Alternativ kann openHAB auch zeitgleich

30 4 Bewegungserkennung von Personen mit dem Systemstart von Ubuntu initialisiert werden [Uh15k]. Fur¨ die Steuerung der Hue- Leuchten uber¨ die Hue-Bridge ist keine weitere Konﬁguration notwendig.

[wik15b] beschreibt die Installation von OpenWrt auf den WAPs und beinhaltet die Benutzero- berfläche ”Luci”. Nach dem ersten Start der WAPs ist fur¨ beide ein Systempasswort via Telnet (Teletype Network) zu vergeben. Um den Zugriff mittels SSH (Secure Shell) zu ermöglichen, mussen¨ folgende Einstellungen vorgenommen werden:

1. Die Firewall-Regeln des WAN (Wide Area Network) -Port anpassen, d.h. sowohl einge- hender als auch ausgehender Verkehr muss akzeptiert werden (Luci:Network/Firewall). 2. Der SSH-Zugriﬀ ist auf den WAN-Port einzustellen und der SSH-Key zu hinterlegen (Luci:System/Administration). 3. Die WAPs uber¨ den WAN-Port anschließen.

Fur¨ die Konfiguration der Funkschnittstellen sind die Konfigurationsdateien ”wireless” und ”network”, wie in Anhang 7.2.1 und 7.2.2 fur¨ den Receiver und in Anhang 7.3.1 und 7.3.2 fur¨ den Sender dargestellt, anzupassen. Alternativ kann eine Konfiguration der Schnittstellen auch uber¨ die Benutzeroberfläche erfolgen (Luci:Network/Interfaces und Network/Wifi). Letztend- lich kommunizieren beide WAPs uber¨ ein Ad-hoc-Netz auf dem 2.4 GHz-Frequenzband, wobei der Receiver, der eine Bewegung bei Auswertung der RSSI erkennen soll, im Vergleich zum Sen- der noch uber¨ eine virtuelle Funk-Schnittstelle im Monitor-Mode verfugt,¨ um den eingehenden Netzwerk-Verkehr zu analysieren.

Um die Kommunikation im Ad-hoc-Netz aufrechtzuerhalten, senden die WAPs die ”Beacon Frames” zum Kommunikationspartner. Da fur¨ die sp¨atere Szenariodurchfuhrung¨ analysiert werden soll, inwieweit die Gute¨ der Bewegungserkennung von der Anzahl der analysierten Pakete abh¨angt, erzeugt der Sender auf Anfrage weiteren UDP (User Datagram Protocol) Verkehr. Der Anhang 7.3.3 zeigt ein Multi-Generator Skript, das exemplarisch zehn weitere UDP-Pakete pro Sekunde an den Receiver verschickt.

Die dann auf dem Receiver durch ”tcpdump” gesniﬀten Pakete werden an die Lua-Skripte zur Auswertung weitergereicht. Um openHAB eine Bewegungserkennung zu signalisieren und die REST-API anzusprechen, wird das Paket ”luasocket” ben¨otigt [Neh15].

Fur¨ eine Auswertung der Ergebnisse ist die MySQL-Datenbank [ubu15] und das MySQL- Binding [Uh15l] zu installieren und zu konﬁgurieren. Die Strategien zur Speicherung der openHAB-Items sind, wie im Anhang 7.1.4 dargestellt, umzusetzen.

31 4 Bewegungserkennung von Personen

4.3 Implementierung

Durch die zuvor deklarierte Sitemap (7.1.3) und die angegebenen Items (7.1.2) visualisiert der Webserver die Benutzeroberﬂ¨ache (7.4), die in funf¨ Sektionen eingeteilt ist:

1 Steuerung: Der Verweis ”Philips Hue-Bloom Lampen” fuhrt¨ zum Sub-Menu¨ wo dann die Hue-Bloom Leuchten an und ausgeschaltet werden können. Zudem können die Leuchten auf alle Farben aus dem HSV-Farbraum gesetzt werden. 2 Profil erstellen: Diese Sektion ermöglicht dem Anwender das Messen einer Signalstärke fur¨ die vorliegende Räumlichkeit und die eingestellte Distanz zwischen Sender und Re- ceiver. Standardmäßig ist die Dauer der Messung auf zehn Sekunden eingestellt. Der Ruckgabewert¨ ist die durch die Anzahl der uber¨ den Zeitraum gemessenen Pakete gemittelte Signalstärke und wird automatisch in ”gespeicherte Signalstärke” eingetragen. Zudem wird die maximal und minimal gemessene Signalstärke an die Benutzeroberfläche ubermittelt.¨ Das in Abbildung 4.2 visualisierte UML-Sequenzdiagramm behandelt diesen Anwendungsfall. 3 Bewegung erkennen: Die dritte Sektion behandelt den Anwendungsfall der Bewegungser- kennung. Fur¨ die spätere Szenariodurchfuhrung¨ ist der absolute Signalstärkenunterschied von gespeicherter Signalstärke aus Sektion 2 und in gemessener Signalstärke aus Sekti- on 3 individuell einstellbar. Falls der Receiver eine Signalstärke misst, die den einstellten Grenzwert uberschreitet,¨ wird die Signalstärke eingetragen und somit die Bewegung erkannt. Der Anwendungsfall ist im UML-Sequenzdiagramm 4.3 dargestellt. 4 Multi-Generator: Um die Verbindung des Ad-hoc-Netzes aufrecht zu erhalten, senden beide WAPs im Rotationsverfahren die Beacons-Frames an die Kommunikationspartner [Inc15d] - im vorliegenden Szenario ca. 6-8 Pakete pro Sekunde. Um eventuelle Abhängig- keiten zwischen der Gute¨ der Bewegungserkennung und Anzahl der gemessenen Pakete aufzuzeigen, kann der Anwender zusätzlichen Netzwerk-Verkehr beim Sender erzeugen - UML-Squenzdiagramm 4.4. 5 Graph: Die funfte¨ Sektion zeigt die graphische Visualisierung der unterschiedlichen Si- gnalstärken.

Das Ziel der Implementierung ist es, eine Bewegung anhand einer Grenzwertuberschreitung¨ von gemessenen Signalst¨arken zu erkennen und durch den Einsatz von unterschiedlichen Hard- warekomponenten und der openHAB-Software die Machbarkeit der herstellerubergreifenden¨ GA bzw. HA aufzuzeigen. Im Folgenden soll die umgesetzte Implementierung anhand der Sequenzdiagramme er¨ortert werden:

Profil erstellen: Der Anwender startet seinen Browser, ruft die Start-Url von openHAB auf (z.B. htttp://openhab:8080) und authentifiziert sich gegebenenfalls. Der Webserver stellt ihm die Benutzeroberfläche zur Verfugung¨ und die openHAB-Items werden durch die Regel ”In-

32 4 Bewegungserkennung von Personen itialize Items” (7.1.5) initialisiert. Sobald der Anwender die Dauer eingestellt und den Schalter fur¨ ”Signalstärke messen” betätigt hat, startet die Messung. Durch Betätigung ändert sich der Status des Schalters von ”OFF” und ”ON” und triggert die Regel ”Measure RSSI Profile”. Neben Log-Informationen wird dem Anwender der Start und das Ende der Messung durch Anderung¨ der Farbe und Lichtintensität der beiden Leuchten signalisiert. Die eigentliche Mes- sung wird durch die Methode ”executeCommandLine” ausgefuhrt.¨ Die Methode ruft das im Ordner ”configurations/scripts” abgelegte Bash-Skript ”remote.sh” (7.1.6) auf und ubergibt¨ die Parameter ”capture”, Dauer und Item-Namen. Im Bash-Skript wird der SSH Aufruf fur¨ den Receiver durchgefuhrt,¨ der den ”tcpdump” startet und die gesnifften Pakete an den Lua- Interpreter bzw. das Lua-Skript ”captureprofile.lua” (7.2.4) weiterleitet.

Abbildung 4.2: UML-Sequenzdiagramm - Proﬁl erstellen

Das Skript berechnet den minimalen, maximalen und mittleren Wert der empfangenen RS- SI fur¨ die vom Anwender eingestellte Dauer und teilt dem Leitrechner durch Verwendung der REST-API und Aufruf der HTTP-Post-Methode die Anderung¨ des openHAB-Items fur¨ die ubermittelten¨ Item-Namen mit. Neben der HTTP-Post-Methode implementiert das Lua-Skript ”openhabcmd.lua” (7.2.6) die HTTP-GET-Methode, um die in openHAB verfugbaren¨ Items als XML-Datei abzurufen. Hierfur¨ wird das oben genannte Paket ”luasocket” verwendet. Das Lua-Skript (7.2.7) zeigt das Parsen von Items auf dem Receiver oder Sender mittels des Pa- ketes ”LuaXML”, ist aber fur¨ dem Anwendungsfall ”Profil erstellen” nicht notwendig. Obwohl in [Uh15o] auf den Mime-Type ”application/json” hingewiesen wird, ist er bei ausgewählter Hard- und Software nicht verfugbar.¨ Selbst eine Anpassung der Konfiguration des Webservers blieb erfolglos. In der weiteren Verarbeitung von ”Profil erstellen” wird der Schalter in der Regel ”Measure RSSI Profile” auf ”OFF” gestellt und dem Anwender neben der gespeicherten

33 4 Bewegungserkennung von Personen

Signalstärke und den Anderungen¨ der Leuchten ein Ende der Messung signalisiert. Fur¨ die Visualisierung der Signalstärken in Sektion 5 werden die Signalstärken mit der Konfiguration der Persistenz (7.1.4) gespeichert. Durch die gewählten Strategien werden die Werte bei jeder Anderung¨ und jede Minute persistiert.

Bewegung erkennen: Der Anwender hat bereits ein Profil erstellt und den Grenzwert fur¨ den Signalstärkenunterschied eingestellt. Durch die Betätigung des Schalters ”Bewegungs- erkennung” wird der Status des Items auf ”ON” gestellt und die Regel ”Start recognizing movement” (7.1.5) getriggert. Die Methode ”executeCommandLine” wird ausgefuhrt¨ und die Parameter ”recognize”, die gespeicherte Signalstärke, der Grenzwert und die Item-Namen dem Bash-Skript fur¨ die Ausfuhrung¨ des Lua-Skripts ”capturerecognition.lua” (7.2.5) auf dem Re- ceiver ubermittelt.¨ Wie bei dem oben erörterten Anwendungsfall nutzt das Lua-Skript die vom ”tcpdump” gesnifften Pakete und uberpr¨ uft,¨ ob die gespeicherte Signalstärke und die derzeitig ermittelte Signalstärke den angegebenen Grenzwert uberschreitet.¨

Abbildung 4.3: UML-Sequenzdiagramm - Bewegungserkennung starten und stoppen

Eine Uberschreitung¨ wird uber¨ die REST-API und Aufruf der HTTP-Post-Methode als neuer Wert im openHAB-Item eingetragen. Bei Anderung¨ des Wertes wird die Regel ”Movement recognized” getriggert und dem Anwender eine Bewegung durch einen Farbwechsel (Grun¨ / Rot) der Leuchten gekennzeichnet. Das Lua-Skript fuhrt¨ solange Berechnungen durch, bis der Anwender den Schalter ”Bewegungserkennung” erneut betätigt und dadurch die Regel ”Stop recognizing movement” anstößt. Die Regel fuhrt¨ das Bash-Skript aus, das dann den Befehl zur Terminierung der Prozesse von ”tcpdump” und dem Lua-Interpreter auf dem Receiver auslöst.

34 4 Bewegungserkennung von Personen

Multi-Generator: Sowohl bei ”Profil erstellen’ als auch bei ”Bewegung erkennen” werden nur die empfangenen Beacon-Frames vom Sender ausgewertet. Mit dem Multi-Generator kann der Anwender optional auf dem Sender zusätzlichen Netzwerk-Verkehr in Form von 64 Byte großen UDP-Paketen erzeugen. Bei Betätigung des Schalters ”UDP-Verkehr erzeugen” agiert die Regel ”Send more packets” und fuhrt¨ das auf dem Sender befindliche MGen-Skript (7.3.3) aus. Das MGen-Skript startet auf der Funkt-Schnittstelle ”wlan0” einen unendlichen und pe- riodischen UDP-Fluss and die angegebene Zieladresse - hier exemplarisch zehn Pakete pro Sekunde, ansonsten wird die Eingabe vom Anwender berucksichtigt.¨ Die so erzeugten UDP- Pakete werden automatisch bei der Auswertung der Signalstärken berucksichtigt.¨ Falls der Anwender den UDP-Verkehr stoppt, wird die Regel ”Stop sending packets” aufgerufen und der Prozess auf dem Sender terminiert.

Abbildung 4.4: UML-Sequenzdiagramm - Zus¨atzliche UDP-Pakete senden

Graph: Fur¨ die graphische Visualisierung wird die rrd4j-Persistenz (7.1.4) eingesetzt. Fur¨ eine korrekte Visualisierung des Chart-Item ”GRSSI Chart” - eine Gruppierung der drei gemessenen Signalst¨arken - ist eine Speicherung mit mindestens der ”everyMinute” -Strategie obligatorisch [Uh15t]. Bei derzeitigem Entwicklungsstand des rrd4j-Bindings ist eine Anpassung fur¨ eine individuelle Achsenbeschriftung oder Skala nicht m¨oglich.

35 4 Bewegungserkennung von Personen

4.4 Aufbau und Durchfuhrung¨

Sowohl Aufbau als auch Durchfuhrung¨ des Szenarios finden im Raum C060 der Hochschule Bonn-Rhein-Sieg statt. Wie in Abbildung 4.5 visualisiert, ist der Leitrechner, die Hue-Bridge und die WAPs uber¨ Ethernet im gleichen Subnetz (10.20.114.0 24) verbunden. Dabei ist der Abstand von Leuchten und Hue-Bridge fur¨ eine korrekte Funktionsweise unerheblich. Der Sze- narioaufbau ist insofern statisch, als dass lediglich der Abstand (1m, 2m, 4m, 6m und 10m) von Sender und Receiver bei der Durchfuhrung¨ variabel ist. Die Antennen der Router sind auf einer Höhe von 95cm angebracht. Fur¨ jede Distanz zwischen den WAPs ist sowohl ”Profil erstellen” als auch ”Bewegung erkennen” fur¨ zwei Signalleistungen (30dBm und 15dBm) durchzufuhren.¨ Fur¨ die Distanzen 1-6m ist die LOS der WAPs nicht beeinträchtigt. Bei einer abschließenden Durchfuhrung¨ ist die LOS durch eine 16cm dicke Betonziegelwand gehindert.

Abbildung 4.5: Aufbau des Szenarios in der Hochschule Bonn Rhein Sieg (Raum C060) [ope15]

36 4 Bewegungserkennung von Personen

Um False-Positives auszuschließen, ist fur¨ jeden Messdurchlauf nach ”Profil erstellen” fur¨ ”Be- wegung erkennen” eine Ruhe-Phase eingeplant, in der keine Bewegung stattfindet. Eine Steue- rung der Benutzeroberfläche erfolgt uber¨ die Android-Applikation ”HABDroid” [Uh15j]. Nach dieser Ruhe-Phase betritt die Testperson den Raum: Sie öffnet die Tur¨ und geht langsamen Schrittes durch die LOS der WAPs hindurch - bis zur eingezeichneten Fensterwand, kehrt um verlässt den Raum und schließt die Tur.¨ Dabei ist die Messung als False-Negatives zu werten, falls die Testperson den Raum durchschritten aber keine Grenzwertuberschreitung¨ stattgefun- den hat. Fur¨ die Abbildung eines realitätsnahen Szenarios sind fur¨ jeden Messdurchlauf weitere WAPs in Reichweite (in- und außerhalb des Raumes) des Senders und Receivers auf dem 2,4GHz Frequenzband verfugbar.¨ Mögliche Fehlmessungen, durch auftretende Interferenzen mit den anderen WAPs, sind deshalb nicht ausgeschlossen. Fur¨ die anschließende Auswertung werden die gemessenen Daten bei jeder Anderung¨ in der MySQL-Datenbank persistiert und mit dem SQL-Query (7.1.4) abgefragt.

Eine korrekte Bewegungserkennung hängt somit von folgenden Parametern ab: Die Dauer fur¨ die Profilerstellung und somit die Anzahl der Pakete fur¨ die Mittelwertbildung der gespeicherten Signalstärke, der eingestellte absolute Grenzwert fur¨ den Signalstärkenunterschied bei aktueller Distanz zwischen Sender und Receiver und die vom Sender und Receiver eingestellte Signalleistung.

Die in Kapitel 5 - ”Ergebnisse und Alternativen” aufgefuhrten¨ Ergebnisse geben Aufschluss uber¨ die Zusammenh¨ange bzw. Abh¨angigkeiten der Parameter.

37 5 Ergebnisse und Alternativen

5.1 Ergebnisse

Bei Durchfuhrung¨ des im vorherigen Kapitel beschriebenen Szenarios, ergeben sich die in Ab- bildung 5.1, 5.2, 5.3 und 7.14 dargestellten Ergebnisse fur¨ insgesamt elf Messdurchläufe. Die erste Spalte jeder Abbildung kennzeichnet den Messdurchlauf. Die Abbildung 5.1 behandelt den Anwendungsfall ”Profil erstellen” und berucksichtigt¨ die Parameter fur¨ Sichtausbreitung, Distanz und Sendeleistung der WAPs. Fur¨ eine Dauer von jeweils 60 Sekunden ist fur¨ jeden Messdurchlauf der minimale, maximale und gemittelte RSSI errechnet. Aufgrund einer unzurei- chenden Verbindung ist bei dem neunten Messdurchlauf eine Sendeleistung von 20dBm statt 15dBm verwendet worden. Fur¨ den elften Messdurchlauf wurde in Abgrenzung zum zehnten Messdurchlauf der Multi-Generator mit zusätzlichen 25pps genutzt.

Abbildung 5.1: Messergebnisse fur¨ den Anwendungsfall ”Proﬁl erstellen”

In Abbildung 5.2 sind die Messergebnisse fur¨ den Anwendungsfall ”Bewegung erkennen” in der Ruhe-Phase aufgefuhrt.¨ Die Einstellung fur¨ den Grenzwert ist durch die Abweichung der gemessenen RSSI aus ”Proﬁle erstellen” zu begrunden¨ und ist fur¨ Ruhe- und Bewegungs-Phase gleichgesetzt. Die False-Positives - eine f¨alschlicherweise erkannte Bewegung in der Ruhe-Phase

38 5 Ergebnisse und Alternativen

- sind die prozentualen Anteile der Grenzwertuberschreitungen¨ fur¨ die Anzahl der Messungen. Fur¨ die Messdurchläufe #1-3 und #6 ist ein False-Positive aufgetreten. Die möglichen Er- klärungen fur¨ die False-Positives sind mit den Anmerkungen (Anhang 7.14) abzugleichen.

Abbildung 5.2: Messergebnisse fur¨ den Anwendungsfall ”Bewegung erkennen” (Ruhe-Phase)

Exemplarisch fur¨ den Messdurchlauf #2 ist der False-Positive aufgetreten, als eine Person mit ihrem Laptop an dem Raum C060 vorbeigegangen ist. Fur¨ die Messdurchl¨aufe #3 und #6 ist auf dem Smartphone mit der HABdroid Applikation zus¨atzlicher Netzwerk-Verkehr eingegangen. Die Rate in der Bewegungs-Phase ist nicht als z.B. ”eine Bewegung ist zu 30,77% erkannt worden” zu deuten, sondern ist der Anteil der Grenzwertuberschreitungen¨ bei Anzahl der Messungen.

Abbildung 5.3: Messergebnisse fur¨ den Anwendungsfall ”Bewegung erkennen” (Bewegungs-Phase)

39 5 Ergebnisse und Alternativen

Dem Anhang 7.5 sind die Visualisierungen der Messdurchläufe beigefugt¨ und geben weiteren Aufschluss uber¨ die Abhängigkeit zwischen verwendeter Sendeleistung, Distanz und einge- stelltem Grenzwert. Wenn auch die Messdurchläufe #1-7 eine präzise Grenzwerteinstellung aufweisen, wären bei Justierung des Grenzwertes fur¨ die Messdurchläufe #8, #10 und #11 mehr Uberschreitungen¨ zu verzeichnen. Der Grenzwert ist die Abweichung der in ”Profil erstellen” gemessenen minimalen und maximalen RSSI zum gemittelten RSSI fur¨ eine Dauer von 60 Sekunden. Bei Verwendung der mittleren quadratischen Abweichung könnten mehr Messwerte als ”Bewegung ” erkannt werden, jedoch auch die Anzahl der False-Positives ansteigen - eine Messung uber¨ einen längeren Zeitraum ist obligatorisch.

Die Visualisierungen zeigen deutlich, dass fur¨ alle Distanzen und Sendeleistungen sowohl bei als auch eingeschr¨ankter LOS der WAPs, die gemessenen Werte in der Ruhe-Phase zu denen in der Bewegungs-Phase abgrenzbar sind. Insgesamt ist durch die gezeigte Implementierung und Szenariodurchfuhrung¨ eine herstellerubergreifende¨ HA bzw. GA beim Einsatz von openHAB gezeigt.

5.2 Alternative Ans¨atze

Die in diesem Abschnitt aufgelisteten alternativen Ansätze sollen fur¨ das Szenario der Bewe- gungserkennung auf bereits implementierte openHAB-Bindings fur¨ herstellerabhängige Hard- warekomponenten und Einsatz von Open-Source-Software hinweisen. Bei Anwendung der Ansätze sind die in Kapitel 4 - ”Bewegungserkennung von Personen” genannten Defizite der ”device-free - vision based” und ”device-free - ambient device based” Klassen zu bedenken.

Variante Nr. 1 - Bewegungsmelder: HomeMatic: • openHAB: Homematic-Binding • Neben openHAB-Rules und openHAB-Skripten ist keine Software erforderlich. • Quelle: http://www.eq-3.de/sensoren-detail/items/hm-sec-mdir.html

FS20: • openHAB: FS20-Binding • Neben openHAB-Rules und openHAB-Skripten ist keine Software erforderlich. • Quelle: http://www.elv.de/fs20-piri-2-hr-funk-bewegungsmelder-mit-dimme rsteuerung.html/refid/zanox/zanpid/2019358387397334016

EnOcean: • openHAB: EnOcean-Binding • Neben openHAB-Rules und openHAB-Skripten ist keine Software erforderlich. • Quelle: http://shop.loxone.com/dede/enocean-funk-bewegungsmelder.html

40 5 Ergebnisse und Alternativen

Variante Nr. 2 - Videoauswertung: Microsoft Kinect: • openHAB: REST-Binding • Fur¨ die Realisierung ist der ”Jnect”-Adapter und das Microsoft Kinect SDK notwendig. • Quelle: https://code.google.com/a/eclipselabs.org/p/jnect/

Motion Detector Bricklet: • openHAB: REST-Binding • Fur¨ die Realisierung ist der Einsatz von ”jmt” obligatorisch. • Quelle: http://www.tinkerforge.com/de/doc/Software/Bricklets/MotionDete ctor_Bricklet_Java.html

Java-Motion-Tracking: • openHAB: REST-Binding • Die Open-Source Software ”jmt” verwendet das Java Media Framework. • Quelle: https://code.google.com/p/java-motion-tracking/

JMyron: • openHAB: REST-Binding • ”JMyron” ist eine Open-Source Bibliothek fur¨ die Bildmanipulation und Bewegungser- kennung. • Quelle: http://www.silentlycrashing.net/p5/libs/jmyron/

OpenCV: • openHAB: REST-Binding • Mit den Algorithmen der ”OpenCV” Bibliothek ist eine Bewegung durch Abgleich der aufgezeichneten Bilder vorstellbar. • Quelle: http://opencv.org/

Variante Nr. 3 - Tonauswertung: Sphinx-4: • openHAB: REST-Binding • Mit der ”sphinx4” Software k¨onnen Audiosignale analysiert werden (Pr¨asenzerkennung). • Quelle: http://cmusphinx.sourceforge.net/wiki/tutorialsphinx4/

Variante Nr. 4 - LEAP Motion: LEAP Motion: • openHAB: Leap-Binding (fruhe¨ Alpha-Phase) • Der Leap-Motion Sensor ist fur¨ eine Gestenerkennung bei kurzen Distanzen einsetzbar. • Quelle: https://www.leapmotion.com/product

41 6 Zusammenfassung und Fazit

Die vorherrschende Inkompatibilität zur Interoperabilität der herstellerabhängigen Technologi- en aus dem Bereich der Heim- bzw. Gebäudeautomatisierung zwingt die Hersteller zur Ent- wicklung von Hard- und Softwarelösungen. Einige dieser Lösungen sind lediglich als Gateway zweier Standards bzw. Protokolle angedacht und können daruber¨ hinaus nicht mit anderen Produkten konkurrieren. In jungster¨ Zeit sieht der Trend der Automatisierung eine Softwa- relösung auf dem Leitrechner vor, die alle konkurrierenden Hard- und Softwarekomponenten vereinigen kann. Die openHAB-Software ist eine solche Lösung die auch dem Begriff der IoT (Internet of Things) zuzuordnen ist:

Die Idee des Internet of Things basiert darauf, dass die Dinge des Alltags vernetzt sind. Was aber, wenn das liebgewonnene Ding“ keine IP- Schnittstelle aufweist ” oder das verwendete Protokoll für den IoT-Service der Wahl unverständlich ist? Was, wenn alle Dinger“ mit einer einheitlichen Oberfläche bedient, ein gemein- ” sames Chart mit Daten bestücken, oder gemeinsamen Automatisierungsregeln folgen sollen? In diesem Fall können Integrationsplattformen helfen, die für diese Problemstellungen Lösungen anbieten. [EE15, 1. April 2012].

Wenn auch Thomas Eichstädt-Engelen als Mitbegrunder¨ der openHAB UG diese Aussage sehr umgangssprachlich formuliert, trifft sie dennoch den Kerngedanken einer zukunftswurdigen¨ Automatisierungsplattform: Nicht nur weil die openHAB-Software auf der Eclipse-Equinox, als Implementierung des OSGi-Standards, aufbaut, sondern auch weil die fortgefuhrte¨ Im- plementierung die geforderten Programmierparadigmen achtet, ist openHAB als dynamisches Modulsystem anzusehen. Dank der aufgelösten Programmkomplexität durch Dekomposition in Softwaremodule verfugt¨ openHAB sowohl uber¨ eine einheitliche Versionierung und Proto- kollierung als auch uber¨ eine Registrierung und Verwaltung von Diensten. Die verwendeten dynamischen Abhängigkeiten der Protokollimplementierungen (openHAB-Bindings) ermögli- chen das (de-)installieren und konfigurieren von Diensten während der Laufzeit und sind somit autark: Hot Deployment. Statische Abhängigkeiten sind nur fur¨ die Kernkomponenten eingesetzt.

Aufgrund einer zentralen Konﬁguration fur¨ die Hard- und Softwarekomponenten, der umgesetz- ten Automatisierungslogik, unterteilt in Regel-, Skripte- und Jobmanagement im expressiven

42 6 Zusammenfassung und Fazit

Dialekt, und der simplen SQL-Logik ist der Funktionsumfangs der openHAB-Software fur¨ den erprobten Endanwender nutzbar. Der Entwicklungsschwerpunkt der openHAB Versionen 2.x liegt in der Verbesserung der Gebrauchstauglichkeit als Teildisziplin der User Experience, um dem Laien die Funktionen der Software zug¨anglicher zu gestalten.

Eine Thematik fur¨ anknupfende¨ Arbeiten ist demnach die Analyse der User Experience bei An- wendung der heuristischen Evaluation, dem Cognitive Walk-Through oder den Usability-Tests. Neben den in Kapitel 5 - ”Ergebnisse und Alternativen” gelisteten Ans¨atzen, kann Thema weitere Projekte auch eine verteile openHAB-Automatisierung uber¨ externe Laufzeitumgebungen sein.

Fur¨ das in dieser Arbeit vorgestellte und durchgefuhrte¨ realit¨atsnahe Szenario gilt eine Bewe- gungserkennung von Personen durch die Auswertung der empfangenen Signalst¨arke von WAPs anhand der Beacon-Frames als plausibel und kennzeichnet eine herstellerubergreifende¨ Auto- matisierung beim Einsatz von openHAB. Fur¨ diese Art der Bewegungserkennung ist vorteilhaft, dass keine Sensorik an den Personen angebracht und die Infrastruktur nicht erweitert werden muss.

Fur¨ eine Produktreife in den Anwendungsbereichen der Angriffserkennung und der Gesund- heitsvorsorge sind Messungen uber¨ einen längeren Zeitraum abzuhalten und die Entwicklung bis hin zur automatischen Konfiguration der WAPs fortzufuhren.¨ Fur¨ die Abschätzungen der Grenzwertuberschreitungen¨ sind andere mathematische Ausdrucke¨ bzw. Wahrscheinlichkeits- verteilungen anzuwenden. In [al15] wird ein mathematisches Model entwickelt, das bei Verwen- dung der ”Kullback Leibner” Distanz und der gemessenen RSSI eine Auskunft uber¨ die Anzahl von Personen in der Lokalität gibt. Störeinflusse¨ durch evtl. Endgeräte auf dem gleichen Fre- quenzband bleiben unberucksichtigt.¨ Zudem wird darauf hingewiesen, dass eine Auswertung der Signalstärken fur¨ alle Kanäle des Frequenzspektrums nahezu die gleichen Ergebnisse liefert, wie bei Auswertung der RSSI.

43 7 Anhang

7.1 Lex Uno Station - Leitrechner mit openHAB

7.1.1 Konﬁguration - openHAB mit Hue-Binding

1: ... 2: folder:items=10,items 3: folder:sitemaps=10,sitemap 4: folder:rules=10,rules 5: folder:scripts=10,script 6: folder:persistence=10,persist 7: ... 8: security:option=ON 9: ... 10: # IP address of Hue Bridge (optional, default is auto- discovery) 11: hue:ip= 12: ... 13: hue:secret=huebridgesecret 14: ...

Quelltext 7.1: Ausschnitt der openHAB-Konﬁguration

7.1.2 Deklaration - openHAB-Items

1: Group GRSSI_Chart 2: Group GItem_Control 3: Color Hue_Light_1 (GItem_Control) { hue="1" } 4: Color Hue_Light_2 (GItem_Control) { hue="2" } 5: Number Duration_Profile 6: Number Threshold_Value 7: Number RSSI_Profile "saved RSSI"(GRSSI_Chart)

44 7 Anhang

8: Number RSSI_Profile_min 9: Number RSSI_Profile_max 10: Number RSSI_Recognition "measured RSSI" (GRSSI_Chart) 11: Number RSSI_Threshold "> Threshold" (GRSSI_Chart) 12: Number Packet_Value 13: Switch Do_Profile 14: Switch Do_Recognition 15: Switch Do_MGen 16: String Persist_Log

Quelltext 7.2: Deklaration der openHAB-Items

7.1.3 Realisierung - openHAB-Sitemap

1: sitemap default label="Main Menu" 2: { 3: Frame label="Steuerung" { 4: Group item=GItem_Control label="Philips Hue-Bloom Lampen" icon="light-on" { 5: Frame{ 6: Colorpicker item=Hue_Light_1 label="1. Hue-Bloom Leuchte " icon="slider" 7: Colorpicker item=Hue_Light_2 label="2. Hue-Bloom Leuchte " icon="slider" 8: } 9: } 10: } 11: 12: Frame label="Profil erstellen" { 13: Setpoint item=Duration_Profile label="Dauer: [%ds]" step=1 minValue=1 maxValue=120 icon="clock-on" 14: Switch item=Do_Profile label="Signalstärke messen" icon=" fire " 15: Text item=RSSI_Profile label= "gespeicherte Signalstärke: [%.2 fdB ]" icon="chart" 16: Text item=RSSI_Profile_min label="min. Signalstärke [%.2 fdB ]" icon="chart" 17: Text item=RSSI_Profile_max label="max. Signalstärke [%.2 fdB ]" icon="chart" 18: } 19:

45 7 Anhang

20: Frame label="Bewegung erkennen" { 21: Setpoint item=Threshold_Value label="Grenzwert für Signalstärkenunterschied (abs): [%.1fdB]" step=0.1 minValue=0.5 maxValue=60 icon="energy" 22: Switch item=Do_Recognition label="Bewegungserkennung" icon="fire" 23: Text item=RSSI_Recognition label="momentane Signalstärke: [%.2 fdB ]" icon="chart" 24: Text item=RSSI_Threshold label="Bewegung erkannt für Signalstärke: [%.2fdB]" icon="chart" 25: Text item=Persist_Log visibility=[Persist_Log==" Uninitialized"] 26: } 27: 28: Frame label="Multi-Generator - OpenWrtSender" { 29: Setpoint item=Packet_Value label="Pakete: [%d/s]" step=5 minValue=5 maxValue=25 icon="box" 30: Switch item=Do_MGen label="UDP-Verkehr erzeugen" icon=" network " 31: } 32: 33: Frame label="Graph" { 34: Chart item=GRSSI_Chart service="rrd4j" period=h refresh =1000 35: //Image url="http://openhab:openhab1!@localhost:8080/ rrdchart.png?groups=GRSSI_Chart&period=h&service=rrd4j& h=200&w=1400" 36: } 37: }

Quelltext 7.3: Konﬁguration der openHAB-Sitemap

7.1.4 Konﬁguration - openHAB-Persistence

1: Strategies{ 2: everyMinute : "0 * * * * ?" 3: //default= everyChange 4: } 5: 6: Items{ 7: RSSI_Recognition: strategy = everyChange, everyMinute

46 7 Anhang

8: RSSI_Profile: strategy = everyChange, everyMinute 9: RSSI_Threshold: strategy = everyChange, everyMinute 10: }

Quelltext 7.4: rrd4j-Persistenz fur¨ Visualisierung der Signalst¨arken

1: Strategies{ 2: default = everyChange 3: } 4: 5: Items{ 6: RSSI_Recognition: strategy = everyChange 7: RSSI_Profile: strategy = everyChange 8: RSSI_Threshold: strategy = everyChange 9: Persist_Log: strategy = everyChange 10: RSSI_Profile_min: strategy = everyChange 11: RSSI_Profile_max: strategy = everyChange 12: }

Quelltext 7.5: Konﬁguration der MySql-Persistenz

1: (SELECT*FROM openhab.Item4ORDERBY openhab.Item4.Time) 2: UNION 3: (SELECT*FROM openhab.Item3ORDERBY openhab.Item3.Time) 4: UNION 5: (SELECT*FROM openhab.Item1ORDERBY openhab.Item1.Time) 6: UNION 7: (SELECT*FROM openhab.Item2ORDERBY openhab.Item2.Time) 8: UNION 9: (SELECT*FROM openhab.Item5ORDERBY openhab.Item5.Time) 10: UNION 11: (SELECT*FROM openhab.Item6ORDERBY openhab.Item6.Time) 12: ORDERBY Time

Quelltext 7.6: MySql-Query fur¨ Auswertung der Ergebnisse

7.1.5 Realisierung - openHAB-Rules

1: import org.openhab.core.library.types.* 2: 3: rule "Initialize Items" 4: when 5: System started

47 7 Anhang

6: then 7: if (Duration_Profile.state == Uninitialized) { 8: Duration_Profile.sendCommand(10) 9: } 10: if(Threshold_Value.state == Uninitialized) { 11: Threshold_Value.sendCommand(1) 12: } 13: if(Packet_Value.state == Uninitialized) { 14: Packet_Value.sendCommand(5) 15: } 16: if(RSSI_Profile.state == Uninitialized) { 17: RSSI_Profile.sendCommand(0) 18: } 19: if(RSSI_Profile_min.state == Uninitialized) { 20: RSSI_Profile_min.sendCommand(0) 21: } 22: if(RSSI_Profile_max.state == Uninitialized) { 23: RSSI_Profile_max.sendCommand(0) 24: } 25: if(RSSI_Recognition.state == Uninitialized) { 26: RSSI_Recognition.sendCommand(0) 27: } 28: if(RSSI_Threshold.state == Uninitialized) { 29: RSSI_Threshold.sendCommand(0) 30: } 31: end 32: 33: rule "Measure RSSI_Profile" 34: when 35: Item Do_Profile received command 36: then 37: var duration = (Duration_Profile.state as DecimalType). intValue 38: if(Do_Profile.state == ON) { 39: logInfo("org.openhab.rules", "RSSI-Profile started: " + duration + "s") 40: Persist_Log.sendCommand("RSSI-Profile started: " + duration + "s") 41: Hue_Light_1.sendCommand("100,100,0") 42: Hue_Light_2.sendCommand("100,100,0") 43: executeCommandLine("/bin/bash ./configurations/scripts/ remote.sh capture "+duration+" RSSI_Profile")

48 7 Anhang

44: Thread::sleep(duration*1000+5000) 45: Hue_Light_1.sendCommand("100,100,70") 46: Hue_Light_2.sendCommand("100,100,70") 47: Do_Profile.sendCommand(OFF) 48: logInfo("org.openhab.rules", "RSSI-Profile finished") 49: Persist_Log.sendCommand("RSSI-Profile finished:" + duration + "s") 50: } 51: end 52: 53: rule "Start recognizing movement" 54: when 55: Item Do_Recognition received commandON 56: then 57: var rssi_profile = (RSSI_Profile.state as DecimalType) 58: var threshold_value = (Threshold_Value.state as DecimalType) 59: executeCommandLine("/bin/bash ./configurations/scripts/ remote.sh recognize -1 RSSI_Recognition "+rssi_profile+ " RSSI_Threshold "+threshold_value) 60: logInfo("org.openhab.rules", "RSSI-Recognition started: " + rssi_profile + "dB and threshold of "+threshold_value+"dB ") 61: Persist_Log.sendCommand("RSSI-Recognition started: " + rssi_profile + "dB and threshold of "+threshold_value+"dB ") 62: end 63: 64: rule "Stop recognizing movement" 65: when 66: Item Do_Recognition changed fromON toOFF 67: then 68: executeCommandLine("/bin/bash ./configurations/scripts/ remote.sh recognize kill") 69: logInfo("org.openhab.rules", "RSSI-Recognition stopped: killed tcpdump and lua") 70: Persist_Log.sendCommand("RSSI-Recognition stopped: killed tcpdump and lua") 71: end 72: 73: rule "Movement recognized" 74: when 75: Item RSSI_Threshold received command

49 7 Anhang

76: then 77: var rssi_profile = (RSSI_Profile.state as DecimalType) 78: var rssi_threshold = (RSSI_Threshold.state as DecimalType) 79: logInfo("org.openhab.rules", "Movement recognized: "+ rssi_threshold+"db measured") 80: Persist_Log.sendCommand("Movement recognized: "+ rssi_threshold+"db measured") 81: Hue_Light_1.sendCommand("30,100,70") 82: Hue_Light_2.sendCommand("30,100,70") 83: Thread::sleep(500) 84: Hue_Light_1.sendCommand("100,100,70") 85: Hue_Light_2.sendCommand("100,100,70") 86: end 87: 88: rule "Send more packets" 89: when 90: Item Do_MGen received commandON 91: then 92: var packet_value = (Packet_Value.state as DecimalType). intValue 93: executeCommandLine("/bin/bash ./configurations/scripts/ remote.sh mgen "+packet_value) 94: logInfo("org.openhab.rules", "Multi-Generator started with " +packet_value+"/s") 95: Persist_Log.sendCommand("Multi-Generator started with "+ packet_value+"/s") 96: end 97: 98: rule "Stop sending packets" 99: when 100: Item Do_MGen changed fromON toOFF 101: then 102: executeCommandLine("/bin/bash ./configurations/scripts/ remote.sh mgen kill") 103: logInfo("org.openhab.rules", "Multi-Generator stopped") 104: Persist_Log.sendCommand("Multi-Generator stopped") 105: end

Quelltext 7.7: openHAB-Rules fur¨ Reaktion auf Nutzer- und Systeminteraktion

7.1.6 Remote-Zugriﬀ - Bash-Skript

50 7 Anhang

1: #!/bin/bash 2: if [ "$1" == "" ] 3: then 4: echo "error: missing params" 5: else 6: if [ "$1" == "capture" ] 7: then 8: if [ "$2" != "" ] 9: then 10: sshpass -p ’openhab1!’ ssh [email protected] ’cd /etc/ recognition/ && tcpdump -i wlan0-1 -e "ether src 30: b5:c2:38:3d:63" | lua captureprofile.lua ’"$2" "$3" " $4" "$5" 11: fi 12: fi 13: if [ "$1" == "recognize" ] 14: then 15: if [ "$2" != "kill" ] 16: then 17: if [ "$4" != "" ] 18: then 19: sshpass -p ’openhab1!’ ssh [email protected] ’cd /etc/ recognition/ && tcpdump -i wlan0-1 -e "ether src 30:b5:c2:38:3d:63" | lua capturerecognition.lua ’" $3" "$4" "$5" "$6" 20: fi 21: else 22: sshpass -p ’openhab1!’ ssh [email protected] ’kill -9 $( pidof lua capture) && kill -9 $(pidof tcpdump) ’ 23: fi 24: fi 25: if [ "$1" == "mgen" ] 26: then 27: if [ "$2" != "kill" ] 28: then 29: sshpass -p ’openhab1!’ ssh [email protected] ’cd /etc/ && mgen input udpgen’"$2"’.mgn’ 30: else 31: sshpass -p ’openhab1!’ ssh [email protected] ’kill -9 $( pidof mgen)’ 32: fi

51 7 Anhang

33: fi 34: fi 35: exit

Quelltext 7.8: Bash-Skript fur¨ Remote-Zugriﬀ auf Sender und Receiver

7.2 TP-Link WLAN Router - Receiver

7.2.1 Konﬁguration - Netzwerk

1: ... 2: config interface ’lan’ 3: option ifname ’eth0.1’ 4: option force_link ’1’ 5: option type ’bridge’ 6: option proto ’static’ 7: option ipaddr ’192.168.1.1’ 8: option netmask ’255.255.255.0’ 9: option ip6assign ’60’ 10: 11: config interface ’wan6’ 12: option ifname ’@wan’ 13: option proto ’dhcpv6’ 14: 15: ... 16: 17: config interface ’wlan0’ 18: option _orig_ifname ’wlan0’ 19: option _orig_bridge ’false’ 20: option proto ’static’ 21: option ipaddr ’10.10.10.48’ 22: option netmask ’255.255.255.0’

Quelltext 7.9: Ausschnitt der Netzwerk-Konﬁguration

7.2.2 Konﬁguration - Wireless

1: config wifi-device ’radio0’ 2: option type ’mac80211’

52 7 Anhang

3: option channel ’11’ 4: option hwmode ’11g’ 5: option path ’platform/ar934x_wmac’ 6: option htmode ’HT20’ 7: option txpower ’30’ 8: option country ’US’ 9: 10: config wifi-device ’radio1’ 11: option type ’mac80211’ 12: option channel ’36’ 13: option hwmode ’11a’ 14: option path ’pci0000:00/0000:00:00.0’ 15: option htmode ’HT20’ 16: option disabled ’1’ 17: 18: config wifi-iface 19: option device ’radio0’ 20: option ssid ’OpenWrt-adhoc’ 21: option mode ’adhoc’ 22: option network ’wlan0’ 23: option encryption ’wep-shared’ 24: option key ’1’ 25: option key1 ’ABCDABCDAB’ 26: 27: config wifi-iface 28: option device ’radio0’ 29: option ssid ’OpenWrt’ 30: option mode ’monitor’

Quelltext 7.10: Wireless-Konﬁguration

7.2.3 Konﬁguration - Lua Skript

1: local conf = { 2: host= "10.20.114.61", 3: port=’8080’, 4: user=’openhab’, 5: pw=’openhab1!’, 6: } 7: return conf

Quelltext 7.11: Lua-Konﬁguration

53 7 Anhang

7.2.4 Proﬁl erstellen - Lua Skript

1: require "socket" 2: local io = require "io" 3: local config = require "config" 4: local openhabcmd = require "openhabcmd" 5: 6: local rssi = 0 7: local duration = arg[1] 8: local cnt = 0 9: local saverssiitem = "/rest/items/"..arg[2] 10: local minrssiitem = "/rest/items/"..arg[3] 11: local maxrssiitem = "/rest/items/"..arg[4] 12: local currentmin = 0 13: local currentmax = -100 14: local host = string.format("http://%s:%s@%s:%d", config.user, config.pw, config.host, config.port) 15: 16: while true do 17: 18: local line = io.read() 19: if line == nil then 20: io.write("error: no input") break 21: end 22: 23: str = string.match(line,"-%d+dB") 24: if str == nil then 25: str = "" 26: else 27: str = string.sub(str,1,string.len(str)-2) 28: rssi = rssi + str 29: cnt = cnt + 1 30: if math.abs(currentmin) < math.abs(tonumber(str)) then 31: currentmin = tonumber(str) 32: end 33: if math.abs(currentmax) > math.abs(tonumber(str)) then 34: currentmax = tonumber(str) 35: end 36: end 37: 38: if duration ~= 0 then 39: socket.select(nil,nil,1)

54 7 Anhang

40: else 41: response = rssi/cnt 42: openhabcmd.request(host..saverssiitem, response, string. len(response)) 43: openhabcmd.request(host..minrssiitem, currentmin, string. len(currentmin)) 44: openhabcmd.request(host..maxrssiitem, currentmax, string. len(currentmax)) 45: break 46: end 47: duration = duration - 1 48: end

Quelltext 7.12: RSSI-Proﬁl erstellen

7.2.5 Bewegung erkennen - Lua Skript

1: require "socket" 2: local io = require "io" 3: local config = require "config" 4: local openhabcmd = require "openhabcmd" 5: 6: local calcrssi = 0 7: local storedrssi = arg[2] 8: local cnt = 0 9: local recognition_item = "/rest/items/"..arg[1] 10: local threshold_item = "/rest/items/"..arg[3] 11: local threshold_value = arg[4] 12: local host = string.format("http://%s:%s@%s:%d", config.user, config.pw, config.host, config.por 13: 14: while true do 15: local line = io.read() 16: if line == nil then 17: io.write("error: no input") break 18: end 19: 20: str = string.match(line,"-%d+dB") 21: if str == nil then 22: str = "" 23: else

55 7 Anhang

24: str = string.sub(str,1,string.len(str)-2) 25: calcrssi = calcrssi + str 26: cnt = cnt + 1 27: end 28: 29: if cnt == 10 then 30: response = calcrssi/cnt 31: openhabcmd.request(host..recognition_item, response, string.len(response)) 32: if math.abs((math.abs(storedrssi)-math.abs(response))) > tonumber(threshold_value) then 33: openhabcmd.request(host..threshold_item, response, string.len(response)) 34: end 35: calcrssi = 0 36: cnt = 0 37: end 38: end

Quelltext 7.13: Bewegung anhand der absoluten RSSI-Diﬀerenz erkennen

7.2.6 Kommandos fur¨ openHAB REST-API - Lua Skript

1: local http = require "socket.http" 2: local ltn12 = require "ltn12" 3: local io = require "io" 4: module("openhabcmd", package.seeall) 5: 6: ------7: -- HTTP.Request(POST); Parameter: url, value, value-length 8: ------9: function request(URL, VALUE, LENGTH) 10: local RSP, CODE, TR = http.request{ 11: url = URL , 12: method = "POST", 13: headers = { [’Content-Type’] = "text/plain", [’Content- Length’] = LENGTH }, 14: redirect = false, 15: source = ltn12.source.string(VALUE), 16: sink = ltn12.sink.null() 17: }

56 7 Anhang

18: returnRSP,CODE,TR 19: end 20: 21: ------22: -- HTTP.Request(GET) return xml; Parmeter: url host with port 23: ------24: function items(URL) 25: local RSP = http.request{ 26: url = URL.."/rest/items", 27: method = "GET", 28: headers = { [’Content-Type’] = "application/xml" }, 29: source = ltn12.source.empty(), 30: sink = ltn12.sink.file(io.open("items.xml", "w")) 31: } 32: returnRSP 33: end

Quelltext 7.14: REST-API Kommandos (POST / GET)

7.2.7 REST-API Kommando fur¨ openHAB-Items - Lua Skript

1: require("LuaXml") 2: module("configurephase", package.seeall) 3: 4: function getItems(host, filepath, itemtype) 5: local response = openhabcmd.items(host) 6: local items = {} 7: if response == 1 then 8: local xmlfile = xml.load(filepath) 9: local xmlitems = xmlfile:find("items") 10: if xmlitems ~= nil then 11: for i in pairs(xmlitems) do 12: local xmlitemtype = xmlitems[i]:find("type") 13: if xmlitemtype ~= nil then 14: -- scenario specific parameter ITEMTYPE 15: if xmlitemtype[1] == itemtype then 16: local xmlitemname = xmlitems[i]:find("name") 17: if xmlitemname ~= nil then 18: -- create dynamic variable for itempath 19: _G["URL"..i] = string.format("%s/rest/items/".. xmlitemname[1], host)

57 7 Anhang

20: table.insert(items, _G["URL"..i]) 21: end 22: end 23: end 24: end 25: end 26: end 27: return items 28: end

Quelltext 7.15: openHAB-Items auf dem Receiver verarbeiten (optional)

7.3 TP-Link WLAN Router - Sender

7.3.1 Konﬁguration - Netzwerk

1: ... 2: config interface ’lan’ 3: option force_link ’1’ 4: option proto ’static’ 5: option ipaddr ’192.168.1.1’ 6: option netmask ’255.255.255.0’ 7: option ip6assign ’60’ 8: option _orig_ifname ’eth0.1 wlan0 wlan1’ 9: option _orig_bridge ’true’ 10: option type ’bridge’ 11: 12: config interface ’wan’ 13: option ifname ’eth0.2’ 14: option proto ’dhcp’ 15: 16: ... 17: 18: config interface ’wlan0’ 19: option _orig_ifname ’wlan0’ 20: option _orig_bridge ’false’ 21: option proto ’static’ 22: option netmask ’255.255.255.0’ 23: option ipaddr ’10.10.10.45’ 24: ...

58 7 Anhang

Quelltext 7.16: Ausschnitt der Netzwerk-Konﬁguration

7.3.2 Konﬁguration - Wireless

1: config wifi-device ’radio0’ 2: option type ’mac80211’ 3: option channel ’11’ 4: option hwmode ’11g’ 5: option path ’platform/ar934x_wmac’ 6: option htmode ’HT20’ 7: option txpower ’30’ 8: option country ’US’ 9: 10: config wifi-device ’radio1’ 11: option type ’mac80211’ 12: option channel ’36’ 13: option hwmode ’11a’ 14: option path ’pci0000:00/0000:00:00.0’ 15: option htmode ’HT20’ 16: option txpower ’17’ 17: option country ’US’ 18: 19: config wifi-iface 20: option device ’radio0’ 21: option ssid ’OpenWrt-adhoc’ 22: option mode ’adhoc’ 23: option network ’wlan0’ 24: option encryption ’wep-shared’ 25: option key ’1’ 26: option key1 ’ABCDABCDAB’

Quelltext 7.17: Wireless-Konﬁguration

7.3.3 Multi-Generator Skript

1: STARTNOW 2: INTERFACE wlan0 3: 0.0ON1UDPDST 10.10.10.48/31337PERIODIC [10 64]COUNT -1

59 7 Anhang

Quelltext 7.18: Multi-Generator Skript fur¨ 10 Pakete/s

7.4 openHAB-GUI fur¨ realisierte Sitemap

Abbildung 7.1: Main-Menu¨ der Benutzeroberﬂ¨ache [Uh15u]

60 7 Anhang

Abbildung 7.2: Sub-Menu¨ der Benutzeroberﬂ¨ache - Steuerung der Leuchten [Uh15u]

7.5 Ergebnisse und Messwertvisualisierung

Abbildung 7.3: Visualisierung fur¨ Messdurchlauf #1

Abbildung 7.4: Visualisierung fur¨ Messdurchlauf #2

61 7 Anhang

Abbildung 7.5: Visualisierung fur¨ Messdurchlauf #3

Abbildung 7.6: Visualisierung fur¨ Messdurchlauf #4

Abbildung 7.7: Visualisierung fur¨ Messdurchlauf #5

62 7 Anhang

Abbildung 7.8: Visualisierung fur¨ Messdurchlauf #6

Abbildung 7.9: Visualisierung fur¨ Messdurchlauf #7

Abbildung 7.10: Visualisierung fur¨ Messdurchlauf #8

63 7 Anhang

Abbildung 7.11: Visualisierung fur¨ Messdurchlauf #9

Abbildung 7.12: Visualisierung fur¨ Messdurchlauf #10

Abbildung 7.13: Visualisierung fur¨ Messdurchlauf #11

64 7 Anhang

Abbildung 7.14: Anmerkungen zu den einzelnen Messdurchl¨aufen

65 8 Eidesstattliche Erkl¨arung

Hiermit erkläre ich an Eides Statt, dass ich die vorliegende Arbeit selbst angefertigt habe. Die aus fremden Quellen direkt oder indirekt ubernommenen¨ Gedanken sind als solche kenntlich gemacht. Die Arbeit wurde bisher keiner Prufungsbeh¨ örde vorgelegt und auch noch nicht veröffentlicht.

Peter Manheller, Sankt Augustin den 26.06.2015

66 Literaturverzeichnis

[al15] Depatla S. et. al. Occupancy Estimation Using Only WiFi Power Measurements. 2015. url: http://www.ece.ucsb.edu/~ymostofi/papers/JSAC15_DepatlaMura lidharanMostofi.pdf (besucht am 10. 06. 2015) (zitiert auf Seite 43).

[All15a] The OSGi Alliance. Certiﬁed Products. 2015. url: http://www.osgi.org/Certification/Certified (besucht am 14. 04. 2015) (zitiert auf Seite 13).

[All15b] The OSGi Alliance. Join the OSGi Alliance. 2015. url: http://www.osgi.org/Join/HomePage (besucht am 14. 04. 2015) (zitiert auf Seite 12).

[All15c] The OSGi Alliance. OSGi Service Platform Core Speciﬁcation - Release 4, Version 4.3 April 2011. 2015. url: https://osgi.org/download/r4v43/osgi.core-4.3.0.pdf (besucht am 11. 04. 2015) (zitiert auf Seiten 5–12).

[All15d] The OSGi Alliance. OSGi Service Platform Service Compendium - Release 4, Version 4.3 January 2012. 2015. url: https://osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf (besucht am 11. 04. 2015) (zitiert auf Seiten 4, 9, 10, 16–18).

[All15e] The OSGi Alliance. Technology. 2015. url: h t tp : / / w w w . o s g i . o r g /T e c h n o l o g y /H o m e P a ge (besucht am 14. 04. 2015) (zitiert auf Seite 12).

[Alw+06] M. Alwan, P.J. Rajendran, S. Kell, D. Mack, S. Dalal u. a. “A Smart and Passive Floor-Vibration Based Fall Detector for Elderly”. In: Information and Communi- cation Technologies, 2006. ICTTA ’06. 2nd. Bd. 1. 2006, S. 1003–1007. (Zitiert auf Seite 28).

[Ass15a] KNX Association. KNX has become an International Standard: ISO/IEC 14543-3. 2015. url: http://www.domo-energie.com/usr_file/Pdf/knx_is_internation al_standard.pdf (besucht am 08. 04. 2015) (zitiert auf Seite 1).

[Ass15b] KNX Association. Standardization. 2015. url: http://www.knx.org/knx-en/knx/technology/standardisation/in dex.php (besucht am 07. 04. 2015) (zitiert auf Seite 1).

67 Literaturverzeichnis

[Aut15] IANA Internet Assigned Numbers Authority. MIME-Tpe Application - vnd.osgi.bundle. 2015. url: http://www.iana.org/assignments/media-types/application/vn d.osgi.bundle (besucht am 11. 04. 2015) (zitiert auf Seite 6).

[CEN15] CENELEC. CLC/TC 205 Home and Building Electronic Systems (HBES). 2015. url: http://www.cenelec.eu/dyn/www/f?p=104:110:1746994019214401:::: FSP_ORG_ID,FSP_PROJECT,FSP_LANG_ID:1258281,53681,25 (besucht am 07. 04. 2015) (zitiert auf Seite 1).

[Com15] KUNBUS Industrial Communication. BatiBUS - already ”history” for a long time, but still signiﬁcant! 2015. url: http://www.kunbus.com/batibus.html (besucht am 07. 04. 2015) (zitiert auf Seite 1).

[Con15] MisterHouse Contributor. MisterHouse - It Knows Kung-Fu. 2015. url: http://misterhouse.sourceforge.net/ (besucht am 15. 04. 2015) (zitiert auf Seite 14).

[Cor15] Oracle Corporation. Jersey RESTful Web Services in Java. 2015. url: https://jersey.java.net/ (besucht am 15. 05. 2015) (zitiert auf Seite 18).

[EE15] Thomas Eichst¨adt-Engelen. Die Welt der Dinge in deiner Hand - openHAB als Integrationsplattform im IoT. 2015. url: https://www.innoq.com/de/articles/2012/04/internet-of- things/ (besucht am 02. 06. 2015) (zitiert auf Seite 42).

[EK+11] K. El-Kafrawy, M. Youssef und A. El-Keyi. “Impact of the human motion on the variance of the received signal strength of wireless links”. In: Personal Indoor and Mobile Radio Communications (PIMRC), 2011 IEEE 22nd International Sympo- sium on. 2011, S. 1208–1212. (Zitiert auf Seite 29).

[Fil12] U. Fildebrandt. Software modular bauen: Architektur von langlebigen Softwaresys- temen - Grundlagen und Anwendung mit OSGi und Java. Dpunkt.Verlag GmbH, 2012. (Zitiert auf Seiten 4–10).

[for15] knx-user forum. Tolle Arbeit, wie geht’s weiter. 2015. url: http://knx-user-forum.de/forum/supportforen/openhab/25148- %E2%88%9A-tolle-arbeit-wie-geht-s-weiter (besucht am 20. 05. 2015) (zitiert auf Seite 24).

[Fou15a] The Eclipse Foundation. Buddy Class Loading. 2015. url: http://wiki.eclipse.org/index.php/Context_Class_Loader _Enhancements#Buddy_Class_Loading (besucht am 14. 04. 2015) (zitiert auf Seite 13).

68 Literaturverzeichnis

[Fou15b] The Eclipse Foundation. FAQ What are extensions and extension points? 2015. url: http://wiki.eclipse.org/FAQ_What_are_extensions_and_extens ion_points%3F (besucht am 14. 04. 2015) (zitiert auf Seite 13).

[Fou15c] The Eclipse Foundation. Jetty. 2015. url: http://eclipse.org/jetty/ (besucht am 15. 05. 2015) (zitiert auf Seiten 18, 20).

[Fou15d] The Eclipse Foundation. Mission Statement. 2015. url: http://www.eclipse.org/equinox/ (besucht am 14. 04. 2015) (zitiert auf Seite 13).

[Gmb15a] EnOcean GmbH. Flexible Br¨ucke von KNX zu EnOcean. 2015. url: https://www.enocean.com/de/flexible-bruecke-von-knx-zu- enocean/ (besucht am 08. 04. 2015) (zitiert auf Seite 1).

[Gmb15b] Insta Elektro GmbH. Historie - Insta Elektro GmbH. 2015. url: http://www.insta.de/index.php?option=com_content&view=artic le&id=26 (besucht am 07. 04. 2015) (zitiert auf Seite 1).

[Gmb15c] OMTEC Vertriebs GmbH. Lex Uno UNO-3I270D-V4G-H16-00. 2015. url: http://www.omtec.de/embedded-server/lex-uno-uno-3i270d- v4g-h16-00/ (besucht am 02. 06. 2015) (zitiert auf Seite 29).

[Han+14] Chunmei Han, Kaishun Wu, Yuxi Wang und L.M. Ni. “WiFall: Device-free fall detection by wireless networks”. In: INFOCOM, 2014 Proceedings IEEE. 2014, S. 271–279. (Zitiert auf Seiten 27–29).

[Har13] R. Harle. “A Survey of Indoor Inertial Positioning Systems for Pedestrians”. In: Communications Surveys Tutorials, IEEE 15.3 (2013), S. 1281–1293. (Zitiert auf Seite 27).

[Inc15a] Dropbox Inc. Install Core API SDKs. 2015. url: https://www.dropbox.com/developers/core/sdks/java (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Inc15b] IFTTT Inc. About IFTTT. 2015. url: https://ifttt.com/wtf (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Inc15c] OpenRemote Inc. OpenRemote - Open Source Automation Platform. 2015. url: http://www.openremote.org/display/HOME/OpenRemote (besucht am 15. 04. 2015) (zitiert auf Seite 14).

[Inc15d] QuinStreet Inc. 802.11 Beacons Revealed. 2015. url: http://www.wi-fiplanet.com/tutorials/article.php/1492071 (besucht am 07. 06. 2015) (zitiert auf Seite 32).

69 Literaturverzeichnis

[Inc15e] Terracotta Inc. Quartz Quick Start Guide. 2015. url: http://quartz-scheduler.org/documentation/quartz- 2.1.x/quick-start (besucht am 18. 05. 2015) (zitiert auf Seite 19).

[Inc15f] Terracotta Inc. Tutorial - Lesson 6: CronTrigger. 2015. url: http://www.quartz-scheduler.org/documentation/quartz- 2.1.x/tutorials/tutorial-lesson-06 (besucht am 20. 05. 2015) (zitiert auf Seite 24).

[Iwa+13] T. Iwase und R. Shibasaki. “Infra-free indoor positioning using only smartphone sensors”. In: Indoor Positioning and Indoor Navigation (IPIN), 2013 International Conference on. 2013, S. 1–8. (Zitiert auf Seite 28).

[JmD15] JmDNS. Idea and Concept. 2015. url: http://jmdns.sourceforge.net/ (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Jur15] Nico Jurran. c’t Magazin - Internet der Dinge, Heimautomation und Smart Homes. 2015. url: http://www.heise.de/ct/ausgabe/2015- 4- Internet- der- Dinge-Heimautomation-und-Smart-Homes-2521024.html (besucht am 08. 04. 2015) (zitiert auf Seite 1).

[Kas+12] N. Kassem, A.E. Kosba und M. Youssef. “RF-Based Vehicle Detection and Speed Estimation”. In: Vehicular Technology Conference (VTC Spring), 2012 IEEE 75th. 2012, S. 1–5. (Zitiert auf Seite 29).

[Kos+12] A.E. Kosba, A. Saeed und M. Youssef. “RASID: A robust WLAN device-free passive motion detection system”. In: Pervasive Computing and Communications (PerCom), 2012 IEEE International Conference on. 2012, S. 180–189. (Zitiert auf Seiten 27–29).

[Kre15] Kai Kreuzer. Java Software Architect and Home Automation Professional. 2015. url: http://kaikreuzer.blogspot.de/ (besucht am 15. 04. 2015) (zitiert auf Seiten 14, 15, 20–22, 25).

[May15] Christian Mayer. CometVisu. 2015. url: h t tp : / / w w w . c o m e t v i s u . o r g / w i k i /C o m e tV i su (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Mer+10] H. Merz, T. Hansemann und C. Hubner.¨ Geb¨audeautomation: Kommunikations- systeme mit EIB/KNX, LON und BACnet. Fachbuchverl. Leipzig im Carl-Hanser- Verlag, 2010. (Zitiert auf Seiten 1, 2).

70 Literaturverzeichnis

[Neh15] Diego Nehab. What is LuaSocket? 2015. url: http://w3.impa.br/~diego/software/luasocket/ (besucht am 05. 06. 2015) (zitiert auf Seite 31).

[Nou+07] N. Noury, A. Fleury, P. Rumeau, A.K. Bourke, G.O. Laighin u. a. “Fall detection - Principles and Methods”. In: Engineering in Medicine and Biology Society, 2007. EMBS 2007. 29th Annual International Conference of the IEEE. 2007, S. 1663– 1666. (Zitiert auf Seite 29).

[Ohl15]G unther¨ Ohland. Die Br¨ucke zwischen den Systemen. 2015. url: http://www.funkschau.de/fileadmin/media/heftarchiv/pdf/ 2010/01-02/fs_1001-2_s22-s23_gebaeude.pdf (besucht am 09. 04. 2015) (zitiert auf Seite 2).

[ope15] openclipart.org. openclipart. 2015. url: https://openclipart.org/ (besucht am 21. 05. 2015) (zitiert auf Seiten 30, 36).

[QOS15] QOS.ch. Simple Logging Facade for Java (SLF4J). 2015. url: http://www.slf4j.org/ (besucht am 13. 05. 2015) (zitiert auf Seite 17).

[ubu15] ubuntuusers.de. MySQL. 2015. url: http://wiki.ubuntuusers.de/mysql (besucht am 09. 06. 2015) (zitiert auf Seite 31).

[Uh15a] openHAB UG (haftungsbeschr¨ankt). Actions. 2015. url: https://github.com/openhab/openhab/wiki/Actions (besucht am 20. 05. 2015) (zitiert auf Seite 24).

[Uh15b] openHAB UG (haftungsbeschr¨ankt). Application Integration. 2015. url: https://github.com/openhab/openhab/wiki/Application- Integration (besucht am 21. 05. 2015) (zitiert auf Seite 26).

[Uh15c] openHAB UG (haftungsbeschr¨ankt). Controlling openHAB with your voice. 2015. url: https://github.com/openhab/openhab/wiki/Controlling- openHAB-with-your-voice (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Uh15d] openHAB UG (haftungsbeschr¨ankt). Explanation of Sitemaps. 2015. url: https://github.com/openhab/openhab/wiki/Explanation-of- Sitemaps (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Uh15e] openHAB UG (haftungsbeschr¨ankt). Features. 2015. url: http://www.openhab.org/features.html (besucht am 15. 04. 2015) (zitiert auf Seite 14).

[Uh15f] openHAB UG (haftungsbeschr¨ankt). GCal Binding. 2015. url: https://github.com/openhab/openhab/wiki/GCal-Binding (besucht am 18. 05. 2015) (zitiert auf Seite 20).

71 Literaturverzeichnis

[Uh15g] openHAB UG (haftungsbeschr¨ankt). GCal Binding. 2015. url: https://github.com/openhab/openhab/wiki/GPIO-Binding (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Uh15h] openHAB UG (haftungsbeschr¨ankt). Getting Started. 2015. url: http://www.openhab.org/gettingstarted.html (besucht am 19. 05. 2015) (zitiert auf Seiten 23, 30).

[Uh15i] openHAB UG (haftungsbeschr¨ankt). GitHub - openHAB Overview. 2015. url: https://github.com/openhab/openhab/wiki (besucht am 16. 04. 2015) (zitiert auf Seiten 15, 18, 19, 21–23).

[Uh15j] openHAB UG (haftungsbeschr¨ankt). HABDroid. 2015. url: https://github.com/openhab/openhab/wiki/HABDroid (besucht am 10. 06. 2015) (zitiert auf Seite 37).

[Uh15k] openHAB UG (haftungsbeschr¨ankt). How to conﬁgure openHAB to start automatically on Linux with screen. 2015. url: https://github.com/openhab/openhab/wiki/Samples-Tricks#how- to-configure-openhab-to-start-automatically-on-linux-with- screen (besucht am 05. 06. 2015) (zitiert auf Seite 31).

[Uh15l] openHAB UG (haftungsbeschr¨ankt). MySQL Persistence. 2015. url: https://github.com/openhab/openhab/wiki/MySQL-Persistence (besucht am 09. 06. 2015) (zitiert auf Seite 31).

[Uh15m] openHAB UG (haftungsbeschr¨ankt). openHAB Runtime. 2015. url: https://github.com/openhab/openhab/releases/download/v1.6. 2/distribution-1.6.2-runtime.zip (besucht am 13. 05. 2015) (zitiert auf Seiten V, 16–19, 21, 22, 26).

[Uh15n] openHAB UG (haftungsbeschr¨ankt). Persistence - Introduction. 2015. url: https://github.com/openhab/openhab/wiki/Persistence (besucht am 18. 05. 2015) (zitiert auf Seiten 19, 24, 25).

[Uh15o] openHAB UG (haftungsbeschr¨ankt). REST-API. 2015. url: https://github.com/openhab/openhab/wiki/REST-API (besucht am 08. 06. 2015) (zitiert auf Seite 33).

[Uh15p] openHAB UG (haftungsbeschr¨ankt). Rules. 2015. url: https://github.com/openhab/openhab/wiki/Rules (besucht am 20. 05. 2015) (zitiert auf Seite 23).

[Uh15q] openHAB UG (haftungsbeschr¨ankt). Scripts - Introduction. 2015. url: https://github.com/openhab/openhab/wiki/Scripts (besucht am 18. 05. 2015) (zitiert auf Seite 19).

72 Literaturverzeichnis

[Uh15r] openHAB UG (haftungsbeschr¨ankt). Squeezebox Binding. 2015. url: https://github.com/openhab/openhab/wiki/Squeezebox-Binding (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Uh15s] openHAB UG (haftungsbeschr¨ankt). User Interfaces. 2015. url: http://www.openhab.org/features-ui.html (besucht am 18. 05. 2015) (zitiert auf Seite 20).

[Uh15t] openHAB UG (haftungsbeschr¨ankt). Using RRD4j Charts. 2015. url: https://github.com/openhab/openhab/wiki/Charts (besucht am 10. 06. 2015) (zitiert auf Seite 35).

[Uh15u] openHAB UG (haftungsbeschr¨ankt). Welcome to openHAB. 2015. url: http://www.openhab.org/index.html (besucht am 09. 04. 2015) (zitiert auf Seiten 2, 60, 61).

[Uts+02] A. Utsumi, N. Tetsutani und S. Igi. “Hand detection and tracking using pixel value distribution model for multiple-camera-based gesture interactions”. In: Knowledge Media Networking, 2002. Proceedings. IEEE Workshop on. 2002, S. 31–36. (Zitiert auf Seite 28).

[V15] Philips Electronics N. V. Philips Tischleuchte. 2015. url: http://www.philips.de/c-p/7299760PH/hue-personal-wireless- lighting-tischleuchte (besucht am 02. 06. 2015) (zitiert auf Seite 29).

[Web+10] B. Weber, P. Baumgartner und O. Braun. OSGi f¨ur Praktiker: Prinzipien, Werk- zeuge und praktische Anleitungen auf dem Weg zur ”kleinen SOA”. Hanser, 2010. (Zitiert auf Seiten 4, 5, 7, 8, 10, 11, 13).

[wik15a] wikidevi.com. TP-LINK TL-WDR4300. 2015. url: https://wikidevi.com/wiki/TP-LINK_TL-WDR4300 (besucht am 02. 06. 2015) (zitiert auf Seite 30).

[wik15b] mandrawes wiki.openwrt.org. TP-Link TL-WDR4300. 2015. url: http://wiki.openwrt.org/toh/tp-link/tl-wdr4300 (besucht am 02. 06. 2015) (zitiert auf Seiten 30, 31).

[Wil15] Arno Willig. Hauptseite - Was ist FHEM? 2015. url: http://www.fhemwiki.de/wiki/Hauptseite (besucht am 09. 04. 2015) (zitiert auf Seite 2).

[Wut08]¨ G.W utherich.¨ Die OSGi Service Platform: eine Einf¨uhrung mit Eclipse Equinox. dpunkt, 2008. (Zitiert auf Seiten 4, 5).