ZHAW Zürcher Hochschule für Angewandte Wissenschaften
Bachelorstudium Informatik
Semesterarbeit

Heimautomatisierung mit iBeacons

Autor: Fabian Vogler, fabian.vogler@gmail.com
Betreuungsperson: Peter Egli
16. Mai 2014, Version 1.1 HEAD

Diese Arbeit entstand im Rahmen einer Semesterarbeit an der Zürcher Hochschule für Angewandte Wissenschaften (ZHAW) in Zürich. Der Quelltext dieser Arbeit ist online unter https://github.com/fabian/home-automation aufrufbar.

Dieses Dokument wurde in HTML geschrieben und mit Hilfe von Prince XML in ein PDF-Dokument umgewandelt. Die verwendete Schriftart ist Helvetica Neue, entwickelt von D. Stempel AG und basierend auf Helvetica von Max Miedinger.

Sämtliche Quellen sind nummeriert [n] und befinden sich im Anhang im Quellenverzeichnis. Die Arbeit setzt Fachwissen in der Informatik voraus. Ein Glossar mit Erklärungen zu den wichtigsten Begriffen und Abkürzungen befindet sich im ebenfalls Anhang.

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.

      November Dezember Januar Februar März April Mai
    Kick-Off   ◆ 13.11.13                                
    Analyse iBeacon                                    
    Design Review                 ◆ 22.01.14                  
    Konzeption Software                              
    Umsetzung Software                                
    Feldversuch                            
    Dokumentation                                  
    Messung RSSI                                          
    Abgabe Dokumentation                                   16.05.13 ◆
    Projektablauf

    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.

    Beschreibung Soll Ist
    Analyse iBeacon 10 h 6 h
    Konzeption Software 10 h 14 h
    Umsetzung Web-Applikation 25 h 19 h
    Umsetzung automatisierte Steuerung 15 h 35 h
    Umsetzung App 25 h 12 h
    Messung RSSI - 11 h
    Dokumentation schreiben 35 h 39 h
    Total 120 h 136 h
    Soll / Ist Vergleich Aufwand

    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.

    iBeacon Logo

    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

    Logo Bluetooth Smart

    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.

    GATT Profilhierarchie, Bluetooth-Spezifikation, Seite 532

    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.

    Aufbau Core Bluetooth, Programming Guide, Seite 5

    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.

    Rollen in Bluetooth Low Energy, Programming Guide, Seite 9

    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] }];
    
    Beispielanwendung von Core Bluetooth

    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.

    Screenshot LightBlue

    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];
    
    Beispielanwendung von Core Bluetooth

    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.

    Screenshot LightBlue ohne iBeacon

    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.

    Screenshot Bluetooth Explorer

    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.

    Screenshot PacketLogger

    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
    
    Advertisement Daten iBeacon

    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.

    Struktur Advertising and Scan Response, Bluetooth Specification, Seite 375

    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.

    ByteBeschreibungWert
    02Length2
    01AD TypeFlags
    1AFlagsLE General Discoverable Mode
    Simultaneous LE and BR/EDR (Controller)
    Simultaneous LE and BR/EDR (Host)
    1ALength26
    FFAD TypeManufacturer Specific Data
    4CCompany Identifier CodeApple, Inc.
    00
    02Fixer WertiBeacon Identifier
    15
    FFiBeacon UUIDFFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    FF
    00iBeacon Major0
    00
    FFiBeacon Minor65535
    FF
    C5Fixer WertMeasured power
    Bluetooth Advertisement iBeacon

    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.

    Screenshot Bluetooth Explorer nach Scan

    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.

    Beispiel Wohnung mit Beacons

    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.

    Stakeholder Beschreibung
    Bewohner Der Bewohner der Wohnung ist der Hauptbenutzer. Die Anwendung soll sein Leben vereinfachen, die funktionalen Anforderungen sind deshalb auf ihn ausgelegt.
    Besucher Besucher der Wohnung wissen im Normalfall nichts über die im Hintergrund laufende Anwendung und müssen vor Überraschungen geschützt werden.
    Beacon-Hersteller Der Beacon-Hersteller entwickelt und liefert die nötige Hardware in Form der Beacons für die Anwendung. Er hat einen Einfluss auf die technischen Anforderungen.
    Lampen-Hersteller Der Lampen-Hersteller entwickelt und produziert die steuerbaren Lampen. Er definiert die technischen Möglichkeiten der Beleuchtung.
    Apple Apple als Entwickler des iBeacon-Formats definiert die technischen Vorgaben und nimmt evtl. in Zukunft Änderungen am Format vor.
    Stakeholder

    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.

    Kontextdiagramm

    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.

    Anwendungsfalldiagramm

    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.

    Attribut Beschreibung
    Identifier Eindeutige Nummer des Anwendungsfalls.
    Name Kurzname des Anwendungsfalls.
    Priorität Dringlichkeit des Anwendungsfalls mit dem Wertebereich tief, mittel und hoch.
    Auslöser Beschreibung des Ereignisses, welches diesen Anwendungsfall relevant macht.
    Beschreibung Kurze Zusammenfassung des Anwendungsfalls.
    Vorbedingungen Voraussetzungen welche für die Ausführung dieses Anwendungsfalls erfüllt sein müssen.
    Standardablauf Schritte zur erfolgreichen Ausführung des Anwendungsfalls.
    Ergebnis Das Resultat nach der erfolgreichen Ausführung des Standardablaufs.
    Ausnahmen Eventuell auftretende Ausnahmesituationen sowie deren Konsequenzen.
    Attribute Anwendungsfall

    Anwendungsfälle

    Identifier UC01
    Name Neues Beacon erfassen
    Priorität mittel
    Auslöser Der Benutzer konfiguriert das System zum ersten Mal oder ist in Besitz eines neuen Beacons gekommen.
    Beschreibung Der Benutzer erfasst ein neues Beacon mit einem eigenen Namen.
    Vorbedingungen
    • Der Benutzer muss die UUID sowie den Major- und den Minor-Wert des Beacons kennen.
    • Der Benutzer ist in der Anwendung eingeloggt und befindet sich auf der Ansicht zur Konfiguration der Beacons.
    Standardablauf
    • Der Benutzer klickt auf «Beacon hinzufügen».
    • Es erscheint ein Formular zur Erfassung des Beacons.
    • Der Benutzer füllt den Namen, die UUID, den Major- und den Minor-Wert ein.
    • Der Benutzer klickt auf «Beacon speichern».
    • Das Beacon wird gespeichert.
    • Es wird wieder die Ansicht zur Konfiguration mit einer Erfolgsmeldung über die erfolgreiche Speicherung des Beacons angezeigt.
    Ergebnis Das neue Beacon erscheint auf der Konfigurationsansicht und kann einem Licht zugewiesen werden.
    Ausnahmen
    • Es ist bereits ein Beacon mit der selben UUID, Major- und Minor-Werten erfasst; in diesem Fall soll das Beacon nicht gespeichert und eine Fehlermeldung angezeigt werden.
    UC01 Neues Beacon erfassen

    Identifier UC02
    Name Beacon Lichtern zuweisen
    Priorität mittel
    Auslöser Der Benutzer konfiguriert das System zum ersten Mal, ist in Besitz eines neuen Beacons oder einer neuen Lampe gekommen.
    Beschreibung Der Benutzer weisst ein Beacon zu einem oder mehreren Lichtern zu.
    Vorbedingungen
    • Es wurde ein Beacon erfasst.
    • Es ist mindestens eine Lampe vorhanden.
    • Der Benutzer ist in der Anwendung eingeloggt und befindet sich auf der Ansicht zur Konfiguration der Beacons.
    Standardablauf
    • Der Benutzer wählt die gewünschten Lichter aus.
    • Der Benutzer klickt auf «Zuweisung speichern».
    • Die Zuweisung der Lichter zum Beacon wird gespeichert.
    • Es wird wieder die Ansicht zur Konfiguration mit einer Erfolgsmeldung über die erfolgreiche Speicherung der Zuweisung angezeigt.
    Ergebnis Die automatisierte Steuerung schaltet die ausgewählten Lichter an, sobald der Benutzer in der Nähe des Beacons ist.
    UC02 Beacon Lichtern zuweisen

    Identifier UC03
    Name Namen eines Beacons ändern
    Priorität tief
    Auslöser Ein Beacon wurde neu positioniert oder es wurde ein Schreibfehler festgestellt.
    Beschreibung Der Benutzer ändert den Namen eines bestehenden Beacons.
    Vorbedingungen
    • Das Beacon wurde zuvor erfasst.
    • Der Benutzer ist in der Anwendung eingeloggt und befindet sich auf der Ansicht zur Konfiguration der Beacons.
    Standardablauf
    • Der Benutzer klickt bei dem gewünschten Beacon auf «Bearbeiten».
    • Es erscheint ein Formular mit dem Namen des Beacons.
    • Der Benutzer ändert den Namen des Beacons.
    • Der Benutzer klickt auf «Beacon speichern».
    • Das Beacon wird gespeichert.
    • Es wird wieder die Ansicht zur Konfiguration mit einer Erfolgsmeldung über die erfolgreiche Speicherung des Beacons angezeigt.
    Ergebnis Das Beacon erscheint mit dem geänderten Namen auf der Konfigurationsansicht.
    UC03 Namen eines Beacons ändern

    Identifier UC04
    Name Beacon ausblenden
    Priorität tief
    Auslöser Ein Beacon wurde entfernt oder ist nicht mehr relevant.
    Beschreibung Der Benutzer markiert ein Beacon als inaktiv.
    Vorbedingungen
    • Das Beacon wurde zuvor erfasst.
    • Der Benutzer ist in der Anwendung eingeloggt und befindet sich auf der Ansicht zur Konfiguration der Beacons.
    Standardablauf
    • Der Benutzer klickt bei dem gewünschten Beacon auf «Bearbeiten».
    • Es erscheint ein Formular mit dem Status des Beacons.
    • Der Benutzer ändert den Status des Beacons auf «Inaktiv».
    • Der Benutzer klickt auf «Beacon speichern».
    • Das Beacon wird gespeichert.
    • Es wird wieder die Ansicht zur Konfiguration mit einer Erfolgsmeldung über die erfolgreiche Speicherung des Beacons angezeigt.
    Ergebnis Das Beacon wird in der Konfigurationsansicht in einer separaten Liste aufgeführt und kann nicht mehr Lichtern zugewiesen werden.
    UC04 Beacon ausblenden

    Identifier UC05
    Name Beacon einblenden
    Priorität tief
    Auslöser Ein Beacon wurde wieder relevant nachdem es deaktiviert wurde.
    Beschreibung Der Benutzer markiert ein Beacon als aktiv.
    Vorbedingungen
    • Das Beacon wurde zuvor erfasst.
    • Das Beacon ist inaktiv.
    • Der Benutzer ist in der Anwendung eingeloggt und befindet sich auf der Ansicht zur Konfiguration der Beacons.
    Standardablauf
    • Der Benutzer klickt bei dem gewünschten Beacon auf «Bearbeiten».
    • Es erscheint ein Formular mit dem Status des Beacons.
    • Der Benutzer ändert den Status des Beacons auf «Aktiv».
    • Der Benutzer klickt auf «Beacon speichern».
    • Das Beacon wird gespeichert.
    • Es wird wieder die Ansicht zur Konfiguration mit einer Erfolgsmeldung über die erfolgreiche Speicherung des Beacons angezeigt.
    Ergebnis Das Beacon wird in der Konfigurationsansicht wieder normale dargestellt und kann Lichtern zugewiesen werden.
    UC05 Beacon einblenden

    Identifier UC06
    Name Automatisch Licht einschalten
    Priorität hoch
    Auslöser Der Benutzer kommt in die Nähe eines Beacons, welches dem Licht zugewiesen ist.
    Beschreibung Das zugewiesene Licht wird eingeschaltet.
    Vorbedingungen
    • Das Beacon wurde zuvor erfasst und ist aktiv.
    • Das Beacon ist einem Licht zugewiesen.
    • Das Licht hat Strom (wurde also nicht durch einen Lichtschalter ausgeschaltet).
    • Der Benutzer hat die App installiert und diese erfolgreich autorisiert.
    Standardablauf
    • Der Benutzer kommt in die Nähe des Beacons.
    Ergebnis Das Licht geht an und leuchtet.
    UC06 Automatisch Licht einschalten

    Identifier UC07
    Name Automatisch Licht ausschalten
    Priorität hoch
    Auslöser Der Benutzer entfernt sich vom Beacon, welches dem Licht zugewiesen ist.
    Beschreibung Das zugewiesene Licht wird nach 3 Minuten ausgeschaltet. Diese 3 Minuten Wartezeit dienen auch zur Verhinderung von flackernden Lichtern, falls der Benutzer nur kurzzeitig (z.B. aufgrund einer Signalschwankung) ausserhalb des Bereichs gemeldet wird.
    Vorbedingungen
    • Das Beacon wurde zuvor erfasst und ist aktiv.
    • Das Beacon ist einem Licht zugewiesen.
    • Das Licht leuchtet.
    • Der Benutzer hat die App installiert und diese erfolgreich autorisiert.
    Standardablauf
    • Der Benutzer entfernt sich vom Beacon.
    • Der Benutzer bleibt 3 Minuten vom Beacon weg.
    Ergebnis Das Licht geht aus und leuchtet nicht mehr.
    Ausnahmen
    • Der Benutzer nähert sich innerhalb von 3 Minuten wieder dem Beacon; das Licht wird in diesem Fall nicht ausgeschaltet.
    UC07 Automatisch Licht ausschalten

    Identifier UC08
    Name Steuerung pausieren
    Priorität mittel
    Auslöser Eine Person zusätzliche Person (z.B. ein Besucher) betritt die Wohnung und möchte nicht im Dunkeln stehen, falls der Benutzer mit der App einen anderen Raum betritt.
    Beschreibung Der Benutzer pausiert die automatisierte Steuerung für eine unbegrenzte Zeit.
    Vorbedingungen
    • Der Benutzer ist in der Anwendung eingeloggt und befindet sich auf der Startseite.
    Standardablauf
    • Der Benutzer klickt auf «Steuerung pausieren».
    • Der Status der Steuerung wird als pausiert angezeigt.
    Ergebnis Die automatisierte Steuerung der Lichter wird pausiert, es werden keine Lichter mehr automatisch an- und ausgeschaltet.
    UC08 Steuerung pausieren

    Identifier UC09
    Name Steuerung wieder aktivieren
    Priorität mittel
    Auslöser Die zusätzliche Person (z.B. ein Besucher) verlässt die Wohnung wieder.
    Beschreibung Der Benutzer aktiviert die automatisierte Steuerung wieder für eine unbegrenzte Zeit.
    Vorbedingungen
    • Der Benutzer ist in der Anwendung eingeloggt und befindet sich auf der Startseite.
    • Die Steuerung wurde pausiert.
    Standardablauf
    • Der Benutzer klickt auf «Steuerung aktivieren».
    • Der Status der Steuerung wird als aktiv angezeigt.
    Ergebnis Die automatisierte Steuerung der Lichter ist wieder aktiv, Lichter werden wieder automatisch an- und ausgeschaltet.
    UC09 Steuerung wieder aktivieren

    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.

    Identifier Q01
    Name Erlernbarkeit
    Beschreibung Die Bedienung der Anwendung soll durch einen Benutzer auch ohne Anleitung innerhalb von einem Tag verstanden werden können. Vom Benutzer begangene Fehler sollen jederzeit wieder rückgängig gemacht werden können.
    Q01 Erlernbarkeit

    Identifier Q02
    Name Änderbarkeit
    Beschreibung Um auch zukünftige Anforderungen umsetzen zu können, soll die Anwendung erweiterbar geschrieben werden. Es muss möglich sein, weiter Funktionen einzubauen ohne bestehende zu beeinträchtigen.
    Q02 Änderbarkeit

    Identifier Q03
    Name Portabilität
    Beschreibung Die Anwendung soll auf einem einfachen Web-Server betrieben werden können, welcher PHP und MySQL unterstützt.
    Q03 Portabilität

    Identifier Q04
    Name Sicherheit
    Beschreibung Die Anwendung soll durch ein Login geschützt sein. Der Benutzer muss sich mit seinem Benutzernamen und Passwort authentifizieren, um die Anwendung zu benutzen.
    Q04 Sicherheit

    Identifier Q05
    Name Performance
    Beschreibung Alle Ansichten der Anwendungen sollen innerhalb von 0.9 Sekunden angezeigt werden.
    Q05 Performance

    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.

    Mockup Dashboard

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

    Mockup Report

    Im Setup kann der Benutzer die Beacons den Lichtern zuweisen.

    Mockup Setup

    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.

    Übersicht Lösungsstrategie

    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.

    Komponentendiagramm

    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.

    Klassendiagramm Homebase\Service

    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.

    Sequenzdiagramm App

    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.

    Sequenzdiagramm Engine

    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.

    Verteilungsdiagramm

    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.

    TabelleInhalt
    beaconsSämtliche vom Benutzer erfassten Beacons
    beacons_proximitiesDie von der iPhone-App gemessenen Abstände
    beacons_statesDie von der iPhone-App gemeldeten Positionen des Benutzers
    beacons_mappingsZuweisungen der Beacons zu den Lampen
    lightsDie über die hue API gefundenen Lampen
    lights_actionsDurchgeführte und geplante Interaktionen mit der hue API zum An- oder Ausschalten der Lampen
    lights_logHistorische Daten über die Brenndauer der Lampen
    oauth_clientsOAuth 2.0 Client-Applikationen (iPhone-Apps)
    oauth_tokensAuthorisierte OAuth-Tokens für die iPhone-App
    configSystemeinstellungen
    Tabellen Datenmodell

    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.

    Datenmodell

    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 Beacon

    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.

    Foto Estimote Beacon

    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.

    Visualisierung erster Stock
    Visualisierung zweiter Stock

    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.

    Foto Wohnung

    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.

    Screenshot iPhone-App

    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.

    Foto Messung

    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.

    Signalstärke -12 dBm
    Datum 01.05.2014
    Zeit Beginn 10:46
    Zeit Ende 12:40
    Notizen Beim Start der Messung des 2. Stockwerks wurde festgestellt, dass ein Beacon nicht gemessen wurde. Kurz zuvor wurde die Signalstärke dieses Beacons mit der Estimote App überprüft. Offenbar hat das Beacon dadurch kurzzeitig keine Daten gesendet. Nach einem erneuten Verbinden mit der Estimote App und der Bestätigung der Signalstärke funktionierte das Beacon wieder fehlerfrei. Der Fehler ist nicht wiederholt aufgetreten. Der Wert wurde gelöscht und die Messung für dieses Feld erfolgreich wiederholt.
    Protokoll Messung 1

    Signalstärke -4 dBm
    Datum 01.05.2014
    Zeit Beginn 16:39
    Zeit Ende 17:58
    Notizen Es sind keine Probleme aufgetreten.
    Protokoll Messung 2

    Signalstärke -20 dBm
    Datum 06.05.2014
    Zeit Beginn 09:12
    Zeit Ende 10:31
    Notizen Neu wurde ein iPad zur laufenden Überwachung der Resultate eingesetzt. Es sind jedoch keine Probleme festgestellt worden.
    Protokoll Messung 3

    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.

    Visualisierung RSSI Beacon 1, -4 dBm

    Visualisierung RSSI Beacon 1, -12 dBm

    Visualisierung RSSI Beacon 1, -20 dBm

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

    Visualisierung RSSI Beacon 2, -4 dBm

    Visualisierung RSSI Beacon 2, -12 dBm

    Visualisierung RSSI Beacon 2, -20 dBm

    Das dritte Beacon befindet sich direkt im Eingangsbereich der Wohnung.

    Visualisierung RSSI Beacon 3, -4 dBm

    Visualisierung RSSI Beacon 3, -12 dBm

    Visualisierung RSSI Beacon 3, -20 dBm

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

    Screenshot Dashboard

    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.

    Screenshot Report

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

    Screenshot Setup

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

    Screenshot Beacon bearbeiten

    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.

    Screenshot Auswertung Messung

    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.

    Identifier AT01
    Name Beacon erfassen
    Relevante Anforderungen UC01
    Vorbedingungen
    • Die Datenbank enthält keine bestehenden Daten.
    • Der Benutzer ist in der Web-Applikation eingeloggt und befindet sich auf der Setup-Seite.
    Ablauf
    • Auf «Add Beacon» klicken.
    • Warten bis Seite mit Formular geladen ist.
    • Im Feld «Name» den Wert «Test» eingeben.
    • Im Feld «UUID» den Wert «096fa58a-dabf-11e3-aa8d-83d9cbc5965a» eingeben.
    • Im Feld «Major» den Wert «98324» eingeben.
    • Im Feld «Minor» den Wert «14832» eingeben.
    • Das Kontrollkästchen «Active» aktivieren.
    • Auf «Save Beacon» klicken.
    Erwartetes Ergebnis Das Beacon wird mit allen Informationen in der Datenbank gespeichert und auf der Setup-Seite wird das Beacon mit dem Namen angezeigt.
    Ergebnis Nach dem Speichern des Beacons wird die Erfolgsmeldung «Beacon was saved successfully.» auf der Setup-Seite angezeigt. Das Beacon «Test» ist ebenfalls sichtbar und korrekt gespeichert.
    Status Erfolgreich getestet
    AT01 Beacon erfassen

    Identifier AT02
    Name Beacon zu einem Licht zuweisen
    Relevante Anforderungen UC02
    Vorbedingungen
    • Es wurde ein Beacon «Test» erfasst.
    • Es ist ein Licht «Beispiel» in der Datenbank vorhanden.
    • Es sind keine Zuweisungen von Lichtern in der Datenbank vorhanden.
    • Der Benutzer ist in der Web-Applikation eingeloggt und befindet sich auf der Setup-Seite.
    Ablauf
    • Das Kontrollkästchen beim Licht «Beispiel» aktivieren.
    • Auf «Save settings» klicken.
    Erwartetes Ergebnis Die Zuweisung des Lichts wurde in der Datenbank gespeichert und ist durch ein aktiviertes Kontrollkästchen auf der Setup-Seite sichtbar.
    Ergebnis Nach dem Speichern der Settings wird die Erfolgsmeldung «Setup was saved successfully.» auf der Setup-Seite angezeigt. Die Zuweisung ist in der Datenbank gespeichert und auf der Setup-Seite sichtbar.
    Status Erfolgreich getestet
    AT02 Beacon zu einem Licht zuweisen

    Identifier AT03
    Name Namen eines Beacons ändern
    Relevante Anforderungen UC03
    Vorbedingungen
    • Es wurde ein Beacon «Test» erfasst.
    • Der Benutzer ist in der Web-Applikation eingeloggt und befindet sich auf der Setup-Seite.
    Ablauf
    • Beim Beacon «Test« auf «Edit» klicken.
    • Im Feld «Name» den Wert mit «Getestet» überschreiben.
    • Auf «Save Beacon» klicken.
    Erwartetes Ergebnis Der neue Name wurde in der Datenbank gespeichert und ist auf der Setup-Seite sichtbar.
    Ergebnis Nach dem Speichern des Beacons wird die Erfolgsmeldung «Beacon was saved successfully.» auf der Setup-Seite angezeigt. Der Name wurde in der Datenbank gespeichert und das Beacon wird mit dem Namen «Getestet» auf der Setup-Seite angezeigt.
    Status Erfolgreich getestet
    AT03 Namen eines Beacons ändern

    Identifier AT04
    Name Beacon ausblenden
    Relevante Anforderungen UC04
    Vorbedingungen
    • Es wurde ein aktives Beacon «Test» erfasst.
    • Der Benutzer ist in der Web-Applikation eingeloggt und befindet sich auf der Setup-Seite.
    Ablauf
    • Beim Beacon «Test» auf «Edit» klicken.
    • Das Kontrollkästchen «Active» deaktivieren.
    • Auf «Save Beacon» klicken.
    Erwartetes Ergebnis Der Status des Beacons wurde in der Datenbank gespeichert. Auf der Setup-Seite wird das Beacon nur unter «Hidden Beacons» aufgelistet.
    Ergebnis Nach dem Speichern des Beacons wird die Erfolgsmeldung «Beacon was saved successfully.» auf der Setup-Seite angezeigt. Das Beacon ist in der Liste für inaktive Beacons und es können ihm keine Lichter mehr zugewiesen werden.
    Status Erfolgreich getestet
    AT04 Beacon ausblenden

    Identifier AT05
    Name Beacon einblenden
    Relevante Anforderungen UC05
    Vorbedingungen
    • Es wurde ein inaktives Beacon «Test» erfasst.
    • Der Benutzer ist in der Web-Applikation eingeloggt und befindet sich auf der Setup-Seite.
    Ablauf
    • Beim Beacon «Test» auf «Edit» klicken.
    • Das Kontrollkästchen «Active» aktivieren.
    • Auf «Save Beacon» klicken.
    Erwartetes Ergebnis Der Status des Beacons wurde in der Datenbank gespeichert. Auf der Setup-Seite wird das Beacon nun oberhalb von «Hidden Beacons» aufgelistet.
    Ergebnis Nach dem Speichern des Beacons wird die Erfolgsmeldung «Beacon was saved successfully.» auf der Setup-Seite angezeigt. Das Beacon ist in der Liste für aktive Beacons oberhalb der inaktiven Beacons angezeigt. Dem Beacon können Lichter zugewiesen werden.
    Status Erfolgreich getestet
    AT05 Beacon einblenden

    Identifier AT06
    Name Licht einschalten
    Relevante Anforderungen UC06
    Vorbedingungen
    • Es wurde ein Estimote Beacon «Test» erfasst.
    • Es ist ein Licht «Beispiel» in der Datenbank vorhanden.
    • Das Beacon «Test» ist dem Licht «Beispiel» zugewiesen.
    • Das Estimote Beacon ist auf die Signalstärke -30 dBm eingestellt.
    • Die iPhone-App ist mit OAuth authentifizieren.
    • Das iPhone befindet sich in einem Abstand von 5 Meter zum Beacon.
    Ablauf
    • Das iPhone direkt neben das Estimote Beacon legen.
    Erwartetes Ergebnis Das Licht geht an.
    Ergebnis Nach 2 Sekunden geht das Licht an.
    Status Erfolgreich getestet
    AT06 Licht einschalten

    Identifier AT07
    Name Licht ausschalten
    Relevante Anforderungen UC07
    Vorbedingungen
    • Es wurde ein Estimote Beacon «Test» erfasst.
    • Es ist ein Licht «Beispiel» in der Datenbank vorhanden.
    • Das Beacon «Test» ist dem Licht «Beispiel» zugewiesen.
    • Das Estimote Beacon ist auf die Signalstärke -30 dBm eingestellt.
    • Die iPhone-App ist mit OAuth authentifizieren.
    • Das iPhone befindet sich direkt neben dem Estimote Beacon.
    Ablauf
    • Das iPhone in einem Abstand von 5 Metern zum Estimote Beacon ablegen.
    Erwartetes Ergebnis Nach 3 Minuten geht das Licht aus.
    Ergebnis Das Licht erlöscht nach 3 Minuten und 2 Sekunden.
    Status Erfolgreich getestet
    AT07 Licht ausschalten

    Identifier AT08
    Name Mehrere Beacons und Lichter
    Relevante Anforderungen UC06, UC07
    Vorbedingungen
    • Es wurden zwei Estimote Beacons A und B erfasst.
    • Es sind zwei Lichter X und Y in der Datenbank vorhanden.
    • Das Beacon A ist den Lichtern X und Y zugewiesen.
    • Das Beacon B ist dem Licht X zugewiesen.
    • Das Estimote Beacons sind auf die Signalstärke -30 dBm eingestellt.
    • Die iPhone-App ist mit OAuth authentifizieren.
    • Die Beacons haben einen Abstand von 5 Metern zueinander.
    • Das iPhone befindet sich in einem Abstand von 5 Meter zu beiden Beacons.
    Ablauf
    • Das iPhone direkt neben das Beacon A legen.
    • Fünf Sekunden warten.
    • Das iPhone direkt neben das Beacon B legen.
    Erwartetes Ergebnis Beide Lichter gehen an, sobald das iPhone neben das Beacon A gelegt wurde. Nachdem das iPhone zum Beacon B gelegt wurde, geht nach 3 Minuten das Licht Y aus.
    Ergebnis Nach einer Sekunde gingen beide Lichter an. Nach 3 Minuten und 15 Sekunden geht das Licht Y aus.
    Status Erfolgreich getestet
    AT08 Mehrere Beacons und Lichter

    Identifier AT09
    Name Steuerung pausieren
    Relevante Anforderungen UC08
    Vorbedingungen
    • Es wurde ein Estimote Beacon «Test» erfasst.
    • Es ist ein Licht «Beispiel» in der Datenbank vorhanden.
    • Das Beacon «Test» ist dem Licht «Beispiel» zugewiesen.
    • Die automatisierte Steuerung ist aktiv.
    • Das Estimote Beacon ist auf die Signalstärke -30 dBm eingestellt.
    • Die iPhone-App ist mit OAuth authentifizieren.
    • Das iPhone befindet sich direkt neben dem Estimote Beacon.
    • Der Benutzer ist in der Web-Applikation eingeloggt und befindet sich auf dem Dashboard.
    Ablauf
    • Auf «Stop Engine» klicken.
    • Das iPhone in einem Abstand von 5 Metern zum Estimote Beacon ablegen.
    Erwartetes Ergebnis Das Licht geht nicht aus.
    Ergebnis Auf dem Dashboard wird die Meldung «Engine stopped.» angezeigt. Das Licht erlöscht auch nach 5 Minuten nicht.
    Status Erfolgreich getestet
    AT09 Steuerung pausieren

    Identifier AT10
    Name Steuerung wieder aktivieren
    Relevante Anforderungen UC09
    Vorbedingungen
    • Es wurde ein Estimote Beacon «Test» erfasst.
    • Es ist ein Licht «Beispiel» in der Datenbank vorhanden.
    • Das Beacon «Test» ist dem Licht «Beispiel» zugewiesen.
    • Die automatisierte Steuerung ist pausiert.
    • Das Estimote Beacon ist auf die Signalstärke -30 dBm eingestellt.
    • Die iPhone-App ist mit OAuth authentifizieren.
    • Das iPhone befindet sich in einem Abstand von 5 Meter zum Beacon.
    • Der Benutzer ist in der Web-Applikation eingeloggt und befindet sich auf dem Dashboard.
    Ablauf
    • Auf «Start Engine» klicken.
    • Das iPhone direkt neben das Estimote Beacon legen.
    Erwartetes Ergebnis Das Licht geht an.
    Ergebnis Auf dem Dashboard wird die Meldung «Engine running.» angezeigt. Das Licht geht nach einer Sekunde an.
    Status Erfolgreich getestet
    AT10 Steuerung wieder aktivieren

    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.

    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.