basa: building automation and security on android · buildings prevents further energy savings, as...
TRANSCRIPT
BASA: Building Automation and Security on Android
João Miguel Marques Sampaio
Thesis to obtain the Master of Science Degree in
Telecommunications and Informatics Engineering
Supervisor: Prof. Ricardo Jorge Feliciano Lopes Pereira
Examination Committee
Chairperson: Prof. Rui Jorge Morais Tomaz ValadasSupervisor: Prof. Ricardo Jorge Feliciano Lopes Pereira
Member of the Committee: Prof. Paulo Jorge Pires Ferreira
November 2016
ii
Abstract
Systems capable of reducing energy consumption are needed in order to reduce monetary energy costs
for companies. At the same time, studies show that temperature can influence human productivity, thus
simply removing Heating, ventilation and air conditioning (HVAC) systems could impact negatively a
company’s employees work productivity.
Nowadays Building Automation Systems (BAS) are used to manage a building, however traditional
systems face a big problem, they have high monetary costs associated with installation and hardware.
At the same time, the market is flooded with cheaper tablet devices with built-in sensors, connectivity
and visual display.
In this document, we propose a system that utilizes an Android tablet, mounted in the room wall,
running an application to achieve building automation. Our solution addresses the energy consumption
problem, increases occupant comfort and offers security, including intrusion detection notification and
video monitoring, to the user. The proposed system differs from traditional centralized BAS by offering
a distributed architecture with nodes deployed in every office and a user mobile application capable of
interacting with the system.
Keywords: Android, Building Automation, Security, Occupancy Detection, Sensors
iii
iv
Resumo
Sistemas capazes de reduzir o consumo de energia sao necessarios a fim de reduzir os custos en-
ergeticos para as empresas. Ao mesmo tempo, estudos mostram que a temperatura pode influenciar a
produtividade humana, portanto, simplesmente remover sistemas HVAC poderia ter um impacto nega-
tivo na produtividade dos funcionarios de uma empresa.
Hoje em dia BAS sao utilizados para gerir um edifıcio, no entanto sistemas tradicionais enfrentam
um grande problema, eles tem custos elevados associados a instalacao e equipamento. Ao mesmo
tempo, o mercado e inundado com tablets baratos com sensores embutidos, conectividade e ecras.
Neste documento, propomos um sistema que utiliza um tablet Android, montado na parede do es-
critorio, que executa uma aplicacao para atingir automacao do edifıcio. A nossa solucao aborda o
problema do consumo de energia, aumenta o conforto dos ocupantes e oferece seguranca, incluindo
a notificacao de deteccao de intrusos e monitorizacao de vıdeo, para o utilizador. O sistema proposto
difere dos sistemas centralizados tradicionais, oferecendo uma arquitetura distribuıda com nos implan-
tados em cada escritorio e uma aplicacao movel de utilizador, capaz de interagir com o sistema.
Palavras-chave: Android, Automacao de edificios, Seguranca, Deteccao de presenca, Sen-
sores
v
vi
Contents
Abstract iii
Resumo v
List of Figures xii
List of Tables xiii
Acronyms xv
1 Introduction 1
1.1 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Proposed Solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Thesis Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Related Work 7
2.1 Building Automation Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Zigbee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 BACnet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 LonWorks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Z-Wave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Home Automation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 Commercial Home/Office Automation Products . . . . . . . . . . . . . . . . . . . . 12
2.2.2 Academic Automation Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 General Purpose, Wireless Communication protocols . . . . . . . . . . . . . . . . . . . . 16
2.3.1 Wireless Communications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.2 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Sensors and their application in Automation Systems . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Sensors available in Android tablet/phone devices . . . . . . . . . . . . . . . . . . 19
2.4.2 Sensor application in Automation Systems . . . . . . . . . . . . . . . . . . . . . . 20
vii
2.4.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3 Architecture 24
3.1 Architecture Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.1.1 User App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.1.2 Hub App . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2 Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Communication Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.1 Hub App Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.2 User App Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4 Implementation 30
4.1 Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.1 Tablet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2 HVAC control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.3 Lighting control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.4 Bluetooth Beacon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Software Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.1 User Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Lighting control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.3 HVAC control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2.4 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2.5 Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.2.6 Security - Motion detection, video recording, Live view . . . . . . . . . . . . . . . . 41
4.2.7 Hub app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.8 User app . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5 Evaluation 54
5.1 Tests Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2 Tests Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.1 User detection - Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2.2 User detection - Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.3 Motion detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.4 Temperature and Luminosity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.5 Hub server load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2.6 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3 Test Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.1 User detection - Room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.3.2 User detection - Building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
viii
5.3.3 Motion detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.4 Temperature and Luminosity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3.5 Hub server load . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.6 Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6 Conclusions 64
6.1 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6.2 Achievements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.3 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
Bibliography 69
ix
x
List of Figures
2.1 A Star Network Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 A Mesh Networking Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 LonTalk protocol architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Philips Hue White E 26 starter kit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5 Nest Learning Thermostat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.6 IEEE 802.15.4 Data Rates and Frequencies of Operation . . . . . . . . . . . . . . . . . . 18
2.7 Temperature / Humidity Ranges for Comfort . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.8 Android embedded sensors Vs Sensors for Arduino or Raspberry pi . . . . . . . . . . . . 23
3.1 Architecture of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Overview architecture of the system . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Hardware architecture of the Hub . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Hub APP architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1 Hardware implementation architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Arduino HVAC circuit diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Edup Light Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Edup Light Switch connected to a lamp to simulate room lights . . . . . . . . . . . . . . . 34
4.5 Software architecture. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Edup packet to set the light state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.7 Arduino HVAC configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.8 UserLocation Class parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9 Light fragment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.10 Temperature fragment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.11 Register screen, allows the user to register using an email or User app. . . . . . . . . . . 47
4.12 Event history screen, shows some events and their date. . . . . . . . . . . . . . . . . . . 48
4.13 Statistics screen, shows temperature, lighting, luminosity and occupation graphics. . . . . 48
4.14 Settings screen, allows the user to configure the app. . . . . . . . . . . . . . . . . . . . . 48
4.15 Screenshot from Gmail, received email after user registration in Hub app. . . . . . . . . . 49
4.16 Create recipe fragment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.17 Add trigger fragment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
xi
4.18 Select action fragment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.19 Final recipe creation fragment. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.20 Zone creation and Zone display. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.21 Adding a Hub device to the user app. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.22 Security - live camera and video history . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.23 Settings screen in User app. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1 Cumulative distribution function of the time it takes to detect a user inside a room . . . . . 57
5.2 Cumulative distribution function of the time it takes to detect a user when he enters the
room . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Cumulative distribution function of the time it takes to detect a user after he enters the
building . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5.4 Motion detection - Frame before and after, motion detected . . . . . . . . . . . . . . . . . 59
5.7 Get Request time per concurrent user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.5 Luminosity Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.6 Temperature Readings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.8 Post Request time per concurrent user. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
xii
List of Tables
2.1 Comparing ZigBee with Bluetooth and 802.11b . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Available BT classes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.1 Comparison between some tablet devices . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Differences between thermostat options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Lighting control options. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.1 Motion detection tests for three people with different heights, 20 measurements each. . . 58
5.2 User usability tests results for task 1 and 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.3 User usability tests, mean and standard deviation . . . . . . . . . . . . . . . . . . . . . . . 63
5.4 Expert user usability tests, mean and standard deviation . . . . . . . . . . . . . . . . . . . 63
xiii
xiv
List of Acronyms
ab ApacheBench
API application programming interface
AP Access Point
BAS Building Automation Systems
BLE Bluetooth Low Energy
BSS Basic Service Set
BT Bluetooth
CPU Central processing unit
DQPSK Differential Quadrature Phase Shift Keying
FFD full-function device
GFSK Gaussian Frequency Shift Keying
GUI graphical user interface
HTTP Hypertext Transfer Protocol
HVAC Heating, ventilation and air conditioning
IEEE Institute of Electrical and Electronics Engineers
IFTTT If This Then That
IP Internet Protocol
ISM Scientific and Medical
IST Instituto Superior Tecnico
JSON JavaScript Object Notation
LAN Local Area Network
LR-WPAN low-rate wireless personal area network
MAC media access control
MS/TP Master-Slave/Token-Passing
P2P Peer-to-peer
xv
PHY Physical Layer
PTP Point-to-Point
PerOMAS Personal Office Management and Automation System
RAM Random-access memory
REST representational state transfer
RFD reduced-function device
ROI Return on investment
SAC access control system
SSDP Simple Service Discovery Protocol
TCP Transmission Control Protocol
UDP User Datagram Protocol
UI User Interface
WLAN wireless local area network
WPAN wireless personal area network
WiFi Wireless fidelity
xvi
Chapter 1
Introduction
Buildings represent a large portion of the total energy consumed. According to the International Energy
Agency, buildings represent 32% of total final energy consumption [1]. One way to contribute to reducing
the energy consumption is to use of BAS to improve their efficiency. Unfortunately, not all buildings are
equipped with such systems. Most times, these systems offer limited functionality and can only be
controlled by the building manager.
Human behavior influences the amount of energy a building requires. Depending on the occupant
behavior, the building’s energy cost can increase or decrease by one-third of its design performance [2].
Simple actions such as leaving the lighting system always on, even after the occupant has gone home,
has an impact on the wasted energy used by the building. The lack of occupant detection systems in
buildings prevents further energy savings, as by knowing when a room is unoccupied it is possible to
shutdown unnecessary electric systems.
Nowadays, consumer smart home systems are becoming more popular. The ability to remote control
the house lighting and electric devices is very appealing to consumers. At the same time smart phones
and tablets flood the market at very accessible price ranges.
1.1 Background
Nowadays, home and office buildings are responsible for a substantial amount of the electricity consump-
tion. A significant part of that consumption can be controlled by the building occupants. In a household
scenario, the occupant is most likely aware of the fact that he must switch off the electronics after they
are no longer required as to save in the electric bill. Yet in an office building, where the occupant isn’t
usually the one paying (directly) the bills, there is less incentive to reduce electricity consumption.
More and more companies are investing in the smart home/building market. Big names like Phillips,
Google, Apple and many other released products aimed at the smart building market. These products
do what they advertise but have high monetary cost. Each light bulb, sensor and display raise the overall
cost of these solutions.
Current solutions suffer from a set of problems:
1
• User Neglect - These are the major responsible for the extra energy consumption and as such
they must be the focus in order to reduce energy consumption, while still delivering the same or
better comfort levels to the occupants.
• Limited Flexibility - Currently installed BAS are not open source and require specialized instal-
lation and configuration. Because of that, they are limited to pre-installed functions and have the
risk of easily becoming outdated.
• Limited Customization - Current solutions do not take in consideration the individual needs of
the rooms and occupants they manage. Different rooms can have different luminous and thermal
requirements.
• Expensive installation - One problem facing BAS is the cost of the devices and their installation.
Some require rewiring and dedicated conduits. Due to the large costs associated, the sensors and
actuators are usually installed in building zones rather than offices.
• Lack of security and access control - When we think of a personal office we assume it is always
safe, yet during the time we are away, the office may be entered by someone that should not have
access to it.
1.2 Proposed Solution
In this thesis, we preset a BASA (Building Automation and Security on Android) a system that uses
existing Android devices to provide a BAS capable of managing a room.
Our system is user aware and is capable of adjusting the lighting and HVAC systems in a energy
efficient way. At the same time it offers the user a If This Then That (IFTTT) system (trigger actions based
on events) including voice recognition, for a personalized smart office experience. Finally, it provides the
user with a security system. The Android camera is used to detect motion, when movement is detected
and no registered person is present in the room a notification is sent to the user and a 30 second video
is recorded to the cloud for latter viewing.
By using a tablet as a BAS we are able to reduce the monetary cost of our system in comparison to
traditional alternatives. The tablet offers several sensors, access to Wireless fidelity (WiFi) and Bluetooth
(BT) networks, microphone, sound speaker and a touch screen. We are able to leverage the tablet
sensors including illuminance, temperature and camera sensor for automation. If the tablet does not
have a temperature sensor it is possible to interact with external sensors to overcome the lack of the
sensor.
The below listed examples represent some automation actions possible with our IFTTT system that
contribute to decrease energy consumption and increase user comfort:
• If no user is present in the office then turn off the lights.
• If user arrives at building then set temperature to 24 oC (pre-heating).
2
• If user arrives at office then say ”Welcome back, I’m always happy to see you again.”.
• If lights are turned on and illuminance is above 120 lux then turn off the lights. (If there is sunshine
and the lights are on, we turn them off).
• If user says ”turn on lights”, then the lights turn on. (Example of voice recognition)
• If no user is present in office and motion is detected then say ”Hi! You are being recorded, smile!”.
The above examples are not hard-coded into the system. They are created by the user. This ability
offers great flexibility to our system to provide a personalized feel to the room.
The system is composed of two mobile applications (Hub and User apps) and other auxiliary devices
to interact with the existing lighting and HVAC systems. The Hub app manages the office and the User
app work provides user detection and allows the user to remotely control the office and security system.
To control the lights we used a already built solution, a smart light switch (25 euros), to interact with the
HVAC system we used a Arduino with built-in WiFi and relays.
Great care was taken developing the user app to make sure the application did not drain to much of
phone’s battery. While other applications that require user detection keep Central processing unit (CPU)
always running and background scan the environment, our approach is based in the phone’s events.
When the user connects to a WiFi network we start our user detection algorithm, if the user is not in the
building with the Hub, we stop the scanning.
The system implementation is open-source and allows home and office owners to use existing An-
droid phones or tablets to turn a regular room into a smart room. For a system capable of controlling
just the lights our solution works out of the box as long as the smart light switch is installed. To control
the HVAC system the user can either assemble an Arduino controller like our solution, or in the future it
is possible to code in support for other devices like thermostats with WiFi.
Our system can be seen as a framework that provides a modern User Interface (UI), a IFTTT and
security system. In the future other controllable devices, triggers and actions can be added to improve
the system.
We created our system with the following requirements in mind:
• Rapid deployment: The system must offer rapid setup and deployment of new Hub instances.
• Isolation: The control and automation of the offices must be independent and work regardless the
state of the rest of the system.
• Manual control: People expect to be some form of manual control over the room such a light
switch or thermostat, the system must provide a graphical interface embedded in the wall that
allows manual control of some basic services such as HVAC and lighting.
• Remote control: It should provide a authenticated user status and remote control over the room’s
services, by the use of an user app.
3
• Automation: The user should be able to create personalized tasks (turn on lights, turn off the
HVAC system) that are triggered by a single or multiple events (sensor reading, user location,
time).
• Load-aware: The system must be able to adjust services such as HVAC and lighting in a energy
efficient way.
• User aware: It must capable of detecting if the user is inside the building with a medium/low
accuracy and the user presence in the room with high accuracy.
• Motion aware: It must capable of detecting if someone enters the office. It must also provide the
means to define part of the room where motion must be ignored because of false positives. For
example a window with a view to the street by can be ignored.
• Cost: The hardware cost must be affordable for small/medium businesses for the Return on in-
vestment (ROI) savings not be too long.
• Usability: There should be a visual appealing UI, simple controls for lighting and heating functions.
1.3 Thesis Contribution
The following list presents the contributions of this thesis:
• Functional prototype - An Android based BAS, creating a proof of concept of integrating Android
devices as part of an automation system.
• Automation IFTTT system - Development of IFTTT system allowing the user to create personalize
trigger/action rules to improve user comfort and reduce wasted energy.
• User detection - Development of a user detection system capable of determining if the user is
inside a specific building and a specific room.
• Hardware Architecture - Design of the architecture with all the hardware components needed and
the network interfaces for communication.
• Software Architecture - Design of the applications to run on the target hardware, that offers manual
and remote control of the HVAC and lighting systems. As well as intrusion detection and notifica-
tion.
1.4 Outline
This document describes the research and work developed and it is organized as follows:
• Chapter 2 describes the previous work in the field.
• Chapter 3 describes the system requirements and the architecture of BASA.
4
• Chapter 4 describes the implementation of BASA and the technologies chosen.
• Chapter 5 describes the evaluation tests performed and the corresponding results.
• Chapter 6 summarizes the work developed and future work.
5
6
Chapter 2
Related Work
The following sections detail the main related work researched in this thesis. In Section 2.1 we explain
the most used Automation Communication Protocols. Section 2.2 showcases both popular commercial
home automation products, as well as academic automation solutions. Section 2.3 follows with a de-
scription of some general purpose communication technologies, these technologies are widely available
in mobile devices and as such play a important role. Finally, Section 2.4 presents commonly available
sensors and how they can be applied to building automation and user comfort.
2.1 Building Automation Protocols
Building automation systems are distributed control systems capable of monitoring and controlling a
multitude of individual systems in a building. Usually they are used to control a building’s HVAC, lighting,
security and access control system (SAC). The objectives of building automation are the reduction
in energy consumption, operating cost, improvement of occupant comfort, and efficient operation of
building systems.
2.1.1 Zigbee
ZigBee [3] is a short-range wireless communication protocol that uses a mesh-network in which the
nodes are able to self organize. This provides an efficient way to integrate a large number of wireless
devices in an automation scenario. ZigBee is a wireless personal area network (WPAN) and the devices
may operate in several frequency bands (868 MHz, 915 MHz and 2.4 GHz). ZigBee main target is
battery powered devices where low data rate, low cost and long battery life are the main requirements.
The ZigBee standard is developed by the ZigBee Alliance, a group of companies that maintains and
publishes the ZigBee standard.
The ZigBee standard has adopted Institute of Electrical and Electronics Engineers (IEEE) 802.15.4
as its Physical Layer (PHY) and media access control (MAC) protocols. Therefore, a ZigBee-compliant
device is compliant with the IEEE 802.15.4 standard as well.
7
ZigBee defines three device roles: the coordinator, the router and the ZigBee end device. The router
is a device capable of relaying messages. If a device is the principal controller of a personal area network
(PAN), it is called the coordinator. Finally, a ZigBee end device is a device that is neither a coordinator
nor a router, it is the most simple device and has the ability to sleep to conserve power.
Device networks must use one of two network topologies specified in IEEE 802.15.4: star and peer-
to-peer.
In a star topology, Figure 2.1, every device in the network can communicate only with the ZigBee
coordinator. The advantage of star topology is that it is simple and packets go through at most two hops
to reach their destination, the disadvantage is the coordinator can become a bottleneck.
In a peer-to-peer topology, Figure 2.2, each device can communicate directly with each other if
the devices are close enough to establish a link. In a peer-to-peer network, only the coordinator or
router devices can relay the messages. However a ZigBee end device can be part of the network and
communicate with one device (a coordinator or router) in the network. This topology allows for greater
range as packets can be routed across multiple routers.
Figure 2.1: A Star Network Topology
Figure 2.2: A Mesh Networking Topology
Table 2.1: Comparing ZigBee with Bluetooth and 802.11b
8
Table 2.1 compares BT, 802.11b (WiFi) and ZigBee. ZigBee [4] offers lower power consumption,
less complexity and lower cost at the expense of less data rate.
Several attempts have been made to bring the power of zigbee to mobile terminals such as Android
phones/tablets. In one example a Nokia phone running Symbian OS had a SD card with a zigbee radio
attached, yet this approach only works for some models of phones since a side slot for a SD card is
needed [5]. In another project an Android phone communicated wirelessly with a computer (acting as a
server) connected to a xbee module capable of communication with ZigBee devices or arduino boards
with xbee modules [6].
Commercially, Gateways1,2,3 are used to communicate with ZigBee devices from a non ZigBee de-
vice, for instance an Android mobile device could interact with a ZigBee device by communicating with a
ZigBee Wifi Gateway, the gateway would then relay the Android device messages to the ZigBee device.
2.1.2 BACnet
BACnet (Building Automation and Control Network) [7, 8, 9, 10] is a standardized data communication
protocol, evolved from the need for a standardized data communication protocol that would enable the
various automation and control components in a building to communicate with each other, ensuring
interoperability and manufacturer independence.
BACnet has a simple four layer architecture aimed to ensure the low cost development and production
of BACnet devices. The Physical layer enables BAC devices to connect and transmit data. The data
link focuses on point-to-point connections between two devices in a single network, organizes data into
frames (or packets), regulates access to the medium, provides addressing, and handles some error
recovery and flow control. The network layer allows two or more subnets connected by a router using
different data link layer options to communicate with each other, the focus of this layer is end-to-end
connections across multiple networks. The BACnet standard is designed to connect devices only in one
logical pathway, which simplifies the routing process in comparison to the Internet partial mesh topology,
with multiple alternative paths.
BACnet data can be transmitted across several different types of networks, it provides four Local Area
Network (LAN) technology options, one WPAN technology and one point-to-point protocol. The ones
standardized were: Master-Slave/Token-Passing (MS/TP); Point-to-Point (PTP); Ethernet; ARCNET;
LonTalk and ZigBee.
The PTP protocol is the only non LAN solution available in BACnet. It provides the means by which
two remote devices can communicate directly with each other through a EIA-232 interface. The typical
scenario could be to connect a dial-up modem to a remote building automation system.
The first LAN alternative, MS/TP, is a simple protocol based on the use of EIA-485 (Electronic In-
dustries Association) physical layer standard, suited for smaller control and operating units that do not
require a fast transfer rate. An MS/TP network uses shielded twisted-pair cable as transmission medium.
1http://www.telegesis.com/products/zigbee-gateway-consumer-access-device/2XBEE ZIGBEE GATEWAY3Rainforest EAGLE Ethernet ZigBee Gateway
9
The second alternative is Ethernet4 (ISO 8802-3), the highest performance LAN option. Nowadays
office and industrial building are generally interconnected using Ethernet so it makes sense it would
be used in building automation. Ethernet systems divide the stream data in small frames, each frame
contains a source and destination address, as well as error-checking data.
The third option, ARCNET5, is also LAN communication protocol. It became the American standard
(ATA/ANSI 878.1). Unlike Ethernet, however, ARCNET is deterministic which means we know the time it
takes for the packet to arrive at its destination, which makes it good for use in industrial communications.
The fourth LAN protocol option in BACnet is LongTalk, it is a proprietary protocol developed by Eche-
lon Corporation. LonTalk can be used in multiple different mediums by selecting appropriate compatible
transceivers. The LonTalk protocol is low-cost, low-speed and has a limited message size of 128 octets.
The final protocol is ZigBee a WPAN protocol, described previously in section 2.1.1. After a joint effort
by ZigBee and BACnet communities they aligned the two specifications[11] so that compliant products
can be designed that benefit from ZigBee’s low-power, mesh wireless networking technology as well as
BACnet’s BAS data model and communications protocol.
BACnet uses ’objects’ to provide a standard way of representing the functions of any device, each
of which has a set of properties that characterize it. There are 25 standard object types. A device does
not need to support all object types. BACnet defines 40 message types (services), that are divided into
six categories: Object Access, File Access, Alarm and Event, Remote Device Management and Virtual
Terminal.
2.1.3 LonWorks
LonWorks [10, 7] is a networking solution for building automation and control networks. It is a proprietary
solution developed by the American company Echelon. It can operate in both as a centralized building
controller as well as in decentralized building control components. LonWorks uses the LonTalk protocol
which is a layered, packet-based, peer-to-peer communications protocol. LonTalk was designed to
support many communication media and wiring topologies. Transmission media include twisted-pair,
coaxial, and fiber-optic cable as well as radio systems that allow scalable transmissions speeds of up to
1.25 Mbit/s.
Figure 2.3 describes the LonTalk protocol architecture that uses the OSI Stack. The Physical Layer
uses the above mentioned transmission media. The layers between the Data Link Layer and Presenta-
tion Layer are implemented using a Neuron chip.
Packets are routed using an routing algorithm. They can be addressed to a single device, to any
group of devices, or to all devices. To support networks from two devices to tens of thousands of
devices the following types of addresses were defined:
• Physical address: Every LonWorks device includes a unique never changing 48-bit identifier called
the Neuron ID.
4https://en.wikipedia.org/wiki/Ethernet, last accessed on January 6th, 20165https://en.wikipedia.org/wiki/ARCNET, last accessed on January 6th, 2016
10
• Device address: A LonWorks device is assigned a device address when it is installed into a par-
ticular network. Device addresses are used instead of physical addresses because they support
more efficient routing of messages, and they simplify replace failed devices.
• Group address: A group is a logical collection of devices within a domain. Unlike a subnet, devices
are grouped together without regard for their physical location in the domain.
• Broadcast address: A broadcast address identifies all devices with a subnet, or all devices within
a domain.
LonWorks offers three basic types of message delivery service and also supports authenticated
messages. These message delivery services (listed below) allow trade-offs between reliability, efficiency
and security:
• Acknowledged messaging provides end-to-end guaranteed delivery. If acknowledgments are not
received, the sender attempts the transaction again.
• Repeated messaging causes a message to be sent to a device or group of any number of devices
multiple times, without waiting for acknowledgments.
• Unacknowledged messaging send the message only once and does not expect a response.
• Authenticated service allows the receivers of a message to determine if the sender is authorized
to send that message. This is implemented by distributing 48-bit keys to the devices at installation
time.
Figure 2.3: LonTalk protocol architecture
2.1.4 Z-Wave
Z-wave [12][13] is a proprietary wireless communication protocol, it allows interoperability between dif-
ferent manufacturers products. It is designed for control, monitoring and status reading application in
11
residential and commercial environments. Z-wave uses low powered RF communications technology
operating in the sub-1GHz band that supports mesh networks without the need for a coordinator node.
Regarding data rates z-wave supports up to 100kbps, with AES128 encryption, IPV6 and multi-channel
operation.
The Z-wav mesh enables any node to talk to other adjacent nodes directly or indirectly through avail-
able relays. If two nodes that want to communicate aren’t within range, information can be exchanged
with another node that both can access. The maximum number of hops supported is 4. Without any
obstacles such as walls the range between two Z-Wave products is about 40 meters, this means the
maximum range with 4 hops is roughly 200 meters.
Primarily focused on monitoring and control functions in the home and commercial facilities. Some
solutions include lighting control, security, climate control, smoke detectors, door locks, security sensors,
appliances, and remote controls.
2.1.5 Summary
The examined BAS were designed with low power consumption in mind.
Platforms such as BAcNet and LonWorks require specialized professionals as well as personalized
software and/or hardware to be configured. These solution present high installation costs. Newer so-
lutions such as ZigBee and Z-Wave are present in many products and offer reduced installation and
remodeling costs: various third-party vendors offer real time analysis and controls of these systems.
One of the major problems with both ZigBee and Z-Wave is the lack of HVAC products compatible with
both standards, this means we probably won’t use these standards to control an available HVAC system.
2.2 Home Automation Systems
Home Automation is the Building Automation equivalent for the residential house.
The popularity of home automation has been increasing in recent years due to higher affordability
and simplicity. Home automation may include centralized control of lighting, HVAC, appliances, security
locks of gates and doors and other systems. Vendor solutions often rely in wireless technologies to
connect the various devices, thus eliminating the need to rewire the house.
2.2.1 Commercial Home/Office Automation Products
2.2.1.1 Philips hue
The Philips hue6 is a wireless lighting system developed by Philips7. It is based on ZigBee LightLink[14],
a low-power technology to control lights.
6www2.meethue.com, last accessed on January 6th, 20167www.philips.com
12
Figure 2.4 illustrates the a Philips Hue kit with light bulbs and Hue bridge controller. This system
is quite simple, you replace existing lights with Hue light bulbs and use a device called Hue bridge to
communicate with the lights using a mobile application.
One problem with these lights is the user cannot use a regular light switch to switch them off. By
doing that the lights become disabled, the user won’t be able to use the mobile application to turned
them back on, requiring the user to flip the light switch back up. We can’t use Philips hue lights in our
system since the lights available to us are long tube Fluorescent bulbs and there are no compatible lights
of this kind available.
Figure 2.4: Philips Hue White E 26 starter kit
2.2.1.2 WINK HUB
Wink Hub is a home automation product developed by Wink8, it provides a unified automation platform
capable of working with several different communication protocols: WiFi, BT, Z-Wave, ZigBee, Lutron
ClearConnect, and Kidde’s RF-equipped devices. As in other home automation solutions, the Wink Hub
acts as a central controller being able to interact with the home devices, as well as users mobile apps.
2.2.1.3 SmartThings
Samsung offers a set of wireless SmartThings9 sensors and power outlet, they integrate with the Smart-
Things Hub to create a smart house.
SmartThings Hub is compatible with Z-Wave, Zigbee, and WiFi radios. It can process video from
compatible security cameras and can see live and recorded video from within the app. Moreover, you
can have a connected camera begin recording when triggered by other SmartThings devices, such as a
motion detector or a window sensor.
Sensors such as the Multi sensor can monitor whether doors, windows, cabinets or the garage door
are open. Other devices like the Power Outlet can control lights, electronics and small appliances, they
can even follow a schedule.
8www.wink.com/9https://www.smartthings.com/
13
2.2.1.4 Nest thermostat
The Nest10 Learning Thermostat, shown in Figure 2.5, is an electronic, programmable, and self-learning
WiFi thermostat. It uses machine learning algorithm to optimize heating and cooling of homes. For the
first weeks users have to regulate the thermostat in order to provide the reference data set. Nest can
then learn people’s schedule, at which temperature they are used to and when.
The Nest Thermostat can be remotely controlled using a developer application programming inter-
face (API), this means we can use this thermostat to control a room HVAC system. The negative point
to use Nest is the high cost of around 250 euros making it unsuitable for our system since low cost is a
requirement.
Figure 2.5: Nest Learning Thermostat
2.2.1.5 Amazon Echo
Amazon Echo11 is a smart speaker developed by Amazon12. The device is capable of voice interaction,
music playback, making to-do lists, setting alarms, streaming podcasts, playing audiobooks, and provid-
ing weather, traffic and other real time information. It can also control several smart devices using itself
as a home automation hub.
The main characteristic of Echo is it’s voice interaction capability, our system could benefit of such
functionality in order to increase user comfort by allowing voice command to be issued.
2.2.1.6 IFTTT
IFTTT13 is a free web-based service that allows users to create simple conditional statements, called
”recipes”, which are triggered based on changes to other web services such as Weather channel, Face-
book, Gmail, Amazon Echo and Nest thermostat.
This service allows the user to automate their Philips Hue lights, Nest thermostat, Samsung Smart-
Things and many other services.10https://nest.com/11https://www.amazon.com/Amazon-Echo-Bluetooth-Speaker-with-WiFi-Alexa/dp/B00X4WHP5E, accessed 10/10/201612https://www.amazon.com/13https://ifttt.com/
14
We discuss this service because we believe our system can benefit of a similar service, to allow
users to create automation recipes.
2.2.2 Academic Automation Systems
Several academic home/office automation prototypes have been proposed over the years.
Kim Baraka and his co-authors proposed a home automation solution whose goal is not only to allow
a user to control a house through a Android app but also to diminish the house energetic cost with the
use a a scheduling algorithm [15] to execute tasks. This prototype uses a Arduino Mega board acting
as the central controller, the board is fitted with a Ethernet shield and a xbee module (wireless commu-
nication based on ZigBee protocol) that enable communication with the Android phone and other xbee
devices in the home network. The Arduino board has the capability to schedule a list of task to ensure
the total power used is not over a certain limit and that certain tasks are only scheduled when the energy
price is cheaper, taking in account different day night power cost tariffs.
This thesis was inspired by previous work done at IST Taguspark: Personal Office Management and
Automation System (PerOMAS) [16]. The proposed system consists of three main components: the
Assistant, the Gateway and the Core. The Assistant is present in every room and enables the occupant
to take several actions that impact the room itself (lights, heating and cooling), the Gateways job is to
collect data from the Assistants and take actions based on the collected data, e.g. controlling the lights
of an hallway, turning them off if all the rooms in the hallway are empty, finally the Core is at the top of
the hierarchy, its job can be to collect statistical data or perform action such as control a central boiler.
Hardware wise these components were built using a Raspberry Pi Model B and several peripherals
components such as LCD screen, temperature, humidity, luminosity sensors.
Shiu Kumar proposed the use of a Arduino board with a Ethernet shield to provide connectivity to a
Android app that enables the user to control a set of lights and electric devices (Air conditioner and
fan)[17]. The system is connected to several external sensors: temperature, smoke gas Sensor, passive
infrared motion sensor that provides temperature monitoring, smoke detection and intrusion detection.
In the mobile app, besides manual buttons to turn on devices there is also voice activation support for
switching functions. In the eventuality of fire or intrusion, email notification is sent to the user.
2.2.3 Summary
The above commercial solutions provide high automation with high cost. Most home automation solution
offer few supported standards. Most products specialize in lighting solutions but also add wireless video
cameras, smoke detector and a few other devices.
In regards to the academic automation systems they focus more in energy saving solutions, Kim
Baraka and his co-authors[15] focused in a proposed task scheduling algorithm that only provides mon-
etary savings in the presence of different day night power cost tariffs. It did provide one energy saving
15
proposal: turning lights off when luminosity exceeds a threshold.
PerOMAS[16] provides important energy saving solutions such as: turning off the lights/HVAC if
no occupant is detected, automatic HVAC on occupant presence and custom temperature values for
different occupants. There is still room for improvement, one of the major problems faced is occupant
detection. In the designed solution the BT of occupants phones is used to detect room occupation. Most
people don’t keep their Bluetooth turned on, or in discoverable mode. A system should not depend on
the possible existence of BT to detect the room occupation.
The system proposed by [17] focuses in controlling and monitoring the home. The notification system
allows the user to be notified in the presence of an intrusion or fire detection. No energy savings are
achieved and no real increases in occupant comfort are present.
2.3 General Purpose, Wireless Communication protocols
Wireless communication allows the transmission of information over a distance without help of wires,
cables or any other forms of electrical conductors. This freedom to connect devices without any physical
connection has sparked the interest of the BA industry and standards development organizations, due to
its flexibility in adding devices to the network and reduced installation costs. The technologies focused
on below are the most used and available wireless technologies whose purpose is not just Building
Automation, as seen in Z-Wave and ZigBee (2.1.4 and 2.1.1 respectively) both of which are wireless
technologies.
2.3.1 Wireless Communications
2.3.1.1 Bluetooth (BT)
BT is a wireless communication technology standard, IEEE 802.15.1, [18, 19, 20], designed to exchange
data over short distances between fixed and mobile devices and build WPAN. Originally developed by
Ericsson 14 in 1994, it was created as an open standard to allow connectivity and collaboration between
disparate products and industries.
BT runs in the 2.4 GHz Industrial, Scientific and Medical (ISM) band. BT employs frequency hopping
techniques with the carrier modulated using one of three available modulations: Gaussian Frequency
Shift Keying (GFSK), Differential Quadrature Phase Shift Keying (DQPSK) or differential phase-shift
keying (8DPSK). The 8DPSK modulation scheme offers the highest bit rate possible of 3 Mbit/s. Many
devices use the ISM band from microwave ovens to WiFi. To avoid interference BT uses hopping carrier.
A Bluetooth transmission only remains on one of its 79 channels for a short time, and if any interference
is present the data will be re-sent later when the signal has changed to a different channel which is likely
to be clear of other interfering signals.
Bluetooth operates based on a Master-Slave structure, where a master can communicate with up to
seven slaves. All devices are synchronized with the master’s clock and the slaves can only exchange
14http://www.ericsson.com/
16
data with the master.
The range of BT varies depending on the device power-class, higher power radios offer higher range.
Figure 2.2 describes the existing classes, Class 3 radios have a range of up to 1 meter, Class 2, found
in mobile devices, 10 meters, and Class 1, primarily for industrial use cases, 100 meters.
Bluetooth Low Energy (BLE), is low-power variation of the original Bluetooth standard and was intro-
duced as part of the Bluetooth 4.0 core specification. The main difference to traditional Bluetooth is
Bluetooth 4.0’s low power consumption. This enables applications to run on a small battery for four to
five years. BLE devices still manage to transmit data at a reasonable rate of 1Mbit/s their focus in low
power consumption, making then attractive to the Building Automation industry.
BLE devices have a maximum range of 50 meters, the range can be increased by means of creating
a mesh network of devices, to extend the range of BLE devices.
Table 2.2: Available BT classes
2.3.1.2 Wireless fidelity (WiFi)
WiFi is a wireless local area network (WLAN) based on the IEEE 802.11 standards [21, 22, 23]. It
operates in the 2.4 and 5 Ghz frequency bands and uses CSMA/CA to control the medium access,
offering data rates of up to 1.3 Gbp/s with the new IEEE 802.11ac revision. To establish a network, one
device called station (STA) connects to another device called an Access Point (AP). An example for STA
could be a mobile device with WiFi capability and the AP the router that usually delivers internet to the
mobile device. STAs associate and authenticate with the AP to get access to the network, forming a star
topology. This topology is called an infrastructure Basic Service Set (BSS).
WiFi offer high-throughput at the cost of greater power consumption. Depending on the 802.11
protocol the maximum range in a indoor environment is between 35 (IEEE 802.11a, 802.11b, 802.11g,
802.11ac) to 70 meters (IEEE 802.11n).
WiFi Direct [24, 25], is a WiFi standard that allows devices to connect with each other without requiring
a wireless access point . Unlike conventional WiFi, which is primarily used for getting online, WiFi Direct
is intended for sharing media across platforms.
InWiFi Direct the roles of AP and clients are dynamic, the device implementing AP-like functionality
in the Peer-to-peer (P2P) Group is referred to as the P2P Group Owner (P2P GO), and devices acting
as clients are known as P2P Clients. When two P2P devices discover each other they negotiate their
17
roles (P2P Client and P2P GO) to establish a P2P Group. Once the P2P Group is established, other
P2P Clients can join the group as in a traditional WiFi network.
2.3.1.3 IEEE 802.15.4
IEEE 802.15.4 standard[3] specifies the physical layer and media access control for low-cost and low-
rate wireless personal area network (LR-WPAN). There are three frequency bands in the latest version
of IEEE 802.15.4: the 868 MHz band is used in Europe, the 915 MHz band is mainly in North America,
whereas the 2.4 GHz band is used worldwide.
Figure 2.6, details the ways these three frequency bands are used in the IEEE 802.15.4 standard.
The mandatory 868/915 MHz bands offer very low data rates (20 Kbps and 40 Kbps, respectively). In
2006 two optional PHY modes were introduced they achieve the 250 Kbps data rate at the 868/915
MHz bands. Devices typical range is 10m, although a larger range is possible thanks to peer-to-peer
networks between devices.
There are two types of devices in an IEEE 802.15.4 wireless network: full-function device (FFD)
and reduced-function device (RFD). An FFD device can take three different roles: coordinator, PAN
coordinator, and device. A coordinator is an FFD device that is capable of relaying messages. A PAN
coordinator is the principal controller of a personal area network (PAN). If a device is not acting as a
coordinator, it is called a device .
An FFD is capable of performing any role in the network. An RFD has limited capabilities. FFD
devices can communicate with any other device in a network, but an RFD can talk only with an FFD
device.
IEEE 802.15.4 defines four MAC frame structures: data, acknowledgment, beacon and MAC com-
mand frames.
The beacon frame is used to synchronize the clock of all the devices within the same network. The
data and acknowledgment frames are used to transmit data and accordingly acknowledge the successful
reception of a frame. The MAC commands such as requesting association or disassociation with a
network are transmitted using a MAC command frame.
Figure 2.6: IEEE 802.15.4 Data Rates and Frequencies of Operation
18
2.3.2 Summary
The examined wireless technologies offer alternatives to the ZigBee and Z-Wave presented previously,
technologies like BT and especially acWiFi are used today for a variety of different ends, making both
technologies accessible to most consumers.
Technologies such as WiFi offer greater data transfer rates at the expense of greater power con-
sumption: WiFi can be used in BA if energy consumption costs aren’t the major concern. Bluetooth Low
Energy is a efficient wireless communication technology. Some lighting products are starting to take
advantage of this technology commonly found in smartphones.
IEEE 802.15.4 based protocols offer low power wireless communications very attractive to BAS,
however the lack compatible smartphone devices able to directly communicate using 802.15.4 create
the necessity of using gateways to be able to communicate with such devices.
2.4 Sensors and their application in Automation Systems
Sensors such as temperature or motion detection sensors provide information to Automation Systems,
allowing them to respond to changes in the environment in which they are deployed. For instance a
temperature sensor inside a room is able to relay the room temperature to the Automation System,
which depending on the temperature values may turn on or off an air or heating unit to make the room
more comfortable to the user. Other sensors such as an ambient light sensor, can be used to save
energy, for instance in a very bright day if no one is present in the room the blinds can be closed to
prevent extra light from heating the room, this keeps the room colder and when the occupant arrives the
room would be more comfortable, perhaps there would be no need to use a cooling unit saving in power
costs.
2.4.1 Sensors available in Android tablet/phone devices
Sensor data is important for an Automation System as seen in the above examples. Regarding to
this thesis main objective, the use of an Android device such as a tablet to act an a Building Automation
Component, the following paragraphs provide a description of the sensors available in an Android mobile
device [26] and how we can leverage these sensors in order to build our automation system.
Light Sensor, measures the ambient light level;
Pressure Sensor, measures the ambient air pressure in hPa or mbar;
Proximity Sensor, measures the proximity of an object in cm relative to the view screen of a device;
Ambient Temperature Sensor, measures the ambient room temperature in degrees Celsius ( C);
Magnetic Field Sensor, measures the ambient geomagnetic field;
Relative Humidity Sensor, measures the relative ambient humidity in percent.
Besides the above sensors there are a few other, described in the Android developer page[26] but
they provide data relative to the device itself such as rotation or accelerometer and at the moment we
don’t see how to take advantage of those sensors since the device will be stationary.
19
Furthermore an Android tablet/phone provides a camera, microphone and speakers. These will also
be leveraged in our automation system.
2.4.2 Sensor application in Automation Systems
2.4.2.1 Occupancy Detection
Human behavior influences the amount of energy a building requires. Depending on the occupant
behavior, the building’s energy cost can increase or decrease by one-third of its design performance [2].
By knowing and tracking when a room is occupied, we can provide the system with relevant information
that in turn my help in taking important actions such as switching off the lights if no one is present.
There are several different methods to determine if a person is in the room, they range from Radio
Frequency Identification (RFID), Passive Infrared (PIR), Vision-based, WiFi and Bluetooth, among other
[27].
Yuvraj Agarwal and his co-authors proposed using a mixture of PIR sensor and a simple magnetic
contact switch to track when the door opens and closes, this solution provides better result in regard to
a PIR only solution[28].
Using WiFi it is possible to estimate the number of occupants in the area. Occupants usually have
mobile devices connected to the building’s WiFi, by knowing the devices currently connected to the AP it
is possible to estimate their relative location. Furthermore since it does not require additional equipment,
it is an economic solution. Sentinel uses a Remote Authentication Dial In User Service (RADIUS) server
to provide centralized Authentication, Authorization, and Accounting [29]. By using the logs provided by
RADIUS the solution Sentinel is able to keep records on the occupancy of an area. Besides the WiFi
solution presented before one other alternative could be to use the Received Signal Strength (RSS) to
determine the physical location of the mobile device[30]. This approach would require someone to go
around the building mapping the signal strength in various points.
A camera and image analysis software are able to identify movement between video frames. Noise
detection could also provide valuable input to determine occupation, yet it is less reliable as external
sounds could induce false positive occupant detection.
2.4.2.2 Auto Dimming light
Some of the light bulbs available in the market can have built-in or external dimming. These lights have
the ability to lower their light intensity and save energy. By using an Light Sensor to measure the light
level of a room and dimming lights it is possible to achieve saving in light energy, a study [31] showed
saving of 10-20% compared to full lighting by using dimming lights with a restriction that ensured the
dimming could not go below 50%. Saving could go up 16-32% had the dimming to zero been allowed.
20
2.4.2.3 Adaptive Heating/Cooling
Several studies show room temperature could influence productivity, Olli Seppanen and his co-authors[32]
developed an initial quantitative relationship between work performance and temperatures within and
above the comfort zone. Data collected from nine previous studies show the range of temperature in
which people are most productive is between 22C and 25 C. For temperatures between 25 C and 33
C they developed a model to measure the relationship between decrement in productivity P in % and
temperature T in C:
P (%) = [2 x (T, C)] - 50
According with the American Society of Heating, Refrigerating, and Air Conditioning Engineers (ASHRAE),
building occupant temperature comfort can be achieved for at least 80% of occupants[33] by following
the temperature range and humidity described in table 2.7.
By using a temperature sensor within the room, the HVAC can be custom suited to the room itself. As
different rooms within the same building have different temperature operation needs. If a building HVAC
is turned on across the entire building uniformly, having the same temperature no matter the actual
needs of the rooms and their occupants, there could be eventual comfort problems and excessive power
consumption. A room with bright sun light can have a higher temperature than the room next to it without
a window. Taking advantage of the fact that not all rooms have the same temperature requirements it
is possible to save energy by only using the HVAC to keep the temperature within the room to human
comfort levels or by not using ventilation if no occupant is present in the room and he is not expected to
return soon.
Figure 2.7: Temperature / Humidity Ranges for Comfort
2.4.2.4 Monitoring/Security Systems
The sense of security is important. By knowing our home or private work space is being monitored while
we are not present we have one less stress factor to worry about. In office buildings there are systems
with a camera always recording (CCTV)[10] and a human monitoring the video stream. There are also
other solutions that integrate sensor as well as image processing algorithms[34] to detect motion in
video frames and warn the owner without the need of human monitoring.
21
2.4.3 Summary
Sensors can have important contributes to BAS. The above sensor applications can provide higher
comfort to the occupants of the building as well as save on energy costs. Comfort can be improved
by regulating the building temperature to maximize occupant productivity while at the same time only
spending energy when required. Energy costs have a direct relation with occupant behavior: a neglectful
occupant will leave the lights on for extensive periods of time even though he is not present. Occupant
detection can help save energy costs by switching off lights and devices when they are not needed
anymore and energy savings can also be archived by dimming the light intensity when possible.
An Android tablet/phone provides a good hardware device for use in building automation. It already
has several embedded sensors and thanks to it’s supported Wireless communication protocols (WiFi,
BT), it can connect to other devices with sensors without the need to attach wires to add more sensors.
These wireless communication technologies allow the an Android based BAS to control or be con-
trolled by WiFi and BT.
Figure 2.8 shows some sensors that can contribute to BAS and the prices of those sensors or which
of them are already embedded in Android devices. The prices were retrieved from sparkfun15 a popular
store that sells microcontroller and all kinds of electronics. When more that one sensor model existed
the cheapest one option was chosen.
The price of the set of sensors excluding the temperature & Humidity, Carbon Monoxide, Accelerom-
eter, Gyroscope, Fingerprint, was 139.2 euros. If we take in account that only the Carbon Monoxide
sensor is not present in any Android device(high end Android Tablets have the other sensors) then
the total price of a system with these sensors is 211.91 euros, this price does not take in account the
microcontroller needed to connect all these sensors neither all the wiring and capacitors and electric
resistance required.
Nowadays cheaper Android devices under the 100 euro range are commonly found in stores. For
the price of 139.2 euros described before we can buy an Android tablet and thanks to an Android app
be able to leverage these sensors to improve building automation.
15www.sparkfun.com
22
Figure 2.8: Android embedded sensors Vs Sensors for Arduino or Raspberry pi
23
Chapter 3
Architecture
This section describes the architecture of BASA, a platform for office automation and security designed
to offer greater comfort to the occupants, reduce the energy use with minimum intervention and perform
intrusion detection.
This section is divided in three subsections: Section 3.1 starts by presenting the overview of the
system. In Section 3.2 we present the hardware architecture. Finally, Section 3.3provides an overview
of the software architecture.
3.1 Architecture Overview
The proposed system consists of two mobile applications, one is the Hub app that runs in a tablet
mounted in a wall in the room (could also run in a smartphone but tablets have bigger screens), the
other is the User app that the occupant of the room can install on his personal smartphone to remotely
control the Hub, perform user detection and access video monitoring of the room. The Hub is responsible
for the room automation and security systems, collection of sensor data and providing the graphical user
interface (GUI) for manual control over the room services.
As represented in Figure 3.1, every Hub is able to work without the presence of any User App. The
User App is able to interact with several different Hubs.
Figure 3.2, describes a top view of the system. In the next sections, we will detail the two main
components of the system.
HUB
USER APP
1..n 0..n
Figure 3.1: Architecture of the system
24
Hub(tablet)
User(phone)
Beacon
WiFi
BLE signal
Lighting SystemController
HVAC systemcontroller
WiFi
Wireless AP
Office location detection Building locationdetection
WiFi
Figure 3.2: Overview architecture of the system
3.1.1 User App
The User app runs in the user’s mobile device and offers remote control of the lighting, HVAC and
security systems provided by the Hub. Besides improving user comfort by allowing remote access to
the Hub, the user app also helps the Hub with user detection, allowing the system to know when an
authorized user is inside the building or room.
3.1.2 Hub App
The Hub app is responsible for controlling the HVAC and lighting systems in the office, enforcing energy
saving policies, improving occupant comfort and providing security monitoring when the user is away
from the office.
The main visual features of the Hub application are: a simple GUI to control the lights and heat-
ing/cooling system, an IFTTT automation system that allows the user to create personalize trigger/actions
rules. In the background it also provides motion detection and video recording for occasions when the
user left the room but movement is detected.
3.2 Hardware Architecture
To achieve building automation, our solutions requires a tablet to act as a central control unit, a beacon
device used for user detection inside the room and two other devices capable of interacting with the
25
lighting and HVAC systems.
The tablet is where the Hub app is executed. It provides the sensors, the connectivity, the storage as
well as a camera, microphone, speaker and a touch screen.
The beacon is used for user detection, this will be explained latter in Section 3.3.
To control the lighting and HVAC systems we require devices capable of interacting with existing
systems that offer a way to remotely control these existing systems. These devices can be for example
microcontrollers. A microcontroller allows the digital world to interact with the real world through the use
of actuators that convert electric signal into mechanical actions. The microcontroller is connected to the
actuators (relay) and is able to switch on/off the lights as well as controlling the HVAC. This component
is needed because typically, lighting and HVAC systems do not have any type of connectivity other than
the electric wires.
If the room had wireless devices that communicate with technologies such as ZigBee or Z-Wave
installed, then the microcontroller could be connected to a radio module able to communicate with those
wireless technologies such as a xbee module.
Figure 3.3, represents a Hub, its components and the main communication protocols used.
3.2.1 Communication Protocols
The system requires that the Hub and User App, are able to communicate with each other. They will
use WiFi to communicate data at high data rate. The Hub can also use BLE to get additional sensor
data from external sensors. Likewise the User App can use BLE to determine if it is close to a beacon.
The communication between the Android tablet and the microcontroller is done using an WiFi network.
Finally the communication among the microcontroller and the actuators is done by using the General
Purpose Input/Output (GPIO) pins.
Microcontroller Board
Android Tablet
RAMCPU
STORAGE
Sensors
Temperature
Luminosity
Proximity
GPIOWi-Fi
Connectivity
Wi-Fi
BT
Display Camera
Microphone
Speakers
External sensors
Actuators
…Relay 1 Relay n
BT
WLAN
Wi-Fi
Wi-Fi
Figure 3.3: Hardware architecture of the Hub
26
3.3 Software Architecture
In this section we present the software architecture for the mobile apps and explain some of the core
functionalities of our solution.
To achieve building automation we propose a IFTTT system. The user is able to create personal-
ized chains of conditional statements, called ”recipes”, they are triggered based on events relevant to
the office. With this system we could turn on the lights automatically when the user enters the room or
shut them down when he leaves.
One of the goals of our solution is user detection, in order to accomplish this, we can leverage two
different types of location systems: WiFi and BLE beacon location. The location detection is handled
by the user app. We use the building’s WiFi network to determine if the user is inside the building by
comparing the MAC address of available APs to a set of known addresses. The other location system
we can use is beacon location. There can be a beacon emitting BLE signals and when this signal is
detected, we know the user is near the beacon source (the office).
Regarding office security, we propose using the tablet’s camera and analyzing the consecutive
frames for changes. When no user is present in the room and a large enough number of pixels are
different, we assume movement has occurred. We can then notify the user that someone is inside the
room.
3.3.1 Hub App Architecture
This section presents the software of the HUB. This is comprised of several managers. Figure 3.4,
represents the architecture of the Hub App.
3.3.1.1 User Interface
This is the interface seen in the Hub screen, it will offer:
• Manual control of the lighting and HVAC systems.
• User registration.
• Creation of automation rules.
• Real-time ambient sensors readings.
• Security settings, enable/disable security monitoring and notification email.
• General settings, activate voice control, allow sound.
3.3.1.2 Communication Layer
The Hub app implements a web server offering an representational state transfer (REST) API that the
user app can use to interact with.
27
The JavaScript Object Notation (JSON) standard is used as the message format. This also means
that in the future our system could communicate and be controlled by other devices using the API.
3.3.1.3 Event Manager
The Event Manager offers publish/subscribe service. It allows other managers to register their interest
in certain events and when those happen they are notified. There can exist several different types of
events: temperature reading, motion detected, user detection, etc.
The Event Manager is also responsible for the automation logic by enforcing the IFTTT rules. The
Automation Manager will check if the condition for the rule has been satisfied and trigger the action.
Finally it also has a scheduler responsible for executing repetitive tasks at regular time intervals or at
fixed moments.
3.3.1.4 User Manager
The User Manager handles user registration, authentication and detection. It tracks the whereabouts of
the user inside the building, in association with the User app so that, it is notified when the user enters
the building or office.
3.3.1.5 Sensor Manager
Sensor Manager allows access to the tablet’s sensors as well as the external sensors. It abstracts
external sensors into virtual sensors. It is responsible for a virtual motion detection sensor, by using the
camera to detect changes that would indicate motion, as well as other data such as the opening and
closing of the door.
3.3.1.6 Lighting Manager
This manager is responsible for managing the lighting system. It communicates with the lightning con-
troller (microcontroller) and synchronizes the lights state with the UI and vice versa.
3.3.1.7 Temperature Manager
The Temperature Manager periodically reads the room temperature and is able to communicate with the
HVAC controller (microcontroller) to turn on/off the system when required.
3.3.2 User App Architecture
The User App is simpler than the Hub App, the app is divided in UI screens. There are no managers like
the Hub architecture, the business logic is handled by each screen separately.
The main screens are the home, lighting, temperature, security and registration screens.
Since the user app can control several Hub apps, we require a simple registration process to add the
user to the Hub. We propose showing a QR-Code in the Hub registration screen, this code possesses
28
User Interface
User managerSensor Manager
EventManager
LightingManager
TemperatureManager
Web ServerCommunication layer
Figure 3.4: Hub APP architecture
the Internet Protocol (IP) address for the Hub and a temporary token used for registration. The user app
can use the phone camera to scan the QR-Code and automatically register the user in the Hub. Then a
virtual representation of the Hub is shown in the home screen.
For user detection to work when the app is not being used, we use a background service to monitor
the WiFi and beacons nearby the phone. The interval between scans are one every five seconds for
BLE scans and one minute for WiFi, these values are adequate times between scans to conservative
regarding the user’s mobile device battery.
29
Chapter 4
Implementation
This chapter addresses the main decisions taken in order to implement the hardware and software
architectures presented in Chapter 3.
4.1 Hardware Architecture
The next sections provide the implementation choices for the hardware architecture. As shown in Fig-
ure 4.1 we require tablet to run the Hub app, an optional user phone with a User app installed, a device
to control the HVAC system (two supported Arduino HVAC or PerOMAS) , a Edup smart light switch
to control the lights. We also need a BLE beacon for user detection inside a room and require the
building’s WiFi network for user detection inside the building. To allow communication between different
components in the system we use the building’s WiFi network for local communication and use Firebase
servers to allow external access from outside the building’s network.
4.1.1 Tablet
A tablet capable of supporting a range of communication protocols and with some embedded sensors
must be chosen as the base for the solution.
Several tablets were taken in consideration, the decisive factors were the price, CPU speed/cores,
Random-access memory (RAM) and finally the supported communication protocols (BLE and WiFi are
required). These factors are important since they allow the device to be easily bought (price) and allow
multiple parallel complex computational operations like image processing, video recording and voice
recognition to be carried out. Since the tablet will be communicating with a client device, it requires WiFi
to transfer and receive data and commands. BLE can be used to read external sensor data such as
temperature.
Table 4.1 shows some examples of tablets running the major operating systems with similar hardware
specifications.
In terms of price, Apple tablets have the largest cost. Since there is such a big gap in cost, the iPad
Mini 4 does not fit our needs. There are many types of Windows and Android tablets with very affordable
30
Hub(tablet)
User(phone)
EstimoteBeacon
WiFi
BLE signal
Firebase Server
Light state, changed
Change light
Edup Light Switch
Arduino HVAC
WiFi
Wireless AP
Office location detection Building locationdetection
Edup server
PerOMAS SupportedHVAC systems
Figure 4.1: Hardware implementation architecture
prices. The Nexus was chosen because it was developed by Google in partnership with Asus, has very
good reviews and is updated to the latest android version. There are Windows tablets cheaper than the
HP ENVY 8 sold by Microsoft, but there were a lack of reviews so a good tablet from a big manufacturer
was picked.
The Android and Windows tablets have very similar hardware specifications. So the tablet chosen
was the Nexus 7 (2013) since the programmer had experience developing Android apps.
4.1.2 HVAC control
In order for our BAS solution to control an HVAC system, we need to either communicate with a building
central controlling unit or physically control the system like a thermostat does. Since many buildings don’t
have a central control point running some kind of server where you can control it using the Internet, we
went with the thermostat route.
For our smart thermostat to work we require a device capable of sending electric impulses to the
HVAC wire. Table 4.2 shows some commercial products and a Arduino solution.
We require a device that offers an API in order to be controlled by our tablet, because the Sensi
thermostat does not offer an official API it does not fit our requirements.
The Nest thermostat is the most popular option in the market, integrated in many home automation
systems, but since one of our requirements is keeping the cost low it does not fit our requirements. The
path chosen was developing an Arduino based solution, shown in Figure 4.2, with built in WiFi, a relay
to drive the electric wires and a temperature and humidity sensor.
31
name Apple iPadmini 4 Nexus 7 2013 HP ENVY
8 Note 5009CPU speed 1.5 GHz 1.5 GHz 1.44 GHzCPU cores 2 4 4RAM 2GB 2GB 2GB
WiFi yes (2.4 GHzand 5 GHz)
yes (2.4 GHzand 5 GHz) yes (2.4 GHz)
BLE yes yes yesLight sensor yes yes yesMicrofone yes yes yesSpeaker yes yes yesFront camera yes yes yes
Size 7.9 inches (1536x 2048 pixels)
7 inches (1200x 1920 pixels)
8 inches (1200x 1920 pixels)
Operating System Apple IOS 10.0.1 Android 6.0 Windows 10Cost (EUR) 449 131 178
Table 4.1: Comparison between some tablet devices
Besides the mentioned Arduino based solution some offices in our University have installed the
PerOMAS automation system that allows remote control of the installed HVAC system. Due to time
constraints the Arduino base solution was not installed and we used PerOMAS for HVAC control instead.
Name Sensi Wi-FiThermostat
Nest (3rd)Thermostat
Wemos D1mini Arduino +Temperature HumiditySensor DHT11 +Solid State Relay4 Channel + box
temperature/humidity yes yes yesDeveloper API no yes yesCost (EUR) 116 223 4 + 1.5 + 6 + 1 = 12.5
Table 4.2: Differences between thermostat options.
4.1.3 Lighting control
Besides controlling the room HVAC, we require control over the lighting system. After some research
we had three options: using wireless controllable light bulbs, using some kind of Arduino/relay solution
(like the thermostat) or using a wireless controllable light switch.
Table 4.3 show some available options to provide lighting control.
Our lighting solution should be affordable, have a physical light switch and an API to control it. The
Philips Hue is costly and does not have lights supported by our office (fluorescent tube lamp) for these
reasons it does not fit our requirements.
In order for our solution to be easily deployable it requires the least amount of assembly and solder-
ing. A pre-built lighting product is preferable if the price range is close enough. Both the Arduino/relay
and the DI-O/Arduino options have shortcomings, the first does not provide touch control and requires
soldering and the latter also requires soldering in the Arduino interface side.
The lighting option chosen was the Edup Smart Light Switch, shown in Figure 4.3. It provides a
32
Figure 4.2: Arduino HVAC circuit diagram
physical light switch, supports the existing infrastructure in the buildings (as long as there is a phase and
neutral wire in the wall socket) and is not too expensive.
Originally we proposed to have, the lighting system integrated with the Arduino/HVAC using relay
actuators. In the end we decided go with the Edup light switch after searching for lighting products we
could control, it is a better solution because of the touch control, the ability to continue to use the lights
in case of system failure (no Internet or control mobile application crash) and no need for assembly as
described previously.
Unfortunately the wall socket where the light switch was going to be installed was missing the neutral
wire and the wait time for electricians to wire the neutral wire to the wall socket would take too long. The
alternative found was to use the light switch to control a lamp, as shown in Figure 4.4.
Figure 4.3: Edup Light Switch
4.1.4 Bluetooth Beacon
We require a way to determine if a user is near a certain point in the building such as the office.
From the alternatives seen in Section 2.4.2.1, we determined that BLE beacons are an option to
achieve room level location in a building.
33
Name
Edup - WirelessSmart Home WifiLighting PowerSwitch
Philips Hue Bridge +light bulb +light switch
Wemos D1mini Arduino +Solid State Relay4 Channel + box
DI-O - lightmodule +DI-O doublelight switch +Wemos D1mini Arduino +RF TransmitterReceiver Module433MHz + box
manual control yes yes no yesDeveloper API yes (not officially) yes yes yes (arduino)
Wifi yes yes yesyes (needs arduinoto interface withRF signals)
Already built(no extra work) yes yes no
no (needs arduinoand RF componentsto be built)
Support forany office(any light bulb)
yes no yes yes
Cost (EUR) 27.93 56,31 +39,34 = 95,65 4 + 6 + 1 = 11 18,40 + 24,40 + 4+ 0,5 +1 = 48,3
Table 4.3: Lighting control options.
Figure 4.4: Edup Light Switch connected to a lamp to simulate room lights
There are many kinds of devices capable of emitting BLE packets: android devices( available in
version 5.0), some microcontrollers and commercial beacon products.
We decided to use an Estimote beacon. One reason it was chosen was because we had access to
one and did not need to buy it. This beacon also has the advantage of providing temperature readings
if needed. Since it is portable we can position it anywhere in the room, enabling better coverage.
4.2 Software Architecture
Our solution is divided into two separate Android applications, the Hub and the User apps, shown in
Figure 4.5. Both apps work side by side in order to achieve the following functions: user detection,
control over HVAC and lighting systems, task automation and finally video monitoring & security. These
functions are the building blocks which enables our solutions to achieve building automation, increase
34
user comfort and security monitoring.
Figure 4.5: Software architecture.
4.2.1 User Detection
One energy wasting problem is having lighting and HVAC systems turned on when no one is present.
In order for our system to take informed actions to cut wasted energy consumption, we need to know
the location of users inside the building.
The location detection is handled solely by the User app. After it confirms the user is inside the
35
building or office it communicates with the Hub. The Hub on the other hand has a timeout system.
When a user fails to communicate for a certain amount of time, we presumed he is outside the office or
building.
In the building
The building location detection consists in scanning the available WiFi networks and checking if the
MAC address of the AP matches a list of pre-scanned APs. This list of pre-scanned APs is sent to the
User app by the Hub.
Scanning for APs is battery draining and should be kept to a minimum. We could scan every minute
all the time, but decided to start scanning only when the phone connectivity changed. For example
when a user enters a building his phone connects to a known WiFi network. We use this event to start
scanning if the user is inside the target building.
This solution ensures the scanning would start when the user is near a known WiFi network. One
problem with just this solution is the scanning would go on forever even if we left the office and went
home. If after the first five scans (5 minutes) no matching MAC address is found, the scanning is
disabled until a new connectivity change happens.
In order to implement the above solution we use an Android BroadcastReceiver to be informed when
the phone changes connectivity. Then we use an AlarmManager to trigger the scanning code every
minute.
In the office
There is an Estimote beacon in the office broadcasting a BLE signal. The User app is scanning for
these signals and when one is found, it checks if the namespace in the beacon package matches the
known office namespace. After a correct match is found the User app informs the Hub the user is near
the office.
The BLE signal scanning runs for 1 second and then waits 4 seconds before resuming the scan. This
means the User app notifies the Hub at most every 5 seconds when it is in the proximity of the office.
While BLE is a lower-energy system than traditional BT, scanning is still a fairly power-intensive
operation. If our app constantly scans for beacons, it drains the battery at a similar rate as the phone
cellular radio. To limit the battery drain, we only start scanning when the user is in the building and stop
after he leaves.
4.2.2 Lighting control
The lights in the room are controlled by the Edup Light Switch. The switch must be connected to a WiFi
network and automatically establishes a connection to Edup servers to enable remote control over the
switch.
To control the light switch we must open a Transmission Control Protocol (TCP) socket send a packet
with the data shown in Figure 4.6 to Edup server at ”http://servers.chitco.com.cn:8081”. The message
36
starts and ends with specific hex strings, the middle part of the message seems to always start with
”ZH03”, followed by the light switch id then a 1 and finally the lights state we want to change. For
example if the ending part of the middle message is ”101” then the first and last lights are turned on,
and the middle one turned off.
Since there is a physical light switch interface we must update our application status if a button is
pressed outside our app. The Edup Light Switch sends a User Datagram Protocol (UDP) multicast
message when the lights are changed. We implemented an UDP server, that when any message is
received the content is verified in order to determine if it is a Edup Light switch message. The message
must start with ”7e7e000d0002” and end with ”7f7f”. The middle text is ”1101”, the first character is
always the same and the three other represent the current status of the lights.
There were some difficulties since there is no official API. In order to understand how the light switch
worked, we used Wireshark to sniff the traffic created by the Edup app and tried to replicate the mes-
sages.
One other problem arises when we quickly turned on/off all the lights in quick succession. When
we turn off the first light at the app the light switch sends the multicast message to notify the network,
but if we have already turned off the second light then by the time the UDP multicast message arrives
the state is already different and some lights my turn on back again. To fix this problem when a light is
pressed in the app we ignore any UDP message for 3 seconds.
Figure 4.6: Edup packet to set the light state.
4.2.3 HVAC control
Our HVAC solution uses an Arduino with a webserver to control a relay in order to interface with the
existing HVAC system.
The Arduino we implemented to control the HVAC system was written using C++ programming lan-
guage. It has four jobs: run a webserver to allow remote control, implement Simple Service Discovery
Protocol (SSDP) to enable discovery, read temperature/humidity values from a DHT11 sensor and con-
trol a four relay module to control the HVAC system.
After the device is first powered up it becomes an AP. The user must connect to this new network
and use the browser to choose the WiFi network he want the Arduino to connect.
The webserver has the following endpoints:
• GET /: Shows xml description of the device, used after SSDP was performed to list the devices.
• GET /reset: Resets the Arduino device, needed if we want to change the WiFi network the Arduino
is connected.
37
• POST /data Receives a JSON message to control the HVAC system, for example the message
{”cha1”: 1, ”cha2”: 0, ”cha3”: 1, ”cha4”: 0} sends cold air at low speed, more information can be
found in Figure 4.7.
• GET /data Receives a JSON with the current temperature and humidity.
To get temperature readings from the Arduino HVAC, we communicate with the REST API we imple-
mented in the Arduino. We receive a JSON message containing the temperature and humidity. There is
a discovery mechanism to setup the Arduino IP address, that will be mentioned in detail later.
To turn on/off the HVAC we send a POST request containing a JSON message containing the relay
channels we want to turn on/off. In Figure 4.7 the channel configuration is shown. If we want cold air
and slow speed we set the ”ch1” to 1 and ”ch3” to 1, the other channels must be set o zero. This will
cause the HVAC starts sending cold air.
Figure 4.7: Arduino HVAC configuration.
4.2.4 Automation
One of the goals of this project is enabling the automation of lighting and HVAC. A simple example of an
automation task is turning off the lights when no occupant is inside the office. With our project we aimed
to give the user high control and flexibility over the automation process. We allow the user to create
chains of simple conditional statements, called ”recipes”, which are triggered based on events relative
to the office.
The recipes contain a list of triggers and actions. A recipe can have one or multiple triggers, when
there are multiple triggers we use the logical AND operator, all the triggers must be true in order for the
recipe to be triggered.
There are seven triggers available:
• Temperature: This trigger allows the user to trigger an action when the office temperature is below
or above a value specified.
• Motion: The motion sensor is triggered when something changes in the field of view of the Hub or
no movement detected in X seconds.
38
• Speech: Say the keyword ”my assistant” and after the beep you say the phrase specified in the
trigger.
• Time: The timer trigger allows the user to run certain actions at a specific time(Scheduler).
• User location: Allows the user to choose from a list of different scenarios (”User is inside office”,
”User is inside building”, ”User leaves office”, ”User leaves building”, ”User arrives at office”, ”No
user inside building”, ”No user inside office” and ”User arrives at building”).
• Light sensor: The light sensor triggers an action if the light level is below or above the value
specified.
• Light state: This trigger allows the user to trigger an action when the lights are in a specific state.
The actions available are:
• Light: Sets the state of the lights.
• Temperature: Changes the target temperature and turns on the HVAC if needed.
• Speech: This action uses the speakers to say the text specified (text to speech).
In order to show the flexibility of our solution we created the following example recipes:
• If a user is in the office and the temperature is above 25oC then we turn on the cooling.
• If no user is inside the office then turn off all the lights and the HVAC.
• If the user says ”turn on lights” then turn on all the lights.
• if the user location status is ”user arrives at office”, then say ”Welcome back”.
4.2.5 Communication
BASA has several devices that need to communicate with each other as well as external services. The
Hub needs to communicate with the user app, Arduino, light switch and BLE beacon.
Our first approach was to implement both a REST server and client in the Hub. This server allowed
the User app to use an API to control the Hub. The REST client allowed the Hub to communicate
with external services such as getting weather forecast information or controlling the Arduino. Latter we
decided to also include Google Firebase Database as a communication channel between the Hub and
User app.
Rest server - Hub app
We implemented the server using java and the SPARK 1.1.2 framework 1 running at port 5002. The
server is launched using a background service running in a separate thread.
The server exposes the following Rest API:1http://sparkjava.com/
39
• GET /register: Returns the Hub UUID, description and name.
• POST /register: Receives the name, email and UUID of a new user. Returns a status true/false
depending if the registration was successful.
• POST /location Receives an UserLocation object, Figure 4.8, a session-id is sent in the request
header to identify the user. This session id is unique for each user and was exchanged when the
user registered in at the Hub app.
• POST /make-changes: Receives the temperature value we want ”targetTemperature”, and re-
ceives a boolean array representing the lights we want to change ”lightsState”;
• GET /status: Returns the current temperature and a boolean array representing the light status.
• GET /alive: Returns a status ”true” signifying the server is running.
public static final int TYPE_BUILDING = 0;public static final int TYPE_OFFICE = 1;
private boolean isInBuilding;private int type;private long duration;private long date;
UserLocation Class
Figure 4.8: UserLocation Class parameters.
The current implementation of SPARK Framework uses JAVA 8, since Android is compatible with
JAVA 7 and partially with JAVA 8 we had to use an older version of the SPARK server that runs JAVA 7.
Rest client - Hub and User app
The Rest client allows our apps to initiate communication with a server. It is used by the User app to
interact with the Hub app server and used by the Hub to communicate with the Arduino, PerOMAS and
Weather forecast API.
We decided to use the Retrofit Android2 library as our REST client, this library is one of the most
popular client libraries used by developers due to performance and extensibility.
Firebase - Hub and User app
Originally the plan was to only use the web server, but in our building we can’t run web servers in the
WiFi network. When we tried to contact the Hub it did not receive any request. Then we changed to a
private wireless network it all worked normally.
2https://square.github.io/retrofit/
40
The solution we found for connecting to the Hub when the User app is outside the WLAN was Google
Firebase. It is a platform that offers multiple services. We use two services, the real-time database and
the storage. We use their real-time database to synchronize application data across clients and store it
on Firebase’s cloud. The application data we store are the temperature, the temperature the thermostat
is set to, the light state, the beacon namespaces and MAC addresses for user location and finally
data related with live camera view of the office and recorded videos storage location URLs. Using the
provided Android library we can store JAVA objects directly in the database. The storage service is used
to upload the recorded videos and live preview images, captured by the security system.
Firebase solves us two problems, one is users can access our solution from home and access the
live camera, Firebase is used as a middle man to communicate. The second problem it fixed was user
detection, since our building is big, the private network where the tablet is connected can’t be access in
most of the building. A user entering the building could not communicate with our Hub and notify of its
presence since they were in different networks. We use Firebase to add our location messages that are
then received by the Hub to achieve and building level user detection.
We ended having two ways to communicate with the Hub app. Each has some strong and weak
points.
The negative points with Firebase are that it requires Internet access to work so we had to keep the
web server in order for our solution to work inside the office even when no internet connectivity was
present. One other problem is the free tier only allows 100 simultaneous connections, which means
there can only be a maximum of 100 users and Hub devices connect at each moment.
One weak point of the web server is it’s response time varies a lot, sometimes just a few milliseconds
up to a few seconds for simple static content. The server is running in a separate thread but while the
APP is in the foreground the response times increase a bit.
Edup Light Switch Communication - Hub app
Communication with the Edup Light Switch required the use of TCP sockets to give commands and
an UDP server to listen to changes. The communication with the light switch was previously explained
in section 4.2.2.
4.2.6 Security - Motion detection, video recording, Live view
With our office being like an extension of our home, we felt the need to have some sort of video surveil-
lance system. We created a system capable of detecting if a object is moving inside the office, identify
if a user is inside the office and if not, send a notification to the user and record a small video.
Motion detection
The motion detection works by comparing two camera frames. If a percentage of pixels are different
we assume motion has happened. Both the percentage of different pixels and the detection period are
configurable using the UI.
41
The camera frames are received by accessing the bitmap of the TextureView where the camera
picture is shown. We had to use the bitmap from the view and not a camera callback because when
video is recording Android does not trigger the camera callback. Video recording happens when motion
is detected and is explain below.
In order for a camera frame pixel to be considered different the RGB value of the pixel must vary
more than 50 in a scale between 0 and 255. The percentage of different pixels for a positive detection is
user defined, the default is 0.5%.
Video recording
When motion is detected and no user is inside the office we record 30 seconds videos. We do
not record constantly, just after motion is detected. These videos are uploaded and stored to Firebase
servers, where the user can latter watch them using the user app.
The videos don’t have any audio because Android does not allow the audio to be shared between
the speech recognizer and the video recorder at the same time.
Live Camera
We can watch in real time pictures from the office camera. When the user is using the User app live
camera functionality, the Hub saves a camera frame every second to the Firebase server. We have seen
a minimum delay of 4 seconds between the live pictures and the time they were taken.
4.2.7 Hub app
The Hub app is the office controller that interacts with all other devices. The Hub offers a UI to manual
control the lighting and HVAC systems, automation rules and settings. In terms of business logic we
implemented a set of managers responsible for different operational requirements of the application.
4.2.7.1 Event Manager
The Event Manager operates in a publish/subscriber basis. Other managers register their interest in
certain events and when the events happen they are notified. The events can be published to the event
manager by any other manager. For example the Sensor Manager can publish a motion detected event,
that the video manager is interested.
Currently there are eight different events available:
• Temperature: Contain the current temperature and humidity.
• Motion: This event contains a boolean to inform if movement is detected, and a long value with
the time since the last movement was detected.
• Speech: The phrase of a successful speech recognition.
• Time: If we need to check some task regularly this event is triggered every 2 seconds.
42
• User location: This event contains the user id, the location type (Office/Building), a boolean to
specify if he is in the location or left and finally a boolean to indicate if the user just arrived.
• Brightness: The value in Lux of the light sensor.
• Light: The light switch number and it’s status.
• Change temperature: The value of temperature we want the thermostat to be at.
The Event Manager is also responsible for the automation. When an event is published all the
recipes are examined to see if all triggers conditions are fulfilled. When this happens, all the actions in
that particular recipe are executed.
4.2.7.2 Speech Recognition Manager
The power to control the office/home with our voice is something increasingly popular with the launch
of products like Amazon Echo, Google Assistant and Apple Siri. In order to increase the comfort of our
users we added speech recognition into the Hub. This allows the user to trigger a recipe with the power
of their voice. For example a user sitting in his chair could say ”turn on the lights” and the office lighting
would trigger.
This manager uses the CMU Sphinx3 offline keyword speech recognizer, meaning it will detect one
sentence in our case ”my assistant”. When it detects the keyword, it shuts down and we launch Google
online speech recognition. We use this other speech recognition because it offers better results, the
reason the manager uses two different speech recognizers is because using only Google recognizer
has higher bandwidth cost since we would be constantly sending audio. The other reason is privacy, we
don’t know if Google is going to disclose our audio files to third parties.
When we successfully say the keyword, a beep sound is played and Google speech recognizer
listens to the rest of the voice command, when the results arrive from Google they are published to the
Event manager.
There were several problems with both recognizers. As the Sphinx has a lot of false positives for
small words, for our current keyword we sometimes need to repeat more than once for it to recognize.
This problem can perhaps be attributed to the fact we are not native English speakers. Google speech
recognizer is plagued with problems since a few version ago, it sometimes will not listen and shutdown
after some 100 ms. To try to minimize the problem, we run a check every 10 seconds. If neither speech
recognizers are running we relaunch Sphinx.
4.2.7.3 Sensor Manager
The Sensor Manager is responsible for the light sensor and virtual motion sensor.
The light sensor is built into the tablet. Every 2 seconds the current light level is published to the
Event manager.
The motion detection3http://cmusphinx.sourceforge.net/wiki/
43
Since the tablet does not have a motion sensor, we use the front camera and analyze the frames
every second to achieve motion detection explained previously in Section 4.2.6.
A problem that motion detecting cameras have are the false positives especially when there is a
windows to the outside. A strong light can also trigger the sensor. Because of that, we designed the
sensor to be able to ignore an area of the camera frame. It is possible to specify the area to ignore in
the Hub app settings.
4.2.7.4 Video Manager
The Video manager does two jobs, it records 30 seconds videos when no user is present in the office
and motion is detected. The other job is offering a live preview of the office, an user can use the user
app to watch in real time the office.
The recorded videos don’t have any audio because Android does not allow the audio to be shared
between the speech recognizer and the video recorder at the same time.
The video manager can be enabled and disabled in the Hub settings for privacy reasons.
4.2.7.5 Lighting Manager
This manager is responsible for turning on/off the room lights and keeping their status updated when
a user uses the manual switch by listening to multicast messages sent by the light switch explained
previously.
4.2.7.6 Temperature Manager
The Temperature Manager is responsible for keeping an updated weather forecast, keeping an updated
temperature reading and turning on/off the Arduino HVAC.
The forecast uses Wunderground4 service API and is used to give information to the user about the
current weather conditions.
There are two different configurations to access the temperature in our solution: using an Estimote
beacon or the Arduino HVAC. The beacon sends a Eddystone telemetry packet containing the current
temperature, it is intended for situations when we just want to display the temperature. The Arduino
option gives the temperature and humidity and allows us to control the HVAC system.
In order to obtain the beacon temperature, the Eddystone-UID primary packet type must be config-
ured using the Estimote mobile app. Then the beacon namespace must be set in the Hub app settings.
4.2.7.7 User Manager
The User Manager keeps track of the user location (in building, in office) and is responsible for registering
new users.
The location system works in the following simplified manner: it receives two types of location mes-
sages from the User app, in-building or in-office; there are timeouts in place so in the eventuality that4http://api.wunderground.com/weather/api/d/docs
44
no message is received for a certain amount of time we assume the user has left the office or building.
The in-building messages arrive every 60 seconds and in-office every 5 seconds, the timeouts are 120
seconds and 20 seconds respectively.
There are two types of user that can register. Users with the mobile User app and users without it. If
a user has the app, it just needs to open the app and there is an semi-automatic register process. If the
user does not have the app he will receive an email with an QR-Code that will act as an identification
card. When the user places the card in front of the Hub camera he is logged on for a certain amount of
minutes specified by the user. Since we can’t track the user whereabouts without the app, the user will
have to manually turn the lights and HVAC if he leaves while logged on. To read the QR-code we use
ZBar5 library to convert the camera frame into a readable string containing the user id.
4.2.7.8 User interface
The UI of the Hub app is composed of three main screens: a lighting screen, a temperature screen and
general menu that contains several advanced features.
The lighting screen, shown in Figure 4.9 allows the user to control the lighting environment in the
room.
The temperature screen, shown in Figure 4.10 gives visual information about the current weather
outside. There is also a virtual thermostat where the user can select the temperature he desires. The
thermostat shows a leaf icon when the selected temperature is inside the range of temperature where
people are comfortable as described in section 2.4.2.3.
There is a general menu that contains the other screens that enable additional features. This menu
contains:
• User registration: Allows a person to setup an account in Hub, shown in Figure 4.11.
• Recipe management: Contains a list of the current recipes in the Hub and allows the user to
create, edit, disable/enable and delete them.
• Event history Shows a list events ordered chronologically, shown in Figure 4.12.
• Statistics screen Shows temperature, lighting status, luminosity and occupation graphics, shown
in Figure 4.13.
• Settings screen Allows the user to configure the Hub app, shown in Figure 4.14.
The user registration screen allows the user to register using the user app or an email address.
If the user uses the Android user app, a visual registration token is shown in the form of a QR-Code.
The QR-Code contains a temporary id and the IP address of the Hub server. This temporary id is
later needed when the user registers and exists to ensure only people inside the office can register and
not just anyone that knows the IP address. If the user chooses to register with just the email we use
5http://zbar.sourceforge.net/
45
Maingun6 API to send an email to the provided email address with a identification QR-Code for user
login, shown in Figure 4.15.
In the recipe screen, the user can create new recipes, first the trigger/s is selected, only then can
the action/s be picked. In Figures 4.16, 4.17, 4.18 and 4.19 the steps needed to create a recipe are
shown, the resulting recipe turns on all the room lights if a user is inside the office and the light level is
low.
The settings screen allows the user to change:
• Number of lights.
• Edit the Edup light id.
• Set the motion detection threshold (percentage of different frames for positive detection)
• The camera detection period, the time between consecutive motion detection.
• Specify an area in the camera frame where motion is ignored, described in Section 4.2.7.3.
• Video recording, enable/disable recording when no user is present and movement is detected.
• Live preview, allow users to watch the office in real time, using the User app.
• Scan for Arduino/HVAC, as mentioned in Section 4.2.7.6 there is a discovery mechanism to add
the Arduino and control it. We use SSDP to discover supported Arduino devices and list the
discovered device/s. The user then selects the device specific to his office. For an Arduino device
to be shown, they have to been programmed to be discoverable using the protocol and have the
search target equal to ”schemas-basa-pt:service:climate:1”.
• Estimote beacon namespace, the id of the estimote beacon we want to get the temperature reading
from.
• Building location, the list of MAC address separated by comma of the building. Used by the User
app to determine if they are in the correct building.
• Room location, the list of Estimote beacon namespace associated to the office.
• Enable Kiosk mode, this mode disables the home and power button of the Android device. It
prevents a user from closing the app.
6http://www.mailgun.com/
46
Figure 4.9: Light fragment.
Figure 4.10: Temperature fragment.
Figure 4.11: Register screen, allows the user to register using an email or User app.
47
Figure 4.12: Event history screen, shows some events and their date.
Figure 4.13: Statistics screen, shows temperature, lighting, luminosity and occupation graphics.
Figure 4.14: Settings screen, allows the user to configure the app.
48
Figure 4.15: Screenshot from Gmail, received email after user registration in Hub app.
Figure 4.16: Create recipe fragment.
49
Figure 4.17: Add trigger fragment.
Figure 4.18: Select action fragment.
Figure 4.19: Final recipe creation fragment.
50
4.2.8 User app
The User app allows user detection, remote control over the office, access to live image preview of the
office, notifications when movement is detected, and video history of recorded videos.
The goal of the application is to add and control Hub devices. This means a user can add multiple
Hubs to a user app and manage them.
To add a device the first thing to do is create a zone, as shown in Figure 4.20. A zone is a virtual
representation of a building. For example we can create a zone and name it ”Home”, then add all our
Hub tablets within the household.
After we created a zone, we can add a device. To add a device the user presses the ”Add device”
button, then a screen with a camera and instructions is shown, as described in Figure 4.21. The goal is
to register the user in the Hub. To this end, the user must first open the registration screen in the Hub
and then point the camera in the user’s phone to the QR-code shown in the Hub registration screen.
Afterwards, all the user needs to do is press ”save” and the Hub is added and can be controlled.
When a Hub device is added three icons representing three services appear in the zone screen:
control lighting, HVAC and security systems. This is shown in Figure 4.20.
The lighting and HVAC screens are straightforward, they allow the user to remotely control a Hub’s
lighting and HVAC systems. The security screen, shown in Figure 4.22 enables live camera visualization
of the Hub’s camera and access to a list of recorded videos. When motion is detected by the Hub all
registered users are notified via Android notification. The purpose of the live camera is to allow the user
to check if someone is indeed inside the office. The recorded video history are small 30 second videos
captured when movement was detected and no user was inside the room. They allow the user to check
in the future if something happened.
The application has two main screens: the UserFragment and the HomeFragment. The UserFrag-
ment, shown in Figure 4.20 allows the user to manage the zones and change application settings. The
HomeFragment shows the current selected zone and all its devices.
In the settings screen available through the UserFragment, shown in Figure 4.23 the user can change
some parameters such as enable/disable Firebase and location tracking or scan for wireless APs. The
screen to scan for wireless APs allows the application to scan and then share via email the list of MAC
address used for building location.
51
(a) Zone creation screen. (b) HomeFragment screen with the added Hub.
Figure 4.20: Zone creation and Zone display.
(a) Before scan QR-Code of Hub device. (b) After scan QR-Code, the device can beadded.
Figure 4.21: Adding a Hub device to the user app.
52
(a) Live camera of the office (b) Video history, videos when movement wasdetected
Figure 4.22: Security - live camera and video history
Figure 4.23: Settings screen in User app.
53
Chapter 5
Evaluation
5.1 Tests Objectives
The test conducted were chosen in order to evaluate the fulfillment of this thesis goals.
Our system leverages user detection to improve occupant comfort and reduce wasted energy and
because of that we require the user detection to be achieved in a reasonable time frame.
The motion detection feature of our system is important to achieve room security and monitoring, for
that reason we need to ensure the system has a good success rate.
The temperature and luminosity sensors have an important role in ensuring our system has the cor-
rect information to perform building automation and increase user comfort, by adjusting the temperature
and lights.
Another objective is to test the Hub web-server ability to respond to a few concurrent users. Since
the server is intended to serve a single office room we don’t expect tens of concurrent user.
Finally we need to determine if users fell comfortable using our system. If they experienced any
problems with the UI, those problems need to be corrected.
5.2 Tests Scenarios
All the tests were conducted in real scenarios inside an office of the Instituto Superior Tecnico (IST) -
Taguspark campus. They were executed using the hardware described in Section 4.1, and one Moto G3
phone running the user app.
5.2.1 User detection - Room
In order to test the user detection time in the office, a series of measurements were performed. The test
consists in observing the time the user app takes to detect the Estimote beacon present inside the office
(beacon with 3.5 meter range). The user will start walking from just outside the beacon range and walk
normally to the office door.
54
The measurements were performed with the beacon device in the center of office. The user’s phone
was a Moto G3 Android phone with BT support up to version 4.0 . For testing purposes, the user app was
set to vibrate when it was near the beacon in order for us to know if it found the beacon. A chronometer
was be used to determine the reaction time. The test resulted in 20 measurements that were used to
determine a meaningful average of the reaction time of the system.
5.2.2 User detection - Building
In order to test the reaction time of user detection in the building, a series of measurements were
performed. The test consists in observing the time the user app takes to detect the phone is inside the
building. The user will start walking from the front door of the building to the office door.
The device used was a Moto G3 Android phone with WiFi 802.11 b/g/n support. For testing purposes
the user app is set to vibrate when it is inside the building. A chronometer will be used to determine the
reaction time. The test resulted in 20 measurements that were used to determine a meaningful average
of the reaction time of the system.
5.2.3 Motion detection
To test the motion detection, a series of measurements were performed to test the algorithm. The test
consists in a person walking in front of the Hub camera at different speeds from the door to a desk. This
test will show if our system is able to detect motion when people enter the office and if it can be tricked
into producing false negatives results.
5.2.4 Temperature and Luminosity
This test measures the correct behavior of the built-in luminosity sensor and the external temperature
sensor (Arduino based).
The luminosity test consists in reading the sensor data in a room with no lights on, and then turn on
the lights to determine if a change in the sensor was observed.
To test the Arduino based temperature sensor the HVAC system will be turned on, and the tempera-
ture readings will show if changes in temperature in the office were observed.
5.2.5 Hub server load
To test our system’s web-server a series of measures were performed. This test consists of making
several concurrent Hypertext Transfer Protocol (HTTP) requests to the server in the Hub app. To send
these requests we used the ApacheBench (ab)1 benchmarking tool.
The goal of this test is to determine if the server handles a small amount of concurrent users. The
website is not expected to server hundreds of concurrent users, instead it will handle a few users sending
occasional POST requests and some periodic GET requests to keep the user app updated when in use.
1http://httpd.apache.org/docs/2.4/programs/ab.html
55
5.2.6 Automation
To evaluate the usability of the IFTTT interface (automation recipes), user usability tests were performed
with a total of 20 users. The users who performed the tests were not familiar with our system and had
no previous experience with similar IFTTT solutions.
The users were asked to create two distinct recipes:
• If the user left the office, then turn off all the lights.
• If the temperature is above 25 oC, then set temperature to below 20 oC.
The test results were then compared to an expert user to determine the usability of the system.
5.3 Test Results
5.3.1 User detection - Room
A set of measurements were taken in order to determine the response time the application takes to
identify the user’s phone is inside the room. Two types of measurements were taken.
In the first test, the user is inside the room with BT turned off, then it was turned on and the timer
started, Figure 5.1 shows the cumulative distribution function obtained from the measurements.
In the second set of measurements, the user starts walking outside the office and the timer starts
when he opens the unlocked door to the room. The cumulative distribution function for the second test
is shown in Figure 5.2.
In the first test we observed that in most cases our system detected the user presence very quickly
within a few seconds but in other occasions, it seemed to take up to 22 seconds. We noticed once it
detected the Estimote beacon the first time it found it correctly the following times, but seems to take
some time for the initial discovery. Looking at the second test, where the user enters the room, we see
worse results in comparison to the first test. The maximum time increased to 27 seconds. We consider
the time to detect the user presence is adequate for turning on the HVAC system in the user presence,
but not perfect for turning on the lights when the user enters the room.
For cases when the user wants the lights to be on when he enters the room and if the detection time
is considered insufficient, a automation recipe can be created for turning on the light when movement
is detected and the user is inside the building. Nevertheless, we consider the room detection time
adequate for rooms with ambient light from a window but not for dark rooms.
The office where the tests were conducted is roughly 3 by 6 meters wide. The Estimote beacon range
was set to approximately 3.5 meters. Regarding false positives, the beacon signal can be observed in the
adjacent office when next to the wall between the rooms. This means our system can incorrectly identify
the user presence when inside an adjacent office next to the wall. A possible solution to this problem
is to use more than one beacon with range set to 1.5 meters and spread them in the room. Since the
range is shorter the signal won’t be so easily detected in adjacent rooms but still offers coverage of the
target room.
56
Figure 5.1: Cumulative distribution function of the time it takes to detect a user inside a room
Figure 5.2: Cumulative distribution function of the time it takes to detect a user when he enters the room
57
5.3.2 User detection - Building
Several measurements were taken to determine the time the application takes to detect that the user is
inside the building. The cumulative distribution function from the measurements is shown in Figure 5.3.
Building level user detection does not need very quick response times, unlike room detection, as
building location will be mostly used to preheat the room before the user arrives. The response time
observed shows an acceptable response time.
Our building WiFi range extends a few meters beyond the front door so in some measurements our
system detected the user before he walked through the front door of the building.
5.3.3 Motion detection
To test motion detection, we conducted tests with three different people with different heights. Each
person entered the room at different speeds, the obtained results are shown in Table 5.1.
Our system was able to correctly identify a person walking inside the room every time. Figure 5.4
shows an example of the different pixels in the camera frames identified by our algorithm. Regarding
false positives, from object motion they don’t seem to be a big problem since our system allows the
creation of a no-monitoring-area in the camera frame to use in cases of rooms with window view.
The motion test was performed during day hours, in these conditions the camera is able to capture
good frames. We did not perform test during the night time but likely our system will have problems
detecting movement in completely dark rooms. To fix this problem we can install sensors to detect if the
office door is open. If the door is opened and there is not enough light our system could turn on the
lights momentarily to enable motion detection.
5.3.4 Temperature and Luminosity
In order to test the functionality of the luminosity and temperature sensors in the system, these were
used to collect ambient data.
To test the luminosity sensor behavior we turned on the lights in the room and allowed the Hub to
record the values for a while, then we turned off the lights and waited for a few minutes then repeated the
same steps one more time. In Figure 5.5 we can observe two different gaps where the lights were off.
As expected the Android luminosity sensor operates as intended and provides the system with correct
data. During the first test period of no lights a computer monitor was turned on and that caused the
luminosity values to be a bit above zero.
Person 1detection
Person 2detection
Person 3detection
Slow walk 20/20 20/20 20/20Normal walk 20/20 20/20 20/20Run 20/20 20/20 20/20
Table 5.1: Motion detection tests for three people with different heights, 20 measurements each.
58
Figure 5.3: Cumulative distribution function of the time it takes to detect a user after he enters thebuilding
Figure 5.4: Motion detection - Frame before and after, motion detected
59
To test the external temperature sensor, the HVAC system was turned on and the temperature was
recorded. In Figure 5.6 we can observe a small decline in the temperature after the HVAC system was
turned on. The temperature was lowered by 2oC and then went back to the 24 oC after the HVAC system
was turned off.
5.3.5 Hub server load
To test the web server, we used ab to send requests during 5 minutes with different concurrency levels.
This simulates multiple users sending concurrent requests to our server.
Two scenarios were tested:
• Users sending GET request to /status endpoint to retrieve the current temperature and light state .
• Users sending POST request to /make-changes endpoint to change the temperature and the lights.
Both scenarios were repeated for different concurrency levels (1, 10, 50, 100, 150, 200). For each
concurrency levels the test was repeated 5 times in order to obtain an average value.
The results of this test are shown in Figures 5.7 and 5.8. We determined our website is able to
respond within 500 ms with 100 concurrent users and no errors. We believe this value is more than
adequate for the expected load the server will handle for normal office rooms with few people. Even if
this system is used in a large room with a few dozens of people it would still perform it’s job.
The results obtained in this test used a specific Android tablet with 2GB of Ram and quad-core CPU
a 2013 Nexus 7. Different Android devices may present different results from the ones observed in these
tests.
Figure 5.7: Get Request time per concurrent user.
60
Light offLight off
Figure 5.5: Luminosity Readings
11:19HVAC
turn ON14:58HVAC
turn OFF
Figure 5.6: Temperature Readings
61
Figure 5.8: Post Request time per concurrent user.
5.3.6 Automation
The results obtained from the usability test allowed us to determine if further changes are need to
improve our IFTTT interface. The test results are shown in Table 5.2. We observed the users took more
time completing the first task due to inexperience with the system. They performed much better on the
second task.
One of the reasons user took more time in the first task was because after they correctly selected
the trigger, they had to select an option inside the trigger. Some options are not visible in the screen and
the user needed to swipe vertically to view the remaining options.
Tests with an expert user were performed in order to compare the times of experienced and inexpe-
rience users when handling the interface. Comparing the results presented in Table 5.3 and Table 5.4
we observe that an inexperienced user on average took 19 seconds more to complete the first task in
comparison with the experienced user. On average, the inexperienced user took more 9 seconds to
complete the second task. These values are to be expected, as first time users always under perform
expert users. The extra time the first time users took is reasonable. We conclude there were no major
problems in the UI used to complete the tasks.
5.4 Summary
In this chapter we detailed the tests done to assure the system’s behavior. We concluded that most of
the system operation followed the predicted guidelines and performed well. The only test that did not
provide the expected results was the room user detection test. The motion detection test performed
as expected and the web server handled several concurrent clients without any problems. The tested
sensors showed good accuracy and provided useful information to the user. The usability tests with user
provided good feedback to improve the designed and showed the flexibility of the automation system.
62
Task 1 Task 256 4023 2433 2941 2625 2728 2230 2024 2041 3035 2743 3234 2027 2336 2948 3835 2833 2955 4038 2935 23
Table 5.2: User usability tests results for task 1 and 2
Task 1 Task 2Mean 36 27.8Standard deviation 9.31 5.96
Table 5.3: User usability tests, mean and standard deviation
Task 1 Task 2Mean 17 18.4Standard deviation 0.89 1.49
Table 5.4: Expert user usability tests, mean and standard deviation
63
Chapter 6
Conclusions
6.1 Summary
In this document, we present BASA a system that uses regular Android tablet devices running an Android
application to create a BAS. Our system aims to improve the comfort of office users, minimize wasted
energy consumption of the building and provide office security monitoring.
To develop the solution for the problem, we started by analyzing Building Automation standards and
smart home solutions available in the market. Then we explored the wireless communication protocols
that we could use in our system to interact with the user’s phone and external devices. Finally, we
analyzed the use of some sensors to improve building automation and provide occupant detection.
We identified a set of problems in conventional BAS, which included high hardware cost, expensive
installation, limited flexibility and customization. Current smart home solutions also suffered from a
few problems, the main problem is high overall cost. Each additional light bulb, sensor and thermostat
increases the overall cost by hundreds of euros.
Our solution uses regular Android devices to achieve automation and security of an office room. The
tablet (Hub) mounted in a wall in the office includes sensors, access to WiFi and BT networks and other
useful components. We use the internal sensors, as well as an external temperature sensor, to allow the
application running in the tablet to take informed actions based on the current conditions of the room. We
added an IFTTT functionality that allows regular users to personalize their office automation to improve
comfort and reduce wasted energy. We mitigate some problems related to user neglect by detecting the
user presence in the room or building. This allows the IFTTT automation component of our system to
take certain actions based on the room and building occupancy, for example turning off the lights when
no user is present inside the room.
Finally, the solution was tested in a real scenario at IST - Taguspark.
64
6.2 Achievements
The main achievement of BASA is using an Android device as a BAS solution. While other system use
proprietary hardware and software solutions to provide building automation our solution uses common,
affordable Android devices to control the lighting & HVAC systems in the room and provide a built-in
security system.
Besides the wall mounted Android tablet in the room, we developed an User app that allows user
to remotely interact and control the wall mounted Android device. We implemented a quick and semi
automatic way for users to add new Hub devices (rooms), by using QR-Codes.
Another contribution of BASA is offering an IFTTT automation solution that allows users to create
conditional event based rules. This solution offer high flexibility as it allows the user to create automation
rules that fit the room and user requirements.
A simple motion detection functionality was added to the system, this allows our system to record
small videos when motion is detected and no user is present inside the room. The videos can be later
accessed using the User app.
Finally our system is able to detect if the user is inside the room or in the building using different
wireless technologies.
We deployed the system in a office room to evaluate its operation.
6.3 Future Work
The results presented in this thesis provide a strong foundation for future work in BAS leveraging Android
devices.
One possible improvement to our system is the possibility of adding a dynamic number of control-
lable devices and external sensors. Currently the system is designed to control a set of lights and a
thermostat, but in the future the system could control smart power outlets, perhaps window blinds or
other devices related to the room.
One aspect this thesis did not focus and is pertinent to its future is the ability to connect multiple
Hub instances (rooms) and take coordinated actions to improve energy efficiency and user comfort. For
example if a section of the building has a boiler for heating but our system does not detect any users
inside the rooms, then the boiler temperature could be turned down a few degrees to save energy. The
same principle also applies to hallways, if no users are inside a section of the building and no motion is
detected the lights can be turned off or the very least lower their brightness to save energy.
Another future improvement to the system is the ability for the tablet itself to act as a BLE beacon.
This means we can use the Android device running the Hub app to achieve room user level detection
and can skip the external beacon device.
Our system has voice recognition functionality, this feature can be used to create a personal assis-
tant. The user could ask questions to the Hub and receive answers. It could also provide voice alerts
65
to Google calendar events and much more. One possible route we could take is to use Amazon Alexa1
voice service. This service already offers answers to verbal questions and can be integrated in our
system.
During the development of our prototype, we were unable to install the Edup light switch in the wall
due to a missing neutral wire. A neutral wire will have to be wired into the wall in order to deploy the
prototype as originally intended.
One aspect of our system we were not completely happy with was the user detection time in a
room. The detection time should have been much lower. Further research and testing must be done to
determine if it is the Android system who is not receiving the BLE signals due to energy saving policies
or if it is the library by Estimote that we used that is not operating as it should.
1https://developer.amazon.com/alexa
66
Bibliography
[1] Agency, I.E.: Energy efficiency (2015) [Online; accessed 7-1-2016].
[2] Tuan Anh Nguyen, M.A.: Energy intelligent buildings based on user activity: A survey. Energy and
Buildings (2013) 244–257
[3] Farahani, S.: ZigBee Wireless Networks and Transceivers. Newnes (2008)
[4] Wenqi (Wendy) GUO, W.M.H., ZHOU, M.: Wireless mesh networks in intelligent building automa-
tion control: A survey. INTERNATIONAL JOURNAL OF INTELLIGENT CONTROL AND SYSTEMS
(2011)
[5] He, N., Li, Z., Jiang, C., Yang, C., Fan, S., Ma, X., Ren, Y., Zhang, J., Chen, C.: A sensing platform to
support smartphones accessing into wireless sensor networks. Master’s thesis, Tsinghua National
Laboratory for Information Science and Technology (2011)
[6] Gustavo Paulo Medeiros da Silva, Marcelo Maia Sobral, E.R.d.M.: Lar inteligente atraves de mi-
crocontroladores e dispositivos android. Rev. Tecnico Cientıfica (IFSC) (2012)
[7] Hermann Merz, Thomas Hansemann, C.H.: Building Automation - Communication Systems with
EIB/KNX, LON and BACnet. Springer (2008)
[8] Bushby, S.T.: Bacnet TM : a standard communication infrastructure for intelligent buildings. Au-
tomation in Construction Jornal (1997) 529–540
[9] Swan, B.: Internetworking with bacnet (2015) [Online; accessed 16-12-2015].
[10] Wang, S.: Intelligent Buildings and Building Automation. Spon Press (2010)
[11] Committee, A.S.: Ansi/ashrae addendum q to ANSI/ASHRAE standard 135-2008 (2009)
[12] z wavealliance: About z-wave technology. http://z-wavealliance.org/about_z-wave_
technology/ 2015.
[13] Frenzel, L.: About z-wave technology. http://electronicdesign.com/communications/
what-s-difference-between-zigbee-and-z-wave 2012.
[14] WANG, J.: Zigbee light link and its applicationss. IEEE Wireless Communications (8 2013)
67
[15] Baraka, K., Ghobril, M., Malek, S., Kanj, R., Kayssi, A.: Low cost arduino/android-based energy-
efficient home automation system with smart task scheduling. 2013 Fifth International Conference
on Computational Intelligence, Communication Systems and Networks, Madrid, Spain (2013)
[16] Balanuta, A.: Peromas: Personal office management and automation system. Computing in Sensor
Systems (DCOSS), International Conference (2015)
[17] Kumar, S.: Ubiquitous smart home system using android application. International Journal of
Computer Networks and Communications 6 (2014)
[18] : Wireless medium access control (mac) and physical layer (phy) specifications for wireless per-
sonal area networks (wpan). IEEE Std. 802.15.1 (2005)
[19] Bluetooth: What is bluetooth technology? (2015) [Online; accessed 27-12-2015].
[20] SIG, B.: Bluetooth specification version 4.2 (2014)
[21] Hiertz, G.R., Dee Denteneer, L.S., Zang, Y., Costa, X.P., Walke, B.: The ieee 802.11 universe.
IEEE Communications Magazine 48(1) (January 2010) 62–70
[22] : Wireless lan medium access control (mac) and physical layer (phy) specification. IEEE Std.
802.11 (2012)
[23] Brenner, P.: A Technical Tutorial on IEEE 802.11 Protocol. BreezeCOM. (1997)
[24] Alliance, W.F.: Wi-fi direct [Online; accessed 27-12-2015].
[25] Daniel Camps-Mur, Andres Garcia-Saavedra, P.S.: Device to device communications with wifi
direct: overview and experimentation. Wireless Communications, IEEE 20 (2012) 96–104
[26] Android: Sensors overview — developer android (2015) [Online; accessed 27-12-2015].
[27] Labeodan, T., Zeiler, W., Boxem, G., Zhao, Y.: Occupancy measurement in commercial office
buildings for demand-driven control applications. Energy and Buildings (2015) 303–314
[28] Agarwal, Y., Balaji, B., Gupta, R., Lyles, J., Wei, M., Weng, T.: Occupancy-driven energy manage-
ment for smart building automation. BuildSys (2010)
[29] Balaji, B., Xu, J., Nwokafor, A., Gupta, R., Agarwal, Y.: Sentinel: occupancy based HVAC actuation
using existing wifi infrastructure within commercial buildings. SenSys ’13 Proceedings of the 11th
ACM Conference on Embedded Networked Sensor Systems (17) (2013)
[30] John Krumm, E.H.: Locadio: Inferring motion and location from wi-fi signal strengths. Mobile and
Ubiquitous Systems: Networking and Services Conference (2004) 4–13
[31] Galasiu, A.D., Newsham, G.R., Suvagau, C., Sander, D.M.: Energy saving lighting control systems
for open-plan offices: A field study. LEUKOS 4(1) (2007) 7–29
68
[32] Seppanen, O., Fisk, W.J., Faulkner, D.: Control of temperature for health and productivity in offices
(2004) Lawrence Berkeley National Laboratory.
[33] ANSI/ASHRAE: Standard 55 - thermal environmental conditions for human occupancy. (2010)
[34] Collins, R.T., Lipton, A.J., Kanade, T., Fujiyoshi, H., Duggins, D., Tsin, Y., Tolliver, D., Enomoto, N.,
Hasegawa, O., Burt1, P., Wixson, L.: A system for video surveillance and monitoring (2000) The
Robotics Institute, Carnegie Mellon University.
69
70