Hersteller ubergreifende Heim-/Geb audeautomatisierung ... · 1.1 Aufgabenstellung Der Auftrag des...

Praxisprojektbericht

im Studiengang Master Informatik

HerstellerubergreifendeHeim-/Gebaudeautomatisierung beim

Einsatz von openHAB

von

Peter Manheller(9016802)

Erstprufer: Prof. Dr. Karl JonasZweitprufer: M.Sc. Michael Rademacher

Zeitraum: 30.03.2015 - 24.07.2015Eingereicht am: 26.06.2015

Inhaltsverzeichnis

1 Einleitung 11.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Die OSGi-Service-Platform 42.1 OSGi-Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.1 Bundles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.1.2 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 OSGi-Schichtenmodell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 OSGi-Implementierungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.3.1 Eclipse Equinox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3.2 Sonstige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3 openHAB 143.1 Architektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.1.1 OSGi-Framework Komponenten . . . . . . . . . . . . . . . . . . . . . 153.1.2 openHAB Kernkomponenten . . . . . . . . . . . . . . . . . . . . . . . 183.1.3 openHAB Erweiterungen . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 openHAB Runtime . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.3 openHAB Designer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.4 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.1 Regeln, Skripte und Aktionen . . . . . . . . . . . . . . . . . . . . . . 233.4.2 Jobmanagement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.6 Persistenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.7 Sonstiges . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 Bewegungserkennung von Personen 274.1 Eingesetzte Hard- und Software . . . . . . . . . . . . . . . . . . . . . . . . . 294.2 Installation und Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . 304.3 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.4 Aufbau und Durchfuhrung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5 Ergebnisse und Alternativen 385.1 Ergebnisse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.2 Alternative Ansatze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6 Zusammenfassung und Fazit 42

II

Inhaltsverzeichnis

7 Anhang 447.1 Lex Uno Station - Leitrechner mit openHAB . . . . . . . . . . . . . . . . . . 44

7.1.1 Konfiguration - openHAB mit Hue-Binding . . . . . . . . . . . . . . . 447.1.2 Deklaration - openHAB-Items . . . . . . . . . . . . . . . . . . . . . . 447.1.3 Realisierung - openHAB-Sitemap . . . . . . . . . . . . . . . . . . . . 457.1.4 Konfiguration - openHAB-Persistence . . . . . . . . . . . . . . . . . . 467.1.5 Realisierung - openHAB-Rules . . . . . . . . . . . . . . . . . . . . . . 477.1.6 Remote-Zugriff - Bash-Skript . . . . . . . . . . . . . . . . . . . . . . 50

7.2 TP-Link WLAN Router - Receiver . . . . . . . . . . . . . . . . . . . . . . . . 527.2.1 Konfiguration - Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . 527.2.2 Konfiguration - Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 527.2.3 Konfiguration - Lua Skript . . . . . . . . . . . . . . . . . . . . . . . . 537.2.4 Profil erstellen - Lua Skript . . . . . . . . . . . . . . . . . . . . . . . 547.2.5 Bewegung erkennen - Lua Skript . . . . . . . . . . . . . . . . . . . . 557.2.6 Kommandos fur openHAB REST-API - Lua Skript . . . . . . . . . . . 567.2.7 REST-API Kommando fur openHAB-Items - Lua Skript . . . . . . . . 57

7.3 TP-Link WLAN Router - Sender . . . . . . . . . . . . . . . . . . . . . . . . . 587.3.1 Konfiguration - Netzwerk . . . . . . . . . . . . . . . . . . . . . . . . 587.3.2 Konfiguration - Wireless . . . . . . . . . . . . . . . . . . . . . . . . . 597.3.3 Multi-Generator Skript . . . . . . . . . . . . . . . . . . . . . . . . . . 59

7.4 openHAB-GUI fur realisierte Sitemap . . . . . . . . . . . . . . . . . . . . . . 607.5 Ergebnisse und Messwertvisualisierung . . . . . . . . . . . . . . . . . . . . . . 61

8 Eidesstattliche Erklarung 66

Literaturverzeichnis 73

III

Abbildungsverzeichnis

2.1 Beziehungen zwischen Bundles [Fil12, S. 74] . . . . . . . . . . . . . . . . . . 82.2 Zusammenhang Bundles und Services [Fil12, S. 78] . . . . . . . . . . . . . . . 92.3 OSGi-Schichtenmodell [i.A.a. All15c, S. 2] . . . . . . . . . . . . . . . . . . . 102.4 Interkation Bundles und Framework-Schichten [Web+10, S. 17] . . . . . . . . 112.5 Bundle-Lebenszyklus [i.A.a. All15c, S. 86] . . . . . . . . . . . . . . . . . . . . 11

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

4.1 Eingesetzte Hard- und Software [ope15] . . . . . . . . . . . . . . . . . . . . . 304.2 UML-Sequenzdiagramm - Profil erstellen . . . . . . . . . . . . . . . . . . . . 334.3 UML-Sequenzdiagramm - Bewegungserkennung starten und stoppen . . . . . . 344.4 UML-Sequenzdiagramm - Zusatzliche UDP-Pakete senden . . . . . . . . . . . 354.5 Aufbau des Szenarios in der Hochschule Bonn Rhein Sieg (Raum C060) [ope15] 36

5.1 Messergebnisse fur den Anwendungsfall ”Profil erstellen” . . . . . . . . . . . . 385.2 Messergebnisse fur den Anwendungsfall ”Bewegung erkennen” (Ruhe-Phase) . 395.3 Messergebnisse fur den Anwendungsfall ”Bewegung erkennen” (Bewegungs-

Phase) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

7.1 Main-Menu der Benutzeroberflache [Uh15u] . . . . . . . . . . . . . . . . . . 607.2 Sub-Menu der Benutzeroberflache - Steuerung der Leuchten [Uh15u] . . . . . 617.3 Visualisierung fur Messdurchlauf #1 . . . . . . . . . . . . . . . . . . . . . . . 617.4 Visualisierung fur Messdurchlauf #2 . . . . . . . . . . . . . . . . . . . . . . . 617.5 Visualisierung fur Messdurchlauf #3 . . . . . . . . . . . . . . . . . . . . . . . 627.6 Visualisierung fur Messdurchlauf #4 . . . . . . . . . . . . . . . . . . . . . . . 627.7 Visualisierung fur Messdurchlauf #5 . . . . . . . . . . . . . . . . . . . . . . . 627.8 Visualisierung fur Messdurchlauf #6 . . . . . . . . . . . . . . . . . . . . . . . 637.9 Visualisierung fur Messdurchlauf #7 . . . . . . . . . . . . . . . . . . . . . . . 637.10 Visualisierung fur Messdurchlauf #8 . . . . . . . . . . . . . . . . . . . . . . . 637.11 Visualisierung fur Messdurchlauf #9 . . . . . . . . . . . . . . . . . . . . . . . 647.12 Visualisierung fur Messdurchlauf #10 . . . . . . . . . . . . . . . . . . . . . . 647.13 Visualisierung fur Messdurchlauf #11 . . . . . . . . . . . . . . . . . . . . . . 647.14 Anmerkungen zu den einzelnen Messdurchlaufen . . . . . . . . . . . . . . . . 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, Sjostrand H., Eichstadt-Engelen T., Jackson C.] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

7.1 Ausschnitt der openHAB-Konfiguration . . . . . . . . . . . . . . . . . . . . . 447.2 Deklaration der openHAB-Items . . . . . . . . . . . . . . . . . . . . . . . . . 447.3 Konfiguration der openHAB-Sitemap . . . . . . . . . . . . . . . . . . . . . . 457.4 rrd4j-Persistenz fur Visualisierung der Signalstarken . . . . . . . . . . . . . . . 467.5 Konfiguration der MySql-Persistenz . . . . . . . . . . . . . . . . . . . . . . . 477.6 MySql-Query fur Auswertung der Ergebnisse . . . . . . . . . . . . . . . . . . 477.7 openHAB-Rules fur Reaktion auf Nutzer- und Systeminteraktion . . . . . . . . 477.8 Bash-Skript fur Remote-Zugriff auf Sender und Receiver . . . . . . . . . . . . 517.9 Ausschnitt der Netzwerk-Konfiguration . . . . . . . . . . . . . . . . . . . . . 527.10 Wireless-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 527.11 Lua-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 537.12 RSSI-Profil erstellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 547.13 Bewegung anhand der absoluten RSSI-Differenz erkennen . . . . . . . . . . . 557.14 REST-API Kommandos (POST / GET) . . . . . . . . . . . . . . . . . . . . 567.15 openHAB-Items auf dem Receiver verarbeiten (optional) . . . . . . . . . . . . 577.16 Ausschnitt der Netzwerk-Konfiguration . . . . . . . . . . . . . . . . . . . . . 587.17 Wireless-Konfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 597.18 Multi-Generator Skript fur 10 Pakete/s . . . . . . . . . . . . . . . . . . . . . 59

V

Abkurzungsverzeichnis

BatiBUS Industrielles Feldbussystem des BCI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

BCI BatiBUS Club International . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

CENELEC Comite Europeen de Normalisation Electrotechnique . . . . . . . . . . . . . . . 1

DDC-GA Direct-Digital-Control-Gebaudeautomation. . . . . . . . . . . . . . . . . . . . . . . . .2

Drools Rule Management System Solution der JBoss Community . . . . . . . . . 14

EHS European Home Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

EHSA European Home Systems Association . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

EIB Europaischer 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 Gebaudeautomatisierung bzw. Gebaudeautomation . . . . . . . . . . . . . . . . . 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 Marz 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 (Comite Europeen de Nor-

malisation Electrotechnique) als europaische Norm unter der Bezeichnung EIB (Europaischer

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 (Gebaudeautomatisierung bzw. Gebaudeautomation) gelegt [Ass15b]. Der daraus entstan-

dene KNX (Konnex-Bus) wird im Fruhjahr 2002 veroffentlicht 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 beschrankt auf den privaten Wohnungsbau mit Einsatzbereichen aus Energieeinsparung,

Komfort und Sicherheit [Mer+10, S. 18]. Hingegen ist die GA konzentriert auf Zweckbauten, z.

B. Burohauser oder Einkaufszentren, deren Einsatzbereiche uber die der HA hinaus gehen und

zudem die Faktoren der Flexibilitat und Kommunikation der Bussysteme betrachten [Mer+10,

S. 19].

Trotz der internationalen Standardisierung weist die Interoperabilitat 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 Anschaffung 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-Gebaudeautomation) wiederzufinden. Den Abschluss bildet die Felde-

bene - der Aktoren und Sensoren zugehorig sind [Mer+10, S. 22-26]. Die Symcon GmbH

bietet bereits mit ihrer proprietaren Software ”IP-Symcon” und dem zugehorigen 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 (haftungsbeschrankt) 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 realitatsnahen 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 benotigte und umgesetzte Plattform-

Restriktionen in openHAB zu klaren.

• Fur das realitatsnahe 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 Losung 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 mogliche auftretende Fehler in der Erkennung zu validieren. Ab-

schließend sollen die gewonnenen Erkenntnisse in Abgrenzung zu weiteren Losungsansatzen

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 Realitatsbezug auch die verwendete Hard- und Software naher 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 Losungsansatze 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” prasentiert. Aufgrund des

umfangreichen OSGi-Standards, der von der OSGi-Alliance (Non-Profit-Organisation - Grundung

Marz 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 naher betrachtet werden - auch die

”OSGi Service Platform Mobile Specification”, die speziell fur mobile Endgerate 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 sprachunabhangig, jedoch plattformunabhangig 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 Komplexitat einer Software durch Dekomposition in Module,

notig 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.1 OSGi-Framework

Das OSGi-Framework ist eine Laufzeitumgebung die einen Container fur die Softwarekom-

ponenten (Module und Dienste) bereitstellt. Neben diesen Komponenten enthalt 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 Begriff

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.

Groß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 Abhangig-

keiten, die in Abschnitt 2.1.1.2 erortert 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-Losungen, die konkrete Implementierungen des OSGi-Framework darstellen, ge-

nannt. Der Fokus liegt auf der Vorstellung der ”Eclipse Equinox”, die als Kernkomponente der

openHAB-Software anzusehen ist.

2.1.1 Bundles

Wie bereits erwahnt, ist ein Bundle mit dem Begriff Modul gleichzusetzen und beinhaltet ne-

ben Java-Archiven, Java-Klassen und anderen Ressourcen (z. B. Icons als Bilder) ein Manifest,

in dem erganzende 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 moglich.

In einem bundle-zugehorigen Manifest ist beschrieben, welche externen Archive das Bund-

le benotigt (import), bzw. ob es seine Funktionalitat anderen Bundles zur Verfugung stellt

(export). Damit ein Bundle die benotigten Abhangigkeiten aufschlusseln kann, erhalt es vom

OSGi-Framework-Container einen eigenen Class-Loader der die benotigten 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]. Grundsatzlich unterscheidet

die Spezifikation drei Arten von Bundles:

5


• 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 Abhangigkeiten 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 Auflosung 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 di-

rekt 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 Abhangigkeiten

zu vermeiden.

Zudem ist das OSGi-Bundle von den IANA (Internet Assigned Numbers Authority) als gultiger

MIME-Type ”vnd.osgi.bundle” klassifiziert [Aut15].

2.1.1.1 Manifest

Das Manifest ”META-INF/MANIFEST.MF” beinhaltet eine Auflistung von Metainformatio-

nen, die ein OSGi-Bundle individuell kennzeichnen. Zudem enthalt 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 Pflichtangabe, 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


fallen, enthalt das Bundle wahrscheinlich Funktionalitat aus semantisch unabhangigen Berei-

chen, wodurch dann die Paradigmen der OSGi-Schichtenarchitektur nicht eingehalten werden

[Fil12, S. 137]. Mit ”RequiredExecutionEnvironment” wird die minimal benotigte Laufzeitum-

gebung gekennzeichnet. Der openHAB-Core benotigt mindestens die Java Plattform in der

Standard Edition Version 5. Aufgrund der Ruckwartskompatibilitat von Java konnen dem-

nach auch hohere 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 Funktionalitat abgerufen wird. Ist die ”Activation Policy” nicht ange-

geben, ist sie standardmaß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, konnen diese mit dem Prefix ”x-” gekennzeichnet werden [All15c,

S. 29]. Auf Header-Angaben, die fur eine Kommunikation von Bundles benotigt werden, wird

in Abschnitt 2.1.1.2 naher 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 erwahnten, konnen die Header-Angaben ”Export-” und ”Import-

Package” genutzt werden, um Abhangigkeiten zwischen den Bundles zu erzeugen. Um externe

Funktionalitaten anderer Bundles nutzen zu konnen, kann das Bundle diese explizit in der

Import-Anweisung auflisten. Umgekehrt wird die Export-Anweisung im Manifest angegeben,

um die eigene Funktionalitat 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 - standardmaßig wird die aktuellste Version vom MA geladen. Neben einer spezifischen

Version konnen auch Version-Ranges durch die mathematische Intervall-Notation vermerkt

werden [vgl. All15c, S. 29 f.; Fil12, S. 79; Web+10, S. 7]. Um statische Abhangigkeiten 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” ermoglicht die flexible Einschrankung 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 mogliche Zyklen in der Abhangigkeitskette der Bundles.

Mit ”Require-Bundle” konnen 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


[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 inter-

faces 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 konnen, um eigene Services zu registrieren

(bundleContext.registerService), fremde Services zu nutzen (bundleContext.getServiceReference

und bundleContext.getService) oder sogar uber mogliche 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 moglich, auf die Schnitt-

stelle zuzugreifen und dadurch die Funktionalitat zu nutzen. Summa Summarum bedeutet dies:

OSGi lost 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 Verfugung stellen [Web+10, S. 24].

Bei Verwendung von Import und Export ermoglicht das OSGi-Framework, mit den Services

als Softwareartefakt, eine dynamische Kommunikation innerhalb der Bundles. Wenn in der

8


Entwicklung eine statische Kopplung mit ”Require” umgesetzt wird, sind die Vorteile der Ser-

vices, ihrer Registry und die Reaktion auf Events mit den Listenern hinfallig [Fil12, S. 78 f.].

Einige der Events sind in Abbildung 2.5 dargestellt und sind speziell dem Lebenszyklus ei-

nes Bundles bzw. der Objektinstanz, dem Service, zuzuordnen. Alle ubrigen Events sind den

Kategorien von Fehlermanagement (z. B. ERROR, WARNING oder INFO) oder der erweiter-

ten 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 Anwendungsfalle

an. Im Folgenden sind die sechs interessantesten Services erwahnt: [All15d]

• Log Service - Der Log-Service besteht aus zwei Services: Der ”LogService” ermoglicht

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 ermoglicht 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


• 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 Identifier) realisiert [All15d,

S. 191].

Bis jetzt konnen die Bundles nur die Funktionalitat von Services innerhalb ihrer Laufzeitumge-

bung nutzen. Mit Einfuhrung des OSGi-Standards 4.2 (Marz 2010) arrangiert der ”Remote

Service Admin Service” die Konnektivitat fur ”Distributed Services” externer Laufzeitum-

gebungen in einem Netzwerk [Web+10, S. 19 f.].

2.2 OSGi-Schichtenmodell

Ausgehend von den Begrifflichkeiten der vorherigen Abschnitte sind die Zusammenhange

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

zugehorigen Bundles [Fil12, S. 139].

Bundleschicht: Auch wenn in Abbildung 2.3 die Bundles als unabhangige Komponente ein-

gezeichnet sind, so konnen sie dennoch auf jede logische Schicht zugreifen und von der Le-

benszyklusschicht noch zusatzlich gesteuert werden - siehe Abbildung 2.4.

10


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

Diensteschicht: Der Diensteschicht sind alle in Abschnitt 2.1.2 erorterten 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 Zustanden festgelegt. Der MA reguliert bzw. manipuliert die Bundle-Zustande.

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

11


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 wahrend der Laufzeit.

Modulschicht: Der Modulschicht sind alle Objektinstanzen der Bundles hinterlegt. Zudem

konnen die vom Bundle benotigten Klassen uber den Class-Loader aus der Modulschicht ge-

laden werden.

Sicherheitsschicht: Die Funktionalitat 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 Tatigkeit 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 Spezifikationen 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 jahrlichen Gebuhr von USD $ 25,000.

(2) mit Teilnahme an Experten-Zirkeln und einer jahrlichen Gebuhr von USD $ 20,000 (≥250 Beschaftigte) oder USD $ 10,000 (≤ 249 Beschaftigte).

(3) ohne Sitz im Ausschuss oder Teilnahme an Zirkeln, mit technisch-unterstutzenden Hin-

tergrund und einer jahrlichen Gebuhr von USD $ 5,000

(4) mit der Berechtigung das Logo der OSGi-Alliance auf der firmeneigenen Website zu

fuhren.

Um die Funktionalitat der OSGi-Service-Platform nutzen zu konnen, 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


der Investition von Zeit und Finanzen, oder auf bereits zertifizierte kommerzielle oder Open-

Source Losungen 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 ermoglich, 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 zertifizierte Losungen [All15a]:

Kommerziell:

• Makewave Knopflerfish 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 Knopflerfish (www.makewave.com)

• Apache Felix Framework 3.0.0 (http://felix.apache.org)

13

3 openHAB

Mit openHAB bietet die openHAB UG (haftungsbeschrankt) - Firmengrundung am 06.01.2014,

Grundungsmitglieder: Kai Kreuzer, Thomas Eichstadt-Engelen und Victor Belov - eine Soft-

warelosung 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 plattformunabhangig, 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 Endgerate 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 Softwarelosung fur die HA unter dem Namen

”SmartKNX” - wegen evtl. Markenrechtsverletzungen ab Februar 2010 fortan openHAB ge-

nannt. 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 anfanglich 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 applicati-

on, 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-

einhalbjahrige Entwicklung (Release Version 1.0) auf und mit dem Release Version 1.2 (April

2013) veroffentlicht die openHAB UG samtliche 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 unter-

teilt: 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 zugehorigen 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 Abhangigkeit 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-

litaten [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-Aktivitaten. 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-Aktivitaten. Eine Protokollierung in Abhangigkeit einzelner Berechtigungen ist

dadurch realisierbar.

• Das Aufstellen einer Trace fur eine evtl. Fehlerbeseitigung.

• Das Einhangen von zusatzlichen 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 konnen

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 Abhangigkeiten 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 ”Configuration 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 erortert. Die Klasse

”OSGILogListener”, als Bestandteil der Core-Komponente, implementiert den ”LogListener”

und ”LogReaderService” und dient als Adapter um die Protokolleintrage 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.


8: case LogService.LOG_WARNING: logger.warn(marker , entry.


9: case LogService.LOG_ERROR: logger.error(marker , entry.


10: }

11: }

12: }

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

Kreuzer K.]

Event Admin: Der ”Event Admin Service” ermoglicht die Kommunikation zwischen Bund-

les auf Grundlage eines ”Event-Publish-Subscribe”- Modells. Fur die Kommunikation sen-

det 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 spezifischen ”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 im-

plementiert: 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” ermoglicht 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 eigenstandiges Binding (configadmin) in der

Klasse ”ConfigAdminBinding” implementiert. Bei Aufruf der ”bindingChanged”-Methode wird

die Konfiguration fur den entsprechenden ”ManagedService” angepasst [Uh15m, Eichstadt-

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 mochten. 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” primar 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 ermoglichen. Neben dieser Kernfunktionalitat 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 konnen 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 ermoglicht 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

Zeitabstanden 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” gehoren alle Funktionalitaten

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 Benutzeroberflache (org.openhab.ui) realisiert.

openHAB REST Service - Der ”openHAB Rest Service” ist das REST-Binding (open-

hab.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” zugehorig 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 - Ermoglicht 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 konnen Google Kalender Eintrage 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 konnen

um openHAB mit der eigenen Stimme zu kontrollieren [Uh15c].

• .net - Dieses Paket enthalt 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: Grundsatzlich 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 eigenstandige 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 moglichst einfach zu halten, wird die Konfiguration uber die deklarativen

UI-Definitionen der Sitemaps realisiert. Die Sitemaps sind wie die Skripte in Xtext geschrie-

ben [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 anfanglich

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. Reprasentativ 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

Komplexitat sind in dem Diagramm keine Attribute oder Methoden dargestellt. Die ”HueBinding”-

Klasse ist die zentrale Komponente des Bindings. Sie verwirklicht die Schnittstellenfunktiona-

litat 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, Lichtintensitat, 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

Lichtintensitat 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 Plausibilitatsprufung der ”HueSettings” vorangestellt,

die moglichen 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 aufzulosen. 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 angehoren, ausfuhren [Uh15m, Kreuzer K., Eichstadt-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 Abhangigkeitsverwaltung 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 konfiguriert 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 Funktionalitat

der Applikation ist zu vergleichen mit der eines einfachen Text-Editors der zusatzlich eine

Syntaxuberprufung, Syntaxhervorhebung und Autovervollstandigung fur die Sitemaps, Items,

Skripte und Regeln anbietet [Uh15i].

3.4 Automation

Die in Abschnitt 3.1.3 getroffenen 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 Rollladen 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 Strukturblocke gleichen denen von Java-Dateien: 1. Import, 2.

Variablen-Deklarationen und 3. Regeln (when-then-Block). Um Regeln auszulosen bietet die

openHAB-Software drei unterschiedliche Varianten von Triggern an [Uh15p]. Dabei konnen

Regeln ausgefuhrt werden wenn...

• ... sich der Status eines Items geandert hat oder selbiges ein Kommando erhalt (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,

Eichstadt-Engelen T. al. teichsta].

Aktionen: Die Aktionen sind Java-Methoden deren Funktionalitat den Regeln und Skripten

zur Verfugung steht. Die openHAB-Runtime bietet bereits Aktionen an [Uh15a]:

• Die dem ”openHAB Event Bus” zugehorigen Aktionen zum Senden eines Events, ak-

tualisieren eines Item-Status und speichern oder wiederherstellen von Status eines oder

mehrerer Items.

• Alle audio-relevanten Aktionen fur die Steuerung der Lautstarke, 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”

serienmaßig verfugbar sind. Alle weiteren Aktionen mussen vom Endanwender als Add-on

nachinstalliert werden - hierzu zahlen [Uh15a]:

• Die Aktionen um SMTP (Simple Mail Transfer Protocol) Dienste zu nutzen oder ei-

ne Kommunikation mit dem XMPP (Extensible Messaging and Presence Protocol) zu

realisieren.

• Und zudem Aktionen um Nachrichten an iOS oder Android Gerate 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 planmaßig ausgelost werden. Fur die planmaß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) konnen die Services uber die Java-Interfaces

genutzt und uber die Methoden des Lebenszykluses modifiziert 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 moglich. 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 zugehoriger 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/)

• InfluxDB (http://influxdb.org/)

• und JPA

In der Implementierung des MySQL-Bindings wird z. B. automatisch die Konnektivitat 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, Sjostrand H., Eichstadt-

Engelen T., Jackson C.]

Fur jedes openHAB-Item, das in der Item-Sektion aufgelistet ist, legt openHAB automatisch

eine Tabelle an, in der die Entitaten der Items als (Time, Value)-Paare gespeichert sind. Der

Endanwender hat somit keinen Einfluss auf die Tabellenstruktur oder Aufbau der Entitaten.

3.7 Sonstiges

Neben den in Abschnitt 3.1.2 erorterten 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].

Erwahnenswert 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 erortert, inwieweit openHAB die Programmierparadigmen des OSGi-Standards

aus Kapitel 2 umsetzt bzw. verfolgt. Auf dieser Wissensbasis aufbauend, soll nun ein realitatsna-

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 ei-

gentliche Durchfuhrung des Szenarios beschrieben. Eine detaillierte Ergebnisauswertung und

alternative Losungsansatze 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 Gegenstanden bei

den eingesetzten Technologien und Verfahren gleichermaßen anzuwenden. Neben moglichen

Anwendungsbereichen der Bewegungserkennung von Personen in Zweckbauten, wie z. B. die

Uberwachung von Arbeitnehmern in Burogebauden 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

Raumlichkeit 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 erwahnten 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 Handen, Fußen oder

am Oberkorper der Personen vorsehen. Die INSs (Inertial Navigation Systems) verwenden

neben Tragheits- und Beschleunigungssensoren auch Gyroskope und Magnetometer, die

neben der Lokalisierung auch eine Navigation ermoglichen - die SHSs (Step-and-Heading

Systems) nutzen zudem Barometer und Funkschnittstellen. Zwar liegt der Fokus der

27


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 sen-

sor 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 Endgerat stehen Barometer, Bluetooth, WLAN,

GPS, Gyroskop, Beschleunigungs- und Helligkeitssensor zur Auswahl. [Iwa+13] zeigt

einen Losungsansatz 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 Raumlichkeit verbaut bzw. installiert sind.

a) vision based - Fur die Bewegungserkennung werden Bilder von hochauflosenden Kameras

ausgewertet. Die Prazision der Systeme reicht bis hin zur fingergenauen Gestenauswer-

tung [Uts+02].

b) ambient device based - Diese Systeme benotigen fest installierte Bewegungs-, oder

Prasenzmelder, 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 mogliche Auswertung der Fort-

bewegung von Personen hin.

Fur (1) ist nachteilig zu erwahnen, dass - bis auf ein evtl. vorhandenes Smartphone - alle

Endgerate 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 Raumlichkeiten des privaten Wohnraums begrenzt oder konnen nicht in der

Dunkelheit ausgewertet werden. Bei (1b) bedarf es zudem einer Planung vor Fertigstellung der

Lokalitat - 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.

Grundsatzlich konnten diese Systeme fur eine korrekte Szenariodurchfuhrung angewendet wer-

den, dennoch soll aufgrund der genannten Defizite die Klasse (2) um ”rf device based” Systeme

erganzt und fur das in diesem Kapitel beschriebene Szenario verwirklicht werden: Darunter fal-

len alle Systeme, die keine Sensorik an den Personen vorsehen, einen funkbasierten Ansatz

(Radiowellen) verfolgen und die vorhandene Infrastruktur nutzen. Die Radiowellen benotigen

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 Ansatze: In [Han+14]

wird ”WiFall” vorgestellt - ein System das den Sturz einer Person mit 87% Wahrscheinlichkeit

28


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 konnte. 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 Prasenz von Vehikel er-

kennt und deren Geschwindigkeit abschatzen 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

zugehorigen 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 herstellerabhangige 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


• Software: Zur Kommunikation des Controllers mit den Leuchten, implementiert das

Produkt die ZigBee Spezifikation 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 ”tcp-

dump” (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 Konfiguration

Nach Installation des Ubuntu-Betriebssystems und der Laufzeitumgebung auf dem Leitrechner,

ist die openHAB-Software nach den in [Uh15h] beschriebenen Schritten zu konfigurieren. Im

Anhang 7.1.1 sind die notwendigen Zeilen fur eine openHAB und Hue-Bridge Konfiguration

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


mit dem Systemstart von Ubuntu initialisiert werden [Uh15k]. Fur die Steuerung der Hue-

Leuchten uber die Hue-Bridge ist keine weitere Konfiguration notwendig.

[wik15b] beschreibt die Installation von OpenWrt auf den WAPs und beinhaltet die Benutzero-

berflache ”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 ermoglichen,

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-Zugriff 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 Benutzeroberflache 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 spatere Szenariodurchfuhrung analysiert

werden soll, inwieweit die Gute der Bewegungserkennung von der Anzahl der analysierten

Pakete abhangt, 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” gesnifften Pakete werden an die Lua-Skripte zur

Auswertung weitergereicht. Um openHAB eine Bewegungserkennung zu signalisieren und die

REST-API anzusprechen, wird das Paket ”luasocket” benotigt [Neh15].

Fur eine Auswertung der Ergebnisse ist die MySQL-Datenbank [ubu15] und das MySQL-

Binding [Uh15l] zu installieren und zu konfigurieren. Die Strategien zur Speicherung der

openHAB-Items sind, wie im Anhang 7.1.4 dargestellt, umzusetzen.

31


4.3 Implementierung

Durch die zuvor deklarierte Sitemap (7.1.3) und die angegebenen Items (7.1.2) visualisiert der

Webserver die Benutzeroberflache (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 konnen. Zudem konnen die Leuchten

auf alle Farben aus dem HSV-Farbraum gesetzt werden.

2 Profil erstellen: Diese Sektion ermoglicht dem Anwender das Messen einer Signalstarke

fur die vorliegende Raumlichkeit und die eingestellte Distanz zwischen Sender und Re-

ceiver. Standardmaßig ist die Dauer der Messung auf zehn Sekunden eingestellt. Der

Ruckgabewert ist die durch die Anzahl der uber den Zeitraum gemessenen Pakete ge-

mittelte Signalstarke und wird automatisch in ”gespeicherte Signalstarke” eingetragen.

Zudem wird die maximal und minimal gemessene Signalstarke an die Benutzeroberflache

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 spatere Szenariodurchfuhrung ist der absolute Signalstarkenunterschied

von gespeicherter Signalstarke aus Sektion 2 und in gemessener Signalstarke aus Sekti-

on 3 individuell einstellbar. Falls der Receiver eine Signalstarke misst, die den einstellten

Grenzwert uberschreitet, wird die Signalstarke eingetragen und somit die Bewegung er-

kannt. 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 Abhangig-

keiten zwischen der Gute der Bewegungserkennung und Anzahl der gemessenen Pakete

aufzuzeigen, kann der Anwender zusatzlichen Netzwerk-Verkehr beim Sender erzeugen

- UML-Squenzdiagramm 4.4.

5 Graph: Die funfte Sektion zeigt die graphische Visualisierung der unterschiedlichen Si-

gnalstarken.

Das Ziel der Implementierung ist es, eine Bewegung anhand einer Grenzwertuberschreitung

von gemessenen Signalstarken 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 erortert 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 Benutzeroberflache zur Verfugung und die openHAB-Items werden durch die Regel ”In-

32


itialize Items” (7.1.5) initialisiert. Sobald der Anwender die Dauer eingestellt und den Schalter

fur ”Signalstarke messen” betatigt hat, startet die Messung. Durch Betatigung andert 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 Lichtintensitat 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 - Profil 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 ausgewahlter

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


Signalstarke und den Anderungen der Leuchten ein Ende der Messung signalisiert. Fur die

Visualisierung der Signalstarken in Sektion 5 werden die Signalstarken mit der Konfiguration

der Persistenz (7.1.4) gespeichert. Durch die gewahlten 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 Signalstarkenunterschied eingestellt. Durch die Betatigung 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 Signalstarke, 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 erorterten Anwendungsfall nutzt das Lua-Skript die vom

”tcpdump” gesnifften Pakete und uberpruft, ob die gespeicherte Signalstarke und die derzeitig

ermittelte Signalstarke 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 betatigt und dadurch die Regel ”Stop

recognizing movement” anstoß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 auslost.

34


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 zusatzlichen Netzwerk-Verkehr in Form von 64 Byte

großen UDP-Paketen erzeugen. Bei Betatigung 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 Signalstarken 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 - Zusatzliche 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

Signalstarken - 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 moglich.

35


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

Hohe 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 beeintrachtigt. 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


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 Benutzeroberflache erfolgt uber die Android-Applikation ”HABDroid” [Uh15j]. Nach

dieser Ruhe-Phase betritt die Testperson den Raum: Sie offnet die Tur und geht langsamen

Schrittes durch die LOS der WAPs hindurch - bis zur eingezeichneten Fensterwand, kehrt um

verlasst 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 realitatsnahen 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. Mogliche 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 hangt somit von folgenden Parametern ab: Die Dauer fur

die Profilerstellung und somit die Anzahl der Pakete fur die Mittelwertbildung der gespei-

cherten Signalstarke, der eingestellte absolute Grenzwert fur den Signalstarkenunterschied 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 Zusammenhange bzw. Abhangigkeiten 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 Messdurchlaufe. 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 zusatzlichen 25pps genutzt.

Abbildung 5.1: Messergebnisse fur den Anwendungsfall ”Profil 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 ”Profile erstellen” zu begrunden und ist fur Ruhe- und Bewegungs-Phase

gleichgesetzt. Die False-Positives - eine falschlicherweise erkannte Bewegung in der Ruhe-Phase

38


- sind die prozentualen Anteile der Grenzwertuberschreitungen fur die Anzahl der Messungen.

Fur die Messdurchlaufe #1-3 und #6 ist ein False-Positive aufgetreten. Die moglichen Er-

klarungen 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 Messdurchlaufe #3 und

#6 ist auf dem Smartphone mit der HABdroid Applikation zusatzlicher 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


Dem Anhang 7.5 sind die Visualisierungen der Messdurchlaufe beigefugt und geben weiteren

Aufschluss uber die Abhangigkeit zwischen verwendeter Sendeleistung, Distanz und einge-

stelltem Grenzwert. Wenn auch die Messdurchlaufe #1-7 eine prazise Grenzwerteinstellung

aufweisen, waren bei Justierung des Grenzwertes fur die Messdurchlaufe #8, #10 und #11

mehr Uberschreitungen zu verzeichnen. Der Grenzwert ist die Abweichung der in ”Profil erstel-

len” gemessenen minimalen und maximalen RSSI zum gemittelten RSSI fur eine Dauer von 60

Sekunden. Bei Verwendung der mittleren quadratischen Abweichung konnten mehr Messwerte

als ”Bewegung ” erkannt werden, jedoch auch die Anzahl der False-Positives ansteigen - eine

Messung uber einen langeren Zeitraum ist obligatorisch.

Die Visualisierungen zeigen deutlich, dass fur alle Distanzen und Sendeleistungen sowohl bei

als auch eingeschrankter 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 Ansatze

Die in diesem Abschnitt aufgelisteten alternativen Ansatze sollen fur das Szenario der Bewe-

gungserkennung auf bereits implementierte openHAB-Bindings fur herstellerabhangige Hard-

warekomponenten und Einsatz von Open-Source-Software hinweisen. Bei Anwendung der

Ansatze 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


• Quelle: http://www.elv.de/fs20-piri-2-hr-funk-bewegungsmelder-mit-dimme

rsteuerung.html/refid/zanox/zanpid/2019358387397334016

EnOcean:

• openHAB: EnOcean-Binding


• Quelle: http://shop.loxone.com/dede/enocean-funk-bewegungsmelder.html

40

http://www.eq-3.de/sensoren-detail/items/hm-sec-mdir.html

http://www.elv.de/fs20-piri-2-hr-funk-bewegungsmelder-mit-dimmersteuerung.html/refid/zanox/zanpid/2019358387397334016

http://www.elv.de/fs20-piri-2-hr-funk-bewegungsmelder-mit-dimmersteuerung.html/refid/zanox/zanpid/2019358387397334016

http://shop.loxone.com/dede/enocean-funk-bewegungsmelder.html


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:


• 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:


• Die Open-Source Software ”jmt” verwendet das Java Media Framework.

• Quelle: https://code.google.com/p/java-motion-tracking/

JMyron:


• ”JMyron” ist eine Open-Source Bibliothek fur die Bildmanipulation und Bewegungser-

kennung.

• Quelle: http://www.silentlycrashing.net/p5/libs/jmyron/

OpenCV:


• 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:


• Mit der ”sphinx4” Software konnen Audiosignale analysiert werden (Prasenzerkennung).

• 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

https://code.google.com/a/eclipselabs.org/p/jnect/

http://www.tinkerforge.com/de/doc/Software/Bricklets/MotionDetector_Bricklet_Java.html

http://www.tinkerforge.com/de/doc/Software/Bricklets/MotionDetector_Bricklet_Java.html

https://code.google.com/p/java-motion-tracking/

http://www.silentlycrashing.net/p5/libs/jmyron/

http://opencv.org/

http://cmusphinx.sourceforge.net/wiki/tutorialsphinx4/

https://www.leapmotion.com/product

6 Zusammenfassung und Fazit

Die vorherrschende Inkompatibilitat zur Interoperabilitat der herstellerabhangigen Technologi-

en aus dem Bereich der Heim- bzw. Gebaudeautomatisierung zwingt die Hersteller zur Ent-

wicklung von Hard- und Softwarelosungen. Einige dieser Losungen sind lediglich als Gateway

zweier Standards bzw. Protokolle angedacht und konnen daruber hinaus nicht mit anderen

Produkten konkurrieren. In jungster Zeit sieht der Trend der Automatisierung eine Softwa-

relosung auf dem Leitrechner vor, die alle konkurrierenden Hard- und Softwarekomponenten

vereinigen kann. Die openHAB-Software ist eine solche Losung 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 fur den IoT-Service der Wahl unverstandlich ist?

Was, wenn alle”Dinger“ mit einer einheitlichen Oberflache bedient, ein gemein-

sames Chart mit Daten bestucken, oder gemeinsamen Automatisierungsregeln fol-

gen sollen? In diesem Fall konnen Integrationsplattformen helfen, die fur diese

Problemstellungen Losungen anbieten. [EE15, 1. April 2012].

Wenn auch Thomas Eichstadt-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 aufgelosten Programmkomplexitat 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 Abhangigkeiten der Protokollimplementierungen (openHAB-Bindings) ermogli-

chen das (de-)installieren und konfigurieren von Diensten wahrend der Laufzeit und sind somit

autark: Hot Deployment. Statische Abhangigkeiten sind nur fur die Kernkomponenten einge-

setzt.

Aufgrund einer zentralen Konfiguration 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 zuganglicher 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 Ansatzen, kann Thema wei-

tere Projekte auch eine verteile openHAB-Automatisierung uber externe Laufzeitumgebungen

sein.

Fur das in dieser Arbeit vorgestellte und durchgefuhrte realitatsnahe Szenario gilt eine Bewe-

gungserkennung von Personen durch die Auswertung der empfangenen Signalstarke 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 langeren Zeitraum abzuhalten und die Entwicklung

bis hin zur automatischen Konfiguration der WAPs fortzufuhren. Fur die Abschatzungen 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 Lokalitat gibt. Storeinflusse durch evtl. Endgerate auf dem gleichen Fre-

quenzband bleiben unberucksichtigt. Zudem wird darauf hingewiesen, dass eine Auswertung

der Signalstarken fur alle Kanale 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 Konfiguration - 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-Konfiguration

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 arke messen" icon="

fire"

15: Text item=RSSI_Profile label= "gespeicherte Signalst arke:

[%.2 fdB]" icon="chart"

16: Text item=RSSI_Profile_min label="min. Signalst arke [%.2

fdB]" icon="chart"

17: Text item=RSSI_Profile_max label="max. Signalst arke [%.2

fdB]" icon="chart"

18: }

19:

45

7 Anhang

20: Frame label="Bewegung erkennen" {

21: Setpoint item=Threshold_Value label="Grenzwert fur

Signalst a rkenunterschied (abs): [%.1 fdB]" 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 arke:

[%.2 fdB]" icon="chart"

24: Text item=RSSI_Threshold label="Bewegung erkannt fur

Signalst arke: [%.2 fdB]" 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: Konfiguration der openHAB-Sitemap

7.1.4 Konfiguration - 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 Signalstarken

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: Konfiguration der MySql-Persistenz

1: (SELECT * FROM openhab.Item4 ORDER BY openhab.Item4.Time)

2: UNION


4: UNION


6: UNION


8: UNION


10: UNION


12: ORDER BY 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")


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 command ON

56: then

57: var rssi_profile = (RSSI_Profile.state as DecimalType)

58: var threshold_value = (Threshold_Value.state as DecimalType)


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 from ON to OFF

67: then


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")



83: Thread ::sleep (500)



86: end

87:

88: rule "Send more packets"

89: when

90: Item Do_MGen received command ON

91: then

92: var packet_value = (Packet_Value.state as DecimalType).

intValue


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 from ON to OFF

101: then


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-Zugriff - 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 root@10 .20.114.48 ’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 root@10 .20.114.48 ’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 root@10 .20.114.48 ’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 root@10 .20.114.45 ’cd /etc/ &&

mgen input udpgen ’"$2"’.mgn ’

30: else

31: sshpass -p ’openhab1!’ ssh root@10 .20.114.45 ’kill -9 $(

pidof mgen)’

32: fi

51

7 Anhang

33: fi

34: fi

35: exit

Quelltext 7.8: Bash-Skript fur Remote-Zugriff auf Sender und Receiver

7.2 TP-Link WLAN Router - Receiver

7.2.1 Konfiguration - 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 ’


21: option ipaddr ’10.10.10.48 ’

22: option netmask ’255.255.255.0 ’

Quelltext 7.9: Ausschnitt der Netzwerk-Konfiguration

7.2.2 Konfiguration - 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:




13: option hwmode ’11a’

14: option path ’pci0000 :00/0000:00:00.0 ’


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:



29: option ssid ’OpenWrt ’

30: option mode ’monitor ’

Quelltext 7.10: Wireless-Konfiguration

7.2.3 Konfiguration - 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-Konfiguration

53

7 Anhang

7.2.4 Profil 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-Profil erstellen

7.2.5 Bewegung erkennen - Lua Skript

1: require "socket"


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-Differenz erkennen

7.2.6 Kommandos fur openHAB REST-API - Lua Skript

1: local http = require "socket.http"

2: local ltn12 = require "ltn12"


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: return RSP ,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: return RSP

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 Konfiguration - Netzwerk

1: ...

2: config interface ’lan’

3: option force_link ’1’


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 ’


22: option netmask ’255.255.255.0 ’

23: option ipaddr ’10.10.10.45 ’

24: ...

58

7 Anhang

Quelltext 7.16: Ausschnitt der Netzwerk-Konfiguration

7.3.2 Konfiguration - Wireless




4: option hwmode ’11g’

5: option path ’platform/ar934x_wmac ’




9:




13: option hwmode ’11a’

14: option path ’pci0000 :00/0000:00:00.0 ’




18:



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-Konfiguration

7.3.3 Multi-Generator Skript

1: START NOW

2: INTERFACE wlan0

3: 0.0 ON 1 UDP DST 10.10.10.48/31337 PERIODIC [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 Benutzeroberflache [Uh15u]

60

7 Anhang

Abbildung 7.2: Sub-Menu der Benutzeroberflache - Steuerung der Leuchten [Uh15u]

7.5 Ergebnisse und Messwertvisualisierung

Abbildung 7.3: Visualisierung fur Messdurchlauf #1


61

7 Anhang




62

7 Anhang




63

7 Anhang




64

7 Anhang

Abbildung 7.14: Anmerkungen zu den einzelnen Messdurchlaufen

65

8 Eidesstattliche Erklarung

Hiermit erklare 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 Prufungsbehorde vorgelegt und auch noch nicht

veroffentlicht.

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_DepatlaMuralidharanMostofi.pdf (besucht am 10. 06. 2015) (zitiert auf Seite 43).

[All15a] The OSGi Alliance. Certified Products. 2015.url: http://www.osgi.org/Certification/Certified (besucht am14. 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 Specification - Release 4, Version4.3 April 2011. 2015.url: https://osgi.org/download/r4v43/osgi.core-4.3.0.pdf (besuchtam 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 (besuchtam 11. 04. 2015) (zitiert auf Seiten 4, 9, 10, 16–18).

[All15e] The OSGi Alliance. Technology. 2015.url: http://www.osgi.org/Technology/HomePage (besucht am14. 04. 2015) (zitiert auf Seite 12).

[Alw+06] M. Alwan, P.J. Rajendran, S. Kell, D. Mack, S. Dalal u. a. “A Smart and PassiveFloor-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_international_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/index.php (besucht am 07. 04. 2015) (zitiert auf Seite 1).

67

http://www.ece.ucsb.edu/~ymostofi/papers/JSAC15_DepatlaMuralidharanMostofi.pdf

http://www.ece.ucsb.edu/~ymostofi/papers/JSAC15_DepatlaMuralidharanMostofi.pdf

http://www.osgi.org/Certification/Certified

http://www.osgi.org/Join/HomePage

https://osgi.org/download/r4v43/osgi.core-4.3.0.pdf

https://osgi.org/download/r4v43/osgi.cmpn-4.3.0.pdf

http://www.osgi.org/Technology/HomePage

http://www.domo-energie.com/usr_file/Pdf/knx_is_international_standard.pdf

http://www.domo-energie.com/usr_file/Pdf/knx_is_international_standard.pdf

http://www.knx.org/knx-en/knx/technology/standardisation/index.php

http://www.knx.org/knx-en/knx/technology/standardisation/index.php


[Aut15] IANA Internet Assigned Numbers Authority. MIME-Tpe Application - vnd.osgi.bundle.2015.url: http://www.iana.org/assignments/media-types/application/vnd.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 am07. 04. 2015) (zitiert auf Seite 1).

[Com15] KUNBUS Industrial Communication. BatiBUS - already ”history” for a long time,but still significant! 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 aufSeite 18).

[EE15] Thomas Eichstadt-Engelen. Die Welt der Dinge in deiner Hand - openHAB alsIntegrationsplattform 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 thevariance of the received signal strength of wireless links”. In: Personal Indoor andMobile 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 aufSeite 13).

68

http://www.iana.org/assignments/media-types/application/vnd.osgi.bundle

http://www.iana.org/assignments/media-types/application/vnd.osgi.bundle

http://www.cenelec.eu/dyn/www/f?p=104:110:1746994019214401::::FSP_ORG_ID,FSP_PROJECT,FSP_LANG_ID:1258281,53681,25

http://www.cenelec.eu/dyn/www/f?p=104:110:1746994019214401::::FSP_ORG_ID,FSP_PROJECT,FSP_LANG_ID:1258281,53681,25

http://www.kunbus.com/batibus.html

http://misterhouse.sourceforge.net/

https://jersey.java.net/

https://www.innoq.com/de/articles/2012/04/internet-of-things/

https://www.innoq.com/de/articles/2012/04/internet-of-things/

http://knx-user-forum.de/forum/supportforen/openhab/25148-%E2%88%9A-tolle-arbeit-wie-geht-s-weiter

http://knx-user-forum.de/forum/supportforen/openhab/25148-%E2%88%9A-tolle-arbeit-wie-geht-s-weiter

http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Buddy_Class_Loading

http://wiki.eclipse.org/index.php/Context_Class_Loader_Enhancements#Buddy_Class_Loading


[Fou15b] The Eclipse Foundation. FAQ What are extensions and extension points? 2015.url: http://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_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 aufSeiten 18, 20).

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

[Gmb15a] EnOcean GmbH. Flexible Brucke 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=article&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 falldetection 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 (besuchtam 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 (besuchtam 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

http://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F

http://wiki.eclipse.org/FAQ_What_are_extensions_and_extension_points%3F

http://eclipse.org/jetty/

http://www.eclipse.org/equinox/

https://www.enocean.com/de/flexible-bruecke-von-knx-zu-enocean/

https://www.enocean.com/de/flexible-bruecke-von-knx-zu-enocean/

http://www.insta.de/index.php?option=com_content&view=article&id=26

http://www.insta.de/index.php?option=com_content&view=article&id=26

http://www.omtec.de/embedded-server/lex-uno-uno-3i270d-v4g-h16-00/

http://www.omtec.de/embedded-server/lex-uno-uno-3i270d-v4g-h16-00/

https://www.dropbox.com/developers/core/sdks/java

https://ifttt.com/wtf

http://www.openremote.org/display/HOME/OpenRemote

http://www.wi-fiplanet.com/tutorials/article.php/1492071


[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) (zitiertauf Seite 24).

[Iwa+13] T. Iwase und R. Shibasaki. “Infra-free indoor positioning using only smartphonesensors”. In: Indoor Positioning and Indoor Navigation (IPIN), 2013 InternationalConference 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 aufSeite 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 am08. 04. 2015) (zitiert auf Seite 1).

[Kas+12] N. Kassem, A.E. Kosba und M. Youssef. “RF-Based Vehicle Detection and SpeedEstimation”. 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-freepassive 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) (zitiertauf Seiten 14, 15, 20–22, 25).

[May15] Christian Mayer. CometVisu. 2015.url: http://www.cometvisu.org/wiki/CometVisu (besucht am18. 05. 2015) (zitiert auf Seite 20).

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

70

http://quartz-scheduler.org/documentation/quartz-2.1.x/quick-start

http://quartz-scheduler.org/documentation/quartz-2.1.x/quick-start

http://www.quartz-scheduler.org/documentation/quartz-2.1.x/tutorials/tutorial-lesson-06

http://www.quartz-scheduler.org/documentation/quartz-2.1.x/tutorials/tutorial-lesson-06

http://jmdns.sourceforge.net/

http://www.heise.de/ct/ausgabe/2015-4-Internet-der-Dinge-Heimautomation-und-Smart-Homes-2521024.html

http://www.heise.de/ct/ausgabe/2015-4-Internet-der-Dinge-Heimautomation-und-Smart-Homes-2521024.html

http://kaikreuzer.blogspot.de/

http://www.cometvisu.org/wiki/CometVisu


[Neh15] Diego Nehab. What is LuaSocket? 2015.url: http://w3.impa.br/~diego/software/luasocket/ (besucht am05. 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] Gunther Ohland. Die Brucke 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 aufSeiten 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) (zitiertauf Seite 31).

[Uh15a] openHAB UG (haftungsbeschrankt). Actions. 2015.url: https://github.com/openhab/openhab/wiki/Actions (besucht am20. 05. 2015) (zitiert auf Seite 24).

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

[Uh15c] openHAB UG (haftungsbeschrankt). 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 (haftungsbeschrankt). 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 (haftungsbeschrankt). Features. 2015.url: http://www.openhab.org/features.html (besucht am 15. 04. 2015)(zitiert auf Seite 14).

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

71

http://w3.impa.br/~diego/software/luasocket/

http://www.funkschau.de/fileadmin/media/heftarchiv/pdf/2010/01-02/fs_1001-2_s22-s23_gebaeude.pdf

http://www.funkschau.de/fileadmin/media/heftarchiv/pdf/2010/01-02/fs_1001-2_s22-s23_gebaeude.pdf

https://openclipart.org/

http://www.slf4j.org/

http://wiki.ubuntuusers.de/mysql

https://github.com/openhab/openhab/wiki/Actions

https://github.com/openhab/openhab/wiki/Application-Integration

https://github.com/openhab/openhab/wiki/Application-Integration

https://github.com/openhab/openhab/wiki/Controlling-openHAB-with-your-voice

https://github.com/openhab/openhab/wiki/Controlling-openHAB-with-your-voice

https://github.com/openhab/openhab/wiki/Explanation-of-Sitemaps

https://github.com/openhab/openhab/wiki/Explanation-of-Sitemaps

http://www.openhab.org/features.html

https://github.com/openhab/openhab/wiki/GCal-Binding


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

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

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

[Uh15j] openHAB UG (haftungsbeschrankt). HABDroid. 2015.url: https://github.com/openhab/openhab/wiki/HABDroid (besucht am10. 06. 2015) (zitiert auf Seite 37).

[Uh15k] openHAB UG (haftungsbeschrankt). How to configure openHAB to start auto-matically 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 (haftungsbeschrankt). MySQL Persistence. 2015.url: https://github.com/openhab/openhab/wiki/MySQL-Persistence(besucht am 09. 06. 2015) (zitiert auf Seite 31).

[Uh15m] openHAB UG (haftungsbeschrankt). 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 aufSeiten V, 16–19, 21, 22, 26).

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

[Uh15o] openHAB UG (haftungsbeschrankt). REST-API. 2015.url: https://github.com/openhab/openhab/wiki/REST-API (besucht am08. 06. 2015) (zitiert auf Seite 33).

[Uh15p] openHAB UG (haftungsbeschrankt). Rules. 2015.url: https://github.com/openhab/openhab/wiki/Rules (besucht am20. 05. 2015) (zitiert auf Seite 23).

[Uh15q] openHAB UG (haftungsbeschrankt). Scripts - Introduction. 2015.url: https://github.com/openhab/openhab/wiki/Scripts (besucht am18. 05. 2015) (zitiert auf Seite 19).

72

https://github.com/openhab/openhab/wiki/GPIO-Binding

http://www.openhab.org/gettingstarted.html

https://github.com/openhab/openhab/wiki

https://github.com/openhab/openhab/wiki/HABDroid

https://github.com/openhab/openhab/wiki/Samples-Tricks#how-to-configure-openhab-to-start-automatically-on-linux-with-screen



https://github.com/openhab/openhab/wiki/MySQL-Persistence

https://github.com/openhab/openhab/releases/download/v1.6.2/distribution-1.6.2-runtime.zip

https://github.com/openhab/openhab/releases/download/v1.6.2/distribution-1.6.2-runtime.zip

https://github.com/openhab/openhab/wiki/Persistence

https://github.com/openhab/openhab/wiki/REST-API

https://github.com/openhab/openhab/wiki/Rules

https://github.com/openhab/openhab/wiki/Scripts


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

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

[Uh15t] openHAB UG (haftungsbeschrankt). Using RRD4j Charts. 2015.url: https://github.com/openhab/openhab/wiki/Charts (besucht am10. 06. 2015) (zitiert auf Seite 35).

[Uh15u] openHAB UG (haftungsbeschrankt). 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 valuedistribution model for multiple-camera-based gesture interactions”. In: KnowledgeMedia 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 fur 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 am02. 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 am02. 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. Wutherich. Die OSGi Service Platform: eine Einfuhrung mit Eclipse Equinox.dpunkt, 2008.(Zitiert auf Seiten 4, 5).

73

https://github.com/openhab/openhab/wiki/Squeezebox-Binding

http://www.openhab.org/features-ui.html

https://github.com/openhab/openhab/wiki/Charts

http://www.openhab.org/index.html

http://www.philips.de/c-p/7299760PH/hue-personal-wireless-lighting-tischleuchte

http://www.philips.de/c-p/7299760PH/hue-personal-wireless-lighting-tischleuchte

https://wikidevi.com/wiki/TP-LINK_TL-WDR4300

http://wiki.openwrt.org/toh/tp-link/tl-wdr4300

http://www.fhemwiki.de/wiki/Hauptseite

Hersteller ubergreifende Heim-/Geb audeautomatisierung ... · 1.1 Aufgabenstellung Der Auftrag des...

Documents

Transcript of Hersteller ubergreifende Heim-/Geb audeautomatisierung ... · 1.1 Aufgabenstellung Der Auftrag des...