ZHAW Zürcher Hochschule für Angewandte Wissenschaften
Bachelorstudium Informatik
Semesterarbeit
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.
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 Anforderungsanalyse 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.
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 Heimautomatisierung 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 Positionsbestimmung 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.
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.
Im Rahmen dieser Semesterarbeit werden vom Studenten folgende Aufgaben ausgeführt:
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 ◆ |
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 |
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 (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.
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.
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.
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).
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.
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.
Byte | Beschreibung | Wert |
---|---|---|
02 | Length | 2 |
01 | AD Type | Flags |
1A | Flags | LE General Discoverable Mode Simultaneous LE and BR/EDR (Controller) Simultaneous LE and BR/EDR (Host) |
1A | Length | 26 |
FF | AD Type | Manufacturer Specific Data |
4C | Company Identifier Code | Apple, Inc. |
00 | ||
02 | Fixer Wert | iBeacon Identifier |
15 | ||
FF | iBeacon UUID | FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF |
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
FF | ||
00 | iBeacon Major | 0 |
00 | ||
FF | iBeacon Minor | 65535 |
FF | ||
C5 | Fixer Wert | Measured power |
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.
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.
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. |
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.
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.
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. |
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 |
|
Standardablauf |
|
Ergebnis | Das neue Beacon erscheint auf der Konfigurationsansicht und kann einem Licht zugewiesen werden. |
Ausnahmen |
|
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 |
|
Standardablauf |
|
Ergebnis | Die automatisierte Steuerung schaltet die ausgewählten Lichter an, sobald der Benutzer in der Nähe des Beacons ist. |
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 |
|
Standardablauf |
|
Ergebnis | Das Beacon erscheint mit dem geänderten Namen auf der Konfigurationsansicht. |
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 |
|
Standardablauf |
|
Ergebnis | Das Beacon wird in der Konfigurationsansicht in einer separaten Liste aufgeführt und kann nicht mehr Lichtern zugewiesen werden. |
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 |
|
Standardablauf |
|
Ergebnis | Das Beacon wird in der Konfigurationsansicht wieder normale dargestellt und kann Lichtern zugewiesen werden. |
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 |
|
Standardablauf |
|
Ergebnis | Das Licht geht an und leuchtet. |
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 |
|
Standardablauf |
|
Ergebnis | Das Licht geht aus und leuchtet nicht mehr. |
Ausnahmen |
|
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 |
|
Standardablauf |
|
Ergebnis | Die automatisierte Steuerung der Lichter wird pausiert, es werden keine Lichter mehr automatisch an- und ausgeschaltet. |
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 |
|
Standardablauf |
|
Ergebnis | Die automatisierte Steuerung der Lichter ist wieder aktiv, Lichter werden wieder automatisch an- und ausgeschaltet. |
Neben den funktionalen Anforderungen gibt es auch gewisse nichtfunktionale Anforderungen, die teilweise implizit vom Benutzer erwartet werden. Diese Qualitätsanforderungen 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. |
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. |
Identifier | Q03 |
---|---|
Name | Portabilität |
Beschreibung | Die Anwendung soll auf einem einfachen Web-Server betrieben werden können, welcher PHP und MySQL unterstützt. |
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. |
Identifier | Q05 |
---|---|
Name | Performance |
Beschreibung | Alle Ansichten der Anwendungen sollen innerhalb von 0.9 Sekunden angezeigt werden. |
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.
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.
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.
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.
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.
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.
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.
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.
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.
Tabelle | Inhalt |
---|---|
beacons | Sämtliche vom Benutzer erfassten Beacons |
beacons_proximities | Die von der iPhone-App gemessenen Abstände |
beacons_states | Die von der iPhone-App gemeldeten Positionen des Benutzers |
beacons_mappings | Zuweisungen der Beacons zu den Lampen |
lights | Die über die hue API gefundenen Lampen |
lights_actions | Durchgeführte und geplante Interaktionen mit der hue API zum An- oder Ausschalten der Lampen |
lights_log | Historische Daten über die Brenndauer der Lampen |
oauth_clients | OAuth 2.0 Client-Applikationen (iPhone-Apps) |
oauth_tokens | Authorisierte OAuth-Tokens für die iPhone-App |
config | Systemeinstellungen |
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.
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.
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.
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:
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. |
Signalstärke | -4 dBm |
---|---|
Datum | 01.05.2014 |
Zeit Beginn | 16:39 |
Zeit Ende | 17:58 |
Notizen | Es sind keine Probleme aufgetreten. |
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. |
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.
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.
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.
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 |
|
Ablauf |
|
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 |
Identifier | AT02 |
---|---|
Name | Beacon zu einem Licht zuweisen |
Relevante Anforderungen | UC02 |
Vorbedingungen |
|
Ablauf |
|
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 |
Identifier | AT03 |
---|---|
Name | Namen eines Beacons ändern |
Relevante Anforderungen | UC03 |
Vorbedingungen |
|
Ablauf |
|
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 |
Identifier | AT04 |
---|---|
Name | Beacon ausblenden |
Relevante Anforderungen | UC04 |
Vorbedingungen |
|
Ablauf |
|
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 |
Identifier | AT05 |
---|---|
Name | Beacon einblenden |
Relevante Anforderungen | UC05 |
Vorbedingungen |
|
Ablauf |
|
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 |
Identifier | AT06 |
---|---|
Name | Licht einschalten |
Relevante Anforderungen | UC06 |
Vorbedingungen |
|
Ablauf |
|
Erwartetes Ergebnis | Das Licht geht an. |
Ergebnis | Nach 2 Sekunden geht das Licht an. |
Status | Erfolgreich getestet |
Identifier | AT07 |
---|---|
Name | Licht ausschalten |
Relevante Anforderungen | UC07 |
Vorbedingungen |
|
Ablauf |
|
Erwartetes Ergebnis | Nach 3 Minuten geht das Licht aus. |
Ergebnis | Das Licht erlöscht nach 3 Minuten und 2 Sekunden. |
Status | Erfolgreich getestet |
Identifier | AT08 |
---|---|
Name | Mehrere Beacons und Lichter |
Relevante Anforderungen | UC06, UC07 |
Vorbedingungen |
|
Ablauf |
|
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 |
Identifier | AT09 |
---|---|
Name | Steuerung pausieren |
Relevante Anforderungen | UC08 |
Vorbedingungen |
|
Ablauf |
|
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 |
Identifier | AT10 |
---|---|
Name | Steuerung wieder aktivieren |
Relevante Anforderungen | UC09 |
Vorbedingungen |
|
Ablauf |
|
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 |
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.
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.
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.
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.
Die während der Arbeit verwendete Software wird zur Vollständigkeit dokumentiert, um eine Reproduktion der Ergebnisse zu ermöglichen.
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)
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.