Heimautomatisierung mit iBeacons

Abstract

Die Grundidee der Arbeit ist eine automatisierte Steuerung der Wohnungsbeleuchtung aufgrund der Position des Bewohners innerhalb der Wohnräume. iBeacon ist eine auf Bluetooth basierende und von Apple entwickelte Technologie zur Lokalisierung innerhalb von Gebäuden. Die offizielle Dokumentation von iBeacon ist nur zertifizierten Partnern zugänglich. Der technische Aufbau von iBeacon wurde während des Projekts analysiert und auf seine mögliche Verwendung in der Heimautomatisierung hin überprüft. In einer Anforderungs­analyse wurden die benötigen Funktionen für eine automatisierte Steuerung der Wohnungsbeleuchtung mit iBeacons dokumentiert. Zur Überprüfung der Alltagstauglichkeit wurde eine den Anforderungen entsprechende Softwarelösung umgesetzt und mit Estimote Beacons getestet. Die optimale Sendestärke der Beacons wurde durch eine Rastermessung der Signalstärke in der Wohnung ermittelt. Die Softwarelösung besteht aus einer iPhone-App sowie einer Web-Applikation und steuert spezifische LED-Lampen vom Produkt Philips hue.

Inhaltsverzeichnis

Einleitung

Ausgangslage

Heimautomatisierung (engl. Home Automation) bezeichnet die intelligente Verknüpfung von Sensoren und anderen technischen Geräten innerhalb der eigenen Wohnräume zur Steigerung des Wohnkomforts. Effizientere Technik und verbraucherorientierte Produkte haben dies in den letzten Jahren auch für normale Konsumenten realisierbar gemacht.

Apple hat in der neusten Version seines mobilen Betriebssystems, iOS 7, eine neue Möglichkeit zur Lokalisierung des Benutzers in geschlossenen Räumen hinzugefügt. Die Technik basiert auf Bluetooth Low Energy, trägt den Namen iBeacon und kann verwendet werden, um das Betreten oder Verlassen eines Raums zu registrieren. Eine Dokumentation des Protokolls wurde von Apple angekündigt, war jedoch zu Beginn des Projekts noch nicht veröffentlicht. Am Ende des Projekts existierte zwar eine Dokumentation zum iBeacon-Format, diese war aber nur zertifizierten Herstellern zugänglich.

Die Verwendung von bestehenden Geräten, wie Smartphones, ist für die Heim­automatisierung interessant, da diese vielfältige Möglichkeiten bieten und nicht separat angeschafft werden müssen. Eine optimale Ergänzung dazu stellt die Philips hue dar. Es handelt sich dabei um eine LED-Lampe in Form einer Glühbirne, welche über eine REST-API verfügt und so gezielt gesteuert werden kann. Zu dieser LED-Lampe existiert auch eine offizielle iPhone-App, welche eine Steuerung der Beleuchtung über die Positions­bestimmung mittels GPS anbietet. Die Anwendung im Alltag zeigte jedoch, dass diese Umsetzung schlecht funktioniert, da die Ortung per GPS besonders in Gebäuden nicht zuverlässig ist (Lichter gehen aus und an während sich die Person am gleichen Ort aufhält).

Schlechte Erfahrungen wurden auch mit anderen Lokalisierungsgeräten gemacht. Chipolo ist ein Bluetooth-Schlüsselanhänger, der einen Alarm auslöst, sobald man sich von seinem iPhone entfernt. Bei dessen Benutzung wurde jedoch beobachtet, dass dies nur unzuverlässig funktioniert. Ohne eine detaillierte Analyse oder Kenntnisse über die genaue Funktionsweise, ist es aber schwierig zu beurteilen, wo die Ursache des Problems liegt. Es führte jedoch zur Vermutung, dass die Ortung mit iBeacons zu ungenau für die Steuerung der Beleuchtung von Räumen ist.

Ziele der Arbeit

Im Rahmen dieser Semesterarbeit soll analysiert werden, wie die neuen Funktionen von iOS 7 optimal verwendet werden können, um eine einfache Heimautomatisierung zusammen mit der Philips hue zu ermöglichen. Es soll eine zentrale Web-Applikation entwickelt werden, welche die Bewegungen eines Benutzers innerhalb der eigenen Wohnräume speichert und die Beleuchtung der Räume entsprechend steuert. Der Standort des Benutzers wird dabei von einer iPhone-App ermittelt und an die Web-Applikation gemeldet.

Aufgabenstellung

Im Rahmen dieser Semesterarbeit werden vom Studenten folgende Aufgaben ausgeführt:

1. Analyse der Funktionalitäten von iBeacon.
2. Untersuchung des auf Bluetooth Low Energy basierenden Protokolls von iBeacon.
3. Anforderungsdokumentation für die Automatisierung der Beleuchtung einer Wohnung.
4. Konzeption und Design des Software-Prototyps zur Umsetzung der dokumentierten Anforderungen.
5. Implementation eines Prototyps bestehend aus einer iPhone-App zur Lokalisierung des Benutzers und einer Web-Applikation zur Überwachung und Steuerung der Beleuchtung.
6. Verifikation des Software-Prototyps in einem Feldversuch und Analyse der Ergebnisse.
7. Demonstration des Software-Prototyps.

Projektablauf

Das folgende Gantt-Diagramm gibt einen Überblick über den effektiven Ablauf des Projekts und die wichtigsten Meilensteine.

Laut dem Reglement für Semesterarbeiten sollte der Aufwand 120 Stunden betragen. Entsprechend wurde die Planung darauf ausgelegt. Die genauen technischen Anforderungen wurden allerdings erst während dem Projekt klar und führten zu einer iterativen Softwareentwicklung, wodurch mehr Zeit für die Konzeptions- und Umsetzungsphasen gebraucht wurde.

Analyse iBeacon

Beschreibung

Bei iBeacon handelt es sich um eine von Apple eingetragene Marke. Sie beschreibt eine proprietäre Technologie für die Lokalisierung eines iPhones mithilfe von Bluetooth Low Energy (BLE). iBeacon setzt das Betriebssystem iOS 7 oder neuer, sowie ein iPhone mit Bluetooth 4.0 voraus. Das Wort Beacon wird zur Beschreibung eines Geräts mit eigener Stromversorgung verwendet, welches einen Standort markiert.

Kommt ein iPhone in die Nähe eines Beacons, wird eine auf dem iPhone laufende App vom Betriebssystem benachrichtigt. Die App kann dann zusätzlich die Distanz zum Beacon abfragen und eigene Aktionen ausführen. Vgl. iOS: Understanding iBeacon.

Bluetooth Low Energy

Bluetooth Low Energy (BLE) ist ein Funkprotokoll und Teil der Bluetooth 4.0-Spezifikation. Vermarktet wird BLE auch als Bluetooth Smart. Es wurde speziell für kleine Geräte mit limitierten Akkukapazitäten entwickelt und kommt deshalb oft auf Smartphones zum Einsatz. Vgl. Bluetooth SIG, Inc. (2013).

BLE-Geräte nutzen das Generic Attribute Profile (GATT), um die zur Verfügung gestellte Funktionalität zu beschreiben. GATT sieht Services und Characteristics vor, welche ein Gerät im Rahmen einen Bluetooth-Profils anbieten kann. Dabei besteht eine hierarchische Beziehung zwischen Services und Characteristics. Services können zudem auf andere Services referenzieren (Include), um deren Characteristics zu erben. Profile dienen bei GATT zur formellen Gruppierung von mehreren Services.

Core Bluetooth

Apple bietet mit Core Bluetooth eine vereinfachte Schnittstelle zur Verwendung von BLE an. Diese Bibliothek ist im Betriebssystem iOS integriert und abstrahiert die BLE-Protokolle.

Dabei wird bei der Programmierung zwischen zwei Rollen, welche nach dem Client-Server-Prinzip aufgebaut sind, unterschieden: Central und Peripheral. Ein Peripheral (Server) stellt dabei Daten zur Verfügung und kann sich selbst über das regelmässige Aussenden von Informationen auffindbar machen (Advertising). Ein Central (Client) hingegen sucht nach Peripherals, und verarbeitet dessen Informationen in weiteren Aktionen. Zum Beispiel kann ein digitaler Pulsmesser (Peripheral) mit BLE die aktuelle Herzfrequenz an eine iOS-App (Central) übermitteln und die iOS-App zeigt dann die Herzfrequenz dem Benutzer an.

Analyse Aufbau

Um die technischen Limitierungen und allfällige Signalprobleme zu verstehen, ist es für das Projekt von Vorteil, das Protokoll von iBeacon genau zu verstehen. Zudem besteht der Hintergedanke evtl. eine eigene Implementierung eines iBeacon mit bestehenden Komponenten wie einem GNU/Linux-Computer zu programmieren.

Es wurde mit der Einarbeitung in die Grundtechnologie von iBeacon begonnen, um der Funktionsweise von iBeacon auf die Spur zu kommen. Mit dem indirekten Ziel, einen Computer als iBeacon zu nutzen, wurde mit der Analyse auf einem Mac begonnen. Dazu wurde die bereits beschriebene Bibliothek Core Bluetooth verwendet, welche seit Version 10.9 von Mac OS X nicht nur auf iOS sondern auch in OS X zur Verfügung steht. Damit sollte ein einfaches BLE-Profil veröffentlicht werden.

Anhand des Kapitels «Performing Common Peripheral Role Tasks» (Seite 16) aus der von Apple zur Verfügung gestellten Dokumentation Core Bluetooth Programming Guide wurde ein minimales Programm mithilfe der Programmierumgebung Xcode erstellt, welches eigene BLE-Dienste anbietet.

// create manager
CBPeripheralManager *manager = [[CBPeripheralManager alloc] initWithDelegate:self queue:nil options:nil];

// initialize UUIDs
CBUUID *characteristicUUID = [CBUUID UUIDWithString: @"2A38"];
CBUUID *serviceUUID = [CBUUID UUIDWithString: @"180D"];

// create value object
int heartRate = 42;
NSData *value = [NSData dataWithBytes: &heartRate length: sizeof(heartRate)];

// create service with characteristic
CBMutableCharacteristic *characteristic = [[CBMutableCharacteristic alloc] initWithType:characteristicUUID properties:CBCharacteristicPropertyRead value:value permissions:CBAttributePermissionsReadable];
CBMutableService *service = [[CBMutableService alloc] initWithType:serviceUUID primary:YES];
service.characteristics = @[characteristic];

// add service and advertise
[manager addService:service];
[manager startAdvertising:@{ CBAdvertisementDataServiceUUIDsKey : @[serviceUUID] }];

Konkret wurde mit der Beispiel-Anwendung ein Bluetooth-Profil mit einem Service für Herzfrequenzen mit der UUID 180D und einer Charakteristik für die Position des Sensors am Körper mit der UUID 2A38 umgesetzt.

Die iPhone-App LightBlue bietet die Möglichkeit, eine Verbindung zu beliebigen BLE-Geräte aufzubauen und die von den Geräten angebotenen Dienste abzurufen. Die App zeigt zudem die vom Gerät versendeten Advertising-Daten an. Die App wurde erfolgreich dazu verwendet, die von der Mac-Anwendung publizierten Services und Characteristics zu bestätigen.

Wie im Kapitel «Turn Your iOS Device Into a Beacon» der Dokumentation zu iBeacon beschrieben, wurde dann eine einfach iPhone-App erstellt, welche die Signale eines iBeacons vom iPhone aussendet. Dazu benötigt werden die beiden Bibliotheken CoreBluetooth.framework und CoreLocation.framwork.

Jedes Beacon braucht eine UUID, sowie einen Major- und einen Minor-Wert, anhand welcher das Beacon eindeutig identifiziert wird. Um die Analyse des Protokols zu vereinfachen und die ID einfach auffindbar zu machen, wurde die UUID FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF definiert. Als Major wurde der Wert 00 (0) verwendet und als Minor der Wert FF (65535).

NSUUID *proximityUUID = [[NSUUID alloc] initWithUUIDString:@"FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF"];

// Create the beacon region.
CLBeaconRegion *beaconRegion = [[CLBeaconRegion alloc] initWithProximityUUID:proximityUUID major:0 minor:65535 identifier:@"ch.zhaw.voglefab.debug"];

// Create a dictionary of advertisement data.
NSDictionary *beaconPeripheralData = [beaconRegion peripheralDataWithMeasuredPower:nil];

// Start advertising your beacon's data.
[self.peripheralManager startAdvertising:beaconPeripheralData];

Diese App wurde auf einem zweiten iPhone installiert und gestartet. Verbindet man sich jedoch nun mit LightBlue auf dem ersten iPhone mit dem zweiten iPhone, werden in LightBlue nur die Services Battery Service und Current Time Service angezeigt - iBeacon ist also kein Service im GATT-Protokoll. Auch bei den Advertisement-Informationen ist das iBeacon in LightBlue nicht sichtbar. Trotz der neuen Erkenntnisse stellt sich dieser Lösungsansatz somit aber als Sackgasse heraus.

In einem weitern Schritt wurde auch nach Analyse-Tools auf dem Mac gesucht. Schliesslich wurde das Software-Packet Hardware IO Tools for Xcode gefunden, welches von Apple für Entwickler gratis zum Download bereitgestellt wird. Dieses enthält unter anderem die Tools PacketLogger und Bluetooth Explorer, welche für die weitere Analyse von iBeacon verwendet wurden.

Das neue Ziel war nun, die Signale eines iBeacons auf dem Mac zu analysieren. Die Software PacketLogger bietet dazu eine Möglichkeit, die vom Computer empfangenen BLE-Packete zu analysieren. Führt man im Bluetooth Explorer einen Scan nach BLE-Geräten durch, werden im PacketLogger die empfangenen BLE Advertisements angezeigt.

Dadurch wurde schlussendlich das Advertisement mit den iBeacon-Daten gefunden. Erkannt wurde das Advertisement anhand der UUID FF FF FF FF…. Verwendet wird hier die hexadezimale Schreibweise von Octet, zwei Hexzahlen entsprechen also einem Byte resp. 8 Bits.

02 01 1A 1A FF 4C 00 02 15 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 00 00 FF FF C5

Der Aufbau des BLE-Advertisements wird auf Kapitel «11 Advertising and Scan Response data format» im Volume 3 der Bluetooth-Spezifikation erklärt. Ein Advertisement besteht aus mehreren Elementen, welche eine variable Länge haben. Am Anfang jedes Elements steht seine eigene Länge gefolgt vom Typ des Elements.

Angewendet auf das empfangene Advertisement ergibt sich folgendes Format für ein iBeacon. Gemäss Spezifikation enthalten die ersten zwei Octets der Manufacturer Specific Data den Company Identifier Code, welcher auf der Website der Bluetooth SIG dokumentiert ist.

Das iBeacon-Format ist also innerhalb der Manufacturer Specific Data im BLE-Protokoll gekapselt. Dies konnte auch mit dem Bluetooth Explorer verifiziert werden, der ebenfalls die Manufacturer Data anzeigt. Um ein iBeacon zu erkennen oder zu simulieren, braucht man also lediglich ein Advertisement mit den entsprechenden Manufacturer Specific Data zu senden/empfangen.

Für das Projekt ist positiv, dass iBeacon als zustandsloses Protokoll aufgebaut ist. Es reduziert die Gefahr von Verbindungsabbrüchen und minimiert den Batterieverbrauch, da keine synchrone Kommunikation notwendig ist. Dadurch kann auch die Überwachung auf Beacons im Hintergrund öfters durchgeführt werden.

Anforderungsanalyse

Einleitung

Das manuelle Bedienen von Lichtern in einer Wohnung ist oft mühsam und ineffizient. Die Lichtschalter sind an ungünstigen Orten angebracht oder das Licht wird beim Verlassen der Wohnung vergessen auszuschalten.

Es soll deshalb eine Softwarelösung entwickelt werden, welche die Lichter in einem Haus automatisiert steuert. Betritt der Bewohner einen Raum, sollen die Lichter im Raum angehen - beim Verlassen des Raums sollen die Lichter wieder automatisch ausgehen. Dies spart Strom und erleichtert den Alltag.

Für die Steuerung soll ein Beacon mehreren Lichtern und ein Licht mehreren Beacons zugewiesen werden können. Die Lichter sollen leuchten, solange sich der Benutzer in der Nähe des Beacon befindet. Eine Wohnung kann sich, wie im folgenden Schema beispielhaft dargestellt, aus mehreren sich überschneidenden Lichtern und Beacons zusammensetzen.

Stakeholder

Die folgenden Stakeholder wurden mit der Beobachtungstechnik sowie aus der Dokumentation der eingesetzten Komponenten ermittelt. Sie haben einen direkten oder indirekten Einfluss auf die Anforderungen. Diese Stakeholder finden sich ebenfalls im nachfolgenden Kontextdiagramm.

Systemkontext

Die Kontextabgrenzung dient zur Definition der Elemente und Stakeholder, welche einen Einfluss auf das System haben. Das System selbst, die automatisierte Steuerung, wird durch den Bewohner und die Beacons beeinflusst und steuert das Licht. Besucher kommen innerhalb der Systemgrenze ebenfalls vor, haben aber keinen direkten Einfluss auf das System. Hersteller der Komponenten liegen ausserhalb der Systemgrenze und haben keinen direkten Einfluss auf die Anforderungen. Die Funktionen ihrer Produkte haben jedoch einen Einfluss auf die technischen Möglichkeiten.

Funktionale Anforderungen

Die funktionalen Anforderungen wurden mit der Beobachtungstechnik und anhand der eigenen Erfahrungen definiert und als Anwendungsfälle festgehalten.

Das folgende Anwendungsfalldiagramm gibt einen Überblick über die erfassten Anwendungsfälle. Es gibt zwei Aktoren, den Benutzer sowie die automatisierte Steuerung.

Die Anwendungsfälle wurden mit den Attributen erfasst, welche im folgenden Schema definiert sind. Die Anwendungsfälle sollen in absteigender Priorität umgesetzt werden. Anwendungsfälle mit tiefer und mittlerer Priorität werden nicht zwingend benötigt oder können Anfangs noch manuell direkt in der Datenbank vorgenommen werden.

Anwendungsfälle

Nichtfunktionale Anforderungen

Neben den funktionalen Anforderungen gibt es auch gewisse nichtfunktionale Anforderungen, die teilweise implizit vom Benutzer erwartet werden. Diese Qualitäts­anforderungen müssen sowohl messbar wie auch für das Projekt relevant sein. Die nichtfunktionale Anforderungen wurden ebenfalls durch die Beobachtungstechnik aus vorherigen Projekten ermittelt.

Benutzerschnittstellen

Die folgenden Mockups dienen dazu, die Anforderungen visuell darzustellen und somit einfacher verständlich zu machen. Es werden die drei wichtigsten Ansichten der Anwendung gezeigt.

Das Dashboard wird beim Starten der Anwendung, jedes Mal wenn sich der Benutzer eingeloggt hat, angezeigt. Im Dashboard erhält der Benutzer eine Übersicht über die letzten Aktionen der automatisierten Steuerung. Er kann zudem die automatisierte Steuerung pausieren und wieder starten.

Der Report zeigt dem Benutzer Informationen über die Brenndauer der Lichter während der letzten Tage an.

Im Setup kann der Benutzer die Beacons den Lichtern zuweisen.

Konzept und Design

Randbedingungen

Um eine möglichst hohe Portabilität zu gewährleisten und die Anwendung auf einem einfachen Webserver betreiben zu können, soll die Anwendung mit PHP und MySQL entwickelt werden.

Da iBeacon ein von Apple entwickeltes Datenformat ist, bietet die iOS-Plattform Bibliotheken zur einfachen Umsetzung. Es soll deshalb eine iPhone-App mit Objective-C entwickelt werden.

Lösungsstrategie

Die zu entwickelnde Software wird mit dem Namen «Homebase» bezeichnet und besteht aus zwei Komponenten: einer iPhone-App sowie einer Web-Applikation. Die Aufgabe der iPhone-App ist lediglich, die Position des Benutzers zu ermitteln und diese an die Web-Applikation zu übertragen. Die Web-Applikation hat eine Anbindung an eine Datenbank und speichert dort alle Positionsangaben, steuert die Beleuchtung und stellt die gesammelten Informationen für den Benutzer dar.

Bausteinsicht

Das folgende Komponentendiagramm zeigt die Softwarekomponenten, aus denen die Anwendung besteht. Die iPhone-App kommuniziert über eine Schnittstelle mit der API. Zwei weitere Komponenten innerhalb der Web-Applikation sind für die automatisierte Steuerung (Engine) sowie den Aufruf der API der Lichter zuständig (hue API). Die Komponente zur Konfiguration stellt Informationen über die vom Benutzer vorgenommenen Einstellungen bereit.

iPhone-App

Die iPhone-App besteht nur aus einer Klasse, welche durch das Betriebssystem über das Delegate-Pattern aufgerufen wird, sobald der Benutzer den Bereich eines Beacons betritt oder verlässt. Diese Klasse sendet dann die Informationen über eine HTTP-Anfrage an den Server.

Die Authentifizierung in der iPhone-App wurde mit dem Standard OAuth 2.0 umgesetzt, da damit keine Benutzerinformationen auf dem iPhone gespeichert werden müssen. Dazu leitet die iPhone-App den Benutzer an die Web-Applikation weiter, diese generiert einen Zugriffscode und sendet diesen an die iPhone-App. Die iPhone-App kann dann diesen Zugriffscode als Authentifizierung für geschützte Aufrufe der API verwenden.

Web-Applikation

Die Web-Applikation wurde nach dem klassischen MVC-Pattern in PHP umgesetzt: Anfragen werden im Controller entgegengenommen, die Daten an das Model weitergeleitet und schlussendlich in der View dargestellt.

Da PHP nur wenig Funktionalität zur komplexeren Verarbeitung von HTTP-Anfragen bietet, wurde das Micro-Framework Silex verwendet. Dieses stellt Funktionen für das Routing zur Verfügung und erlaubt die einfache Benutzung der Templating-Engine Twig. Sowohl Silex wie auch Twig sind weit verbreitet, gut getestet und wurden bereits in mehreren Projekten erfolgreich eingesetzt.

Ein zentrales Element der Web-Applikation ist die Engine, welche die aktuellen Positionsdaten analysiert und entscheidet, welche Lichter an- und welche ausgeschaltet werden sollen.

Das nachfolgende Klassendiagramm beschreibt die Klassen im Packet Homebase\Service, welche das Model und damit die eigentliche Funktionalität enthalten.

Laufzeitsicht

Dynamisch sind in der Software hauptsächlich die Web-Oberfläche und die Engine. Die Web-Oberfläche zur Konfiguration der Anwendung ist einfach zu verstehen, da sie nach den gängigen Prinzipien einer Web-Applikation funktioniert und im Browser beobachtet werden kann. Die automatisierte Steuerung der Lampen durch die Engine jedoch geschieht im Hintergrund ohne sichtbare Ausgaben. Die Funktionsweise der Engine wird deshalb in diesem Kapitel beschrieben.

Die Engine bezieht ihre Informationen aus der Datenbank. Das folgende Sequenzdiagramm zeigt, wie die Informationen über die Position des Benutzers in die Datenbank gelangen. Nähert oder entfernt sich der Benutzer von einem Beacon, ruft das Betriebssystem die Funktion didDeterminateState der iPhone-App auf. Die iPhone-App sendet dann diese Informationen über einen HTTP-Request an die API der Web-Applikation, welche wiederum die Informationen in der Datenbank speichert.

Die Engine wird einmal pro Sekunde durch einen Cronjob aufgerufen und ermittelt die Lichter, welche ein- oder ausgeschaltet werden müssen. Dazu holt die Engine die in der Datenbank gespeicherten Informationen über die Position des Benutzers (state), berechnet die nötigen Befehle zum Ein- oder Ausschalten der Lichter und schreibt diese wieder in die Datenbank (action).

Ein Teilelement der Engine namens Delayed wird ebenfalls einmal pro Sekunde aufgerufen und ist für die effektive Ausführung der Befehle zuständig. Die Befehle werden aus der Datenbank gelesen und als HTTP-Request an die hue API gesendet. Diese Auftrennung der Berechnung und der Ausführung wurde so umgesetzt, um eine Verzögerung der Engine durch lang andauernde HTTP-Requests zur hue API zu verhindern.

Verteilungssicht

Die Web-Applikation wird zusammen mit dem Datenbank-Schema auf den gleichen Server deployed. Das Deployment ist über einen Continuous-Integration-Server automatisiert. Diese Automatisierung reduziert den Aufwand und verhindert menschliche Fehler, welche beim manuellen Deployment auftreten könnten. Zudem werden vor jedem Deployment die Tests der Anwendung ausgeführt und das Deployment nur durchgeführt, falls alle Tests erfolgreich waren. Bei einem Fehler wird der Benutzer per Email benachrichtigt.

Die iPhone-App wird manuell mit einem USB-Kabel auf dem iPhone installiert, da ein vollständig automatisiertes Deployment auf iOS nicht ohne grossen Aufwand möglich ist.

Datenmodell

Sämtliche Informationen der Anwendung werden in einer MySQL-Datenbank gespeichert. In der folgenden Tabelle finden sich zu jeder Tabelle eine kurze Beschreibung des Inhalts resp. des Zwecks der Tabelle.

Das nachfolgende relationale Datenmodell zeigt die Entitäten sowie deren Beziehungen. Beacons können mehrere gemessene Abstände sowie Positionen haben und zu keinen oder mehreren Lampen zugewiesen sein.

Benutzeroberfläche

Die Benutzeroberfläche der Web-Applikation wurde mit Bootstrap umgesetzt. Diese Bibliothek ermöglicht unter anderem, dass die Web-Applikation auch auf mobilen Geräten einfach zu bedienen ist.

Für die Darstellung von Diagrammen wurde D3.js, eine Bibliothek zur Erstellung von Datenvisualisierungen, verwendet. D3.js wurde aufgrund der Flexibilität und der guten Erfahrung damit gewählt.

Implementation

Estimote Beacon

Für die Umsetzung des Projektes wurden Beacons von Estimote eingesetzt. Die Estimote Beacons wurden hauptsächlich für den Einsatz in Läden entwickelt und enthalten einen Bluetooth-Sender, der das iBeacon-Signal sendet. Da iBeacon eine neue Technologie ist, existierten zu Beginn des Projektes nur wenige Anbieter, welche Hardware für iBeacon anboten. Die Estimote Beacons wurden deshalb aufgrund ihrer Verfügbarkeit gewählt.

Estimote verfügt über eine eigene iPhone-App, mit welcher sich die Signalstärke und der Sendeintervall der Beacons konfigurieren lässt. Die Beacons werden eigentlich wasserfest produziert. Leider waren die Batterien nach 5 Monaten aber bereits leer. Per Email erhielt ich dann vom Estimote-Support eine Anleitung zum Austausch der Batterien. Für den Austausch muss das Beacon mit einem Messer aufgeschnitten werden - die Wasserfestigkeit geht dadurch natürlich verloren.

Der Austausch der Batterie war dennoch interessant, da ich dadurch einen Blick in den Inhalt der Beacons erhalten konnte. Die Beacons bestehen aus einer Leiterplatte mit Schaltkreisen. Die Batterie selbst ist eine Knopfbatterie vom Typ CR2450 und kann im Detailhandel gekauft werden.

Das Gehäuse ist aus einem elastischen Kunststoff gefertigt und ca. 7 mm dick. Aufgrund der Elastizität bietet das Gehäuse jedoch keinen grossen Schutz der technischen Elemente vor äusserer Druckeinwirkung. So hat sich beim Andrücken eines Beacons die Halterung der Batterie derart verbogen, dass diese den Kontakt zur Batterie verloren und manuell wieder zurecht gebogen werden musste.

Auf der Unterseite befindet sich eine selbsthaftende Oberfläche zur Montage an einem beliebigen Ort. Aufgrund der starken Abschirmung der Signale durch Wasser (Menschen bestehend hauptsächlich aus Wasser), ist eine Platzierung an der Decke optimal. Je nach Struktur der Decke ist die selbsthaftende Oberfläche jedoch nicht stark genug. Auch das Demontieren und erneute Anbringen (zum Auswechseln der Batterie) scheint einen negativen Einfluss auf die Haftfestigkeit zu haben. Bei zwei Beacons musste die selbsthaftende Oberfläche durch doppelseitige Klebstreifen unterstützt werden.

Messung RSSI

Da sich die Signalstärke in den Estimote Beacons konfigurieren lässt, stellt sich die Frage, wie die optimale Konfiguration innerhalb einer Wohnung aussieht. Für folgende Wohnung wurden mehrere Messungen durchgeführt, um für jedes Beacon eine Signalstärke zu finden, die den Anforderungen entspricht.

Die empfangene Signalstärke kann in iOS über den RSSI-Wert (Received Signal Strength Indicator) ausgelesen werden. Je grösser der Wert ist, umso besser ist der Empfang, resp. umso näher befindet sich der Empfänger am Sender.

In einem ersten Schritt wurden die Bauzeichnungen der Wohnung eingescannt und mit der Gratis-Software Sweet Home 3D digitalisiert. Die Wohnung besteht aus zwei Stockwerken, welche mit einer Treppe verbunden sind. Auf dem ersten Stock befindet sich der Wohn- und Bürobereich.

Im zweiten Stock finden sich zwei Schlaf- sowie ein Badezimmer. Das Badezimmer befindet sich in der Visualisierung auf der rechten Seite.

In einem nächsten Schritt wurde die Wohnung in Raster unterteilt. Jedes Quadrat hat im Raster eine Seitenlänge von 120 cm. Diese Länge wurde aufgrund der Gangbreite von 120 cm gewählt, da der Gang normalerweise in der Mitte durchschritten wird und eine mehrfache Messung dort nur wenig Sinn machen würde. Das Raster wurde mit Malerklebband auf die Wohnung übertragen, um die Durchführung der Messung effizient zu gestalten.

Für die Messung wurde eine iPhone-App entwickelt, auf welcher sich die Signalstärke sowie die Koordinaten des iPhones innerhalb der Wohnung konfigurieren lassen. Die App empfängt alle iBeacon-Signale und deren RSSI-Wert. Aktiviert man dann die Messung, wartet die App 10 Sekunden und überträgt dann die empfangenen RSSI-Werte an einen Web-Server zur Auswertung.

Gemessen wurde auf einer Höhe von 90 cm. Auf dieser Höhe befindet sich das iPhone normalerweise auch, wenn es in der Hosentasche getragen wird. Für die Messung wurde das iPhone auf einem Stativ montiert, damit die Messung ohne Störungsquellen durchgeführt werden kann.

Für die Messung wurde das Advertisting Interval aller Estimote Beacons auf 500 ms eingestellt, um pro Sekunde zwei klar getrennte Signale zu erhalten. Dieser Intervall verlängert auch die Batteriedauer im Vergleich zur Standardeinstellung von 200 ms. Das iPhone hatte zu Beginn einer Messung jeweils 100% Akku. Der Batteriestand fiel während der Messung nie unter 60%. Auch die Estimote Beacons hatten frische Batterien.

Während eines ersten Probelaufs mit 10 Sekunden warten und 30 Sekunden messen zeigte sich, dass die 10 Sekunden Wartezeit genügten, um sich ausserhalb des Messbereichs zu begeben. Die Messdauer von 30 Sekunden erwies sich allerdings als zu lange, da die Standardabweichung der gemessenen Daten sehr klein war. Anhand der aufgezeichneten Daten wurde deshalb die Messdauer auf 20 Sekunden reduziert.

Aufgrund der Grösse der Wohnung und der in der Estimote ausgewiesenen Distanzen wurden die drei Signalstärken -20 dBm (3.5 m), -12 dBm (15 m) und -4 dBm (40 m) für die Messung definiert.

Ablauf einer Messung:

1. Zu messende Signalstärke definieren
2. Alle Beacons auf die definierte Signalstärke einstellen
3. App auf iPhone starten
4. Signalstärke in App eintragen
5. iPhone auf Stativ montieren
6. Stativ in der Mitte eines Felds platzieren
7. Koordinaten von Plan ablesen und in App eintragen
8. Schalter "Messung" in App auf aktiv stellen
9. Sich innerhalb von 10 Sekunden aus dem Messbereich entfernen
10. 20 Sekunden warten
11. Zurück zu Schritt 6 bis alle Felder/Koordinaten gemessen wurden

Messprotokolle

Die folgenden Messprotokolle geben Auskunft über die Durchführung der Messungen.

Visualisierungen

Bei den nachfolgenden Auswertungen wird die Position des gemessenen Beacons im Wohnungsplan jeweils durch ein schwarzes Hexagon gekennzeichnet. Die Visualisierung zeigt jeweils den Median-Wert der während der 20 Sekunden gemessenen Werte.

Das erste Beacon befindet sich im Wohnzimmer der Wohnung.

Das zweite Beacon befindet sich in einem Schlafzimmer im zweiten Stock.

Das dritte Beacon befindet sich direkt im Eingangsbereich der Wohnung.

Auswertung Messung

Die Visualisierungen der Messergebnisse ergeben ein einigermassen stimmiges Bild: In der Nähe der Beacons ist das gemessene Signal stärker und höhere Signalstärken resultieren in einer grösseren Abdeckung. Auffällig ist jedoch, dass direkt unter dem Beacon der Empfang teilweise schlechter ist als im nahen Umfeld. Eventuell hat dies mit der Ausrichtung der Antenne der Beacons zu tun. Klar sichtbar ist auch, dass sich die Signale besser durch Luft als durch die Wände und Decken verbreiten.

Eine Ungenauigkeit, welche eventuell Einfluss auf die Ergebnisse hatte wurde erst im Nachhinein erkannt: Die horizontale Ausrichtung des iPhones wurde nicht definiert und war bei der Messung nicht immer gleich. Die Frage, ob die Ausrichtung der Antenne beim iPhone eine Relevanz hat, wurde nicht untersucht.

Das Ziel, eine Entscheidungshilfe zur Wahl der Signalstärke der Beacons für den Alltag zu erhalten, wurde erreicht. Für das Beacon 1 wird die Signalstärke -12 dBm aufgrund der guten Abdeckung des ganzen ersten Stocks festgelegt. Um zu verhindern, dass das Licht im Schlafzimmer unnötig brennt, wird die Signalstärke des Beacon 2 auf -4 dBm festgelegt. Für das Beacon 3 wird die Signalstärke -12 dBm festgelegt, da damit die Beleuchtung im Gang gesteuert werden soll.

Software

Die folgenden Screenshots zeigen die während des Projekts umgesetzte Web-Applikation, welche auf einem gemieteten Web-Server installiert wurde. Es konnten alle in der Anforderungsdokumentation definierten Funktionen umgesetzt werden.

Das Dashboard hat neben den Events und der Schaltfläche zum pausieren der Engine auch einige Zusatzinformationen wie die Anzahl an (aktiven) Beacons, die Anzahl an (leuchtenden) Lampen sowie ein Diagramm zur Nutzung der Lichter während der letzten 3 Wochen (dargestellt als Streamgraph).

Der Report zeigt die Nutzung der Lichter während der letzten 3 Tage in einem Ringdiagramm. Das Diagramm zeigt, zu welchen Uhrzeiten wie viele Lichter aktiv waren.

Auf der Seite für das Setup werden die Beacons und deren Zuweisung zu den Lichtern angezeigt und können bearbeitet werden.

Bearbeitet der Benutzer ein Beacon, kann er dessen Namen sowie seine Identifikationsmerkmale ändern.

Auf einer nicht verlinkten Seite werden die Messresultate dargestellt. Über eine Dropdown-Liste kann das Beacon sowie die Signalstärke, welche angezeigt werden sollen, ausgewählt werden.

Testing

Zur Überprüfung des Programm-Codes auf Fehler werden automatisierte Unit-Tests eingesetzt. Um die Anforderungen an die umgesetzte Software zu verifizieren, werden die folgenden Akzeptanztests verwendet.

Feldversuch

Die entwickelte Anwendung war rund 3 Monate im Einsatz. Dabei wurden unterschiedliche Probleme festgestellt und teilweise direkt in der Software gelöst. Insgesamt wurden über 20’000 Positionsänderungen und über 300’000 Abstandsmessungen gespeichert.

Hält sich der Benutzer für längere Zeit am gleichen Ort auf, kann es vorkommen, dass iOS meldet, der Benutzer habe sich von einem Beacon entfernt - nur wenige Sekunden später kommt dann aber wieder die Meldung, dass sich der Benutzer wie in der Nähe des Beacons befindet. Eine Erklärung für dieses Verhalten konnte nicht gefunden werden. Durch das Warten von 3 Minuten vor dem Ausschalten der Lichter konnte dieses Problem aber gelöst werden.

Am Anfang wurde die Engine bei jeder Positionsmeldung aufgerufen. Dies führte jedoch zu sich überschneidenden Aufrufen an die hue API. Zudem konnte damit die Verzögerung von 3 Minuten zum Ausschalten der Lichter nicht umgesetzt werden. Die Engine wurde deshalb umgeschrieben und neu durch den Crob-Job aufgerufen. Cron-Jobs haben aber eine minimale Wartezeit von einer Minute, weshalb die Engine anfangs nur einmal in der Minute lief. Es zeigte sich jedoch, dass diese Reaktionszeit im Alltag zu langsam ist. Gelöst wurde das Problem damit, dass die Engine mehrmals pro Minute durch das vom Cron-Job aufgerufene PHP-Skript gestartet wird. Zwischen den Aufrufen der Engine wird das PHP-Skript bis zur nächsten Sekunde pausiert.

Es wurde auch mehrmals festgestellt, dass offenbar beim Verlassen der Wohnung die Positionsänderung von der iPhone-App an die Web-Applikation verloren ging. Beim Gebrauch des iPhones beim Verlassen der Wohnung wurde auch schon oft beobachtet, dass das Internet zwischen dem Wechsel von WLAN zum Mobilfunk nur schlecht funktioniert und oft Verbindungsabbrüche hat. Daraus wurde gefolgert, dass die Positionsmeldung an die Web-Applikation dort verloren geht. Nachdem die iPhone-App so umgeschrieben wurde, dass fehlgeschlagene HTTP-Anfragen bis zu dreimal erneut gesendet werden, trat das Problem nicht mehr auf.

Ebenfalls mehrmals wurde beobachtet, dass die iBeacon-Funktionalität auf dem iPhone auf einmal nicht mehr funktionierte. Dies betraf nicht nur meine iPhone-App sondern war ein systemweites Problem und war dann in allen Apps, welche iBeacon verwenden, zu beobachten. Nach einer Analyse zeigte sich, dass Bluetooth auf dem iPhone weiter funktionierte, sich das Problem also auf die iBeacon-Funktionalität beschränkte. iOS meldete den Fehler kCLErrorRangingUnavailable. Im Internet wurden ähnliche Berichte zu diesem sporadischen Problem gefunden - offenbar handelt es sich um einen Fehler in iOS. Um das Problem zu beheben muss das iPhone neu gestartet werden.

Fazit

iBeacon

Die Heimautomatisierung mit iBeacons ist durchaus möglich, muss aber detailliert geplant sein. Aufgrund der technischen Einschränkungen in iOS ist eine fortlaufende Messung der Distanz zu einem iBeacon nicht möglich, die Position des Bewohners muss deshalb über das Betreten und Verlassen des Empfangsbereichs des Beacons realisiert werden.

Die von Apple gesetzten Einschränkungen machen jedoch Sinn, da sie den Akku des iPhones schonen und einen übermässigen Energieverbrauch aufgrund einer Hintergrundaktivität verhindern. Insofern wäre es wohl auch empfehlenswert, eine ähnliche Implementierung auf anderen Plattformen anzuwenden.

Aufgrund dieser Voraussetzungen ist es notwendig, die Signalstärke der Beacons auf ca. 3-5 Meter (-20 dBm) zu reduzieren. Die daraus resultierende Signalstärke ist auch aufgrund des Energieverbrauchs der Estimote Beacons empfehlenswert. Dadurch werden je nach Grösse des Raums mehrere Beacons pro Raum notwendig. Die im Projekt eingesetzte Anzahl von drei Beacons war eher knapp. Pro Raum sind drei bis vier Beacons zu empfehlen.

Durch die gewonnenen Kenntnisse über das iBeacon-Format wäre es nun auch möglich, ohne Hard- oder Software von Apple ein Beacon nach zu bauen.

Software

Für die Software gibt es bereits mehrere Ideen für eine Weiterentwicklung. Zum einen wäre es für Haushalte mit mehreren Personen sinnvoll, wenn die Anwendung auch mehrbenutzerfähig ist. In der Web-Applikation könnte die Visualisierung der stattgefundenen Events noch verbessert und die Funktionalität zur manuellen Steuerung der Beleuchtung eingebaut werden. Eine hilfreiche Funktion wäre auch die Warnung des Benutzers, falls die Batterie eines Beacons fast leer ist. Zudem wäre ein regelmässiger Abgleich des effektiven Lichtstatus mit der von der Engine definierten Zustand nützlich.

Der Umstand, dass die Lichter weiterhin über die normalen Lichtschalter gesteuert werden können, hat einen positiven und einen negativen Aspekt. Es ist praktisch, wenn die Lichter über die Nacht manuell komplett ausgeschaltet werden können. Sobald man die Lichter jedoch manuell ausschaltet, können diese nicht mehr automatisch angeschaltet werden. Während dem Projekt wurden aus Gewohnheit die Lichter beim Verlassen der Wohnung oft manuell abgeschaltet und gingen dann beim erneuten Betreten der Wohnung nicht wieder an. Die teilweise auftretende Verzögerung beim automatischen Einschalten des Lichts in einem kleinen Raum führte auch oft dazu, dass automatisch der Lichtschalter betätigt wurde. Das Licht war somit vom Strom getrennt und konnte nicht mehr automatisch angeschaltet werden.

Projekt

Eine der Schwierigkeiten war die lineare Dokumentation des Projekts, da dieses eher explorativ entwickelt wurde. Basierend auf den ersten Anforderungen wurde zu Beginn des Projekts eine erste Version der Software entwickelt. Der tägliche Gebrauch führte dann immer wieder zu neuen Anforderungen und Design-Änderungen. Aufgrund der unregelmässigen Auslastung in der Schule und bei der Arbeit waren diese Iterationen jedoch nicht immer klar abgegrenzt.

Das Erforschen von unbekannten Protokollen zeigte, dass meist nicht der direkte Weg zum Ziel führt und verschiedene Ansätze verfolgt werden mussten. Die Bedeutung des genauen Formats von iBeacon war schlussendlich aber nicht so gross wie ursprünglich erhofft. Die Kombination von unterschiedlichen Technologien zu einer funktionierenden Anwendung war dennoch sehr lehrreich.

Anhang

Software

Die während der Arbeit verwendete Software wird zur Vollständigkeit dokumentiert, um eine Reproduktion der Ergebnisse zu ermöglichen.

• Mac OS X 10.9 Build 13A603
• iOS 7.1.1 Build 11D201
• Xcode 5.0.2 Build 5A3005
• Bluetooth Explorer 4.2.0 Build 4.2.0f2
• PacketLogger 4.2.0 Build 4.2.0f2
• Prince 9.0 rev 4
• MySQL Workbench 6.0 Build 6.0.7.11216
• MySQL 5.1.70
• PHP 5.4.26
• Silex 1.1.2
• PHPUnit 3.7.31
• Twig 1.15.1
• Sweet Home 3D 4.3
• Git 1.8.5.2
• Tower 1.5.4
• Bootstrap 3.1.0
• jQuery 1.9.1
• D3.js 3.4.1

Quellenverzeichnis

Apple Inc. (2011): CoreBluetooth: Health Thermometer. Version 1.0. https://developer.apple.com/library/mac/samplecode/HealthThermometer/Introduction/Intro.html#//apple_ref/doc/uid/DTS40011370 (abgerufen am 20. November 2013)

Apple Inc. (2013): Core Bluetooth Programming Guide. 18. September 2013. https://developer.apple.com/library/ios/documentation/NetworkingInternetWeb/Conceptual/CoreBluetooth_concepts/CoreBluetooth_concepts.pdf (abgerufen am 20. November 2013)

Apple Inc. (2013): Hardware IO Tools for Xcode. Veröffentlicht am 22. Oktober 2013. https://developer.apple.com/downloads/index.action?name=hardware%20io (abgerufen am 20. April 2014)

Apple Inc. (2013): iOS: Understanding iBeacon. 4. Dezember 2013. http://support.apple.com/kb/HT6048 (abgerufen am 19. April 2014)

Apple Inc. (2013): Location and Maps Programming Guide https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/LocationAwarenessPG/Introduction/Introduction.html#//apple_ref/doc/uid/TP40009497 (abgerufen am 24. November 2013)

Bluetooth SIG, Inc. (2010): Bluetooth Specification Version 4.0 https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=229737 (abgerufen am 22. November 2013)

Bluetooth SIG, Inc. (2012): Supplement to Bluetooth Core Specification. Version 2. https://www.bluetooth.org/docman/handlers/downloaddoc.ashx?doc_id=260933 (abgerufen am 22. November 2013)

Bluetooth SIG, Inc. (2013): Bluetooth Smart http://www.bluetooth.com/Pages/Bluetooth-Smart.aspx (abgerufen am 19. April 2014)

Bluetooth SIG, Inc. (2014): Company Identifiers https://www.bluetooth.org/en-us/specification/assigned-numbers/company-identifiers (abgerufen am 21. April 2014)

Estimote, Inc. (2013): Estimote Beacons http://estimote.com/ (abgerufen am 4. Mai 2014)

eTeks (2014): Sweet Home 3D http://www.sweethome3d.com/ (abgerufen am 7. Mai 2014)

Geatronik d.o.o. (2014): Chipolo http://www.chipolo.net/ (abgerufen am 10. Mai 2014)

Laurent Gaches (2013): BeaconEmitter. https://github.com/lgaches/BeaconEmitter (abgerufen am 20. November 2013)

Mark Otto (2013): Bootstrap http://getbootstrap.com/ (abgerufen am 7. Mai 2014)

Mike Bostock (2013): D3.js http://d3js.org/ (abgerufen am 7. Mai 2014)

Dick Hardt (2012): The OAuth 2.0 Authorization Framework. Oktober 2012. http://tools.ietf.org/html/rfc6749 (abgerufen am 12. Mai 2014)

Punch Through Design LLC (2013): LightBlue - Bluetooth Low Energy. Version 1.50. https://itunes.apple.com/ch/app/lightblue-bluetooth-low-energy/id557428110?l=en&mt=8 (abgerufen am 20. April 2014)

Sensio Labs (2013): Silex http://silex.sensiolabs.org/ (abgerufen am 4. Mai 2014)

Sensio Labs (2014): Twig http://twig.sensiolabs.org/ (abgerufen am 4. Mai 2014)

Abbildungsverzeichnis

Glossar

API: Application Programming Interface, bezeichnet die Schnittstelle, über welche der Client Daten vom Server abruft.

Beacon: Ein elektronisches Bauteil, das ein iBeacon-Signal aussendet.

Browser: Software zur Darstellung von Websites aus dem Internet. Beispielsweise Google Chrome oder Mozilla Firefox.

Client: Ein Anwendungsprogramm, welches auf dem Gerät des Benutzers läuft und meist mit einem Server kommuniziert.

Continuous-Integration: Automatisiertes Testen von Software in regelmässigen Abständen.

Cron: Eine Software zur automatisierten Ausführung von wiederkehrenden Aufgaben.

Deployment: Das Verschieben oder Aktualisieren von Software auf die Ziellaufzeitumgebung.

GNU/Linux: Betriebssystem basierend auf freier Software.

GPS: Global Positioning System, Positionsbestimmung mithilfe von Satelliten.

HTTP: Hypertext Transfer Protocol, ist ein Protokoll zur Übertragung von Daten über ein Netzwerk.

iOS: Betriebssystem von Apple für Handys und Tablets (iPhone und iPad).

Micro-Framework: Bezeichnet eine Mischung ein Framework mit reduzierter Funktionalität, welche eher wie eine Bibliothek aufgebaut ist.

REST: Representational State Transfer, ist eine Architektur für eine API, welche die nach HTTP definierten Regeln befolgt.

RSSI: Received Signal Strength Indicator, gibt die empfange Stärke eines Signals an.

Templating-Engine: Interpretiert einen einfachen Syntax im HTML-Code und verbindet diesen mit Daten zu einer fertigen HTML-Seite.

WLAN: Drahtlose Internetverbindung.

XML: Extensible Markup Language, ein Datenformat.