Herstellerübergreifende Heim-/Gebäudeautomatisierung beim Einsatz von openhab

Praxisprojektbericht im Studiengang Master Informatik Herstellerübergreifende Heim-/Gebäudeautomatisierung beim Einsatz von openhab von Peter Manheller (9016802) Erstprüfer: Zweitprüfer: Prof. Dr. Karl Jonas M.Sc. Michael Rademacher Zeitraum: 30.03.2015-24.07.2015 Eingereicht am: 26.06.2015

Inhaltsverzeichnis 1 Einleitung 1 1.1 Aufgabenstellung................................. 2 1.2 Zielsetzung.................................... 2 1.3 Vorgehensweise.................................. 3 2 Die OSGi-Service-Platform 4 2.1 OSGi-Framework................................. 5 2.1.1 Bundles................................. 5 2.1.2 Services................................. 8 2.2 OSGi-Schichtenmodell.............................. 10 2.3 OSGi-Implementierungen............................ 12 2.3.1 Eclipse Equinox............................. 13 2.3.2 Sonstige................................. 13 3 openhab 14 3.1 Architektur.................................... 15 3.1.1 OSGi-Framework Komponenten..................... 15 3.1.2 openhab Kernkomponenten....................... 18 3.1.3 openhab Erweiterungen......................... 19 3.2 openhab Runtime................................ 22 3.3 openhab Designer................................ 23 3.4 Automation................................... 23 3.4.1 Regeln, Skripte und Aktionen...................... 23 3.4.2 Jobmanagement............................. 24 3.5 Bindings..................................... 24 3.6 Persistenz.................................... 25 3.7 Sonstiges..................................... 26 4 Bewegungserkennung von Personen 27 4.1 Eingesetzte Hard- und Software......................... 29 4.2 Installation und Konfiguration.......................... 30 4.3 Implementierung................................. 32 4.4 Aufbau und Durchführung............................ 36 5 Ergebnisse und Alternativen 38 5.1 Ergebnisse.................................... 38 5.2 Alternative Ansätze............................... 40 6 Zusammenfassung und Fazit 42 II

Inhaltsverzeichnis 7 Anhang 44 7.1 Lex Uno Station - Leitrechner mit openhab.................. 44 7.1.1 Konfiguration - openhab mit Hue-Binding............... 44 7.1.2 Deklaration - openhab-items...................... 44 7.1.3 Realisierung - openhab-sitemap.................... 45 7.1.4 Konfiguration - openhab-persistence.................. 46 7.1.5 Realisierung - openhab-rules...................... 47 7.1.6 Remote-Zugriff - Bash-Skript...................... 50 7.2 TP-Link WLAN Router - Receiver........................ 52 7.2.1 Konfiguration - Netzwerk........................ 52 7.2.2 Konfiguration - Wireless......................... 52 7.2.3 Konfiguration - Lua Skript........................ 53 7.2.4 Profil erstellen - Lua Skript....................... 54 7.2.5 Bewegung erkennen - Lua Skript.................... 55 7.2.6 Kommandos für openhab REST-API - Lua Skript........... 56 7.2.7 REST-API Kommando für openhab-items - Lua Skript........ 57 7.3 TP-Link WLAN Router - Sender......................... 58 7.3.1 Konfiguration - Netzwerk........................ 58 7.3.2 Konfiguration - Wireless......................... 59 7.3.3 Multi-Generator Skript.......................... 59 7.4 openhab-gui für realisierte Sitemap...................... 60 7.5 Ergebnisse und Messwertvisualisierung...................... 61 8 Eidesstattliche Erklärung 66 Literaturverzeichnis 73 III

Abbildungsverzeichnis 2.1 Beziehungen zwischen Bundles [Fil12, S. 74].................. 8 2.2 Zusammenhang Bundles und Services [Fil12, S. 78]............... 9 2.3 OSGi-Schichtenmodell [i.a.a. All15c, S. 2]................... 10 2.4 Interkation Bundles und Framework-Schichten [Web+10, S. 17]........ 11 2.5 Bundle-Lebenszyklus [i.a.a. All15c, S. 86].................... 11 3.1 openhab Architektur [Uh15i, i.a.a.]...................... 15 3.2 UML-Klassendiagramm des Philips Hue-Bindings................ 21 4.1 Eingesetzte Hard- und Software [ope15]..................... 30 4.2 UML-Sequenzdiagramm - Profil erstellen.................... 33 4.3 UML-Sequenzdiagramm - Bewegungserkennung starten und stoppen...... 34 4.4 UML-Sequenzdiagramm - Zusätzliche UDP-Pakete senden........... 35 4.5 Aufbau des Szenarios in der Hochschule Bonn Rhein Sieg (Raum C060) [ope15] 36 5.1 Messergebnisse für den Anwendungsfall Profil erstellen............ 38 5.2 Messergebnisse für den Anwendungsfall Bewegung erkennen (Ruhe-Phase). 39 5.3 Messergebnisse für den Anwendungsfall Bewegung erkennen (Bewegungs- Phase)...................................... 39 7.1 Main-Menü der Benutzeroberfläche [Uh15u].................. 60 7.2 Sub-Menü der Benutzeroberfläche - Steuerung der Leuchten [Uh15u]..... 61 7.3 Visualisierung für Messdurchlauf #1....................... 61 7.4 Visualisierung für Messdurchlauf #2....................... 61 7.5 Visualisierung für Messdurchlauf #3....................... 62 7.6 Visualisierung für Messdurchlauf #4....................... 62 7.7 Visualisierung für Messdurchlauf #5....................... 62 7.8 Visualisierung für Messdurchlauf #6....................... 63 7.9 Visualisierung für Messdurchlauf #7....................... 63 7.10 Visualisierung für Messdurchlauf #8....................... 63 7.11 Visualisierung für Messdurchlauf #9....................... 64 7.12 Visualisierung für Messdurchlauf #10...................... 64 7.13 Visualisierung für Messdurchlauf #11...................... 64 7.14 Anmerkungen zu den einzelnen Messdurchläufen................ 65 IV

Quelltextverzeichnis 2.1 Manifest - Ausschnitt openhab Core..................... 6 3.1 Ausschnitt - OSGILogListener.class - Delegation an den SLF4J-Logger [Uh15m, Kreuzer K.].................................... 17 3.2 Ausschnitt der execute -Methode der HueBinding -Klasse [Uh15m, Hartmann R., Schering J.].............................. 21 3.3 Ausschnitt des MySQL-Services - Datentypen [Uh15m, Sjöstrand H., Eichstädt- Engelen T., Jackson C.]............................. 25 7.1 Ausschnitt der openhab-konfiguration..................... 44 7.2 Deklaration der openhab-items......................... 44 7.3 Konfiguration der openhab-sitemap...................... 45 7.4 rrd4j-persistenz für Visualisierung der Signalstärken............... 46 7.5 Konfiguration der MySql-Persistenz....................... 47 7.6 MySql-Query für Auswertung der Ergebnisse.................. 47 7.7 openhab-rules für Reaktion auf Nutzer- und Systeminteraktion........ 47 7.8 Bash-Skript für Remote-Zugriff auf Sender und Receiver............ 51 7.9 Ausschnitt der Netzwerk-Konfiguration..................... 52 7.10 Wireless-Konfiguration.............................. 52 7.11 Lua-Konfiguration................................ 53 7.12 RSSI-Profil erstellen............................... 54 7.13 Bewegung anhand der absoluten RSSI-Differenz erkennen........... 55 7.14 REST-API Kommandos (POST / GET).................... 56 7.15 openhab-items auf dem Receiver verarbeiten (optional)............ 57 7.16 Ausschnitt der Netzwerk-Konfiguration..................... 58 7.17 Wireless-Konfiguration.............................. 59 7.18 Multi-Generator Skript für 10 Pakete/s..................... 59 V

Abkürzungsverzeichnis BatiBUS Industrielles Feldbussystem des BCI............................... 1 BCI BatiBUS Club International....................................... 1 CENELEC Comité Européen de Normalisation Électrotechnique............... 1 DDC-GA Direct-Digital-Control-Gebäudeautomation.........................2 Drools Rule Management System Solution der JBoss Community......... 14 EHS European Home Systems......................................... 1 EHSA European Home Systems Association.............................. 1 EIB Europäischer Installationsbus......................................1 EIBA European Installation Bus Association............................. 1 EnOcean Technologie batterieloser Funksensorik Fhem Hausautomations-Server auf Basis von Perl........................ 2 FS20 Protokoll für Funksysteme GA Gebäudeautomatisierung bzw. Gebäudeautomation................. 1 HA Heimautomatisierung bzw. Heimautomation....................... 1 HomeMatic Produktfamilie der eq-3 AG für 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 für 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 - Gründung März 1999....................4 OSGi-Framework Softwareplattform mit Komponentenmodell auf Basis von Java..... 2 PBX Private Branch Exchange........................................ 26 POJOs Plain Old Java Objects........................................... 8 RCP Rich Client Platform............................................ 23 ROS Robot Operating System........................................ 26 RSSI Received Signal Strength Indicator............................... 29 SDK Software Development Kit....................................... 20 SHSs Step-and-Heading Systems...................................... 27 SLF4J Simple Logging Facade for Java................................. 17 SMTP Simple Mail Transfer Protocol................................... 24 SQL Structured Query Language......................................25 SSH Secure Shell.................................................... 31 Telnet Teletype Network............................................... 31 TTS Text-To-Speech................................................. 20 UDP User Datagram Protocol.........................................31 UIs User Interfaces..................................................20 URI Uniform Resource Identifier...................................... 10 UX User Experience.................................................. 2 SMI Standard Motor Interface......................................... 1 WAN Wide Area Network............................................. 31 WAPs Wireless Access Points.......................................... 28 Xbase Expression Language für 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 Unternehmensgründung der Insta Elektro GmbH, einer Fusion der Unternehmer Berker, Gira und Jung, die Entwicklung des Instabus (Installation Bussystem) [Gmb15b]. Das Instabus wird im Jahre 1994 von dem CENELEC (Comité Européen de Normalisation Électrotechnique) als europäische Norm unter der Bezeichnung EIB (Europäischer Installationsbus) für die EIBA (European Installation Bus Association) ratifiziert [CEN15]. Etwa zeitgleich zur Einführung 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 Bündnis der oben genannten Organisationen zur KNX-Association, wird bei gleichzeitiger Zusammenlegung der Bussysteme EIB, BatiBUS und EHS, der internationale Grundstein für die heutige GA (Gebäudeautomatisierung bzw. Gebäudeautomation) gelegt [Ass15b]. Der daraus entstandene KNX (Konnex-Bus) wird im Frühjahr 2002 veröffentlicht und letztendlich im November 2006 als internationaler Standard (ISO/IEC 14543-3) verabschiedet [Ass15a]. Wenn auch neben KNX weitere leitungsgebundene Standards, wie z. B. LON (Local Operating Network) und SMI (Standard Motor Interface), im Bereich der GA wiederzufinden sind, geht der heutige Trend in Richtung kabelloser Systeme, z. B. EnOcean, HomeMatic und FS20, deren Anwendung vermehrt in der HA (Heimautomatisierung bzw. Heimautomation) anzutreffen ist [Jur15]. Dabei stehen die GA und HA nicht synonym für Anwendung eines speziellen Standards oder Installation einer konkreten Technologie, sondern eine Abgrenzung findet vielmehr durch die Art der Bauten und die nutzerspezifischen Einsatzbereiche statt [Mer+10, S. 17]. So ist die HA beschränkt auf den privaten Wohnungsbau mit Einsatzbereichen aus Energieeinsparung, Komfort und Sicherheit [Mer+10, S. 18]. Hingegen ist die GA konzentriert auf Zweckbauten, z. B. Bürohäuser oder Einkaufszentren, deren Einsatzbereiche über die der HA hinaus gehen und zudem die Faktoren der Flexibilität und Kommunikation der Bussysteme betrachten [Mer+10, S. 19]. Trotz der internationalen Standardisierung weist die Interoperabilität der Technologien, sowohl Hard- als auch Software, Lücken auf. Dies fordert die Hersteller für die Zusammenführung der Vorteile ihrer Kommunikationsstandards zur (Weiter-)Entwicklung neuer Vernetzungssysteme (Gateways) auf [Gmb15a]. Da die Kosten für Anschaffung und der Aufwand für die Installation und die Vernetzung der Gateways quadratisch ist, verliert der Ansatz an Bedeutung. 1

1 Einleitung Um die Defizite zu decken, sieht der verbesserte Top-Down-Ansatz nur noch eine einzige Hardware-Komponente, den zentralen Leitrechner, auf der Management-Ebene vor. Auf der darunter folgenden Automationsebene sind dann letztendlich die Komponenten der DDC-GA (Direct-Digital-Control-Gebäudeautomation) wiederzufinden. Den Abschluss bildet die Feldebene - der Aktoren und Sensoren zugehörig sind [Mer+10, S. 22-26]. Die Symcon GmbH bietet bereits mit ihrer proprietären Software IP-Symcon und dem zugehörigen Web-Service ein Produkt an, das einige Hardware-Module unterschiedlicher Hersteller vernetzt [Ohl15]. Mit Fhem (Hausautomations-Server auf Basis von Perl) ist bereits die Grundlage für eine Open- Source-Software (GPL v2) für den Anwendungsbereich der GA bzw. HA geschaffen [Wil15]. Mit openhab (open Home Automation Bus) bietet die openhab UG (haftungsbeschränkt) eine Open-Source-Software (EPL) auf Basis des OSGi-Framework (Softwareplattform mit Komponentenmodell auf Basis von Java) an. Der Schwerpunkt der Entwicklung strebt neben der herstellerübergreifenden Vernetzung zudem im aktuellen Stadium die Verbesserung der UX (User Experience) an [Uh15u]. 1.1 Aufgabenstellung Der Auftrag des Projektes besteht in der Ausführung eines realitätsnahen Szenarios der Automatisierung beim Einsatz der openhab -Software und der Vernetzung verschiedener Herstellerkomponenten. Zudem soll die Software im Hinblick auf umgesetzte Modularisierung und verwendete Architekturen der OSGi-Service-Platform analysiert werden. Für obigen Auftrag sind folgende Teilanforderungen durchzuführen: Die OSGi-Service-Platform bildet die Kernkomponente von openhab: Neben Funktionsweise und Architektur des OSGi-Framework sind benötigte und umgesetzte Plattform- Restriktionen in openhab zu klären. Für das realitätsnahe Szenario sollen hinreichende Hardwarekomponenten und Software erarbeitet werden, die im Zusammenhang mit dem Oberbegriff der Bewegungserkennung von Personen stehen. Eine anschließende Realisierung der Installation ist obligatorisch. Des Weiteren soll die Implementierung beim Einsatz von openhab für das Szenario verwirklicht und die Güte der Bewegungserkennung bei variierender Parametrisierung analysiert werden. 1.2 Zielsetzung Das Ziel des vorliegenden Projektes ist es, eine herstellerübergreifende Lösung für das Anwendungsszenario der Bewegungserkennung von Personen im Rahmen der GA und HA beim Einsatz 2

1 Einleitung von openhab auszuarbeiten. Außerdem ist die eingesetzte Hard- und Software zur Umsetzung des Szenarios im Hinblick auf mögliche auftretende Fehler in der Erkennung zu validieren. Abschließend sollen die gewonnenen Erkenntnisse in Abgrenzung zu weiteren Lösungsansätzen analysiert werden. 1.3 Vorgehensweise In Kapitel 2 - Die OSGi-Service-Platform wird neben einer allgemeinen Vorstellung der OSGi- Service-Platform das OSGi-Framework vorgestellt. Fokus liegt hier sowohl auf der Struktur und dem Aufbau der Framework Module als auch deren Services und Kommunikation untereinander. 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 Paradigmen des OSGi-Frameworks, analysiert. Aufbauend auf den Erkenntnissen der Kapitel 2 und 3 stellt Kapitel 4 - Bewegungserkennung von Personen das Szenario vor. Dazu wird neben dem Realitätsbezug auch die verwendete Hard- und Software näher betrachtet und eine anschließende Durchführung stellt das Proof of Concept dar. Die Ergebnisse werden im Anschluss in Kapitel 5 - Ergebnisse und Alternativen genutzt um die eingesetzten Technologien gegen alternative Lösungsansätze abzugrenzen. Das Kapitel 6 - Zusammenfassung und Fazit weist, neben abschließenden Worten, auf Forschungsgebiete im Zusammenhang mit der HA und GA hin, deren Thematik weitere wissenschaftliche Arbeiten befürworten. 3

2 Die OSGi-Service-Platform In diesem Kapitel wird ein Überblick der OSGi-Service-Platform präsentiert. Aufgrund des umfangreichen OSGi-Standards, der von der OSGi-Alliance (Non-Profit-Organisation - Gründung März 1999) entwickelt und verbreitet wird [Web+10, S. 30], greift dieses Kapitel lediglich die Hauptbestandteile des Release 4 in Version 4.3 der OSGi-Service-Platform auf. Die Dokumentation des Standards teilt sich in die OSGi Service Platform Core Specification und das OSGi Service Platform Service Compendium auf. Erstere beinhaltet neben den zentralen Bestandteilen des OSGi-Framework - die in diesem Kapitel näher betrachtet werden - auch die OSGi Service Platform Mobile Specification, die speziell für mobile Endgeräte definiert ist [vgl. Web+10, S. 29; Wüt08, 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 Augenmerk auf der Verwaltung, Entwicklung und Kommunikation von bzw. zwischen Services liegt. OSGi ist zwar durch die Spezifizierung auf der JVM (Software-Platform - Java Virtual Machine) nicht sprachunabhängig, jedoch plattformunabhängig und erfreut sich deshalb großer Beliebtheit und Anwendung rund um das Smartphone, den Automobilbereich, der Unterhaltungselektronik, reinen Desktop-Applikationen aber auch serverseitige Anwendungen und vor allem der HA [vgl. Web+10, S. 1 f.; Wüt08, S. 14 f.] - auf konkrete Implementierungen von OSGi wird im Abschnitt 2.3 eingegangen. Der Vorteil und damit auch die Befürwortung zur Nutzung des OSGi-Framework liegt in der Beurteilung als bestbewertetes dynamisches Modulsystem im Vergleich zu Laufzeitsystemen, wie z. B. DDL/COM und Shared Libraries [Fil12, S. 68 ff.]. Die für die Bewertung betrachteten Kriterien behandeln dazu sowohl den Aufbau bzw. die Struktur als auch die Umsetzung der Bestandteile, die für eine korrekte Modularisierung, also das Brechen der Komplexität einer Software durch Dekomposition in Module, nötig sind [vgl. Fil12, S. 67 f.; Wüt08, S. 16 f.]. Das sind zum einen die Module und Services und zum anderen die Registry und Versionierung eines Frameworks. Der folgende Abschnitt 2.1 behandelt die Komponenten, die OSGi als dynamisches Modulsystem kennzeichnen. 4

2 Die OSGi-Service-Platform 2.1 OSGi-Framework Das OSGi-Framework ist eine Laufzeitumgebung die einen Container für die Softwarekomponenten (Module und Dienste) bereitstellt. Neben diesen Komponenten enthält das Framework den MA (Management Agent) als zentrale Verwaltungsstelle, dessen Hauptaufgabe die Überwachung des Lebenszykluses der Module und deren Dienste ist [Wüt08, 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-übergreifenden Kommunikation verwendet werden, charakterisiert. Größere Softwareprodukte tendieren mit der Zeit dazu, dasss ihre innere Struktur mehr einem Irrgarten ähnelt als einer geplanten Entwicklung. Das wird allgemein als Architecture Erosion bezeichnet [Fil12, S. 59]. Um der Architecture Erosion bereits zu Beginn der Entwicklung entgegenzuwirken, nutzt das Framework zur Kopplung der Bundles neben statischen auch dynamische transitive Abhängigkeiten, die in Abschnitt 2.1.1.2 erörtert werden. Im Anschluss daran zeigt der Abschnitt 2.2 das Schichtenmodell des OSGi-Framework das von den Services bis zum Betriebssystem definiert ist. Als Abschluss dieses Kapitels (Abschnitt 2.3) werden sowohl zertifizierte Produkte als auch Open-Source-Lösungen, die konkrete Implementierungen des OSGi-Framework darstellen, genannt. Der Fokus liegt auf der Vorstellung der Eclipse Equinox, die als Kernkomponente der openhab-software anzusehen ist. 2.1.1 Bundles Wie bereits erwähnt, ist ein Bundle mit dem Begriff Modul gleichzusetzen und beinhaltet neben Java-Archiven, Java-Klassen und anderen Ressourcen (z. B. Icons als Bilder) ein Manifest, in dem ergänzende Metadaten aufgelistet sind [All15c, S. 25] - was ein Bundle letztendlich auch als ein Java-Archiv kennzeichnet [vgl. Fil12, S. 72 f.; Web+10, S. 16 ff.]. Nach [Web+10, S. 126] ist die Migration von jedem konventionellen Java-Archiv in ein OSGi-Bundle möglich. In einem bundle-zugehörigen Manifest ist beschrieben, welche externen Archive das Bundle benötigt (import), bzw. ob es seine Funktionalität anderen Bundles zur Verfügung stellt (export). Damit ein Bundle die benötigten Abhängigkeiten aufschlüsseln kann, erhält es vom OSGi-Framework-Container einen eigenen Class-Loader der die benötigten Java-Archive bzw. Java-Klassen sowohl aus dem Boot- und Framework-Class-Path als auch aus dem Bundle- Space nachladen kann. Die Gesamtheit aller Class-Loader wird als Class Loading-Delegation- Netzwerk bezeichnet [vgl. Fil12, S. 74 f.,138; Web+10, S. 6]. Grundsätzlich unterscheidet die Spezifikation drei Arten von Bundles: 5

2 Die OSGi-Service-Platform Requiring Bundles [All15c, S. 66 ff.] - Requiring Bundles setzen eine direkte Kommunikation bzw. Verbindung mit dem Require-Mechanismus um und werden in Abschnitt 2.1.1.2 detaillierter beschrieben. Der Einsatz des Mechanismus birgt die Gefahr von statischen Abhängigkeiten zwischen Bundles. Fragment Bundles [All15c, S. 69 ff.] - Bundles, die von der Laufzeitumgebung des Frameworks einem oder mehreren Host -Bundles zugewiesen werden - z. B. ein Sub- Jar-Archive, das nach Auflösung als Bestandteil des Host -Bundles angesehen wird, jedoch keinen eigenen Class-Loader besitzen muss, wird Fragment Bundle genannt. Extension Bundles [All15c, S. 72 f.] - Diese Bundles verwenden wie die Requiring Bundles nicht den Import/Export -Mechanismus (Abschnitt 2.1.1.2), sondern müssen direkt dem Boot-Class-Path beigelegt werden. Zwar bieten diese Bundles framework-eigene Services an, wie z. B. den Permission Admin Service, sollten aber nicht für die Implementierung anwendungsspezifischer Bundles verwendet werden, um statische Abhängigkeiten zu vermeiden. Zudem ist das OSGi-Bundle von den IANA (Internet Assigned Numbers Authority) als gültiger MIME-Type vnd.osgi.bundle klassifiziert [Aut15]. 2.1.1.1 Manifest Das Manifest META-INF/MANIFEST.MF beinhaltet eine Auflistung von Metainformationen, die ein OSGi-Bundle individuell kennzeichnen. Zudem enthält es Informationen für 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 Namensgebung folgt keiner direkten Konvention. Sollte die Namensgebung allerdings schwer 6

2 Die OSGi-Service-Platform fallen, enthält das Bundle wahrscheinlich Funktionalität aus semantisch unabhängigen Bereichen, wodurch dann die Paradigmen der OSGi-Schichtenarchitektur nicht eingehalten werden [Fil12, S. 137]. Mit RequiredExecutionEnvironment wird die minimal benötigte Laufzeitumgebung gekennzeichnet. Der openhab-core benötigt mindestens die Java Plattform in der Standard Edition Version 5. Aufgrund der Rückwärtskompatibilität von Java können demnach auch höhere Versionen für den openhab-core genutzt werden [All15c, S. 35 f.]. Die Angabe Activator dient dem MA, damit er weiß, welche Java-Klasse er verwenden muss, um das Bundle in den Lebenszyklus einzubinden. Die Activation Policy gibt an, wie bzw. wann das Bundle gestartet werden soll [All15c, S. 91 ff.]. Ist sie lazy, wird das Bundle erst geladen, wenn dessen Funktionalität abgerufen wird. Ist die Activation Policy nicht angegeben, ist sie standardmäßig auf directive gesetzt und das Bundle wird direkt beim Start der Laufzeitumgebung mit initialisiert. Für selbst-definierte Header-Angaben, die nicht dem OSGi-Namespace folgen, können diese mit dem Prefix x- gekennzeichnet werden [All15c, S. 29]. Auf Header-Angaben, die für eine Kommunikation von Bundles benötigt werden, wird in Abschnitt 2.1.1.2 näher eingegangen - für Weitere sei auf die auf OSGi-Service-Platform Core Specification [All15c, S. 26-31] verwiesen. 2.1.1.2 Import, Export und Require Neben den in Abschnitt 2.1.1.1 erwähnten, können die Header-Angaben Export- und Import- Package genutzt werden, um Abhängigkeiten zwischen den Bundles zu erzeugen. Um externe Funktionalitäten anderer Bundles nutzen zu können, kann das Bundle diese explizit in der Import-Anweisung auflisten. Umgekehrt wird die Export-Anweisung im Manifest angegeben, um die eigene Funktionalität anderen Bundles bereitzustellen [Fil12, S. 73]. Die Abbildung 2.1 zeigt die mit der Angabe von Import und Export geschaffenen Beziehungen der Bundles. Als Beigabe der Import-Anweisung kann optional eine Version mit Semikolon getrennt angegeben werden - standardmäßig wird die aktuellste Version vom MA geladen. Neben einer spezifischen Version können auch Version-Ranges durch die mathematische Intervall-Notation vermerkt werden [vgl. All15c, S. 29 f.; Fil12, S. 79; Web+10, S. 7]. Um statische Abhängigkeiten zu vermeiden, sollten Bundles für den Export nie die direkten Implementierungen weiterreichen, sondern nur solche Packages angeben, die ausschließlich Schnittstellen beinhalten: Das Class Filtering ermöglicht die flexible Einschränkung der Sichtbarkeit von Bestandteilen des Bundles [All15c, S. 49 f.]. Bei der Verwendung von Import und Export greift der Standard-Resolving-Mechanismus des MA und verhindert gleichzeitig auch mögliche Zyklen in der Abhängigkeitskette der Bundles. Mit Require-Bundle können Bundles direkt miteinander verbunden werden. Die mit Require geschaffenen statischen Beziehungen bergen Risiken, die den Standard-Resolving-Mechanismus umgehen und dadurch Split Packages, Mutable Exports und Shadowing verursachen 7

2 Die OSGi-Service-Platform [All15c, S. 68 f.]: Für eine dynamische Kopplung der Bundles ist somit der Import und Export zu bevorzugen. Abbildung 2.1: Beziehungen zwischen Bundles [Fil12, S. 74] 2.1.2 Services A service is a normal Java object that is registered under one or more Java interfaces with the service registry [All15c, S. 111] OSGi-Services sind Instanzen von POJOs (Plain Old Java Objects) die durch die Bundle Context -Objekte von Bundles genutzt werden können, um eigene Services zu registrieren (bundlecontext.registerservice), fremde Services zu nutzen (bundlecontext.getservicereference und bundlecontext.getservice) oder sogar über mögliche Änderungen der Services informiert zu werden (bundlecontext.addservicelistener) [All15c, S. 111 f.]. Als zentrale und bundleübergreifende Stelle dient die Service Registry der Verwaltung der registrierten Services und regelt Anfragen oder Änderungen der Services über Service Events. Wie in Abbildung 2.2 dargestellt, ist es es anderen Bundles nach Instanziierung der Services möglich, auf die Schnittstelle zuzugreifen und dadurch die Funktionalität zu nutzen. Summa Summarum bedeutet dies: OSGi löst die Diskrepanz zwischen Komponenten und Diensten auf sehr elegante Weise: Ein Bundle entspricht nicht einem Service, sondern ein Bundle kann einen oder mehrere Services zur Verfügung stellen [Web+10, S. 24]. Bei Verwendung von Import und Export ermöglicht das OSGi-Framework, mit den Services als Softwareartefakt, eine dynamische Kommunikation innerhalb der Bundles. Wenn in der 8

2 Die OSGi-Service-Platform Entwicklung eine statische Kopplung mit Require umgesetzt wird, sind die Vorteile der Services, ihrer Registry und die Reaktion auf Events mit den Listenern hinfällig [Fil12, S. 78 f.]. Einige der Events sind in Abbildung 2.5 dargestellt und sind speziell dem Lebenszyklus eines Bundles bzw. der Objektinstanz, dem Service, zuzuordnen. Alle übrigen Events sind den Kategorien von Fehlermanagement (z. B. ERROR, WARNING oder INFO) oder der erweiterten Package-Verwaltung (z. B. PACKAGES REFRESHED oder WAIT TIMEOUT) zugeordnet [All15c, S. 105 f.]. Der MA nutzt die Service-Registry, um auf Änderungen 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 für unterschiedliche Anwendungsfälle an. Im Folgenden sind die sechs interessantesten Services erwähnt: [All15d] Log Service - Der Log-Service besteht aus zwei Services: Der LogService ermöglicht das Aufzeichnen eines Protokolls (bestehend aus: Nachicht, Level, Fehlermeldung, Service- Referenz und dem Bundle-Objekt) und der LogReaderService kann die Informationen der gespeicherten Protokolle abrufen [All15d, S. 5]. HTTP Service - Der HTTP-Service ermöglicht dem Entwickler die Standard-Technologien, wie z. B. HTTP, HTML, XML und Servlets, zu nutzen. Dieser Service ist demnach geeignet, 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 (Java Database Connectivity - Standard) mit relationalen Datenbanken zu kommunizieren [All15d, S. 701]. JPA Service - Der JPA-Service dient der Persistenz von Objekten in einer Datenbank. Die JPA (Java Persistence API) bietet dazu die Technik des ORM (Object Relational Mapping) an [All15d, S. 727]. 9

2 Die OSGi-Service-Platform IO Connector Service - Der IO-Connector-Service ist eine Kommunikationsinfrastruktur, die auf der Implementierung der J2ME (Java 2 Micro Edition) basiert: Notwendige Kommunikationen werden über den URI (Uniform Resource Identifier) realisiert [All15d, S. 191]. Bis jetzt können die Bundles nur die Funktionalität von Services innerhalb ihrer Laufzeitumgebung nutzen. Mit Einführung des OSGi-Standards 4.2 (März 2010) arrangiert der Remote Service Admin Service die Konnektivität für Distributed Services externer Laufzeitumgebungen in einem Netzwerk [Web+10, S. 19 f.]. 2.2 OSGi-Schichtenmodell Ausgehend von den Begrifflichkeiten der vorherigen Abschnitte sind die Zusammenhänge der Framework-Komponenten, wie in Abbildung 2.3 dargestellt, zu betrachten. Das OSGi- Framework als Basiskomponente der OSGi-Service-Platform ist in mehrere logische Schichten eingeteilt. Abbildung 2.3: OSGi-Schichtenmodell [i.a.a. All15c, S. 2] Die Schnittstelle einer logischen Schicht ist die Menge der exportierten Java-Interfaces der ihr zugehörigen Bundles [Fil12, S. 139]. Bundleschicht: Auch wenn in Abbildung 2.3 die Bundles als unabhängige Komponente eingezeichnet sind, so können sie dennoch auf jede logische Schicht zugreifen und von der Lebenszyklusschicht noch zusätzlich gesteuert werden - siehe Abbildung 2.4. 10

2 Die OSGi-Service-Platform Abbildung 2.4: Interkation Bundles und Framework-Schichten [Web+10, S. 17] Diensteschicht: Der Diensteschicht sind alle in Abschnitt 2.1.2 erörterten Komponenten zugeteilt. Für die Verwaltung und Nutzung der Services verwendet das OSGi-Framework das Publish-Find-Bind-Modell. Die Schnittstellen der Dienste sind Java-Interfaces [Web+10, S. 14 f.]; Lebenszyklusschicht: In der Lebenszyklusschicht wird der Lebenzyklus eines Bundles mit all seinen Zuständen festgelegt. Der MA reguliert bzw. manipuliert die Bundle-Zustände. Abbildung 2.5: Bundle-Lebenszyklus [i.a.a. All15c, S. 86] 11

2 Die OSGi-Service-Platform Ein Bundle kann somit nach seiner Installation direkt wieder deinstalliert werden. Andernfalls folgt auf den INSTALLED-Zustand der RESOLVED-Zustand, von dem ausgehend der MA dann das Bundle startet und der Modulschicht als ACTIVE zur Verfügung stellt. Das OSGi-Framework verwirklicht dadurch Hot Deployment - das Aktualisieren, Installieren und Deinstallieren von Bundles und Services während der Laufzeit. Modulschicht: Der Modulschicht sind alle Objektinstanzen der Bundles hinterlegt. Zudem können die vom Bundle benötigten Klassen über den Class-Loader aus der Modulschicht geladen werden. Sicherheitsschicht: Die Funktionalität der Sicherheitsschicht basiert auf der Java-2-Sicherheits- Architektur und ist in Fine-grained (Die Umsetzung von Sicherheit wird von der Anwendung realisiert.), Manageable (Die Tätigkeit wird an die Lebenszyklusschicht delegiert.) und Optional unterteilt. Die OSGi-Service-Platform unterstützt die Authentifizierung von Programmcode 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-übergreifenden Wirkungsgrad zu verdeutlichen. 2.3 OSGi-Implementierungen Die OSGi-Service-Platform ist eine Ansammlung von Spezifikationen die ein Komponentensystem mit einer modularen Softwarearchitektur auf Basis der Programmiersprache Java beschreiben [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 Weiterentwicklung der Spezifikationen und einer jährlichen Gebühr von USD $ 25,000. (2) mit Teilnahme an Experten-Zirkeln und einer jährlichen Gebühr von USD $ 20,000 ( 250 Beschäftigte) oder USD $ 10,000 ( 249 Beschäftigte). (3) ohne Sitz im Ausschuss oder Teilnahme an Zirkeln, mit technisch-unterstützenden Hintergrund und einer jährlichen Gebühr von USD $ 5,000 (4) mit der Berechtigung das Logo der OSGi-Alliance auf der firmeneigenen Website zu führen. Um die Funktionalität der OSGi-Service-Platform nutzen zu können, sind mehrere Varianten denkbar. Eine Mitgliedschaft in der OSGi-Alliance mit eigener Realisierung und Implementierung der Spezifikationen und anschließender Zertifizierung des Softwareproduktes - intensiv in 12

2 Die OSGi-Service-Platform der Investition von Zeit und Finanzen, oder auf bereits zertifizierte kommerzielle oder Open- Source Lösungen 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 für die OSGi-Service-Platform R4 zertifiziert [All15a]. Für die Eclipse IDE (Integrated Development Environment) stellt die Eclipse Equinox, neben Texteditoren, Compiler und Debuggern, eine Kernkomponente der Anwendung dar [Fou15d]. Equinox besitzt Eigenheiten, wie z. B. das Buddy-Class-Loading und die Extension Points, die in der OSGi-Spezifikation nicht vorgesehen sind [Web+10, S. 33]. Das Buddy-Class-Loading beschreibt einen Mechanismus der es Bundles ermöglich, mit Hilfe von Class-Loadern anderer Bundles, Java-Ressourcen zu binden, die der eigene Class-Loader nicht verknüpfen kann. Die Buddy-Policy beschreibt, für die Auswahl der Helfer-Bundles, fünf Richtlinien [Fou15a]. Extension Points sind Bundle-Schnittstellen die nicht das Konzept der OSGi-Services umsetzen, sondern eigens dafür Schnittstelleninformationen in einer XML-Datei festhalten [Fou15b]. 2.3.2 Sonstige Neben der Eclipse Equinox existieren noch weitere zertifizierte Lösungen [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 (haftungsbeschränkt) - Firmengründung am 06.01.2014, Gründungsmitglieder: Kai Kreuzer, Thomas Eichstädt-Engelen und Victor Belov - eine Softwarelösung für die GA und HA an, deren Hauptziel eine herstellerübergreifende Kopplung von Hard- und Software ist. Die openhab UG ist Mitglied der EnOcean Allicance, AllSeen Alliance und Eclipse Foundation. Durch den Einsatz der Programmiersprache Java ist openhab nicht nur plattformunabhängig, sondern kann durch die Verwendung von der Eclipse Equinox auf die dem OSGi-Framework (Abschnitt 2.1) zugrundeliegende Softwarearchitektur zurückgreifen [Uh15e]. Aus Sicht des Endanwenders verfolgt openhab das Prinzip des Intranet Of Things - alle Endgeräte sind im eigenen Netzwerk verbunden und für 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] für die Steuerung seiner KNX-Komponenten, entscheidet sich Kai Kreuzer im November 2009 zur Entwicklung einer eigenen Softwarelösung für die HA unter dem Namen SmartKNX - wegen evtl. Markenrechtsverletzungen ab Februar 2010 fortan openhab genannt. Er entscheidet sich zudem explizit gegen eine Projektbeteiligung und Weiterentwicklung der OpenRemote (Open Source Automation Platform) [Inc15c]: Seiner Meinung nach, ist durch die dort fortgeschrittene Architecture Erosion die Umsetzung einer zukunftsweisenden Softwarearchitektur nur durch einen Rewrite des Programmcodes zu bewerkstelligen. Für das Build-Management von openhab wird Maven (Software für den Erstellungsprozess von Softwareprodukten) in der Version 3 und das Plugin Tycho verwendet. Drools (Rule Management System Solution der JBoss Community) wird anfänglich als Rule Engine eingesetzt und im Mai 2012 durch eine Kombination aus dem Quartz-Framework, der Xbase (Expression Language für Java implementiert in Xtext) und der Joda-Time Bibliothek ersetzt [Kre15]. Looking back at this evolution of the project, I am perfectly sure that if I had designed openhab as a normal Java application instead of an OSGi application, it would not have prospered as it did. It is really the choice of the software architecture that made it happen [...] [Kre15, 17. Dezember 2012]. 14

3 openhab Zu dem Zeitpunkt der von Kai Kreuzer getroffenen Aussage, weist openhab bereits eine zweieinhalbjährige Entwicklung (Release Version 1.0) auf und mit dem Release Version 1.2 (April 2013) veröffentlicht die openhab UG sämtliche Implementierungen zur Kopplung der HA- Produkte von HomeMatic, Philips Hue, DMX und Kouchbachi. Noch im selben Jahr folgen Implementierungen für Z-Wave, EnOcean, Fritz AHA und Tinkgerforge. Mit dem Entwicklungszweig (Release Versionen 2.x) verfolgt openhab den User Comfort, also vorwiegend die Gebrauchstauglichkeit der Software - als Teildisziplin der UX [Kre15]. Die Analyse der Architektur und Programmcode in den Folgeabschnitten basiert auf dem openhab Release Version 1.6. 3.1 Architektur Die Abbildung 3.1 zeigt die Softwarearchitektur von openhab und ist in drei Sektionen unterteilt: Die Komponenten des OSGi-Frameworks (grün), 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 Eclipse Equinox in der Version 3.8.2 (04.02.2013) und die zugehörigen Services in der Version 3.3 15

3 openhab dar. Damit alle anderen Architektur-Komponenten die Programmierparadigmen des OSGi- Standards berücksichtigen, stellt jede Komponente eine Plug-in Abhängigkeit zur Eclipse Equinox und den Services her. Mit der Equinox bietet Eclipse nicht nur ein Framework für den OSGi-Standard an, sondern verwirklicht eine Laufzeitumgebung mit folgenden Funktionalitäten [Uh15m, Kreuzer K. et al.]: Die Bereitstellung einer Konsole sowohl für die Eingabe und Interpretation von Kommandos 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 für die Protokollierung der Bundle-Aktivitäten. Der StatsManager verbindet die Informationen der Bundles ohne die Bundle-Registry zu beeinflussen. Die Verwaltung von Berechtigungen und Erweiterungen für die Protokollierung der Bundle-Aktivitäten. Eine Protokollierung in Abhängigkeit einzelner Berechtigungen ist dadurch realisierbar. Das Aufstellen einer Trace für eine evtl. Fehlerbeseitigung. Das Einhängen von zusätzlichen Funktionen mittels der Hook-Registry und der Verwaltung 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 für einzelne Manifest-Elemente ( internal.core oder osgi.util ). Von den ca. 20 Standard-Services des OSGi-Standards verwendet die openhab-software die folgenden fünf Services: Declarative Services: Mit den Declaratice Services stellt der OSGi-Standard ein publishfind-bind -Modell für die Verwendung der Dienste zur Verfügung. Mit dem Modell können Applikationen erstellt werden, die das Arbeiten und die Kommunikation der Bundles untereinander realisieren. Dabei simplifizieren die Declarative Services die Verwaltung der Dienste indem sie die Registrierung und Abhängigkeiten von anderen Diensten übernehmen. In dem Modell übernimmt die Service Component Runtime die Instanziierung der Components und die Kontrolle der Component Configuration(s) [All15d, S. 245 f.]. Die einzelnen Klassen bzw. Schnittstellen für 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 übrigen Komponenten implementieren nur den Configuration Admin Service. Logback/SLF4J: Der Logback/SLF4J - Dienst ist in [All15d, S. 5 f.] unter der Bezeichnung Log Service wiederzufinden und wird bereits in Abschnitt 2.1.2 erörtert. Die Klasse OSGILogListener, als Bestandteil der Core-Komponente, implementiert den LogListener und LogReaderService und dient als Adapter um die Protokolleinträge an die SLF4J (Simple Logging Facade for Java) zu delegieren [QOS15]. 1: private static class NLogListener implements LogListener { 2: public void logged ( LogEntry entry ) { 3: Logger logger = LoggerFactory. getlogger (" OSGi "); 4: Marker marker = MarkerFactory. getmarker ( entry. getbundle (). getsymbolicname ()); 5: switch ( entry. getlevel ()) { 6: case LogService. LOG_DEBUG : logger. debug ( marker, entry. getmessage (), entry. getexception ()); break ; 7: case LogService. LOG_INFO : logger. info ( marker, entry. getmessage (), entry. getexception ()); break ; 8: case LogService. LOG_WARNING : logger. warn ( marker, entry. getmessage (), entry. getexception ()); break ; 9: case LogService. LOG_ERROR : logger. error ( marker, entry. getmessage (), entry. getexception ()); break ; 10: } 11: } 12: } Quelltext 3.1: Ausschnitt - OSGILogListener.class - Delegation an den SLF4J-Logger [Uh15m, Kreuzer K.] Event Admin: Der Event Admin Service ermöglicht die Kommunikation zwischen Bundles auf Grundlage eines Event-Publish-Subscribe - Modells. Für die Kommunikation sendet der Event Publisher mithilfe des Event Admin Service einen Event an den Event Handler der wiederum das Event an den Event Comsumer weiterleitet [All15d, S. 295 f.]. In der openhab-software implementiert die Core-Komponente in der EventPublisherImpl - Klasse einen solchen Event Publisher der dann mit dem Event Admin Service und der sendevent -Methode das Event für 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 implementiert: Die Core-Komponente stellte eine zentrale Broadcast-Einheit dar und leitet die 17

3 openhab eintretenden Ereignisse an die Bindings weiter. Die openhab UG tituliert dieses Modell und dessen Implementierung als openhab Event Bus [Uh15i]. Configuration Admin: Der Configuration Admin Service ermöglicht die Konfiguration von installierten ManagedService(s). Damit notwendige Änderungen in der Konfiguration eines ManagedService bereits vor Aktivierung durch den MA vorliegen, reagiert der Configuration Admin Service sofort auf eingehende Kommandos [All15d, S. 57]. In der openhab- Software ist der Configuration Admin Service als eigenständiges Binding (configadmin) in der Klasse ConfigAdminBinding implementiert. Bei Aufruf der bindingchanged -Methode wird die Konfiguration für den entsprechenden ManagedService angepasst [Uh15m, Eichstädt- Engelen T.]. Als ManagedService sind in der openhab-software alle Bundles (Action, Binding, Persistence, etc.) gekennzeichnet, die die Service-Schnittstelle in der XML-Datei im OSGI-INF Ordner und im Manifest auflisten und zudem die updated -Methode der ManagedService -Schnittstelle implementieren. HTTP Service: Der HttpService wird überall dort eingesetzt wo die Bundles die Standardtechnologien wie z. B. HTTP, HTML, XML oder Servlets nutzen möchten. Der HTTP Service registriert mit dem HttpContext die Servlets, in denen dann auf den geforderten Request ein Response folgt [All15d, S. 15 f.]. In der openhab-software wird der HTT- PService primär in der Klasse RESTApplication des REST-Bindings umgesetzt [Uh15m, Kreuzer K.]. Für die Realisierung nutzt openhab den Web-Server und Servlet-Container von Jetty in der Version 8.1.3 [Fou15c] und das Jersey Framework für 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 darzustellen. 3.1.2 openhab Kernkomponenten openhab Core: Der openhab Core ist die Kernkomponente der openhab-software und implementiert den Event Admin Service um eingehende Ereignisse weiterzuleiten und eine Kommunikation der Bundles zu ermöglichen. Neben dieser Kernfunktionalität bietet der open- HAB Core die Dienste an, die es Bundles erlauben selbst auf eingehende Events zu reagieren, z. B. das Wake-on-Lan-Binding sendet bei Ausführung der receivecommand -Methode das zum Wecken entfernter Clients notwendige Paket. Ein weiterer Dienst ist die ItemRegistry. Sie dient als zentrale Stelle um die Items (Elemente aktiver Bundles) und ihre Status in einer ConcurrentHashMap im flüchtigen Speicher der Laufzeitumgebung abzulegen. Die Items können hinzugefügt, 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 Status in Verbindung mit einer Datenbank-Software (z. B. db4o, rrd4j, mysql und mongodb) [Uh15n]. Das AutoUpdate -Feature ermöglicht es Bundles automatisch auf eingehende Änderungen zu reagieren (openhab.core.autoupdate). Der SchedulerActivator ist eine Erweiterung des OSGi-Bundle-Activator der in Verbindung mit dem Bundle-Context steht. Um geplante Jobs rechtzeitig oder in gewissen Zeitabständen abzuarbeiten, verwendet die openhab-software den Quartz-Scheduler in der Version 2.1.7 [Inc15e] Die openhab-skripte sind wiederverwendbare Zusammenstellungen von openhab-regeln und werden in Abschnitt 3.4.1 beschrieben. Um diese Skripte auszuführen stellt der openhab-core eine Script-Engine zu Verfügung (openhab.core.scriptengine). Da die openhab-skripte in Xtend (flexibler und expressiver Dialekt von Java) geschrieben sind, verwendet der openhab-core zur Komposition und dem Parsen der Skripte das Xtext- Framework in der Version 2.3.0 [Uh15q]. Letztendlich bietet der openhab-core neun unterschiedliche Transformation-Services an, um eingehende Dokumenttypen zu verarbeiten (z. B. JavaScript, JSonPath, Map, RegEx, XPath oder Xslt). openhab Base Library: Zu der openhab Base Library gehören alle Funktionalitäten die unter dem openhab-core als Features aufgelistet sind. Zwar liegt in der Darstellung der Architektur eine Trennung zwischen diesen beiden Komponenten vor, programmatisch sind diese Features jedoch als Subpakete des openhab-core aufzufassen. openhab Repository: In [Uh15i] wird das openhab Repository als Softwarekomponente beschrieben, die mit dem openhab Event Bus, der Automation Logic und dem User Interface interagiert. Das openhab Repository ist eine Schnittstelle die in der openhab- Software als ModelRepository wiederzufinden ist (org.opehab.model.core). Neben einer Implementierung im REST-Binding ist das ModelRepository im PersistenceManager und den Klassen zur Erzeugung der Benutzeroberfläche (org.openhab.ui) realisiert. openhab REST Service - Der openhab Rest Service ist das REST-Binding (openhab.io.rest) welches den OSGi-HTTP-Service implementiert. 3.1.3 openhab Erweiterungen openhab Add-on Libraries: Da in [Uh15i] keine weiteren Informationen vorliegen, welche Komponenten der openhab-software den openhab Add-on Libraries zugehörig sind, ist anzunehmen, 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 für eine Konsole die mithilfe des Interpreters einfache Kommandos (items, send, update, status, say und >) umsetzt..cv - Hier sind alle Schnittstellen der Web-basierten Echtzeitvisualisierung CometVisu wiederzufinden [May15]..dropbox - Ermöglicht die Nutzung des Filehosting-Dienst Dropbox. Zur Realisierung wird das Dropbox Core SDK (Software Development Kit) in der Version 1.7.3 verwendet [Inc15a]..gcal - Es können Google Kalender Einträge heruntergeladen und dazu genutzt werden um mit dem Quartz-Scheduler die relevanten Aktionen durchzuführen [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 für Mac OS und MaryTTS die genutzt werden können um openhab mit der eigenen Stimme zu kontrollieren [Uh15c]..net - Dieses Paket enthält Realisierungen um z. B. in openhab-skripten die Konsolen- Kommandos oder einen HTTP-Request auszuführen..servicediscovery - Eine Realisierung des Netzwerkprotokoll mdns (multicast Domain Name System) bei Verwendung der JmDNS Implementierung in der Version 3.4.1 [JmD15]..squeezeserver - Der Squeezeserver regelt die Kommunikation zwischen der openhab- Software und den Netzwerk-Musikplayern Squeezebox [Uh15r]. openhab User Interfaces: Grundsätzlich bietet die openhab UG sowohl Mobile- als auch Desktop-UIs (User Interfaces) an. Zu den Mobile-UIs existieren für die Betriebssysteme Android, ios und Windows Phone eigenständige Applikationen. Für die Standard-Desktop-UI wird das WebApp.Net Framework eingesetzt, ansonsten kann eine UI auch als GreenT (Sencha JavaScript Framework) oder mit CometVisu gestaltet werden [Uh15s]. Um die Gestaltung der UI für den Endanwender möglichst einfach zu halten, wird die Konfiguration über die deklarativen UI-Definitionen der Sitemaps realisiert. Die Sitemaps sind wie die Skripte in Xtext geschrieben [Uh15d]. Für die Darstellung bzw. Übertragung der Dokumente an die Clients wird der Servlet-Container des Webservers Jetty in der Version 8.1.3 [Fou15c] verwendet. openhab Automation Logic: Als die openhab Automation Logic ist ein Zusammenspiel der Script-Engine und der Scheduler zu bezeichnen. Also die Verarbeitung der openhab-regeln bzw. openhab-skripte bei Verwendung des Quartz-Scheduler. Obwohl Kai Kreuzer anfänglich dieses Zusammenspiel als die perfekte Funktionseinheit tituliert,... Xtext + Xbase + Quartz + Joda Time = Perfect Rule Engine [Kre15, 20. Mai 2012].... stehen für 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 Implementierung eines OSGi-Bundles für eine Technologie bzw. ein Protokoll. Derzeitig verfügt die openhab-software über mehr als 120 Bindings. Repräsentativ für die Umsetzung namhafter Protokolle steht das DMX-, EnOcean-, FritzBox-, FS20-, HomeMatic-, Hue-, KNX-, Koubachi-, SamsungTV-, XBMC- und ZWave-Binding [Uh15i]. Exemplarisch soll die Implementierung des Hue-Binding genauer betrachtet werden. Abbildung 3.2: UML-Klassendiagramm des Philips Hue-Bindings Die Abbildung 3.2 zeigt das UML-Klassendiagramm des Philips Hue-Bindings. Aufgrund der Komplexität sind in dem Diagramm keine Attribute oder Methoden dargestellt. Die HueBinding - Klasse ist die zentrale Komponente des Bindings. Sie verwirklicht die Schnittstellenfunktionalität des HueBindingProvider und des ManagedService um die registrierten Hue-Items (Lampen) aufzulisten und auf mitgeteilte Änderungen der Konfiguration durch den Configuration Admin Service zu reagieren. In der HueBinding -Klasse interpretiert die execute - Methode die eingehenden Events (Licht an/aus, Lichtintensität, Farbe), informiert den Event Publisher und nimmt die Änderungen an der Konfiguration vor [Uh15m, Hartmann R., Schering J.]. Der folgende Quelltext zeigt einen Ausschnitt der execute -Methode indem die Lichtintensität einer Lampe reguliert wird. 1:... 2: if ( deviceconfig. gettype (). equals ( BindingType. brightness )) { 3: if (( bulb. getison () == true ) && ( bulb. getisreachable () == true )) { 21

3 openhab 4: // Only postupdate when bulb is on, otherwise dimmer item is not retaining state and shows to max brightness value 5: PercentType newpercent = new PercentType (( int ) Math. round (( bulb. getbrightness () * ( double ) 100) / ( double ) 255) ); 6: if (( deviceconfig. itemstatepercenttype == null ) ( deviceconfig. itemstatepercenttype. equals ( newpercent ) == false )) { 7: eventpublisher. postupdate ( hueitemname, newpercent ); 8: deviceconfig. itemstatepercenttype = newpercent ; 9: } 10: } 11:... Quelltext 3.2: Ausschnitt der execute -Methode der HueBinding -Klasse [Uh15m, Hartmann R., Schering J.] Vor der Ausführung des Events ist eine Plausibilitätsprüfung der HueSettings vorangestellt, die möglichen Aufschluss über eine fehl-konfigurierte bzw. nicht initialisierte Hue-Bridge gibt. Ein Objekt der HueBulb -Klasse stellt eine konkrete Lampe dar und bietet zahlreiche Methoden an, um die Lampen-Parameter einzustellen oder auszulesen. Die SsdpDiscovery -Klasse wird dazu verwendet, die IP-Adresse der Hue-Bridge aufzulösen. Die HueActivator -Klasse ist eine Implementierung des OSGi-Bundle-Activator und stellt eine Protokollierung für 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 Verknüpfungen (AND, OR, NAND und NOR) kann der openhab Item Provider auch einige Aggregatfunktionen (AVG, SUM, MIN und MAX), für Items die einer Gruppe angehören, ausführen [Uh15m, Kreuzer K., Eichstädt-Engelen T.]. 3.2 openhab Runtime Der openhab Runtime werden in [Uh15i] alle in Abschnitt 3.1 beschriebenen Komponenten der Architektur zugeordnet. Um dem Endanwender eine ausführbare Software für die Betriebssysteme Windows, Mac OS X und Linux anzubieten, wird die Build-Management Software Maven 3 eingesetzt. Dabei wird die Versions- und Abhängigkeitsverwaltung der Bundles in den XML-Files (pom.xml) festgelegt [Kre15, 27. April 2008]. Letztendlich steht dem Endanwender 22

3 openhab eine Software zu Verfügung die er in den in [Uh15h] beschrieben Schritten auf seinem Betriebssystem installieren kann. Die dort aufgeführten Addons sind die Jar-Archive der Bindings und müssen explizit vom Endanwender installiert und konfiguriert werden. Für 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 für die Konfiguration der openhab Runtime genutzt werden kann. Die Funktionalität der Applikation ist zu vergleichen mit der eines einfachen Text-Editors der zusätzlich eine Syntaxüberprüfung, Syntaxhervorhebung und Autovervollständigung für 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 herstellerübergreifende Verwaltungstelle sondern als Heimautomatisierungssoftware zu bezeichnen. Die Regeln dienen der Automatisierung von Hardwarekomponenten und Web-Technologien. In den Regeln wird z. B. definiert, dass Fenster geschlossenen und Rollläden heruntergelassen werden, wenn durch die am Haus angebrachte Sensorik schlechtes Wetter signalisiert bzw. triggert wird. Die Regeln sind in Xtext verfasst und deren Aufbau und Strukturblöcke gleichen denen von Java-Dateien: 1. Import, 2. Variablen-Deklarationen und 3. Regeln (when-then-block). Um Regeln auszulösen bietet die openhab-software drei unterschiedliche Varianten von Triggern an [Uh15p]. Dabei können Regeln ausgeführt werden wenn...... sich der Status eines Items geändert hat oder selbiges ein Kommando erhält (itembased.... eine Uhrzeit erreicht ist oder der mit dem Quartz-Scheduler definierte Ausdruck zutrifft (time-based). 23

3 openhab... die openhab-software gestartet oder gestoppt wird (system-based). Skripte: Die Skripte sind in Xtend geschrieben und dienen dazu redundanten Programmcode in den Regeln zu vermeiden. Sie werden innerhalb des Then-Blocks einer Regel aufgerufen - vergleichbar mit einem Methodenaufruf jedoch ohne Ein- und Ausgabeparameter [for15, Eichstädt-Engelen T. al. teichsta]. Aktionen: Die Aktionen sind Java-Methoden deren Funktionalität den Regeln und Skripten zur Verfügung steht. Die openhab-runtime bietet bereits Aktionen an [Uh15a]: Die dem openhab Event Bus zugehörigen Aktionen zum Senden eines Events, aktualisieren eines Item-Status und speichern oder wiederherstellen von Status eines oder mehrerer Items. Alle audio-relevanten Aktionen für die Steuerung der Lautstärke, das Abspielen von Audio-Dateien oder Streams und die TTS-Wiedergabe. Und zudem Aktionen zur Protokollierung und für die Ausführung eines HTTP-Request oder einem Befehl auf der Konsole. Die oben aufgelisteten sind die Aktionen die nach der Installation der openhab Runtime serienmäßig verfügbar sind. Alle weiteren Aktionen müssen vom Endanwender als Add-on nachinstalliert werden - hierzu zählen [Uh15a]: Die Aktionen um SMTP (Simple Mail Transfer Protocol) Dienste zu nutzen oder eine Kommunikation mit dem XMPP (Extensible Messaging and Presence Protocol) zu realisieren. Und zudem Aktionen um Nachrichten an ios oder Android Geräte zu schicken. 3.4.2 Jobmanagement Für das Jobmanagement wird der Quartz-Scheduler eingesetzt. Der Quartz-Scheduler kann Trigger erzeugen die einem Job zugeordnet und planmäßig ausgelöst werden. Für die planmäßige Ausführung 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 Abschnitt 2.1.1 und 3.1.3 beschriebenen Bundles basiert: 24

3 openhab As openhab allows adding support for a new system by implementing a single OS- Gi bundle (a so-called binding ), we have seen a great activity in the community during the past months [Kre15, 17. Dezember 2012] Bei Instanziierung der Bundles (openhab-bindings) können die Services über die Java-Interfaces genutzt und über 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 möglich. Da lediglich die Status der Items persistiert werden, ist keine Erfahrung in der SQL (Structured Query Language) 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 aufgeführt und die Items-Sektion in denen die Items mit zugehöriger Strategie aufgelistet sind. Die SQL wird in den Bindings realisert und bleibt dem Anwender verborgen. Die derzeitig unterstützen 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 Konnektivität zur MySQL-Datenbank hergestellt und die Tabelle Items angelegt. Auf Anfrage werden die Items mit ihrem Namen abgespeichert. Des Weiteren werden die openhab-typen auf die MySQL-Datentypen abgebildet. 1:... 2: public void activate () { 3: // Initialise the type array 4: sqltypes. put (" COLORITEM ", " VARCHAR (70) "); 5: sqltypes. put (" CONTACTITEM ", " VARCHAR (6) "); 6: sqltypes. put (" DATETIMEITEM ", " DATETIME "); 7: sqltypes. put (" DIMMERITEM ", " TINYINT "); 8: sqltypes. put (" GROUPITEM ", " DOUBLE "); 25

3 openhab 9: sqltypes. put (" NUMBERITEM ", " DOUBLE "); 10: sqltypes. put (" ROLERSHUTTERITEM ", " TINYINT "); 11: sqltypes. put (" STRINGITEM ", " VARCHAR (20000) "); 12: sqltypes. put (" SWITCHITEM ", " CHAR (3) "); 13: } 14:... Quelltext 3.3: Ausschnitt des MySQL-Services - Datentypen [Uh15m, Sjöstrand H., Eichstädt- Engelen T., Jackson C.] Für jedes openhab-item, das in der Item-Sektion aufgelistet ist, legt openhab automatisch eine Tabelle an, in der die Entitäten der Items als (Time, Value)-Paare gespeichert sind. Der Endanwender hat somit keinen Einfluss auf die Tabellenstruktur oder Aufbau der Entitäten. 3.7 Sonstiges Neben den in Abschnitt 3.1.2 erörterten Transformation-Services, dem REST-Binding und den TTS Diensten in Abschnitt 3.1.3, bietet die openhab-software die Integration von derzeitig neun Applikationen an [Uh15b]. Erwähnenswert ist das Astersik Framework (http://www.asterisk.org/) für die Umsetzung von IP PBX (Private Branch Exchange) Systemen und VoIP Gateways und das ROS (Robot Operating System) (http://www.ros.org/). 26

4 Bewegungserkennung von Personen In Kapitel 3 wird erörtert, inwieweit openhab die Programmierparadigmen des OSGi-Standards aus Kapitel 2 umsetzt bzw. verfolgt. Auf dieser Wissensbasis aufbauend, soll nun ein realitätsnahes Anwendungsszenario aus dem Bereich der Bewegungserkennung erarbeitet werden, welches Hardwarekomponenten unterschiedlicher Hersteller einsetzt und somit eine herstellerübergreifende HA bzw. GA beim Einsatz von openhab realisiert. Dazu wird in den Folgeabschnitten neben dem Aufbau, eingesetzter Hard- und Software auch die Implementierung und die eigentliche Durchführung des Szenarios beschrieben. Eine detaillierte Ergebnisauswertung und alternative Lösungsansätze sind in Kapitel 5 - Ergebnisse und Alternativen wiederzufinden. Zwar ist das hier beschriebene Szenario explizit auf die Bewegungserkennung von Personen zugeschnitten, dennoch ist eine Detektion der Bewegung von Tieren oder Gegenständen bei den eingesetzten Technologien und Verfahren gleichermaßen anzuwenden. Neben möglichen Anwendungsbereichen der Bewegungserkennung von Personen in Zweckbauten, wie z. B. die Überwachung von Arbeitnehmern in Bürogebäuden oder die Auswertung von Verbraucherverhalten in Einkaufszentren, verfolgen die Einsatzbereiche im privaten Wohnungsbau eine effiziente Steuerung der Hausautomatik, eine Angriffserkennung und eine Gesundheitsvorsorge der Personen [vgl. Han+14, S. 271; Kos+12, S. 181]. So wird z. B. beim Betreten/Verlassen einer Räumlichkeit das Licht automatisch an/aus geschaltet, das Eindringen von unerwünschten Personen oder ein kritischer Gesundheitszustand frühzeitig erkannt und hilfestellende Maßnahmen eingeleitet. Die Erkennungssysteme für die erwähnten Anwendungsbereiche sind in zwei Klassen zu unterteilen - (1) device-based und (2) device-free. [Han+14] unterscheidet vier Klassen die (1) und (2) wie folgt zuzuweisen sind: (1) device-based - Hierunter fallen die Systeme, bei denen die notwendige Sensorik zur Bewegungserkennung direkt an den Personen angebracht ist. a) wearable sensor based - [Har13] zeigt Systeme, die eine Sensorik an Händen, Füßen oder am Oberkörper der Personen vorsehen. Die INSs (Inertial Navigation Systems) verwenden neben Trägheits- und Beschleunigungssensoren auch Gyroskope und Magnetometer, die neben der Lokalisierung auch eine Navigation ermöglichen - die SHSs (Step-and-Heading Systems) nutzen zudem Barometer und Funkschnittstellen. Zwar liegt der Fokus der 27

4 Bewegungserkennung von Personen Anwendung dieser Systeme in der Lokalisierung und der Navigation von Personen, eine Bewegungserkennung ist aber durch eine mehrfache Lokalisierung gegeben. b) smart-{phone watch} based techniques - Diese Systeme gleichen den wearable sensor based Systemen. Einziger Unterschied ist, dass die vorliegende Infrastruktur nicht erweitert, sondern auf die vorhandene Sensorik von Smartphone oder Smartwatch zurückgegriffen wird - Je nach verwendeten Endgerät stehen Barometer, Bluetooth, WLAN, GPS, Gyroskop, Beschleunigungs- und Helligkeitssensor zur Auswahl. [Iwa+13] zeigt einen Lösungsansatz der auf der Wi-Fi Sensorik beruht. (2) device-free - Die Bewegung wird anhand von Sensoren erkannt, die nicht von Personen mitgeführt werden, sondern explizit in der Räumlichkeit verbaut bzw. installiert sind. a) vision based - Für die Bewegungserkennung werden Bilder von hochauflösenden Kameras ausgewertet. Die Präzision der Systeme reicht bis hin zur fingergenauen Gestenauswertung [Uts+02]. b) ambient device based - Diese Systeme benötigen fest installierte Bewegungs-, oder Präsenzmelder, werten Audio-Signale von Mikrofonen oder Daten von Piezo-Sensoren aus. [Alw+06] beschreibt ein Verfahren zur Erkennung von gestürzten Personen beim Einsatz von Piezo-Sensoren und deutet zudem auf eine mögliche Auswertung der Fortbewegung von Personen hin. Für (1) ist nachteilig zu erwähnen, dass - bis auf ein evtl. vorhandenes Smartphone - alle Endgeräte und Sensoren explizit für den Anwendungsfall erworben werden und zu jeder Zeit an der Person angebracht sein müssen - was auf Dauer eine hohe Belastung für die Person darstellt. Die Klasse device-free besitzt neben den hohen Anschaffungskosten weitere Defizite, die eine korrekte Bewegungserkennung verhindern: Die vision based Systeme scheitern oft an der notwendigen LOS (Line-Of-Sight) zur Person (z. B. tote Ecken / Winkel), sind nur auf bestimmte Räumlichkeiten des privaten Wohnraums begrenzt oder können nicht in der Dunkelheit ausgewertet werden. Bei (1b) bedarf es zudem einer Planung vor Fertigstellung der Lokalität - z. B. die Piezo-Sensoren werden meist vor Montage des Fußboden installiert. Somit ist für die Einrichtung der obigen Systeme die vorhandene Infrastruktur zu erweitern. Grundsätzlich könnten diese Systeme für eine korrekte Szenariodurchführung angewendet werden, dennoch soll aufgrund der genannten Defizite die Klasse (2) um rf device based Systeme ergänzt und für das in diesem Kapitel beschriebene Szenario verwirklicht werden: Darunter fallen alle Systeme, die keine Sensorik an den Personen vorsehen, einen funkbasierten Ansatz (Radiowellen) verfolgen und die vorhandene Infrastruktur nutzen. Die Radiowellen benötigen keine direkte LOS zu den Personen [Kos+12, S. 181] und die Auswertung der Bewegungserkennung kann auf bereits installierten WAPs (Wireless Access Points) des konfigurierten WLAN stattfinden. Stellvertretend für die eingeführte Klasse stehen folgende Ansätze: In [Han+14] wird WiFall vorgestellt - ein System das den Sturz einer Person mit 87% Wahrscheinlichkeit 28

4 Bewegungserkennung von Personen erkennt und eine Fehlerrate von 18% besitzt [Han+14, S. 278]. Zwar unterscheidet die referenzierte Literatur die Falltypen in Fallrichtungen, Endpositionen und Rotationen [Nou+07, S. 1665], WiFall zeigt jedoch keine typenspezifische Auswertung die Aufschluss über die erzielte Ungenauigkeit und Fehlerraten geben könnte. Ein weiteres System ist RASID, das die Erkennung einer Bewegung anhand der aufgezeichneten RSSI (Received Signal Strength Indicator) im WLAN realisiert [Kos+12]. In [Kos+12, S. 182 ff.] wird statistischer Mittelwert und Varianz der gemessenen RSSI zur Berechnung verwendet. Weitere Erkenntnisse der Auswirkung der menschlichen Bewegung auf die Varianz der RSSI wird in [EK+11] gezeigt. In [Kas+12] wird die Implementierung eines Systems vorgestellt, das die Präsenz von Vehikel erkennt und deren Geschwindigkeit abschätzen kann. Die oben genannten Systeme sehen neben dem zentralen Leitrechner zumeist einen Rechner für die Auswertung der gemessenen RSSI vor, d.h. die Analyse der Bewegungserkennung wird nicht direkt von einem WAP übernommen. Für die Realisierung des Projektziels soll ein rf device based System umgesetzt werden, das in Verbindung mit openhab ein Szenario der herstellerübergreifenden 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 für 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 verfügt über 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 für den Einsatz der openhab-software eingesetzte Laufzeitumgebung ist OpenJDK-Java-7. Sowohl die openhab-runtime, der openhab-designer als auch die zugehörigen Bindings org.openhab.binding.{hue, http}, org.openhab.persistence.{rrd4j, mysql} liegen in der Version 1.6.2 vor. Für die Ausführung der Skripte werden sshpass und die Bash-Shell genutzt. Die erste herstellerabhängige Hardwarekomponente ist das Philips Hue Living-Colors Bloom Starter Kit [V15]: Hardware: Die Hue-Bridge (1xLAN) dient als Controller für die Hue Bloom Leuchten. 29

4 Bewegungserkennung von Personen 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 für 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 Betriebssystem Barrier Breaker in der Version 14.07 installiert [wik15b]. Auf dem Sender wird das Paket mgen (Multi-Generator) und auf dem Receiver werden die Pakete tcpdump (inkl. libpcap) und luasocket installiert. In der Grundinstallation von OpenWrt ist der Lua (Imperative und funktionale Skriptsprache) Interpreter verfügbar. 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 für eine openhab und Hue-Bridge Konfiguration aufgelistet. Die genannten Bindings sind im Ordner addons hinterlegt. Für den Start von openhab ist das Shell-Skript (start.sh) auszuführen. Alternativ kann openhab auch zeitgleich 30

4 Bewegungserkennung von Personen mit dem Systemstart von Ubuntu initialisiert werden [Uh15k]. Für die Steuerung der Hue- Leuchten über die Hue-Bridge ist keine weitere Konfiguration notwendig. [wik15b] beschreibt die Installation von OpenWrt auf den WAPs und beinhaltet die Benutzeroberfläche Luci. Nach dem ersten Start der WAPs ist für beide ein Systempasswort via Telnet (Teletype Network) zu vergeben. Um den Zugriff mittels SSH (Secure Shell) zu ermöglichen, müssen folgende Einstellungen vorgenommen werden: 1. Die Firewall-Regeln des WAN (Wide Area Network) -Port anpassen, d.h. sowohl eingehender 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 über den WAN-Port anschließen. Für die Konfiguration der Funkschnittstellen sind die Konfigurationsdateien wireless und network, wie in Anhang 7.2.1 und 7.2.2 für den Receiver und in Anhang 7.3.1 und 7.3.2 für den Sender dargestellt, anzupassen. Alternativ kann eine Konfiguration der Schnittstellen auch über die Benutzeroberfläche erfolgen (Luci:Network/Interfaces und Network/Wifi). Letztendlich kommunizieren beide WAPs über 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 Sender noch über eine virtuelle Funk-Schnittstelle im Monitor-Mode verfügt, um den eingehenden Netzwerk-Verkehr zu analysieren. Um die Kommunikation im Ad-hoc-Netz aufrechtzuerhalten, senden die WAPs die Beacon Frames zum Kommunikationspartner. Da für die spätere Szenariodurchführung analysiert werden soll, inwieweit die Güte der Bewegungserkennung von der Anzahl der analysierten Pakete abhängt, 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 benötigt [Neh15]. Für 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 Bewegungserkennung von Personen 4.3 Implementierung Durch die zuvor deklarierte Sitemap (7.1.3) und die angegebenen Items (7.1.2) visualisiert der Webserver die Benutzeroberfläche (7.4), die in fünf Sektionen eingeteilt ist: 1 Steuerung: Der Verweis Philips Hue-Bloom Lampen führt zum Sub-Menü wo dann die Hue-Bloom Leuchten an und ausgeschaltet werden können. Zudem können die Leuchten auf alle Farben aus dem HSV-Farbraum gesetzt werden. 2 Profil erstellen: Diese Sektion ermöglicht dem Anwender das Messen einer Signalstärke für die vorliegende Räumlichkeit und die eingestellte Distanz zwischen Sender und Receiver. Standardmäßig ist die Dauer der Messung auf zehn Sekunden eingestellt. Der Rückgabewert ist die durch die Anzahl der über den Zeitraum gemessenen Pakete gemittelte Signalstärke und wird automatisch in gespeicherte Signalstärke eingetragen. Zudem wird die maximal und minimal gemessene Signalstärke an die Benutzeroberfläche übermittelt. Das in Abbildung 4.2 visualisierte UML-Sequenzdiagramm behandelt diesen Anwendungsfall. 3 Bewegung erkennen: Die dritte Sektion behandelt den Anwendungsfall der Bewegungserkennung. Für die spätere Szenariodurchführung ist der absolute Signalstärkenunterschied von gespeicherter Signalstärke aus Sektion 2 und in gemessener Signalstärke aus Sektion 3 individuell einstellbar. Falls der Receiver eine Signalstärke misst, die den einstellten Grenzwert überschreitet, wird die Signalstärke eingetragen und somit die Bewegung erkannt. Der Anwendungsfall ist im UML-Sequenzdiagramm 4.3 dargestellt. 4 Multi-Generator: Um die Verbindung des Ad-hoc-Netzes aufrecht zu erhalten, senden beide WAPs im Rotationsverfahren die Beacons-Frames an die Kommunikationspartner [Inc15d] - im vorliegenden Szenario ca. 6-8 Pakete pro Sekunde. Um eventuelle Abhängigkeiten zwischen der Güte der Bewegungserkennung und Anzahl der gemessenen Pakete aufzuzeigen, kann der Anwender zusätzlichen Netzwerk-Verkehr beim Sender erzeugen - UML-Squenzdiagramm 4.4. 5 Graph: Die fünfte Sektion zeigt die graphische Visualisierung der unterschiedlichen Signalstärken. Das Ziel der Implementierung ist es, eine Bewegung anhand einer Grenzwertüberschreitung von gemessenen Signalstärken zu erkennen und durch den Einsatz von unterschiedlichen Hardwarekomponenten und der openhab-software die Machbarkeit der herstellerübergreifenden GA bzw. HA aufzuzeigen. Im Folgenden soll die umgesetzte Implementierung anhand der Sequenzdiagramme erörtert werden: Profil erstellen: Der Anwender startet seinen Browser, ruft die Start-Url von openhab auf (z.b. htttp://openhab:8080) und authentifiziert sich gegebenenfalls. Der Webserver stellt ihm die Benutzeroberfläche zur Verfügung und die openhab-items werden durch die Regel In- 32

4 Bewegungserkennung von Personen itialize Items (7.1.5) initialisiert. Sobald der Anwender die Dauer eingestellt und den Schalter für Signalstärke messen betätigt hat, startet die Messung. Durch Betätigung ändert sich der Status des Schalters von OFF und ON und triggert die Regel Measure RSSI Profile. Neben Log-Informationen wird dem Anwender der Start und das Ende der Messung durch Änderung der Farbe und Lichtintensität der beiden Leuchten signalisiert. Die eigentliche Messung wird durch die Methode executecommandline ausgeführt. Die Methode ruft das im Ordner configurations/scripts abgelegte Bash-Skript remote.sh (7.1.6) auf und übergibt die Parameter capture, Dauer und Item-Namen. Im Bash-Skript wird der SSH Aufruf für den Receiver durchgeführt, 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 für die vom Anwender eingestellte Dauer und teilt dem Leitrechner durch Verwendung der REST-API und Aufruf der HTTP-Post-Methode die Änderung des openhab-items für die übermittelten 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 verfügbaren Items als XML-Datei abzurufen. Hierfür 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 Paketes LuaXML, ist aber für dem Anwendungsfall Profil erstellen nicht notwendig. Obwohl in [Uh15o] auf den Mime-Type application/json hingewiesen wird, ist er bei ausgewählter Hard- und Software nicht verfügbar. Selbst eine Anpassung der Konfiguration des Webservers blieb erfolglos. In der weiteren Verarbeitung von Profil erstellen wird der Schalter in der Regel Measure RSSI Profile auf OFF gestellt und dem Anwender neben der gespeicherten 33

4 Bewegungserkennung von Personen Signalstärke und den Änderungen der Leuchten ein Ende der Messung signalisiert. Für die Visualisierung der Signalstärken in Sektion 5 werden die Signalstärken mit der Konfiguration der Persistenz (7.1.4) gespeichert. Durch die gewählten Strategien werden die Werte bei jeder Änderung und jede Minute persistiert. Bewegung erkennen: Der Anwender hat bereits ein Profil erstellt und den Grenzwert für den Signalstärkenunterschied eingestellt. Durch die Betätigung des Schalters Bewegungserkennung wird der Status des Items auf ON gestellt und die Regel Start recognizing movement (7.1.5) getriggert. Die Methode executecommandline wird ausgeführt und die Parameter recognize, die gespeicherte Signalstärke, der Grenzwert und die Item-Namen dem Bash-Skript für die Ausführung des Lua-Skripts capturerecognition.lua (7.2.5) auf dem Receiver übermittelt. Wie bei dem oben erörterten Anwendungsfall nutzt das Lua-Skript die vom tcpdump gesnifften Pakete und überprüft, ob die gespeicherte Signalstärke und die derzeitig ermittelte Signalstärke den angegebenen Grenzwert überschreitet. Abbildung 4.3: UML-Sequenzdiagramm - Bewegungserkennung starten und stoppen Eine Überschreitung wird über die REST-API und Aufruf der HTTP-Post-Methode als neuer Wert im openhab-item eingetragen. Bei Änderung des Wertes wird die Regel Movement recognized getriggert und dem Anwender eine Bewegung durch einen Farbwechsel (Grün / Rot) der Leuchten gekennzeichnet. Das Lua-Skript führt solange Berechnungen durch, bis der Anwender den Schalter Bewegungserkennung erneut betätigt und dadurch die Regel Stop recognizing movement anstößt. Die Regel führt das Bash-Skript aus, das dann den Befehl zur Terminierung der Prozesse von tcpdump und dem Lua-Interpreter auf dem Receiver auslöst. 34

4 Bewegungserkennung von Personen Multi-Generator: Sowohl bei Profil erstellen als auch bei Bewegung erkennen werden nur die empfangenen Beacon-Frames vom Sender ausgewertet. Mit dem Multi-Generator kann der Anwender optional auf dem Sender zusätzlichen Netzwerk-Verkehr in Form von 64 Byte großen UDP-Paketen erzeugen. Bei Betätigung des Schalters UDP-Verkehr erzeugen agiert die Regel Send more packets und führt das auf dem Sender befindliche MGen-Skript (7.3.3) aus. Das MGen-Skript startet auf der Funkt-Schnittstelle wlan0 einen unendlichen und periodischen UDP-Fluss and die angegebene Zieladresse - hier exemplarisch zehn Pakete pro Sekunde, ansonsten wird die Eingabe vom Anwender berücksichtigt. Die so erzeugten UDP- Pakete werden automatisch bei der Auswertung der Signalstärken berücksichtigt. Falls der Anwender den UDP-Verkehr stoppt, wird die Regel Stop sending packets aufgerufen und der Prozess auf dem Sender terminiert. Abbildung 4.4: UML-Sequenzdiagramm - Zusätzliche UDP-Pakete senden Graph: Für die graphische Visualisierung wird die rrd4j-persistenz (7.1.4) eingesetzt. Für eine korrekte Visualisierung des Chart-Item GRSSI Chart - eine Gruppierung der drei gemessenen Signalstärken - ist eine Speicherung mit mindestens der everyminute -Strategie obligatorisch [Uh15t]. Bei derzeitigem Entwicklungsstand des rrd4j-bindings ist eine Anpassung für eine individuelle Achsenbeschriftung oder Skala nicht möglich. 35

4 Bewegungserkennung von Personen 4.4 Aufbau und Durchführung Sowohl Aufbau als auch Durchführung 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 über Ethernet im gleichen Subnetz (10.20.114.0 24) verbunden. Dabei ist der Abstand von Leuchten und Hue-Bridge für eine korrekte Funktionsweise unerheblich. Der Szenarioaufbau ist insofern statisch, als dass lediglich der Abstand (1m, 2m, 4m, 6m und 10m) von Sender und Receiver bei der Durchführung variabel ist. Die Antennen der Router sind auf einer Höhe von 95cm angebracht. Für jede Distanz zwischen den WAPs ist sowohl Profil erstellen als auch Bewegung erkennen für zwei Signalleistungen (30dBm und 15dBm) durchzuführen. Für die Distanzen 1-6m ist die LOS der WAPs nicht beeinträchtigt. Bei einer abschließenden Durchführung ist die LOS durch eine 16cm dicke Betonziegelwand gehindert. Abbildung 4.5: Aufbau des Szenarios in der Hochschule Bonn Rhein Sieg (Raum C060) [ope15] 36

4 Bewegungserkennung von Personen Um False-Positives auszuschließen, ist für jeden Messdurchlauf nach Profil erstellen für Bewegung erkennen eine Ruhe-Phase eingeplant, in der keine Bewegung stattfindet. Eine Steuerung der Benutzeroberfläche erfolgt über die Android-Applikation HABDroid [Uh15j]. Nach dieser Ruhe-Phase betritt die Testperson den Raum: Sie öffnet die Tür und geht langsamen Schrittes durch die LOS der WAPs hindurch - bis zur eingezeichneten Fensterwand, kehrt um verlässt den Raum und schließt die Tür. Dabei ist die Messung als False-Negatives zu werten, falls die Testperson den Raum durchschritten aber keine Grenzwertüberschreitung stattgefunden hat. Für die Abbildung eines realitätsnahen Szenarios sind für jeden Messdurchlauf weitere WAPs in Reichweite (in- und außerhalb des Raumes) des Senders und Receivers auf dem 2,4GHz Frequenzband verfügbar. Mögliche Fehlmessungen, durch auftretende Interferenzen mit den anderen WAPs, sind deshalb nicht ausgeschlossen. Für die anschließende Auswertung werden die gemessenen Daten bei jeder Änderung in der MySQL-Datenbank persistiert und mit dem SQL-Query (7.1.4) abgefragt. Eine korrekte Bewegungserkennung hängt somit von folgenden Parametern ab: Die Dauer für die Profilerstellung und somit die Anzahl der Pakete für die Mittelwertbildung der gespeicherten Signalstärke, der eingestellte absolute Grenzwert für den Signalstärkenunterschied bei aktueller Distanz zwischen Sender und Receiver und die vom Sender und Receiver eingestellte Signalleistung. Die in Kapitel 5 - Ergebnisse und Alternativen aufgeführten Ergebnisse geben Aufschluss über die Zusammenhänge bzw. Abhängigkeiten der Parameter. 37

5 Ergebnisse und Alternativen 5.1 Ergebnisse Bei Durchführung des im vorherigen Kapitel beschriebenen Szenarios, ergeben sich die in Abbildung 5.1, 5.2, 5.3 und 7.14 dargestellten Ergebnisse für insgesamt elf Messdurchläufe. Die erste Spalte jeder Abbildung kennzeichnet den Messdurchlauf. Die Abbildung 5.1 behandelt den Anwendungsfall Profil erstellen und berücksichtigt die Parameter für Sichtausbreitung, Distanz und Sendeleistung der WAPs. Für eine Dauer von jeweils 60 Sekunden ist für jeden Messdurchlauf der minimale, maximale und gemittelte RSSI errechnet. Aufgrund einer unzureichenden Verbindung ist bei dem neunten Messdurchlauf eine Sendeleistung von 20dBm statt 15dBm verwendet worden. Für den elften Messdurchlauf wurde in Abgrenzung zum zehnten Messdurchlauf der Multi-Generator mit zusätzlichen 25pps genutzt. Abbildung 5.1: Messergebnisse für den Anwendungsfall Profil erstellen In Abbildung 5.2 sind die Messergebnisse für den Anwendungsfall Bewegung erkennen in der Ruhe-Phase aufgeführt. Die Einstellung für den Grenzwert ist durch die Abweichung der gemessenen RSSI aus Profile erstellen zu begründen und ist für Ruhe- und Bewegungs-Phase gleichgesetzt. Die False-Positives - eine fälschlicherweise erkannte Bewegung in der Ruhe-Phase 38

5 Ergebnisse und Alternativen - sind die prozentualen Anteile der Grenzwertüberschreitungen für die Anzahl der Messungen. Für die Messdurchläufe #1-3 und #6 ist ein False-Positive aufgetreten. Die möglichen Erklärungen für die False-Positives sind mit den Anmerkungen (Anhang 7.14) abzugleichen. Abbildung 5.2: Messergebnisse für den Anwendungsfall Bewegung erkennen (Ruhe-Phase) Exemplarisch für den Messdurchlauf #2 ist der False-Positive aufgetreten, als eine Person mit ihrem Laptop an dem Raum C060 vorbeigegangen ist. Für die Messdurchläufe #3 und #6 ist auf dem Smartphone mit der HABdroid Applikation zusätzlicher 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 Grenzwertüberschreitungen bei Anzahl der Messungen. Abbildung 5.3: Messergebnisse für den Anwendungsfall Bewegung erkennen (Bewegungs-Phase) 39

5 Ergebnisse und Alternativen Dem Anhang 7.5 sind die Visualisierungen der Messdurchläufe beigefügt und geben weiteren Aufschluss über die Abhängigkeit zwischen verwendeter Sendeleistung, Distanz und eingestelltem Grenzwert. Wenn auch die Messdurchläufe #1-7 eine präzise Grenzwerteinstellung aufweisen, wären bei Justierung des Grenzwertes für die Messdurchläufe #8, #10 und #11 mehr Überschreitungen zu verzeichnen. Der Grenzwert ist die Abweichung der in Profil erstellen gemessenen minimalen und maximalen RSSI zum gemittelten RSSI für eine Dauer von 60 Sekunden. Bei Verwendung der mittleren quadratischen Abweichung könnten mehr Messwerte als Bewegung erkannt werden, jedoch auch die Anzahl der False-Positives ansteigen - eine Messung über einen längeren Zeitraum ist obligatorisch. Die Visualisierungen zeigen deutlich, dass für alle Distanzen und Sendeleistungen sowohl bei als auch eingeschränkter 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 Szenariodurchführung eine herstellerübergreifende HA bzw. GA beim Einsatz von openhab gezeigt. 5.2 Alternative Ansätze Die in diesem Abschnitt aufgelisteten alternativen Ansätze sollen für das Szenario der Bewegungserkennung auf bereits implementierte openhab-bindings für herstellerabhängige Hardwarekomponenten und Einsatz von Open-Source-Software hinweisen. Bei Anwendung der Ansätze sind die in Kapitel 4 - Bewegungserkennung von Personen genannten Defizite der device-free - vision based und device-free - ambient device based Klassen zu bedenken. Variante Nr. 1 - Bewegungsmelder: HomeMatic: openhab: Homematic-Binding Neben openhab-rules und openhab-skripten ist keine Software erforderlich. Quelle: http://www.eq-3.de/sensoren-detail/items/hm-sec-mdir.html FS20: openhab: FS20-Binding Neben openhab-rules und openhab-skripten ist keine Software erforderlich. Quelle: http://www.elv.de/fs20-piri-2-hr-funk-bewegungsmelder-mit-dimme rsteuerung.html/refid/zanox/zanpid/2019358387397334016 EnOcean: openhab: EnOcean-Binding Neben openhab-rules und openhab-skripten ist keine Software erforderlich. Quelle: http://shop.loxone.com/dede/enocean-funk-bewegungsmelder.html 40

5 Ergebnisse und Alternativen Variante Nr. 2 - Videoauswertung: Microsoft Kinect: openhab: REST-Binding Für die Realisierung ist der Jnect -Adapter und das Microsoft Kinect SDK notwendig. Quelle: https://code.google.com/a/eclipselabs.org/p/jnect/ Motion Detector Bricklet: openhab: REST-Binding Für die Realisierung ist der Einsatz von jmt obligatorisch. Quelle: http://www.tinkerforge.com/de/doc/software/bricklets/motiondete ctor_bricklet_java.html Java-Motion-Tracking: openhab: REST-Binding Die Open-Source Software jmt verwendet das Java Media Framework. Quelle: https://code.google.com/p/java-motion-tracking/ JMyron: openhab: REST-Binding JMyron ist eine Open-Source Bibliothek für die Bildmanipulation und Bewegungserkennung. Quelle: http://www.silentlycrashing.net/p5/libs/jmyron/ OpenCV: openhab: REST-Binding Mit den Algorithmen der OpenCV Bibliothek ist eine Bewegung durch Abgleich der aufgezeichneten Bilder vorstellbar. Quelle: http://opencv.org/ Variante Nr. 3 - Tonauswertung: Sphinx-4: openhab: REST-Binding Mit der sphinx4 Software können Audiosignale analysiert werden (Präsenzerkennung). Quelle: http://cmusphinx.sourceforge.net/wiki/tutorialsphinx4/ Variante Nr. 4 - LEAP Motion: LEAP Motion: openhab: Leap-Binding (frühe Alpha-Phase) Der Leap-Motion Sensor ist für eine Gestenerkennung bei kurzen Distanzen einsetzbar. Quelle: https://www.leapmotion.com/product 41

6 Zusammenfassung und Fazit Die vorherrschende Inkompatibilität zur Interoperabilität der herstellerabhängigen Technologien aus dem Bereich der Heim- bzw. Gebäudeautomatisierung zwingt die Hersteller zur Entwicklung von Hard- und Softwarelösungen. Einige dieser Lösungen sind lediglich als Gateway zweier Standards bzw. Protokolle angedacht und können darüber hinaus nicht mit anderen Produkten konkurrieren. In jüngster Zeit sieht der Trend der Automatisierung eine Softwarelösung auf dem Leitrechner vor, die alle konkurrierenden Hard- und Softwarekomponenten vereinigen kann. Die openhab-software ist eine solche Lösung die auch dem Begriff der IoT (Internet of Things) zuzuordnen ist: Die Idee des Internet of Things basiert darauf, dass die Dinge des Alltags vernetzt sind. Was aber, wenn das liebgewonnene Ding keine IP- Schnittstelle aufweist oder das verwendete Protokoll für den IoT-Service der Wahl unverständlich ist? Was, wenn alle Dinger mit einer einheitlichen Oberfläche bedient, ein gemeinsames Chart mit Daten bestücken, oder gemeinsamen Automatisierungsregeln fol- gen sollen? In diesem Fall können Integrationsplattformen helfen, die für diese Problemstellungen Lösungen anbieten. [EE15, 1. April 2012]. Wenn auch Thomas Eichstädt-Engelen als Mitbegründer der openhab UG diese Aussage sehr umgangssprachlich formuliert, trifft sie dennoch den Kerngedanken einer zukunftswürdigen Automatisierungsplattform: Nicht nur weil die openhab-software auf der Eclipse-Equinox, als Implementierung des OSGi-Standards, aufbaut, sondern auch weil die fortgeführte Implementierung die geforderten Programmierparadigmen achtet, ist openhab als dynamisches Modulsystem anzusehen. Dank der aufgelösten Programmkomplexität durch Dekomposition in Softwaremodule verfügt openhab sowohl über eine einheitliche Versionierung und Protokollierung als auch über eine Registrierung und Verwaltung von Diensten. Die verwendeten dynamischen Abhängigkeiten der Protokollimplementierungen (openhab-bindings) ermöglichen das (de-)installieren und konfigurieren von Diensten während der Laufzeit und sind somit autark: Hot Deployment. Statische Abhängigkeiten sind nur für die Kernkomponenten eingesetzt. Aufgrund einer zentralen Konfiguration für die Hard- und Softwarekomponenten, der umgesetzten 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 für den erprobten Endanwender nutzbar. Der Entwicklungsschwerpunkt der openhab Versionen 2.x liegt in der Verbesserung der Gebrauchstauglichkeit als Teildisziplin der User Experience, um dem Laien die Funktionen der Software zugänglicher zu gestalten. Eine Thematik für anknüpfende Arbeiten ist demnach die Analyse der User Experience bei Anwendung der heuristischen Evaluation, dem Cognitive Walk-Through oder den Usability-Tests. Neben den in Kapitel 5 - Ergebnisse und Alternativen gelisteten Ansätzen, kann Thema weitere Projekte auch eine verteile openhab-automatisierung über externe Laufzeitumgebungen sein. Für das in dieser Arbeit vorgestellte und durchgeführte realitätsnahe Szenario gilt eine Bewegungserkennung von Personen durch die Auswertung der empfangenen Signalstärke von WAPs anhand der Beacon-Frames als plausibel und kennzeichnet eine herstellerübergreifende Automatisierung beim Einsatz von openhab. Für diese Art der Bewegungserkennung ist vorteilhaft, dass keine Sensorik an den Personen angebracht und die Infrastruktur nicht erweitert werden muss. Für eine Produktreife in den Anwendungsbereichen der Angriffserkennung und der Gesundheitsvorsorge sind Messungen über einen längeren Zeitraum abzuhalten und die Entwicklung bis hin zur automatischen Konfiguration der WAPs fortzuführen. Für die Abschätzungen der Grenzwertüberschreitungen sind andere mathematische Ausdrücke bzw. Wahrscheinlichkeitsverteilungen anzuwenden. In [al15] wird ein mathematisches Model entwickelt, das bei Verwendung der Kullback Leibner Distanz und der gemessenen RSSI eine Auskunft über die Anzahl von Personen in der Lokalität gibt. Störeinflüsse durch evtl. Endgeräte auf dem gleichen Frequenzband bleiben unberücksichtigt. Zudem wird darauf hingewiesen, dass eine Auswertung der Signalstärken für alle Kanäle des Frequenzspektrums nahezu die gleichen Ergebnisse liefert, wie bei Auswertung der RSSI. 43

7 Anhang 7.1 Lex Uno Station - Leitrechner mit openhab 7.1.1 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 ä rke messen " icon =" fire " 15: Text item = RSSI_Profile label = " gespeicherte Signalst ä rke : [%.2 fdb ]" icon =" chart " 16: Text item = RSSI_Profile_min label =" min. Signalst ä rke [%.2 fdb ]" icon =" chart " 17: Text item = RSSI_Profile_max label =" max. Signalst ä rke [%.2 fdb ]" icon =" chart " 18: } 19: 45

7 Anhang 20: Frame label =" Bewegung erkennen " { 21: Setpoint item = Threshold_Value label =" Grenzwert f ü r Signalst ä rkenunterschied ( abs ): [%.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 ä rke : [%.2 fdb ]" icon =" chart " 24: Text item = RSSI_Threshold label =" Bewegung erkannt für Signalst ä rke : [%.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 für Visualisierung der Signalstärken 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 3: ( SELECT * FROM openhab. Item3 ORDER BY openhab. Item3. Time ) 4: UNION 5: ( SELECT * FROM openhab. Item1 ORDER BY openhab. Item1. Time ) 6: UNION 7: ( SELECT * FROM openhab. Item2 ORDER BY openhab. Item2. Time ) 8: UNION 9: ( SELECT * FROM openhab. Item5 ORDER BY openhab. Item5. Time ) 10: UNION 11: ( SELECT * FROM openhab. Item6 ORDER BY openhab. Item6. Time ) 12: ORDER BY Time Quelltext 7.6: MySql-Query für Auswertung der Ergebnisse 7.1.5 Realisierung - openhab-rules 1: import org. openhab. core. library. types.* 2: 3: rule " Initialize Items " 4: when 5: System started 47

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

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

7 Anhang 76: then 77: var rssi_profile = ( RSSI_Profile. state as DecimalType ) 78: var rssi_threshold = ( RSSI_Threshold. state as DecimalType ) 79: loginfo (" org. openhab. rules ", " Movement recognized : "+ rssi_threshold +"db measured ") 80: Persist_Log. sendcommand (" Movement recognized : "+ rssi_threshold +"db measured ") 81: Hue_Light_1. sendcommand (" 30,100,70 ") 82: Hue_Light_2. sendcommand (" 30,100,70 ") 83: Thread :: sleep ( 500) 84: Hue_Light_1. sendcommand (" 100,100,70 ") 85: Hue_Light_2. sendcommand (" 100,100,70 ") 86: end 87: 88: rule " Send more packets " 89: when 90: Item Do_MGen received command ON 91: then 92: var packet_value = ( Packet_Value. state as DecimalType ). intvalue 93: executecommandline ("/ bin / bash./ configurations / scripts / remote.sh mgen "+ packet_value ) 94: loginfo (" org. openhab. rules ", " Multi - Generator started with " + packet_value +"/s") 95: Persist_Log. sendcommand (" Multi - Generator started with "+ packet_value +"/s") 96: end 97: 98: rule " Stop sending packets " 99: when 100: Item Do_MGen changed from ON to OFF 101: then 102: executecommandline ("/ bin / bash./ configurations / scripts / remote.sh mgen kill ") 103: loginfo (" org. openhab. rules ", " Multi - Generator stopped ") 104: Persist_Log. sendcommand (" Multi - Generator stopped ") 105: end Quelltext 7.7: openhab-rules für 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:3 d :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:3 d :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 für 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 20: option proto static 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 11 g 5: option path platform / ar934x_wmac 6: option htmode HT20 7: option txpower 30 8: option country US 9: 10: config wifi - device radio1 11: option type mac80211 12: option channel 36 13: option hwmode 11 a 14: option path pci0000 :00/0000:00:00.0 15: option htmode HT20 16: option disabled 1 17: 18: config wifi - iface 19: option device radio0 20: option ssid OpenWrt - adhoc 21: option mode adhoc 22: option network wlan0 23: option encryption wep - shared 24: option key 1 25: option key1 ABCDABCDAB 26: 27: config wifi - iface 28: option device radio0 29: option ssid OpenWrt 30: option mode monitor Quelltext 7.10: Wireless-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 " 2: local io = require " io" 3: local config = require " config " 4: local openhabcmd = require " openhabcmd " 5: 6: local calcrssi = 0 7: local storedrssi = arg [2] 8: local cnt = 0 9: local recognition_item = "/ rest / items /".. arg [1] 10: local threshold_item = "/ rest / items /".. arg [3] 11: local threshold_value = arg [4] 12: local host = string. format (" http ://% s:% s@%s:%d", config.user, config.pw, config.host, config. por 13: 14: while true do 15: local line = io. read () 16: if line == nil then 17: io. write (" error : no input ") break 18: end 19: 20: str = string. match (line," -%d+db") 21: if str == nil then 22: str = "" 23: else 55

7 Anhang 24: str = string. sub (str,1, string. len ( str ) -2) 25: calcrssi = calcrssi + str 26: cnt = cnt + 1 27: end 28: 29: if cnt == 10 then 30: response = calcrssi / cnt 31: openhabcmd. request ( host.. recognition_item, response, string. len ( response )) 32: if math. abs (( math. abs ( storedrssi )-math. abs ( response ))) > tonumber ( threshold_value ) then 33: openhabcmd. request ( host.. threshold_item, response, string. len ( response )) 34: end 35: calcrssi = 0 36: cnt = 0 37: end 38: end Quelltext 7.13: Bewegung anhand der absoluten RSSI-Differenz erkennen 7.2.6 Kommandos für openhab REST-API - Lua Skript 1: local http = require " socket. http " 2: local ltn12 = require " ltn12 " 3: local io = require " io" 4: module (" openhabcmd ", package. seeall ) 5: 6: ----------------------------------------------------------- 7: -- HTTP. Request ( POST ); Parameter : url, value, value - length 8: ----------------------------------------------------------- 9: function request ( URL, VALUE, LENGTH ) 10: local RSP, CODE, TR = http. request { 11: url = URL, 12: method = " POST ", 13: headers = { [ Content - Type ] = " text / plain ", [ Content - Length ] = LENGTH }, 14: redirect = false, 15: source = ltn12. source. string ( VALUE ), 16: sink = ltn12. sink. null () 17: } 56

7 Anhang 18: 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 für 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 4: option proto static 5: option ipaddr 192.168.1.1 6: option netmask 255.255.255.0 7: option ip6assign 60 8: option _orig_ifname eth0.1 wlan0 wlan1 9: option _orig_bridge true 10: option type bridge 11: 12: config interface wan 13: option ifname eth0.2 14: option proto dhcp 15: 16:... 17: 18: config interface wlan0 19: option _orig_ifname wlan0 20: option _orig_bridge false 21: option proto static 22: option netmask 255.255.255.0 23: option ipaddr 10.10.10.45 24:... 58

7 Anhang Quelltext 7.16: Ausschnitt der Netzwerk-Konfiguration 7.3.2 Konfiguration - Wireless 1: config wifi - device radio0 2: option type mac80211 3: option channel 11 4: option hwmode 11 g 5: option path platform / ar934x_wmac 6: option htmode HT20 7: option txpower 30 8: option country US 9: 10: config wifi - device radio1 11: option type mac80211 12: option channel 36 13: option hwmode 11 a 14: option path pci0000 :00/0000:00:00.0 15: option htmode HT20 16: option txpower 17 17: option country US 18: 19: config wifi - iface 20: option device radio0 21: option ssid OpenWrt - adhoc 22: option mode adhoc 23: option network wlan0 24: option encryption wep - shared 25: option key 1 26: option key1 ABCDABCDAB Quelltext 7.17: Wireless-Konfiguration 7.3.3 Multi-Generator Skript 1: START NOW 2: INTERFACE wlan0 3: 0.0 ON 1 UDP DST 1 0.10.1 0.48/3 1337 PERIODIC [10 64] COUNT -1 59

7 Anhang Quelltext 7.18: Multi-Generator Skript für 10 Pakete/s 7.4 openhab-gui für realisierte Sitemap Abbildung 7.1: Main-Menü der Benutzeroberfläche [Uh15u] 60

7 Anhang Abbildung 7.2: Sub-Menü der Benutzeroberfläche - Steuerung der Leuchten [Uh15u] 7.5 Ergebnisse und Messwertvisualisierung Abbildung 7.3: Visualisierung für Messdurchlauf #1 Abbildung 7.4: Visualisierung für Messdurchlauf #2 61

7 Anhang Abbildung 7.5: Visualisierung für Messdurchlauf #3 Abbildung 7.6: Visualisierung für Messdurchlauf #4 Abbildung 7.7: Visualisierung für Messdurchlauf #5 62

7 Anhang Abbildung 7.8: Visualisierung für Messdurchlauf #6 Abbildung 7.9: Visualisierung für Messdurchlauf #7 Abbildung 7.10: Visualisierung für Messdurchlauf #8 63

7 Anhang Abbildung 7.11: Visualisierung für Messdurchlauf #9 Abbildung 7.12: Visualisierung für Messdurchlauf #10 Abbildung 7.13: Visualisierung für Messdurchlauf #11 64

7 Anhang Abbildung 7.14: Anmerkungen zu den einzelnen Messdurchläufen 65