DroidEnergy - Detecting and Alerting Users of PowerSupply Failures
Goncalo Nuno de Brito Galado da Costa Grazina
Thesis to obtain the Master of Science Degree in
Telecommunications and Informatics Engineering
Supervisor: Prof. Paulo Jorge Pires Ferreira
Examination Committee
Chairperson: Prof. Rui Jorge Morais Tomaz ValadasSupervisor: Prof. Paulo Jorge Pires Ferreira
Member of the Committee: Prof. Ricardo Jorge Feliciano Lopes Pereira
November 2016
Acknowledgments
To Professor Paulo Ferreira a sincere thank you for supervising this work and sharing his knowledge
with me.
To my parents for all the support during the difficult times we passed. They are proof that anyone
can overcome difficulties if surrounded by the ones we love and care for us. I hope I make you proud.
To my grandparents Antonio, Lino and Alda for giving me good memories that I will always keep in
my heart. Although you can not be here physically, I know you are watching and enjoying this moment
with me.
To my sweet little goddaughter Mariana, my brother Marcos, Joao Miguel, Leonel, Gilda, Joao Paulo
and uncle Helder for also being part of my life.
To my girlfriend Ines for giving me the motivation to finish this work and never doubting that I could
do it. For making me a better person each day and supporting my decisions. For listening, supporting
and making me as happy as I have never been. I hope you are as proud of me as I am of you.
A special thank you to my grandmother Mariana for teaching me one of the most beautiful qualities
a person can have: helping others without asking something in return. For being part of my life and for
being one of my best friends, for making me go from being upset to start laughing with only a smile.
All of you are part of this and I can not thank you enough.
Abstract
In a society where the number and variety of in-house technological devices continues to increase,
some of these devices can not tolerate long power supply failures an require its user to be warned.
For instance, a power loss of more than a couple of hours may spoil the food in the refrigerator, or
the video surveillance system may become unusable. Currently, existing solutions either provide only a
limited outages monitoring (on or off), or are specific products connected to a cloud server that can be
scheduled to activate/deactivate outlets and provide a limited set of configurations. The goal of this work
is to develop a system that is able to detect power supply failures, their duration, and alert the user of
such events according to a flexible range of configurations. The proposed solution, called DroidEnergy,
is a smartphone application (along with a server for back-office purposes) that is plugged into an electric
outlet, and is able to detect outages and alert users. DroidEnergy has several easy to configure features,
e.g. alerting the user via e-mail or Short Message Service (SMS), can be configured remotely or locally,
creating a highly configurable system. Furthermore, we describe the solution design options, as well as
the challenges to overcome in order to validate the proposed solution.
Keywords
Outage detection; Android; Home Automation; User alert.
iii
Resumo
Numa sociedade em que o numero de dispositivos electronicos aumenta cada vez mais, muitos destes
dispositivos nao toleram falhas de energia prolongadas. Por exemplo, uma falha de energia com uma
duracao superior a duas horas podera estragar a comida dentro de um frigorıfico ou um sistema de
videovigilancia podera ficar inutilizavel. Actualmente as solucoes que tentam tratar esta problematica
apenas oferecem um leque limitado de monitorizacao e controlo de dispositivos electronicos ou sao
produtos proprietarios que se ligam a um servidor na nuvem e em que podem ser programados para
activar/desactivar tomadas eletricas. O objectivo deste trabalho passa por desenvolver e avaliar um sis-
tema que seja capaz de detectar e monitorizar falhas de energia, de avisar os utilizadores da ocorrencia
destes eventos, atraves de SMS ou e-mail, e que ofereca um conjunto de configuracoes flexıveis para
que o utilizador o possa configurar de acordo com as suas preferencias. A solucao proposta, chamada
DroidEnergy, e um sistema composto por uma aplicacao desenvolvida em Android e por um servidor
web para funcoes de back-office, em que apenas e necessario ligar o telemovel a qualquer tomada
electrica. Para alem disso o utilizador podera configurar varias caracterıstica de forma facil e rapida,
tanto directamente no telemovel como tambem atraves de uma pagina web. Por fim, descrevemos o
desenho e implementacao da aplicacao, assim como os desafios que terao de ser ultrapassados de
modo a que o solucao seja validada.
Palavras Chave
Deteccao de falhas de energia; Android; Automacao; Alerta ao utilizador
v
Contents
1 Introduction 1
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Proposed Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2 Background and Related Work 5
2.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Uninterruptible Power Supply (UPS) . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.2 Smart Meters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1.3 Advanced Metering Infrastructure (AMI) . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Energy Monitoring at Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Power backup solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.2 Home Automation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Architecture 17
3.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Algorithm overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 User configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4 Implementation 27
4.1 Broadcast Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1 UpdateBatteryReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.1.2 Energy Receiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.3 IncomingSMSReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.1.4 LoggerReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.1.5 InternetConnectionReceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
vii
4.2 Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.1 SQLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3.2 Assets folder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.3 Shared Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.4 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5.1 Main Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.5.2 Devices Activity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5.3 Preferences Menu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Evaluation 49
5.1 Performance tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.1.1 RAM usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
5.1.2 Battery usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 Usability tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1 Validation Survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.2.2 Testing with users . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6 Conclusion 67
6.1 System Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
viii
List of Figures
2.1 Advanced Metering Infrastructure (AMI) Building Blocks [1] . . . . . . . . . . . . . . . . . 8
3.1 Solution overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2 DroidEnergy application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3 Database class UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 Machine state diagram representation of the proposed solution . . . . . . . . . . . . . . . 24
4.1 DroidEnergy modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Web server statistics page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.3 Examples of the main and location screens . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Examples of the preferences screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.1 Android devices connected to the computer . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5.2 Information retrieved using BatteryStats . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Chart representation of the answers given in the validation survey . . . . . . . . . . . . . 58
5.4 Chart representation of the answers given to filter the appropriate participants to partici-
pate in the rest of the survey and to determine if they would pay for the presented system 59
5.5 Chart representation of the answers given to the question 1 (yy axis: number of responses) 60
5.6 Chart representation of the answers given to the question 2 (yy axis: number of responses) 61
5.7 Chart representation of the answers given to the question 3 . . . . . . . . . . . . . . . . . 61
5.8 Chart representation of the answers given to the question 4 . . . . . . . . . . . . . . . . . 61
5.9 Time each user took to complete each scenario in mm:ss . . . . . . . . . . . . . . . . . . 63
5.10 Rated scenario difficulty by user . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.11 Results of the post-testing survey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
ix
x
List of Tables
2.1 Comparison between the presented solutions according to the objectives . . . . . . . . . 15
3.1 Description of each class and function in our solution . . . . . . . . . . . . . . . . . . . . . 25
5.1 Comparison between the devices used in the evaluation . . . . . . . . . . . . . . . . . . . 51
5.2 Comparison between the available memory in both devices . . . . . . . . . . . . . . . . . 54
5.3 Results of the three hour RAM usage test . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
xi
xii
Listings
4.1 Code to retrieve the charging information . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Definition of the runnable class that is executed when an outage is detected . . . . . . . . 31
4.3 Code used to save the log file in internal and external storage . . . . . . . . . . . . . . . . 33
4.4 Code to verify if the external storage is available . . . . . . . . . . . . . . . . . . . . . . . 34
4.5 Code to verify if internet connection is available . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6 Code to authenticate the user and send the e-mail . . . . . . . . . . . . . . . . . . . . . . 37
4.7 Telephony service to retrieve phone type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.8 SQL statement to create the Device table . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.9 Code to retrieve a device from the database . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.10 Server request handling code (excerpt) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.11 Code used to update the main screen information during an outage . . . . . . . . . . . . 44
4.12 Adds the preference fragment to the activity . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.1 Function that retrieves and outputs the memory information of the device . . . . . . . . . 53
xiii
xiv
Acronyms
AoO Alert on Outage
CD Check Devices
AoR Alert on Reestablishment
SMS Short Message Service
SIM Subscriber Identification Module
LAN Local Area Network
LANs Local Area Networks
IP Internet Protocol
API Application Programming Interface
PDU Protocol Data Unit
SMTP Simple Mail Transfer Protocol
MIME Multipurpose Internet Mail Extensions
APK Android Application Package
JS JavaScript
CSS Cascading Style Sheets
SQL Structured Query Language
SSL Secure Sockets Layer
HTML HyperText Markup Language
HTTP Hypertext Transfer Protocol
xv
URI Uniform Resource Identifier
XML eXtensible Markup Language
UPS Uninterruptible Power Supply
AMI Advanced Metering Infrastructure
MDMS Meter Data Management System
NAHB National Association of Home Builders
HAS Home Automation Systems
SeMF Security Modeling Framework
OS Operating Systems
GC Garbage Collections
adb Android Debug Bridge
xvi
1Introduction
Contents
1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Proposed Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1
2
Home automation has been in the vanguard of the research subjects for several years. It provides
mechanisms to control various aspects of a house, with the objective of providing comfort to users and
help them make energy efficient choices when using their own devices [2] or house embedded devices.
With the continuous increase of in-house electronic devices, the power consumption is becoming an
important issue and home automation gives an important contribution to this matter.
Several contributions to this issue have been made through investigation of energy-aware tech-
niques. Such contributions include energy monitoring systems [3–5] and context-aware power man-
agement [6, 7]. Besides providing efficient ways to manage power consumption, Home Automation
Systems (HAS) should also be able to deal with power cuts, in order to maintain the availability of the
devices when a power outage occurs. The solution to this problem is hard to achieve, since most of the
infrastructures would have to be adapted to be able to incorporate programmable technology and power
backup systems. Furthermore, most of the existing solutions only monitor the occurrence of power out-
ages, in order to present statistical information to the user and are unable to alert the user of these
electrical events and are constrained to in-house use.
1.1 Motivation
In a society where the number and variety of in-house technological devices continues to increase, some
of these devices can not tolerate long power supply failures. For instance, a power loss of more than
a couple of hours may spoil the food in the refrigerator, or the video surveillance system may become
unusable. Currently, existing solutions either provide only a limited outage monitoring (on or off), are
specific products connected to a cloud server that can be scheduled to activate/deactivate outlets and
provide a limited set of configurations or have a high complexity level. The goal of this work is to develop
a system that is able to detect power supply failures, their duration, and alert the user of such events
according to a flexible range of configurations. The proposed solution, called DroidEnergy, is a system
composed by a smartphone application and a web server (for back- office purposes) that is plugged
into an electric outlet, and is able to detect outages and alert users. DroidEnergy has several easy
to configure features, e.g. alerting the user via e-mail or SMS, can be configured remotely or locally,
creating a highly configurable system; we describe the solution design options, as well as the challenges
to overcome in order to validate the proposed solution.
1.2 Objectives
The main objective of this work is to develop and evaluate a system able to detect power failures
and reestablishments, alert the user without the need of a backup-power infrastructure and work au-
3
tonomously. For the developed system to be successful, it has to meet the following requirements:
• Power supply failure and reestablishment detection based on pre-specified time intervals;
• Highly configurable for experienced and inexperienced users;
• Capable of notifying a user when a power outage occurs, either by e-mail or via SMS;
• Low price.
The evaluation of the system should also take into account the performance and battery autonomy
in order to maximize the time the system can be monitoring an outage without entering sleep mode.
1.3 Proposed Solution Overview
The proposed solution consists in a low price system that by being plugged into the wall and connected
to the Internet, is able to detect power supply failures and consequently, identify the electrical devices
that have a higher power dependency and alert users via e-mail, SMS or both even though the local
internet router may be affected. Besides being highly configurable, the configurations and statistical
information can be remotely accessed via a web server. In addition, the performance of the system
minimizes the battery consumption, guaranteeing that most power outages can be monitored without
the system entering sleep mode.
1.4 Contribution
Contrary to energy management and monitoring that is a highly explored topic, outage monitoring with
the objective of alerting the user has yet to be further addressed. Most monitoring systems, besides
being hard to install and having a high installation cost, look upon power outages as any other electrical
event. Other monitoring systems do not even have the ability to deal with power outages.
The main contribution of this work is the development of system that is able to detect power outages
and alert users of such events. It is composed by a smartphone application and a web server which
allow device monitoring and remote access to its features. Since it explores the existing house infras-
tructure, the installation produce has a low level of complexity and does not require additional smart
house appliances, such as sensors. In addition, its cost is considerably lower when compared to home
automation solutions presented in the market.
4
2Background and Related Work
Contents
2.1 Basic Concepts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Energy Monitoring at Home . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5
6
There is vast literature regarding energy-efficient mechanisms and power management in smart envi-
ronments. Most works are focused in energy monitoring in order to provide suggestions to the users
regarding energy efficient mechanisms to save or optimize their home electrical consumption. Other
research works focus on providing comfort to users by enabling them to have control over their devices
or to have the devices auto adjusting their settings according to the user’s preferences. The interest in
this topic and the ever-growing digital services world extended the smart devices offer and consequently
let to the reduction of their price. In this section we review relevant literature that addresses this topic.
We divide this chapter in three sections where in Section 2.1 we introduce basic concepts of our work,
in Section 2.2 we review existing solutions in home automation approaches. In Section 2.3 we present
an overview of technologies that exist to tackle our or similar problems and in Section 2.4 we discuss
the several solutions presented and explain why they do not meet the requirements defined previously.
2.1 Basic Concepts
In this section we present some basic concepts related with the field of our work that are important to
understand the related work addressed in Section 2.3.
2.1.1 Uninterruptible Power Supply (UPS)
An Uninterruptible Power Supply (UPS) consists of an electrical equipment that provides emergency
power from batteries in unexpected power supply failures. This is typically used to protect computers,
data centers, telecommunication equipment or other electrical equipment where unexpected power out-
age could disturb businesses or cause data loss [8]. In data centers UPSes are also used to supply
power while an automatic transfer switch (ATS) selects the source of power [9], which takes about 10-20
seconds [10].
2.1.2 Smart Meters
Smart Meters are metering devices embedded in systems such as electrical meters [11]. When com-
pared to the conventional electrical meters, they offer a large array of new functionalities such as remote
readout of data measurement and provide the user with the current energy consumption. Also, when
used to support eletric smart grids, energy providers can use the gathered data to automatically adjust
the amount of produced energy according to the demand [11].
7
2.1.3 Advanced Metering Infrastructure (AMI)
An AMI consists of one or more smart meters, communication technology, meter data management and
associated software and hardware [12]. It is viewed as a fundamental component of the smart grid
because it provides a two-way communication network between utility companies and a set of smart
meters at the customer side [13,14].
Figure 2.1 shows the four blocks that compose an AMI. The first block represents the smart meters
on the costumer side, that are responsible for collecting consumption data such as electrical, water or
gas usage. The second block represents the communication layer, where the raw data collected by the
smart meters is securely sent to an AMI Host (third block). This block is the server that controls all the
communications between the company and the customer side. The last block represents the Meter Data
Management System (MDMS) who is responsible for filtering the extensive raw data that was collected
in order to extract the relevant information.
Figure 2.1: AMI Building Blocks [1]
The deployment of AMI has several associated benefits, such as reducing the meter reads, provid-
ing higher accuracy in meter readings, providing statistical information of outages, providing the user
with better power profiles according to his energy usage and helping in the reduction of utility costs
that companies have with equipment and maintenance [1]. It can also be used with conjunction with
Home Automation Systems (HAS) to provide adjustments in the electrical devices according to the user
preferences via context-awareness, activity recognition or proactive interaction [15].
2.2 Energy Monitoring at Home
In recent years the number of devices in our homes has increased significantly. With this increase,
the users want agile ways of operating, connecting and controlling the state of the devices. In 1984,
8
the National Association of Home Builders (NAHB) introduced the concept of a “smart house” where a
system would control automatically or manually various functions in the house, such as turning on/off
a light based on daylight, therefore offering interoperability between devices [2]. The concept was later
materialized into HAS. HAS connects the “smart devices” in a house with the objective of providing
comfort to users in a ubiquitous way.
With the functionality increase offered by HAS and consequent escalation of energy consumption,
researchers started focusing more in energy efficient solutions. One interesting fact is that HAS are
not only the cause of energy consumption increase as they are also a solution. In 2002, Banerjee et.
al inquired a user about the performance of his solar panel installation to which the user responded
that he monitored the reading manually [16]. Later on, technologies such as WattsUpMeter [17] and
Android@Home as well as services such as Google PowerMeter or Microsoft Hohm began the process
of providing users access to raw data. Monitoring systems, capable of analyzing the raw data, can have
a high impact in lowering the energy consumption by creating profiles and presenting it to the user in
a human readable format. Dobson [18] and Chetty’s [19] research has shown that granting the user
visibility into the energy consumption can reduce the electricity usage in 5-20% [20]. These monitoring
systems, based in data collected from smart meters, can be further integrated with AMI in order to create
a power system capable of automatically diagnose, monitor and repair a smart grid [12]. Nezhad et.
al [5] propose SmartD, a easy to use and to extend dashboard to visualize and analyze data gathered by
smart meters. Based on GNS middleware [21] it can be integrated with almost every existing smart meter
to provide real-time readings. By being capable of analyzing the gathered data according to different
contexts, it provides the user with visualization of different power consumption profiles according to
temporal aggregations and consumer segments. Being a smart meter ”aggregation” system, it requires
the installation of smart meters throughout the house which can prove to be expensive. More recently
Apple launched an iOS application is serves as a gateway for smart devices such as wireless light bulbs.
Although the amount of research work in this subject is high, houses that use AMI are still only a few.
The three main factors that cause this low “acceptance” are the costs of installation, learning of user’s
preferences that do not fully fulfill their needs and the wide range of customization that research solutions
offer [15].
Banerjee et. al [16] propose a monitoring station which makes energy recommendations in order to
lower consumption based on the energy profile of the house. The recommendation system can advise
users of when to use high-power applications or how to minimize the energy waste. Although the solution
is capable of monitoring energy consumption and detected power outages, the main goal is to provide
energy efficient suggestions to the user. It also requires additional equipment, increase the installation
complexity.
Although the primary focus of energy management research is monitoring, controlling the electronic
9
devices is also an important step towards power efficiency. Some research works propose systems
based on the ZigBee technology that are able to turn off power outlets when the maximum power load is
reached [22,23], but they do not offer real time control over the devices. Zigbee is a mesh network which
uses low-power digital radios to allow control and monitoring over appliances such as light switches
[24]. Its power consumption is lower when compared to system based in Bluetooth and Wi-Fi which
represents a long battery life and therefore relieves the burden of having failures in the system due to
the need of battery replacement. Han et. al [25] propose a remote-controllable and energy-saving room
architecture that provides the user with a way to control the state of the power outlets using a hand held
device.
Another way to manage and adjust the appliances is to use policies. Policies are a set of rules that
can be used to define user preferences on various electrical devices and based on these preferences,
adjust the state of the devices and resolve possible conflicts [26]. They can also be used to describe
device behavior according to the energy usage. For instance Kaliappan et. al [27] propose a policy
based framework which can be used to control the state of electrical devices based on the current
energy consumption and the amount of devices that are being used. Most the policy based research
work has the objective of defining a framework which permits the gateway to aggregate the device’s
information and use this information to adjust the device properties according to the defined policies.
One characteristic that is common to most research works is that the smart devices must be config-
ured individually. Although this may be relatively easy to do in a smaller environment, if we consider a
house closer to a fully smart environment in terms of the number of devices, this may pose as a burden.
Regarding this potential problem there are three types of approaches. The first one is a centralized
approach where the power consumption is analyzed and disaggregate to identify each electrical appli-
ance [28–31]. This approach can be useful to minimize the number of sensors, since it only needs a
centralized one, although it may have problems when detecting low-power appliances [32]. One of the
contributions that uses a centralized approach was made by Englert et. al, which developed an approach
that permits the building to receive information of the electrical appliances regarding their presence and
activity [33]. Their solution consists in sampling the alternate voltage and current signals and running
the samples through a machine learning algorithm, which predicts what type of electrical appliance the
samples correspond to.
Another approach is to measure the power consumption at appliance level. This can be achieved by
using a wireless mesh network such as Zigbee, ACme [34], where each appliance has a sensor which
sends the power consumption reading to the gateway. For instance, Kim et. al propose ViridiScope, a
power monitoring system that uses several non-intrusive sensors to identify the appliances [35]. This
design reduces the need to re-wire the devices since the sensors are placed near the devices and have
different types, such as light intensity, microphones and magnetometers. For instance, by using a light
10
intensity sensor near a refrigerator, the sensor can determine if the refrigerator is open since the light
inside it turns on when the door is opened.
The last approach is using electrical devices that already have network capabilities. These appli-
ances can then be aggregated in a common smartphone or web based application to send information
regarding their state and, if possible, allow control over themselves. In the last years these appliances,
such as remote-controlled outlets or lamp dimmers, have emerged at a relatively low price. These three
types of solutions can have a high impact in the deployment of fully equipped smart houses by reducing
the complexity of the configuring all the devices and the price of installation.
Security is also a concern when developing automation systems, since the gathered information can
have information regarding the electronic devices of a house and private user information. Fuchs et.
al [11] introduced the formal model of a system for transmission of measurement gathered by smart
meters based on the Security Modeling Framework (SeMF) [36]. The model defines a secure and
trustworthy way of specifying the security requirements that need to be considered in a metering system.
2.3 Technologies
In this section we refer to power backup products (Section 2.3.1) and in Section 2.3.2 we present Home
Automation solutions that are related with this research work. We describe the various solutions ac-
cording to our requirements, in order to make a proper comparison between them and the proposed
solution.
2.3.1 Power backup solutions
Regarding power supply failures there are products in the market that are able to provide backup power
during a small amount of time. Most of the products already have the ability of detecting power outages
and automatically switch the house power supply to the secondary supplier.
No Outage [37] offers some home backup systems. Their House UPS System is fully automatic
in power switching when an outage is detected, provides an estimated running time up to 10 hours,
depending on the powered devices, and the total cost of the product plus installation varies from $2,000
to $3,000.
Automatic Standby Generator & Automatic Transfer Switch (ASG) solutions consists in a diesel gen-
erator with a fully automatic Transfer Switch that does not require user intervention. Since it runs of fuel it
can operate for days or even weeks and has an estimated cost between $5,000 and $10,000 depending
on the size of the generator.
Portable Generator with Manual Transfer Switch (PG) solutions consist in a portable generator that
requires manual intervention to switch between power sources. The time delay caused by the manual
11
switching varies from 15 to 45 minutes, the product installation cost varies between $1,000 and $3,000
and permits a run time from 3 to 8 hours, also depending on the devices that are supplied during the
outage.
The first and second solutions have the ability of detecting the power supply failures and are able to
supply some electrical appliances in the house for an extensive period of time, but their price is extremely
high and they are not able to alert a user if he is not present, which are requirements of our solution, as
stated in Section 1.2.
2.3.2 Home Automation
Klugman et. al [38] propose GridWatch, one of the most similar solutions to our work. Their solution was
developed based on the idea that by using a everyday device, such as a smartphone, users can have
a better understanding of the power conditions and energy usage without the need of utility companies.
In addition, the solution does not require the installation of smart meters, lowering the complexity and
cost of implementation. Using the sensors of the smartphone to analyze the power states while the
smartphone is charging, their solution can retrieve information of power outages, such as GPS location
of the outage and duration time. The results of the evaluation show that the prototype can detect power
outages with high accuracy. The main constraints in using GridWatch are that it does not allow remote
access or alerts users when an outage occurs. Another limitation is that it required a large community
to fully function as expected, since the main purpose is to present information based on a large set of
retrieved data.
Chacon [39] has a simple energy meter product that is able to measure in real-time the energy
consumption of an electrical device or household. By using this solution a user can determine which
actions have a higher impact in power consumption and therefore build a more energy efficient profile.
They also have a Wi-Fi smart plug which can be controlled by an Android and iOS application. Although
it can detect power outages, the objective of the first product is only to monitor the electrical events. The
smart plug can not monitor outages but it may be possible to detect outages. If the user tries to connect
to the plug and it fails there are two possible explanations, (i) an outage occurred and (ii) there was a
problem with the plug. The main limitation is that the user can not know if an outage occurred without
interacting with the application, which would probably not occur very often.
HomeSeer [40] has several products in home automation controllers. The controllers can be used to
control or monitor almost every appliance in the house such as light switches, thermostats, door locks
and so on. The system is configurable through a web or smartphone application and offers an heavy set
of possible configurations according to the user‘s intents. The price of the controllers vary from $199.95
to $1,199.95 plus the price of each sensor the user wishes to acquire, which can prove to be very
costly when installing a monitoring system. While HomeSeer‘s products offer a wide range of features in
12
monitoring, the devices require a constant power supply, therefore being unable to detect power outage.
Luan et. al [12] implemented a ZigBee-based smart power meter to measure detailed power con-
sumption, register outage event data and send the data to a processing system. By using ZigBee, the
gathered data from smart meters can be wirelessly sent to the processing system, reducing the instal-
lation complexity, since there is no need of re-wiring the electrical devices. Since it depends on smart
meter deployment, the cost of implementing this system can prove to be high and the feature of alerting
users is not guaranteed.
Patel et al. [28] presents an approach that uses a single sensor that monitors the electrical noise
made by electrical applicants in order to recognize a variety of events. Apart from the sensor this
approach only requires a computer to collect and analyze the incoming electrical noise. This approach
was influenced by PowerLine Positioning System [41], where the detection of electrical events is based
on the electrical noise in the power line made by the switching of electrical devices. Although this solution
is able to detect several electrical events, it requires special equipment. Furthermore the system must
be handled locally and can not provide the results remotely.
Banerjee et. al [16] proposes a monitoring station which makes energy recommendations in order to
lower consumption based on the energy profile of the house. The recommendation system can advise
users of when to use high-power applications or how to minimize the energy waste. Although the solution
is capable of monitoring energy consumption and detected power outages, the main goal is to provide
energy efficient suggestions to the user. It also requires additional equipment, increase the installation
complexity.
De Russis et. al [15] developed a prototype of a smart watch application that is able to communicate
with an AMI environment. The objective of this work is to be able to react to suggestions, such as
disconnecting a certain device according to the current energy consumption or alerting the user that
a device may have a power supply problem, made by the AMI environment without direct interaction
with the devices. Most, or probably all current wrist smart devices include the requirements of the wrist
device the authors defined in 2013, while most low specification devices are in the price range defined
(between 25 and 50$). The main limitations of this prototype are that the message queue is limited
to two messages and that the device uses Bluetooth or SimpliciTI protocols, therefore, it is unable to
receive alerts or interact with the system when the user is not at home.
Das et. al [42] propose an Android application to manage electrical devices using Zigbee. The
application provides both speech recognition and touch commands to control the relays connected to
the devices so they can be switch ON/OFF, as well as statistical information such as power consumption.
The state of the devices is stored in a database present at the server. The server is connected to
the Zigbee components (transmitter and receiver). The receiver reads the state of a micro controller
connected to each device and sends it to the server via the transmitter. To interact with the devices the
13
application connects to the server and retrieves the database information. Every command sent follows
the opposite path describe before, i.e. application→ server→Zigbee transmitter→Zigbee receiver→
micro controller. The authors do not refer to outage detection although it may be possible, since the
database reads the state of each appliance. But if the server is connected to a local router, the smart
phone will not be able to connect to the server. This can be assume to be an outage or it can be a failure
in the PC running the server or in any other component. Furthermore this implementation requires
components that can be expensive depending on the number of appliances the user wants to monitor
and does not provide a way to alert the users of the occurrence of the outage.
Weng et. al [43] propose a management system to control and analyze power consumption in
buildings. It is divided in three different software services, (i) DataService (DS) responsible for storing
the data retrieved from sensors and make it accessible via several interfaces; (ii) CentralService which
stores the building and user information; (iii) ApplicationService which is a server that offers a library
to facilitate the development of applications that use or interact with the system. By using well defined
templates for the sensors and the building they define a common language and therefore, simplify the
interaction and implementation of the system.
These approaches ensure that every user is able to adapt the configurations to fit his preferences and
that each electrical device can be monitored and controlled without direct interaction. Their results show
that the development of such systems is viable and can be applied to every room in a home, however it
may be extremely complex to implement since it requires the installation of sensors in the devices and
connect the sensors to a gateway which is the entity that controls/monitors the devices. Furthermore
they are more focused in the energy management and some fail to include the outage detection and
monitoring in their solutions.
2.4 Summary
The previous sections present related work that cover the research fields in which we believe our solution
is enclosed. However, the presented solutions do not cover all of the requirements we define in Section
1.2 and some of them do not aim for our main objective, which is to detect power supply failures and
notify the users, but they are still presented because they are related to our research. Table 2.1 presents
an overview of the solutions described in the previous sections, according to the requirements we define
in this research work. The requirements presented in Table 2.1 are defined as follow:
• Cost - Represents the estimated cost of the solution. Not applicable if the solution does not have
a retail price.
• Detection - Is the solution capable of detecting power supply failures and reestablishments?
14
• Configurable - Is the solution highly configurable?
• Notifications - Can the solution notify the user? Not applicable if information regarding the notifi-
cations is not present
Table 2.1: Comparison between the presented solutions according to the objectives
System Cost Detection Configurable Notifications
No Outage UPSSystem [37] $2,000 - $3,000 Yes No N/A
ASG $5,000 - $10,000 Yes No N/A
PG $1,000 - $3,000 Yes No N/A
GridWatch [38] No information 1 Yes No N/A
Chacon [39] ' $30 Yes No No
HomeSeer [40] $199.95 -$1,199.95 No Yes Yes
At the Flick of aSwitch [41] No information Yes Yes N/A
Smart PowerMeter [12] No information Yes No N/A
Android Zigbeenetwork [42] No information 2 No Yes No
Wrist homecontroller [15] $58 3 No Yes No
BuildingDepot2.0 [43] No information No Yes No
1 (Used) Price range from $60.98 to $160.95 according to the phones used for evaluatingthe solution
2 There is limited information in what components were used. The price of the Zigbee’scomponents is around $40 and the current transformer is around $3
3 Based on the watch used by the authors (Texas EZ430-CHRONOS)
As mentioned before and as we can see in Table 2.1, none of the solutions presented fulfill all the
requirements we described in Section 1.2. GridWatch [38] is close to our objective, but it does not cover
all the requirements since it was developed with the objective of categorizing the power grid conditions to
provide data regarding the power grid. Furthermore it is not able to alert a user without direct interaction
with the application. At the Flick of a Switch [28] is also very similar to our solution since it is able to
detect power outages, but its primary objective is to identify certain electrical events, such as turning
on or off a television by analyzing the electrical noise. Smart plugs can also be used to detect outages
but similar to the previous solutions, to accomplish that goal, they depend on constant interaction by the
15
user, meaning that an outage can go unnoticed if the user does not check regularly the electrical state
of the house. As such the solution we propose is the only that is able to detect power supply failures,
can be highly configurable and can notify a user by e-mail/SMS.
16
3Architecture
Contents
3.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.2 Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3 Algorithm overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.4 User configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
17
18
In the previous chapter, we introduce the problem we are aiming to solve and present related work. In this
chapter we analyze the solution requirements and introduce the architecture of the solution we propose,
DroidEnery. In Section 3.1 we present the detailed system overview. In Section 3.3 we introduce the
skeleton of the algorithm that is used to detect and monitor power outages. In Section 3.4 we describe
which configurations the user can make and how he can adjust them according to his preferences.
3.1 System overview
This section presents a global view of DroidEnergy’s architecture. DroidEnergy is a system that detects
power outages and alerts the users of these events using a smartphone. It is divided in two major com-
ponents, a smartphone application and a web server. Figure 3.1 shows a global view of the proposed
solution. Most houses have an electrical installation that uses a single electrical switchboard to power
all the appliances. Figure 3.1 not only shows the architecture of the system but also represents the
general electrical infrastructure of a house. By inference and by excluding the cases where the appli-
ances are faulty, if the electrical switchboard is unable to power the appliances, an outage occurs. The
smartphone running DroidEnergy connects to any power outlet in the house and detects the outage by
using its charging state. While most solutions presented in Section 2.3 require additional wiring in the
infrastructure or more complex system, our solution takes advantage of the house electrical infrastruc-
ture to reduce the complexity and cost of installation since it does not require re-wiring or any additional
component.
As we previously explained, the smartphone running the application must be connected to a power
outlet. This power outlet can be one of two possibilities, a (i) common wall socket or an (ii) extension
cord. To obtain better results, it is suggested that the smartphone is plugged directly into the wall
socket to prevent other points of failures. It should also be connected to the local internet router and
have a cellular internet connection. The local Wi-Fi or wired network provide remote access to system
configurations via a web server. When an outage occurs, it is almost certain that the local network will
also be affected by the outage. When this occurs the application uses the mobile connection to send
any alerts, since this connection is usually not affected.
The application requires an initial configuration where the user adds his home devices and what kind
of alerts he wants to receive. He also should set his e-mail account which is used to send any e-mail
alerts, the phone number to which the application should send SMS alerts and create a web server
account which is used to access the configurations remotely.
The system can detect power outages by monitoring the charging state of the smartphone. When
this occurs it starts monitoring the outage. At this point the system can immediately alert the user that
an electrical event was detected. It continues to check if any device has been out of power for longer
19
than its corresponding time. Furthermore, when the outage ends, another alert can be sent to notify the
user of such electrical event.
The user can access the configurations directly on the phone or via a web server, which is not
available during an outage. Besides the configurations, the web server also has statistical information,
e.g. frequency of detected outages in the last year and their duration.
Figure 3.1: Solution overview
3.2 Application components
The software architecture of DroidEnergy is divided in five modules. Figure 3.2 shows the application
modules of DroidEnergy. It is divided in five main modules which control the base operation of the
application.
The activities of the application represent the screens where the user can perform actions and where
the information is presented. The main activity is where battery and charging information is presented.
The location activity is where the user can add house areas and corresponding devices. The third activity
is the preferences menu. Here the user can set all the necessary configurations for the application
to correctly monitor the power outages. These configurations include, e.g. setting the type of alert to
receive, configuring the e-mail properties, adding house areas and corresponding devices. For instance,
a simple set of configurations can be (i) choosing to be alerted on outage detection after five minutes,
20
(ii) choosing to be alerted via e-mail and (iii) adding the e-mail credentials. Additional configurations
include setting e.g. the web server port or setting the web server account list.
Figure 3.2: DroidEnergy application components
The web server is the component of the solution which provides all the configurations in a remote
environment. For this remote access to work there are additional configurations to make. Besides being
responsible for controlling the private network in the house, the local area router also has a public
Internet Protocol (IP) which can be used to make requests from outside the Local Area Network (LAN).
If even the user is not at home, he is able to make requests to the router, but the router needs to be
configured to port forward these requests to the receiver. The first step is to configure a static IP on
the phone. Most of the existing Operating Systems (OS) already allow this change. The second step
is to create a rule in which the user specifies the receiver port and protocol. For instance, to forward
the TCP/UDP requests to the port 8000, the user creates a rule where he indicates that every request
made to <public IP , 8000 > should be translated to the local IP 192.168.1.80:8000. Furthermore, every
action the user takes in the web server is communicated to the data storage via a web interface. This
interface converts the request into an application specific format. This way we are able to reuse the
existing implementation instead of creating a complete set of new actions for the web server calls with a
different format.
In the web server the information is divided in four pages. The home page is where the user can
check the charging and battery state of the smartphone. The second page is where the user can view,
add or remove any devices configured in the application. The third page presents all the configurations
of the application. These are divided in the same way as in the smartphone and every configuration
presented can be changed. The last page in where it presents the statistical information that is gathered
during an outage.
The broadcast receivers are components that react to special events, such as changes in the battery
charging state. They are registered throughout the application and can react to the events independently
21
of the activity where the user is. One of these receivers is the EnergyReceiver. This receiver reacts to
the connection/disconnection of the AC charger and determines if the monitoring services should be
started/stopped. The services include the outage and reestablishment services. The outage service is
used to count the current outage time and check if the user should be alerted for any of the configured
devices. It is also responsible for saving the outage information in the database when the outage ends.
The reestablishment service is only called if the user chooses to be alerted on reestablishment detection.
When an outage ends, the service reads the time set by the user for this alert and starts counting the
time until it reaches zero, sending the alert after.
The LoggerReceiver is responsible for writing and reading the log file. This log is written every time a
change is detected, such as adding a new device, or when an alert is sent. Furthermore the log file can
be exported via e-mail. The SMSReceiver is responsible for activating/deactivating the web server. The
user has an option in the web server configurations to enable this feature. While this feature is active the
user can send an SMS to the phone running the system to enable or disable the web server. The last
receiver is the InternetConnectionReceiver. When the system can not send an alert due to an internet
connection problem, it stores the alert. When the connection is available, it sends the stored alerts.
The last components are the alerts. These correspond to the type of alert an user wants to receive
and are associated with a time. Basically, this time is used by the system to determine when to alert the
user after the corresponding electrical event is detected. There are three types of alerts:
• Alert on Outage (AoO) - alerts the user if an outage has occurred and if the current outage time
exceeds the time set on this alert configuration;
• Check Devices (CD) - during the outage checks if the current outage time exceeds the time con-
figured for each device;
• Alert on Reestablishment (AoR) - alerts the user when the outage ends, after a pre-specified time
has passed.
In the case of the AoO and AoR alerts, if the user does not specify a time, the system will notify him
of the corresponding alert as soon as it is detected. In the other case, the time is used to determine
when to check if any of the devices are affected. For instance, if the user sets this time to 10 minutes,
the system will check every 10 minutes if any devices are affected.
The persistent data is stored in files and in a database. Figure 3.3 shows the database model
DroidEnergy uses to store part of the persistent data. As we can see, there are four classes where the
Location and Devices are related. Although we could have opted for a relation model where Device had
a foreign key location, the amount of entries in the Device table does not require a relation between
the two tables. The other two classes represent the Outage table where the application stores all the
22
Figure 3.3: Database class UML
information regarding the outage monitoring and the web server user table where the accounts to access
the web server are stored.
3.3 Algorithm overview
The solution we propose includes an algorithm which continuously monitors the charging state of the
smartphone. When it detects that the smartphone stopped charging, it starts the monitoring phase.
During this phase it verifies if an alert should be sent according to the application configurations. Figure
3.4 illustrates the state machine diagram that represents the functionality of DroidEnergy. The states and
functions of the diagram are defined in Table 3.1. Prior to start using the system, the user configures it
by choosing which kind of alerts he wants to receive (refer to Section 3.2).
The smartphone exposes the current state of charging to DroidEnergy, which can be of two types:
charging and not charging. As we can see in Figure 3.4 when the charge state is not charging, DroidEn-
ergy deploys a Sentinel. The Sentinel is responsible for launching the timers according to the battery
state and for sending the alerts and logging the registered activity. If the user chooses to monitor the
devices CD, DroidEnergy checks if the current outage time exceeds the time set by the user for each
device. If it does, the Sentinel sends an alert to the user, which contains information regarding the out-
age time of occurrence, the current outage time and which devices were affected. If none of the devices
23
Figure 3.4: Machine state diagram representation of the proposed solution
are affected, this verification is delayed for a pre-specified time (by default 5 minutes) to minimize the
impact in battery duration. If the local router is not accessible, since it may be affected by the outage,
and the user chose to receive alerts by e-mail the Sentinel sends the alert using the cellular network if it
is available. If none of the internet connections are available, the Sentinel stores the alert and sends it
when one of the connections become available. When the power is reestablished, the user can also be
alerted. The system retrieves the information of the outage (duration, devices affected, alerts sent) and
stores this data persistently, to build statistical information, which can be visualized in the web server.
3.4 User configurations
Since one of the objectives of this work is to provide a wide set of configurations on the application, the
user can change almost every aspect of the application to fit his needs. These configurations can be
made directly on the phone or via the web server.
The objective of the web server is to provide a way to configure the system without direct interaction
with it, which is particularly useful if the user is not at home. Since Windows, Android and Apple phones
already have the option to set up a static IP on their smartphones, we decided to only provide the con-
24
Table 3.1: Description of each class and function in our solution
Class DescriptionSentinel Responsible for deploying the monitoring tools
Device Home device (e.g. refrigerator, dryer) which contains informationabout the device (e.g name)
Function Description
Deploy Sentinel When an outage is detected, the system deploys a sentinel, thatwill monitor the outage
Power On? Verifies if the smartphone is chargingSend Reestablishment
Alert?Verifies if the user chose to receive an alert when the outageends
Alert Type? Verifies which kind of alerts the user wants to receive.
Alerts can have two types:[alert on outage] - if the user chose to be notified when an outageoccurs;[check devices] - if the user chose to monitor the devices.
Check Devices Retrieves the device list and for each device checks if corre-sponding time was exceeded by the outage time
Send Alert Sends an alert to the user with information about the occurrenceof the outage and the devices affected
On success, this function sends a message according tothe alert type:[reestab. alert sent] - outage ended, go back to battery monitor;[outage alert sent] - continue to monitor the outage;[device alert sent] - same as above.
Sleep Sentinel sleeps for a defined amount of time too emulate a real-time system
Log Changes Logs the outage event, the devices affected and alerts sent
figuration of the port in which the web server is listening for requests (port 80 by default). Nevertheless,
the user still needs to assign a static IP address to the smartphone and port forward the requests made
to the public IP of the LAN router to the smartphone IP and server port. One important aspect to notice
is when the outage occurs, if the device can not access the Local Area Networks (LANs) in which it has
registered, the web server is not available.
As previously stated (see 3.3) there are three different alerts. While the time set for the AoO and
AoR alerts is used to send an alert after the time is exceeded, the time set in the CD configuration is
different. It is the frequency used by DroidEnergy to check if any devices are affected by the outage and
send the corresponding alert. The user can change these alerts anytime, even during an outage. This is
particularly important for the device configuration, since the user may want to adjust the corresponding
timer during an outage.
The alerts can be sent via SMS or e-mail, or both. The user may specify a different e-mail account
25
from the sign in account to send the e-mail alerts. We chose this configuration option since some e-mail
SMTP servers block e-mail accounts that generate too many messages. To receive the alerts via SMS,
the user only needs to input the recipient phone number, although the smartphone running DroidEnergy
requires a Subscriber Identification Module (SIM) card to properly function with this option.
The user can also enable the system to collect information about the electrical events such as number
of outage occurrences, the mean time of an outage, the average of devices affected, among others.
This information can be visualized in the application but it is more detailed in the web server since it is
constructed using Google Charts.
26
4Implementation
Contents
4.1 Broadcast Receivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Alerts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.3 Data Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.4 Web Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Activities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
27
28
As already mentioned, one of the components of DroidEnergy is the Android application which detects
power outages and alert users of such events. While it is still not possible for an application to learn
the user needs based on his smartphone information, we believe that with a simple initial configuration
we can achieve the autonomy a smart appliance should have. The application was developed for API
23 (Marshmallow), although it has backward compatibility until API 16 (JellyBean), since around 43%
of Android devices run versions between API 16 and 19 (including) [44]. This detail also enables the
use of older Android phones that users may have at home. In the following subsections we describe the
implementation of the application features, necessary to achieve the requirements.
Figure 2 shows the software modules of the application. The application is divided in 5 main modules:
(1) Activities; (2) Broadcast Receivers; (3) Alerts; (4) Data Storage and (5) Web Server. These modules
represent the baseline of the application and the arrows represent the possible interactions between
modules.
Figure 4.1: DroidEnergy modules
4.1 Broadcast Receivers
A Broadcast Receiver is a Java class of the Android Application Programming Interface (API) used to
react to messages broadcasted by the system or the application. They receive intents which contain the
description of an action to be performed. These receivers can be registered directly in the application
29
manifest or programmatically. One important aspect to notice is that the registration of receivers can
make them global. This means that other applications in the phone can send them intents regardless
of the specified filters [45]. This may cause a performance issue in DroidEnergy, but some broadcast
receiver of the application depend on system broadcasts, such as battery state. This means that these
receivers are registered globally while the receivers that only receiver app-specific broadcasts are reg-
istered using the Local Broadcast Manager. There are five broadcast receivers in DroidEnergy:
• UpdateBatteryReceiver
• Energy Receiver
• IncomingSMSReceiver
• LoggerReceiver
• InternetConnectionReceiver
In the following sections we introduce the behavior of the five broadcast receivers.
4.1.1 UpdateBatteryReceiver
The UpdateBatteryReceiver is the receiver used to verify the current charging state of the device. To
enable this feature, we register it with an intent filter for the action ACTION BATTERY CHANGED. This
action is sent every time a battery change is detected and the frequency depends of the hardware. When
the receiver is called, we extract the information that lets the receiver know if the phone is charging and
what type of charge (USB or AC), by using the snippet code presented in Listing 4.1 on the intent
received.
Listing 4.1: Code to retrieve the charging information
1 // get charging information
2 int chargePlug = intent.getIntExtra(BatteryManager.EXTRA PLUGGED, -1);
3 boolean acCharge = chargePlug == BatteryManager.BATTERY PLUGGED AC;
The first line of the snippet returns an integer which can be zero if the device is on battery and can
be other positive integers according to the power sources. The second line is used to verify if the power
source is an AC charger. We only use this type of power source since devices charging via USB can
stop charging when the device they are connected to is turned off. This information is then used by the
Energy Receiver to know if the system should start to monitor an outage or if an outage has ended.
30
4.1.2 Energy Receiver
The EnergyReceiver is the application component that reacts to charger connect and disconnect changes
in the smartphone. It is registered for two different actions: (i) ACTION POWER CONNECTED and (ii)
ACTION POWER DISCONNECTED. The first one is the action broadcast by the smart phone when the
user connects the device to a USB or AC charger.
When the receiver is called, it checks which action was sent. If the action was ACTION POWER
DISCONNECTED, the receiver reads the previous charging state, which was determine by the Up-
dateBatteryReceiver. If the previous state was charging via the AC charger it means an outage was
detected. To monitor this event, the receiver launches a service called Outage Service by invoking the
method context.startService(new Intent(context, OutageService.class)). When the service is launched,
it creates a runnable. Since the runnable code will always be the same, there is no need to create the
runnables every time the receiver is called, or to use threads. Instead we define the runnable code and
send it to a Handler each time an outage is detected. The Listing 4.2 represents the code of the runnable
for the outage monitoring. As we can see, the method updates an event list in the beginning of every
run. This structure is a HashMap that contains the two possible outage events. The update on the list is
made by reading the preferences set by the user and sorting it by the least alert time.
Listing 4.2: Definition of the runnable class that is executed when an outage is detected
1 outageRunnable = new Runnable() {
2 @Override
3 public void run() {
4 events = constants.getEventList(context);
5 checkIfEventOccurred();
6 if (activity.isRunning) {
7 activity.updateNextEvent(currentTime, NEXT EVENT TYPE 5); // update
current outage time
8 if (events.size() > 0){
9 Map.Entry<String,Integer> entry= events.entrySet().iterator().
next();
10 activity.updateNextEvent(entry.getValue() - currentTime, entry.
getKey());
11 }else{
12 activity.updateNextEvent(currentTime, NEXT EVENT TYPE 4);
13 }
14 }
15 checkIfEventOccurred();
31
16 currentTime += 10000;
17 handler.postDelayed(this, 10000);
18 }
19 };
This structure is created by a static class called Constants, which is responsible for saving and
providing objects that are equal, independently of the application context or activity. After the update,
the method for each event, time pair in the list checks, verifies if the current outage time exceeds the
corresponding time. The actions when this occurs differ for each event:
Alert on outage - a simple alert is sent to the user with the current outage time.
Check devices - since the device’s information is stored in the database, to check each device
we use an AsyncTask. As the name suggest, the AsyncTask is an asynchronous task that runs on
a background thread, therefore removing the burden of manipulating threads and handlers or running
tasks that could cause excessive work in the UI thread [46]. On the doInBackground method of the
AsyncTask, a request to the database is sent with the current outage time which returns an array list
with the affected devices. The result of the method is the message to be sent in the alert.
Every ten seconds the method sends an update message to the main activity if it is running. This
message carries the current outage time and type of event which will then be processed by the activity to
update the main screen. When the action ACTION POWER DISCONNECTED is received, it represents
that the device is charging and therefore, the outage ended. If the user chose to receive a reestablish-
ment alert, the receiver launches the ReestablishmentService which is similar to the previous one. The
only difference is that when the reestablishment alerts is sent the service stops itself.
4.1.3 IncomingSMSReceiver
The IncomingSMSReceiver is used to enable or disable the web server via SMS. The intent filter of
this receiver is registered for the action android.provider.Telephony.SMS RECEIVED. When a SMS is
received, the received checks if the user selected the option to enable or disable the web server via
SMS. The receiver reconstructs the incoming SMS by reading the Protocol Data Unit (PDU) objects
stored in the received intent. After this step, the receiver get the message body by calling the getDis-
playMessageBody() method on the reconstructed SmsMessage and matches it with the strings Activate
server and Deactivate server. If it matches the first string the receiver launches the web server service
and stops it otherwise.
32
4.1.4 LoggerReceiver
Every change in the application is logged to a file so the user can keep track of every configuration or
outage detection. To do so, we implement a broadcast receiver called LoggerReceiver, registered with
the filter for the action LOG CHANGES. When an action which should be logged is detected, the activity
or method that generated the action sends an intent to the receiver. The user can opt to store the log file
in the external storage or in the internal (default). The listing 4.3 shows the snippet code used to save
the file. If the user choose to store the log file in the internal storage, we only need to open the file using
the openFileOutput in append mode.
Listing 4.3: Code used to save the log file in internal and external storage
1 public void writeToLog(String storage, String msg) {
2
3 Calendar c = Calendar.getInstance();
4 SimpleDateFormat df = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss", Locale.
ENGLISH);
5 String formattedDate = df.format(c.getTime());
6 String logMessage = formattedDate + " " + msg + "\n";
7
8 switch(storage){
9 case INTERNAL STORAGE: //write msg to internal storage
10 try {
11 FileOutputStream fileout= context.openFileOutput(LOG FILE,
Context.MODE APPEND);
12 OutputStreamWriter outputWriter=new OutputStreamWriter(fileout);
13 outputWriter.write(logMessage);
14 outputWriter.close();
15 } catch (Exception e) {
16 e.printStackTrace();
17 }
18 break;
19 case EXTERNAL STORAGE: //write msg to external storage
20 try{
21 File logFile = new File(context.getExternalFilesDir(filepath),
LOG FILE);
22 FileWriter fw = new FileWriter(logFile, true);
23 fw.append(msg);
33
24 fw.close();
25 } catch (IOException e) {
26 e.printStackTrace();
27 }
28 break;
29 }
30 }
If the user prefers to store the log file in the external storage we need to check if an external storage is
available using the code in Listing 4.4. After checking the availability of the external storage, the receiver
appends the message to the file in the path specified by the user.
Listing 4.4: Code to verify if the external storage is available
1 /* Checks if external storage is available for read and write */
2 public boolean isExternalStorageWritable() {
3 String state = Environment.getExternalStorageState();
4 if (Environment.MEDIA MOUNTED.equals(state)) {
5 return true;
6 }
7 return false;
8 }
4.1.5 InternetConnectionReceiver
When the application detects that an alert should be sent and the user wants to receive the alert via
e-mail, it verifies if an internet connection is available prior to trying to send the alert. When there are no
internet connections available (both cellular and Wi-Fi) the alerts are stored until the outage ends. During
the outage if an internet connection becomes available, the system will try again to send the alerts. This
broadcast receiver is registered with an intent filter for the action CONNECTIVITY CHANGE. When this
action is received by the broadcast receiver we check if the two types of possible connections (cellular
and Wi-Fi) are available (refer to 4.5). If at least one of the connections are available, the alerts are
aggregated in the same e-mail and sent. In the other case the alerts continue to be stored and when
another connectivity change is detected the receiver repeats the process. When the outage ends, if
there are stored alerts that could not be sent, the user receives a summary of the alerts that could not
be sent.
34
4.2 Alerts
As stated in section 3.3 there are three different types of alerts. In the case of the alerts sent via e-mail,
to send them we need to take into account the two possible internet connections and their state when
the alerts are to be sent. The same will not happen if the alerts are sent via SMS since most cellular
infrastructure is built and design to sustain common power failures. In the first case we defined the
following priority chain of internet connection verification to determine what connection is available to
send the alert.
checkIfWifiIsAvailable()→ checkIfCellularIsAvailable()→Store()
We set a priority of one to the Wi-Fi network and a priority of two to the mobile connection. Although
most mobile bundles include at least 200 MB of mobile data monthly, with the wide range of internet
services this data may not be enough. Therefore we chose to give a higher priority to the Wi-Fi network.
Listing 4.5 shows the code we use to determine if any of the internet connections are available. As we
can see, we use the Connectivity Manager to retrieve the network info of both types and then using
the isConnected() method to determine if the connection is established. If neither of the connections is
available, the application stores the alert and tries to re-send it if a connection becomes available.
Listing 4.5: Code to verify if internet connection is available
1 /**
2 * Checks if the desired network is available and connected
3 *
4 * @priority - represents the priority of the network
5 * 1 = Wifi
6 * 2 = Mobile
7 * 3 = Both
8 */
9 public boolean checkNetworkConnectionByPriority(int priority){
10
11 ConnectivityManager connMgr = (ConnectivityManager)
12 context.getSystemService(Context.CONNECTIVITY SERVICE);
13 boolean isAvailable = false;
14
15 switch (priority){
16 case 1:
17 NetworkInfo networkWifiInfo = connMgr.getNetworkInfo(
ConnectivityManager.TYPE WIFI);
35
18 isAvailable = !(networkWifiInfo == null | | !networkWifiInfo.
isConnected());
19 break;
20 case 2:
21 NetworkInfo networkMobileInfo = connMgr.getNetworkInfo(
ConnectivityManager.TYPE MOBILE);
22 isAvailable = !(networkMobileInfo == null | | !networkMobileInfo.
isConnected());
23 break;
24 }
25 return isAvailable;
26 }
After checking if any internet connections is available, the application can set up the necessary
configurations to send the e-mail. Although Android offers a mechanism to generate an e-mail and start
an activity via an intent with the e-mail information, it requires the user to choose an e-mail account
configured in the device. Since our solution is more useful if the user is not in the house, this solution
would not work. Instead we use Oracle’s JavaMail API which makes it possible to generate and send
e-mail without user interaction. First we set the Simple Mail Transfer Protocol (SMTP) properties which
include the SMTP server host and port, if it should connect with authentication and if the encryption of
the data is enabled. So far the user can choose from the following SMTP servers in the preferences
menu:
• Google - smtp.gmail.com:587
• Yahoo - smtp.mail.yahoo.com:587
• Outlook - smtp-mail.outlook.com:465
• IST - smtp1.tecnico.ulisboa.pt:25
After the properties are set, we create a Multipurpose Internet Mail Extensions (MIME) message
with the session created from the previous properties. In this message we set the recipient, the from,
the subject and body of the message. The final step is to authenticate the user and send the message
as shown in listing 4.6. The application retrieves the transport protocol of the e-mail (SMTP), tries to
connect using the credentials set by the user in the preference menu and sends the e-mail. As stated in
section 3.4 some mail servers may block e-mail accounts that generate too many e-mails, since it may
associate them with spam. In the case of the Gmail server, the user must set the ”allow less secure
apps” option to true.
36
Listing 4.6: Code to authenticate the user and send the e-mail
1 Transport transport = getMailSession.getTransport("smtp");
2 transport.connect("smtp.mail.xpto.com", "username", "password");
3 transport.sendMessage(generateMailMessage, generateMailMessage.getAllRecipients()
);
4 transport.close();
In the case where the user only wants to receive the alerts via SMS, the application will have a
different verification method when comparing to internet connection. In order to check if a telephony
connection is available we use the TelephonyManager. This manager provides information regarding
the telephony services and states. First we reference an instance of the TelephonyManager and get the
SIM card state by calling the following methods:
Listing 4.7: Telephony service to retrieve phone type
1 TelephonyManager telephonyManager = (TelephonyManager) getSystemService(Context.
TELEPHONY SERVICE);
2 int telephonyState = telephonyManager.getPhoneType();
3 int simState = telephonyManager.getSimState();
The telephonyState indicates the type of radio network of the phone and if it is available. If this
state is equal to PHONE TYPE NONE, the phone is unable to send or receive SMS. If not, we create
an instance of the SMSManager. This manages all SMS operations and enables the application to
send SMS without user interaction. To do so we read the phone number configured by the user in
the preference menu and execute the sendTextMessage(String destinationAddress, String scAddress,
String text, PendingIntent sentIntent, PendingIntent deliveryIntent) method of the manager. If an error
occurs when sending the SMS or the phone has no SMS capability, the alert is stored and the application
tries to re-send it after a brief time.
4.3 Data Storage
Taking into account that some information of the application must be stored persistently, we implement
storage mechanisms according to the type of the data. As we can see in Figure 4.1 there are three types
of storage.
• SQLite database
• Assets folder
37
• Shared Preferences
In the following sections we described the functionality and purpose of each one of the storage
mechanisms.
4.3.1 SQLite
SQLite is an in-process library that implements a transactional Structured Query Language (SQL)
database which reads and writes directly to files [47]. In Android we are able to implement a SQLite
database by creating a class which extends the SQLiteOpenHelper and overriding the onCreate and
onUpgrade methods to create the tables of the database. Prior to this we first need to define the
database model. The database is used to store the devices and house areas added by the user and the
web server accounts. As previously stated, Figure 3.3 shows the database model for the three objects
described previously. As we can see the Location is defined by a name which is unique in the application
context, the Device class is defined by a unique pair <deviceName, location>, since different locations
may have similar devices, and the web server user is defined by the e-mail, which is also unique. Fur-
thermore we have an Outage class which includes all the information monitored during an outage and
it is represented by a string representation of date and time. In the corresponding repository beside
having the normal operations such as remove and insert, we also have an operation that retrieves all
the outage information in the database and creates a JSON object with that information.
After defining the model we can create the tables that will be used by the application by creating
the SQL statement for each of the tables in the onCreate method. This stated is then executed in the
database by executing the exeqSQL() method on the statement. For instance, to create the Device table
of DroidEnergy we define the following SQL statement (4.8):
Listing 4.8: SQL statement to create the Device table
1 CREATE TABLE " + Device.TABLE + "("
2 + Device.KEY devicename + " TEXT, "
3 + Device.KEY location + " TEXT, "
4 + Device.KEY timetonotify + " INTEGER )";
The operations which can be executed for each table are also defining in Figure 3.3. Every object has
a repository where are the functions that can be executed on the corresponding table are stored. In this
repositories an instance of the SQLiteOpenHelper extended class is obtained through the constructor
that receives the application context. Since SQLite stores the information in files and each application
has a context, which maps the application package, by using this constructor we ensure that we are
operating in the right database.
38
Listing 4.9 shows an excerpt of the device repository code, which is used to get device informa-
tion. For instance, assume we configured a device ”TV” in the location ”Living room” and we want to
check the device settings. The activity creates an instance of the DeviceRepo and calls the getDe-
vice(name,location) method. First the repository gets an instance of the database (db). Secondly it
creates the SQL statement. The third phase is to execute the statement as a raw query in the database
(db) with the information sent by the activity which will return a cursor. A cursor is an interface that
allows read-write operations on the result set of a database query. The repository iterates over the
cursor, although in this case it will only have one entry, and fetches the data via the getColumnIn-
dex(columnName).
Listing 4.9: Code to retrieve a device from the database
1 public Device getDevice(String name, String location){
2 SQLiteDatabase db = dbHelper.getReadableDatabase();
3 String query = "SELECT * FROM " + Device.TABLE + " WHERE " + Device.
KEY devicename + " =?"
4 + " AND " + Device.KEY location + " =?";
5
6 Cursor cursor = db.rawQuery(query, new String[]{name, location});
7 Device device = null;
8
9 if (cursor.moveToFirst()) {
10 do {
11 String deviceName = cursor.getString(cursor.getColumnIndex(Device.
KEY devicename));
12 String timeToNotify = cursor.getString(cursor.getColumnIndex(Device.
KEY timetonotify));
13 device = new Device(deviceName, Integer.parseInt(timeToNotify),
location);
14 } while(cursor.moveToNext());
15 }
16
17 cursor.close();
18 db.close();
19 return device;
20 }
Although we could have opted for a relational database where the Location would have a one-to-
39
many relationship with the Device object, the expected data size stored in the database will not have
enough proportion to real benefit when compared with the extra layer of complexity.
4.3.2 Assets folder
The assets folder is a directory where we can store files that will be compiled into the Android Application
Package (APK) as-is. In this folder we store all the HTML pages, JavaScript (JS) and Cascading Style
Sheets (CSS) files necessary for the web server.
4.3.3 Shared Preferences
The shared preferences storage mechanism is a structure designed to persistently store <key,value>
pairs. They can be stored privately by creating the structure with the Context.MODE PRIVATE or can be
world readable (by other applications) if created with the Context.MODE WORLD READABLE option.
Commonly the shared preferences are used to support the preference menu activity. They offer a way
to ”reconstruct” the app when the user re-opens it, according to the preferences set before closing the
application.
When describing the EnergyReceiver (refer to Section 4.1.2) we pointed out that the algorithm which
verifies if an alert should be sent uses an event list. The event list is built using the values stored in
shared preferences. In the case of an outage, it reads the boolean value of each alert by calling the
getBoolean(preferenceName) on the default shared preferences. If the alert is set to true, the according
time is also read and an entry is created in the event list with the key being the alert type. Every time
the outage event list is updated it is sent to a sort function which does an ascending sort by value. This
is particularly useful for the receiver to determine the next event to take place, when sending the update
callback to the main activity.
4.4 Web Server
The web server is implemented using NanoHTTPD which is an open source lightweight Hypertext Trans-
fer Protocol (HTTP) Java server with HTTP 1.1 and Secure Sockets Layer (SSL) support [48]. To build
our own server we created a new class that extends from the NanoHTTPD class and defined two con-
structors, one for a port server and another for a host:port server. Since smartphones have the option
to configure a static IP, we only use the port server, which means that when the user starts the server,
it uses the smartphone IP address, removing the need of specifying a host name. Nevertheless we cre-
ated the other constructor so that we can implement a host:port server if needed. The extended class
described above is responsible for handling the HTTP requests by overriding the serve(IHTTPSession)
40
method. The serve parameter is a session which allows us to get the parameters of the request and
parse the body of the message. The first step to implement the server is defining the possible paths be-
tween HyperText Markup Language (HTML) pages and requests to the JS and CSS resources via static
strings. The second step is to construct an Uniform Resource Identifier (URI) matcher to determine the
request made to the web server. To do so we implement a class that uses a Pattern class. This java
class is a representation of a regular expression that can be compiled to return a Matcher that can verify
if the input string the compiled pattern.
The third aspect to notice is that although there is a difference between requesting a resource via
the web server and requesting the same resource directly from the device, the server should access the
resource in a similar way. This reduces the burden of implementing two different functions that have the
same output. Therefore we developed a set of interfaces which are used by the web server to access
the application resources as a user would do when interacting with the phone. The interfaces are the
following:
• PagesInterface - methods to retrieve HTML pages and device information
• SettingsInterface - methods to retrieve and save individual settings of the preference menu
• JSONInterface - methods to retrieve bulk data, such as a set of locations, devices or preferences
• CSSInterface - methods to retrieve the CSS files
• JSInterface - methods to retrieve the JS files
Each interface is extended by a class that implements the methods. Listing 4.10 shows an excerpt of
the serve(IHTTPSession) method. As we can see, when the server receives an IHTTPSession request,
it retrieves the URI. It then passes the URI to the URIMatcher that verifies if the URI matches any of
the paths previously defined. When it detects a match it returns a string indicating the matched path.
The returned string is then used in a switch statement to determine the requested page or resource. If
no match is found the server replies with a ”Not found (404)” code. In the other case the content of the
message is sent to the interface responsible for the request. The content is parsed and the operation
takes place. In case there is an error during the execution of the operation, the server replies with an
error message to the client.
Listing 4.10: Server request handling code (excerpt)
1 @Override
2 public Response serve(IHTTPSession session) {
3 String uri = session.getUri();
41
4 String matched = matcher.checkIfURIMatches(uri);
5 switch (matched){
6 case INDEX PATTERN: //index.html
7 return newFixedLengthResponse(webServerPages.getIndexPage(context));
8 case LOGIN PATTERN: //login.html
9 return newFixedLengthResponse(webServerPages.getLoginPage(context));
10 case LOCATIONS PATTERN: //locations.html
11 return newFixedLengthResponse(webServerPages.getLocationsPage(context
));
12 ...
13 }
An Android service is an application component that can be used to perform long operations on the
background [49]. Since the user can activate the web server for an undetermined amount of time, we
deploy the server as an unbound service. A bound service is useful if we want to communicate between
the service and the activity it is bound too, which is not our case, so we opted by the use of an unbound
service. When the user activates the server, via SMS or directly on the phone, the application launches
the service by executing the following method:
startService(new Intent(getApplicationContext(), WebServerService.class));
The second parameter of the function is the class that extends the Service class. The life cycle of
an unbound service is different from the Android activity life cycle. When a service is started the first
method that executes is the onCreate() followed by the onStartCommand(). After the second method
executes the service keeps running until it is stopped by itself or by the client. Before being completely
shut down, the onDestroy() is called. Although being unbound, a service always runs on the UI thread.
This may prove to be a problem if the service is executing too much work. In the onCreate() method we
create an instance of the web server. On the onStartCommand() we create a new thread and start the
server. This assures that the web server executes in a different thread and will not block the UI thread.
When the user shuts down the server, the onDestroy() is called and the server is stopped before the
service is destroyed.
To access the web server the user requires an account. The account can be created on the appli-
cation or one can request an account via the web server. When an user chooses the second option,
an e-mail is sent to the e-mail used to log in in the application. If the user accepts the request, the ap-
plication generates a password and sends the credentials to the user that requested the account. This
option was chosen to provide some security on who accesses the server. In the application the user
can view and manage all the accounts that have permission to access and view the web server content.
Furthermore, the activation/deactivation of the server via SMS can only be made if the incoming SMS
42
was sent by the phone number configured in the preferences menu.
The server presents all the configuration options present in the application with the exception of the
account management, which only the administrator has access to. The server also features as charts
with statistical information. The charts are build using the outage information stored in the device and
Google Charts. This is a free tool that is easy to use and offers interaction which is particularly useful
when changing, for instance, date ranges. The information to build the charts is requested when the
page loads by a JQuery function which sends a HTTP GET request to the server and receives a string
representation of a JSON object. This object is then parsed and the charts are built, as we can see in
Figure 4.2. In addition each chart has a range slider so the user can zoom in and out.
Figure 4.2: Web server statistics page
4.5 Activities
There are four different activities in DroidEnergy. The main activity is where the battery information is
presented. The devices activity is where the devices can be configured according to their location and
has an underlying activity where the settings of each device can be changed. Finally, the preference
activity presents the various configurable options of the application.
43
4.5.1 Main Activity
The main activity represents the main screen of the application and it is where the user can view battery
information such as charge level, state of charge, the current outage time (if applicable) and the time
for next event. Figure 4.3(a) shows a screenshot of the main activity. The charge level, state of charge
and type of charge areas are updated according to the BatteryReceiver, which is only registered in the
main activity, since it is the only activity that needs to receive this information. The BatteryReceiver is
registered every time the main activity is resumed for the ACTION BATTERY CHANGE action. This
action enables the reading of the charging state, battery percentage and type of charge. When this
action is received, the receiver updates the corresponding areas of the main screen.
The next event information area is basically a time counter for the next verification the system will
make for a certain alert. The Listing 4.11 shows the code that updates the main screen timers. As
we can see, when the main activity receives a message from the EnergyReceiver, it updates the screen
according to the type of event. For instance, if the user selected the AoO with a time of three minutes and
the CD with a time of two minutes, when an outage occurs, every ten seconds the EnergyReceiver will
send a message to the main activity with the next event (CD) and the current outage time. As a result, if
the current outage time is one minute, the screen will show 00:02:00 - Check devices as the next event.
This function only exists in the main activity and therefore update messages are only sent if the activity
is running. Furthermore, the main activity uses the custom constructor for the EnergyReceiver which
receives as an argument the activity itself. By doing this, when the receiver wants to know if an update
message should be sent, it can access the isRunning parameter. This parameter returns true or false
depending if the activity is running or not.
Listing 4.11: Code used to update the main screen information during an outage
1 private static final String NEXT EVENT TYPE 1 = "Outage";
2 private static final String NEXT EVENT TYPE 2 = "Reestablishment";
3 private static final String NEXT EVENT TYPE 3 = "Check for devices";
4 private static final String NEXT EVENT TYPE 4 = "Event ended";
5 private static final String NEXT EVENT TYPE 5 = "Outage time update";
6
7
8 public void updateNextEvent(final long time, final String type){
9 MainActivity.this.runOnUiThread(new Runnable() {
10 @Override
11 public void run() {
12 TextView nextEvent = (TextView) findViewById(R.id.next event);
44
13 String resultTime = String.format(Locale.getDefault(), "%02d:%02d:%02
d",
14 TimeUnit.MILLISECONDS.toHours(time),
15 TimeUnit.MILLISECONDS.toMinutes(time) -
16 TimeUnit.HOURS.toMinutes(TimeUnit.MILLISECONDS.
toHours(time)),
17 TimeUnit.MILLISECONDS.toSeconds(time) -
18 TimeUnit.MINUTES.toSeconds(TimeUnit.MILLISECONDS.
toMinutes(time)));
19 switch (type) {
20 case NEXT EVENT TYPE 1:
21 resultTime += getString(R.string.main next event type 1);
22 nextEvent.setText(resultTime);
23 break;
24 case NEXT EVENT TYPE 2:
25 resultTime += getString(R.string.main next event type 2);
26 nextEvent.setText(resultTime);
27 break;
28 case NEXT EVENT TYPE 3:
29 resultTime += getString(R.string.main next event type 3);
30 nextEvent.setText(resultTime);
31 break;
32 case NEXT EVENT TYPE 4:
33 nextEvent.setText(getString(R.string.main next event value));
34 break;
35 case NEXT EVENT TYPE 5:
36 TextView outageCounter = (TextView) findViewById(R.id.
outage time);
37 outageCounter.setText(resultTime);
38 break;
39 }
40 }
41 });
42 }
The main screen also features four buttons:
• Start - registers the EnergyReceiver which is accountable for monitoring the battery charging state
• Devices - shows the house locations
45
• Web Server (in ActionBar) - enables/disables the web server
• Preferences - shows the preference menu
An Intent Filter is a structured description of actions, data and schemes to which a Broadcast Re-
ceiver can respond to [50]. When the user clicks the Start button the EnergyReceiver is registered.
This means that this broadcast receiver can now respond to specific changes in the hardware or in
the application itself, according to the Intent Filter it was registered with. In this case, the EnergyRe-
ceiver is registered with an Intent Filter with three different actions: (i) ACTION BATTERY CHANGE, (ii)
START TIMERS and (iii) STOP TIMERS. Each action determines the behavior of theEnergyReceiver,
as stated before (see 4.1).
4.5.2 Devices Activity
The Device Activity (entitled House Areas in the application) is separated in three activities. The first
one is where the user can configure the locations of the devices he will add later. The second one is
where the devices are listed and new ones can be added. The third activity is where the settings of each
device can be visualized and changed. The first activity’s layout is defined by a ListView and two buttons
in the ActionBar. The ListView is where the house areas are listed. Figure 4.3(b) shows a screen shot
of the devices activity. As we can see the list shows the house areas added by the user. This list is
populated by fetching the data from the database. The locations are fetched from the database using
an AsyncTask. With the resulting set create an array adapter and set the adapter to the list view. We
then add an onClickListener for each of the rows of the list. This is used to access the second activity
by sending an intent with the location name, which will be used to populated the list with the devices that
belong to that location.
4.5.3 Preferences Menu
Android provides a special API to develop a preference menu interface similar to Android’s settings
menu. Instead of using a layout to set the menu interface, a hierarchy of subclasses of the Preference
class are declared in a eXtensible Markup Language (XML) file. These subclasses can be the default
ones, such as a CheckboxPreference or a ListPreference or one can create new classes and customize
them to fit the application. The preferences can be aggregated in groups. In this case preferences can be
set inside a PreferenceCategory and a title can be specified to the category. Preference can also open
a sub-menu where more options are available. This can be achieved by creating a PreferenceScreen
and then setting the preferences within the PreferenceScreen.
After creating the visual structure of the preference menu, we have created an activity that adds a
preference fragment to the preference activity. This can be achieved by executing the code in Listing
46
4.12. When the SettingsFragment is created it reads all the preference values that were saved in the
SharedPreferences and sets the summary of each preference according to that value. Furthermore it
has methods for special preferences, such as the TestConnectivity preference, which has a different
behavior when compared to the usual preferences. To make this preference work like a button we create
a OnPreferenceClickListener on the preference and set the onClick() to call a method instead of saving
a value to the SharedPreferences.
Listing 4.12: Adds the preference fragment to the activity
1 getFragmentManager().beginTransaction()
2 .replace(android.R.id.content, new SettingsFragment())
3 .commit();
Another feature that this API permits is to know when a preference changes. This can be achieve by
implementing a OnSharedPreferenceChangeListener on the activity. We can use this feature to change
the behavior of the application as soon as the user change a setting. The result of implementing such
menu is illustrated in Figures 4.4(a) and 4.4(b). In the first figure we can see the main preference screen
where we aggregated the preferences in two distinct groups. In the second we can see a sub-menu of
the preference E-mail address of the first figure.
(a) Home screen (b) Location screen
Figure 4.3: Examples of the main and location screens
47
(a) Preferences main screen (b) E-mail configuration screen
Figure 4.4: Examples of the preferences screen
48
5Evaluation
Contents
5.1 Performance tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
5.2 Usability tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
49
50
In order to evaluate the proposed solution according to the motivation and solution requirements, we
defined a set of performance and usability tests. These tests provide information that is useful to validate
and identify implementation problems and design options which are important to create the best solution
possible. In this chapter we present the performance tests in section 5.1 and usability tests in section
5.2.
For the performance and usability tests we used two different devices with different versions of the
Android OS. Table 5.1 shows the specifications of the two devices. To fulfill the purpose of this work
the phone should stay at the location to monitor when the user is not at home. Therefore we chose two
devices that differ in Android OS versions and performance. The first one is a white-branded Android
phone running Android KitKat (version 4.4.2) that has no retail price, although devices with similar hard-
ware specifications cost around 55e in 2014. The second phone is a Motorola Galaxy Nexus 6 running
Android Marshmallow (version 6.0.1) whose cost was around 600e when it was released, also in 2014.
Each device has a SIM card with a mobile plan which has 1 GB of mobile data and unlimited SMS.
Table 5.1: Comparison between the devices used in the evaluation
Devices
White-branded phone Nexus 6
CPU MediaTek MTK6572 Qualcomm Snapdragon 805
RAM 512 MB 3 GB
InternalMemory 4 GB 64 GB
OS Version 4.4.2 6.0.1
Batterycapacity 1650 (mAh) 3220 (mAh)
BatteryStand-by 24h 330h
For the performance and user tests we defined the following scenarios.
1. Scenario A - Device A is configured with a time of 1 minute and Device B with a time of 3 minutes.
The user selected the SMS alert. An outage occurs and its duration time exceeds the time set for
Device A and the user is notified.
2. Scenario B - The user changes the time for Device B to 1 minute. The user selected the e-mail
and SMS alerts. An outage occurs and its duration time exceeds the time set for both devices.
The system notifies the user for both devices and using both types of notifications.
3. Scenario C - Before leaving the house, the user selected the ”Activate WebServer via SMS”.
After he leaves, he tries to access the web server but he forgot to enable the server. He sends
51
an SMS to the phone running DroidEnergy to enable the server. He then enables the ”alert on
reestablishment”. An outage occurs and after a while ends, sending the alert to the user.
The possible scenarios are far more vast when compared to the scenarios we present, however
we only present some examples that we believe can validate and improve the features of the solution.
Ideally the timers set for the devices in the scenarios would be in hours but since these timers do not
influence the overall performance of the tests, we reduced them to minimal values.
We also created these scenarios with different difficulties in order to test if the application becomes
easier to use after the first interaction. The first scenario had a medium difficulty, while the second was
the easiest and the third was the hardest. The second scenario is very similar to the first one and this
decision was made to prove that most users can reduce significantly the time completing an action after
doing a similar one for the first time. Furthermore, since each user only did each scenario once, the
measured times refer to the worst case scenario. Therefore, in theory, the users would take less time if
they did the scenarios more than once.
5.1 Performance tests
When developing mobile applications, the performance and resource management is one of the most
important factors to take into account. While the performance is more dependent on the hardware itself,
the resource management done in the applications can still make an impact. This management can be
done with help of tools that retrieve fine-grained information and make them human readable, so the
programmer can focus more on how to solve the problems.
Android Studio is the official IDE for Android which offers all the tools needed to develop and optimize
applications. The best way to optimize an application is to run it while connected to the IDE and use
the provided tools to check the resource consumption in real-time and therefore, discover more easily
potential problems or optimization opportunities. Since one of the objectives of DroidEnergy is to monitor
outages, we need to ensure that the application is able to run during long periods of time. For this to
happen, there is a need to test the features of the application during the development phase, in order to
minimize eventual problems in the code and have better performance.
In this sections we present the performance tests that were made to verify the resource consumption
of DroidEnergy. In Section 5.1.1 we present the results of the RAM usage testing and in Section 5.1.2
we present the tests and results of the battery profiling tests.
52
5.1.1 RAM usage
Android offers a way to determine the amount of RAM an application can use (called threshold) before
the system starts to reject additional memory allocation. This threshold varies according to the RAM of
the device and can be retrieved to check if the RAM usage of the application is near the limit [51]. Listing
5.1 shows a snippet of the code used to read the device’s memory during the run time of the application.
We use the Activity Manager to retrieve a reference to the Memory Info which contains the total memory
of the system and the value of the threshold. Since this information is given in bytes, the values to be
outputted to the log of Android Studio are converted to MB by diving the read value for 1048576L.
Listing 5.1: Function that retrieves and outputs the memory information of the device
1 private static final String TAG = "Main Activity":
2
3 public void showAvailableMemory() {
4
5 // Before doing something that requires a lot of memory,
6 // check to see whether the device is in a low memory state.
7 ActivityManager.MemoryInfo memoryInfo = getAvailableMemory();
8
9 Log.i(TAG, "Available memory "+memoryInfo.availMem/1048576L+" MB");
10 Log.i(TAG, "Total memory "+memoryInfo.totalMem/1048576L+" MB");
11 Log.i(TAG, "Heap size "+Runtime.getRuntime().maxMemory()/1048576L+" MB");
12 Log.i(TAG, "App Threshold "+memoryInfo.threshold/1048576L+" MB");
13 }
14
15 // Get a MemoryInfo object for the device's current memory status.
16 private ActivityManager.MemoryInfo getAvailableMemory() {
17 ActivityManager activityManager = (ActivityManager) this.getSystemService(
ACTIVITY SERVICE);
18 ActivityManager.MemoryInfo memoryInfo = new ActivityManager.MemoryInfo();
19 activityManager.getMemoryInfo(memoryInfo);
20 return memoryInfo;
21 }
To determine the threshold for each of the devices in Table 5.1 we made two slight modifications to
the application. The first one was to add the snippet code explained previously. We then launched the
application in each device and retrieved the following information.
53
Table 5.2: Comparison between the available memory in both devices
Devices
White-branded phone Nexus 6
Total 1 468 2968
Available 1 133 2186
Heap size 1 96 256
Threshold 1 56 1441 In MB
As expected the heap size and threshold are higher in the Nexus, since it has six times more RAM
that the other device. These values are used to determine if the RAM usage of the application is in the
accepted value range and that memory problems will not occur during the application life cycle.
The second modification was to remove the need to connect an AC charger prior to start the moni-
toring. This modification was made to be able to simulate an outage while keeping the device connected
to Android Studio via USB. Therefore we are able to visualize and retrieve information from the Android
Monitor during an outage.
The procedure to profile the RAM usage is defined as follows. We connected the device via USB
to Android Studio and gathered the RAM usage during the execution of the three scenarios described
previously. In the beginning of the test we configured all the necessary details for the scenarios, such
as the e-mail configuration and the web server accounts. We then performed each scenario separately
and with a period of approximately two minutes between them. The reason why we chose not to do the
scenarios consequently is because we wanted to check if any Garbage Collections (GC) were triggered
by each of the scenarios. Android documentation points the number of GC as an indicator of excessive
allocation of temporary objects and therefore as an indicator of a potential memory usage problem.
Therefore, besides measuring the peek RAM usage in the scenarios, we also counted the number of
GC. Table 5.3 show the measured results for each scenario, during the length of the test.
As we can see, in the Nexus there was only one GC during the three scenarios while in the other
phone there were two. After the second scenario both devices issued a GC. This is probably related with
the end of the outage service, since it is destroyed when the outage ends. The peek RAM usage was on
average 30,90 MB for the Nexus and 9,72 MB for the other phone. If we compare the obtained results
with the Heap Size for each device (refer to Table 5.2) we can see that the measured values correspond
to approximately 12% of the heap size in the Nexus and 10% in the other case. From these tests we
can conclude that the applications used approximately the same proportion of RAM in both devices and
the values represent a small percentage of the total available memory for applications.
54
Table 5.3: Results of the three hour RAM usage test
Scenario # RAM peek 1 Number of GC 2
White-brandedScenario 1 9.84 0
Scenario 2 9.95 1
Scenario 3 9.38 1
Nexus 6Scenario 1 31.60 0
Scenario 2 29.72 1
Scenario 3 31.39 01 RAM maximum value (in MB) measured during the execution of the correspond-
ing scenario2 Counted between the previous scenario and the end of following scenario
5.1.2 Battery usage
Battery usage is also a problem that is not easily resolved. While smartphone hardware components
keep increasing every year in terms of performance, the battery life and cycle duration do not follow the
hardware trend. When developing a mobile application the performance is probably the most important
aspect but the battery duration also has a high importance to the user. In this work we use two smart-
phones with a noticeable difference in performance as well in battery duration. Since we developed
the application with backward compatibility until Android KitKat (4.4.2), most of the devices still running
this version will not have a great battery duration. For this reason it is important to make sure that
DroidEnergy uses the minimum battery as possible. This will result in a longer monitoring time during
an outage.
In Table 5.1 we described the devices and the battery duration of each device when they are in
standby. Of course this does not correspond to the real duration when the device is, e.g. running an
application, using the Wi-Fi or mobile connections or has the display turned on.
Google provides two tools that are able to extract and analyze the battery information of the smart-
phone. The BatteryStats is part of the Android framework and is responsible for retrieving the smart-
phone power usage and the BatteryHistorian analyzes the extracted data and presents it in an HTML
page. Unfortunately these tools only work in Android 5 or above, so we were only able to use these tools
to determine the application power usage in the Nexus. To determine the power usage of DroidEnergy
we defined an hour long scenario. We chose this time interval so that the RAM and CPU usage could
stabilize between events. Since these resources have a direct relation with battery consumption and the
events in the scenario will not occur at the same time, the estimation is more accurate. Furthermore,
a measured time in a fixed interval of one hour can be easily used to estimate battery consumption in
different time intervals. The steps of the additional scenario are the following:
• Enable the mobile internet connection
55
• Configure the e-mail and SMS settings
• Enable the web server
• Add the house area ”bedroom” with the devices (<device A, 20 minutes >, <device B, 30 minutes
>)
• Add the house area ”kitchen” with the devices (<device C, 40 minutes >, <device D, 20 minutes
>)
• Choose to receive the device alert
• Start the monitoring
• An outage occurs
• After one hour, the outage ends
Android smartphones gather battery information between full charges. In order to have a reliable
battery usage reading, the battery stats must be cleared. To do so we connected the Nexus 6 to a
computer and removed all battery stats using the Android Debug Bridge (adb). The adb is a command-
line tool that enables the communication between a computer and an Android emulator or a Android-
powered device. After connecting the device to the computer we can confirm that the devices are detect
by calling the adb devices in the command-line. Figure 5.1 shows the list of devices detected by the
adb. As we can see, the adb is able to detect the Nexus.
Figure 5.1: Android devices connected to the computer
After confirming that the device is detected we use the adb shell dumpsys batterystats –reset com-
mand to reset the battery statistics gathered by the phone. After the reset we disconnected the devices
from the computer and started the testing. After completing the scenario we reconnected the phone to
the computer and extracted the battery information gathered by executing the command abd bugreport
>nexus bugreport.txt. A small part of this information can be viewed in the Apps − > Name of the App
− > Battery. The full report can be viewed by launching the battery historian server. In this server we
can upload the bug report retrieved from the phone. The server analyzes the data and builds a chart
where we can see many characteristics such as the CPU time, battery level and temperature. The server
also has another section where we can select the application and check the individual statistics. Figure
5.2 shows the gathered statistics of DroidEnergy. As we can see the estimated power consumption of
DroidEnergy is 0,14% of the battery capacity of the Nexus. If we take into account that the application
was used over a period of one hour, the estimated value of 0,14% battery per hour is a promising value.
As an example, in a case where only our solution was draining power from the battery, it would take
56
approximately 39 days and 3 hours for a full discharge. Taking into account that most outages last for a
period of few hours, the application would be able to run trough almost every outage.
Figure 5.2: Information retrieved using BatteryStats
Although we are not able to use the same method to retrieve the battery information of the other
device, the CPU usage in the Nexus indicates that our application does not use much CPU time since
the higher CPU usage was 2%. Another important aspect to notice is that the application also does not
require constant rendering of the screens, which is a common source of considerable battery drain. In
the case of the other phone, during the RAM usage testing we were able to observe the CPU usage.
Naturally it was higher than in the Nexus but the highest registered value was 20% during one second.
We also registered two other CPU usage peeks but they were less than 10%, also during one second.
These values are high for an application but they occurred only three times during one hour of testing and
during very short periods of time (one second maximum). We can not make a direct relation between
the observations and how much battery the application would drain in the cheaper phone, but we can
have an insight on how much work intensive the application is and therefore, determine that the power
usage of the application would not be high.
5.2 Usability tests
Usability tests are an important part of validating a platform. User experience provide an accurate way
to determine the aspects to improve by testing the application in a real environment. Prior to testing the
57
application with users, we elaborated a survey to validate the idea behind the prototype. The questions
presented in the survey are more focused in determining if the users find the idea and its features useful
and interesting.
5.2.1 Validation Survey
Before the validation specific questions, we asked a few questions to characterize the group of partici-
pants. Figures 5.3(a) to 5.3(c) show the responses for the questions that allowed us to characterize the
participants. From the 53 responses in the survey, 73.6% are the in group age between 18 and 24 years
old, while 22.6% are between 25 and 30, as we can see in Figure 5.3(a). 60.4% of the participants are
currently studying and 24.5% are working-students, and in terms of gender distribution it was roughly
50%.
(a) Number of participants by age group (b) Number of participants by gender
(c) Number of participants by occupation
Figure 5.3: Chart representation of the answers given in the validation survey
After characterizing the participants, we selected the ones which are qualified to participate in the
rest of the study using two questions. Figures 5.4(a) and 5.4(b) show the responses to those questions.
58
As we can see in Figure 5.4(a) from the 53 subjects that answered the survey, 92.5% of the responses
were affirmative to the question ”Do you own a smartphone?”. Since part of this work is prototyping a
smart phone application, the remaining 7.5% were excluded.
The last question to filter the appropriate subjects was ”Would you consider using a system that
detects power outages and alerts you even if you are not at home?”. As we can see in Figure 5.4(b),
85.7% of the subjects responded affirmatively, ending up with a total of 42 test subjects to continue the
survey. We asked one final question to the 14.3% which did not find the application useful to determine
why the subjects did not find the idea appealing. The justification that most participants gave was that
they do not find it useful due to the rareness of the outages. We also inquired the participants that
answered yes to the previous question to know if they would pay for such a system, to which almost
40% would pay at least 0.99e as we can see in Figure 5.4(c).
(a) Chart representation of the answers given to thequestion ”Do you own a smartphone ?”
(b) Chart representation of the answers given to thequestion ”Would you consider using a mobile appthat detects power outages and alerts you even ifyou are not at home?”
(c) Percentage of participants that would pay for eachprice group
Figure 5.4: Chart representation of the answers given to filter the appropriate participants to participate in the restof the survey and to determine if they would pay for the presented system
59
The second part of the survey has the objective of determining which features the test subjects find
more useful. To do so we asked the users to rate from a scale of 1 to 5 the following four questions
according to their usefulness, where 1 means Not useful, 3 means no opinion and 5 Very useful.
1. Would you find useful that the app could monitor different home devices?
2. Would you find useful accessing the app configurations even if you are not at home?
3. Would you find useful to receive outage alerts via SMS ?
4. Would you find useful to be able to configure almost every aspect of the app?
Figures 5.5 to 5.8 show the chart representation of the answers given to the corresponding question.
For the first question the users were informed of the context of the application, where they were told
that the monitoring of devices is to associate a time which will be used to determine if the user should
be alerted for that device, during an outage. As we can see in Figure 5.5, 95.2% of the participants
find it useful to monitor different devices while only a minority of the participants (4.8%) do not have
opinion. Regarding question number 2, again most of the participants found the feature of accessing
to the application from outside the house at least useful (refer to 5.6). The responses to this question
were not as good as the responses of the previous question. A reason for this may be the fact that the
participants know that outages are usually rare or do not last for a period that could affected the home
devices. In fact this was the justification of most of the participants that answered no to the question in
Figure 5.4(b).
Figure 5.5: Chart representation of the answers given to the question 1 (yy axis: number of responses)
Regarding question 3, since the objective of this work is to alert users of power outage, we chose to
question the participants if they would find useful to be alerted of such events. As we can see 54,5% of
the participants find this feature useful, which is worse than expected. Similar to the previous question,
we feel that the participants answered from the context of non-smart houses or houses where there
are no or few services or devices that need continuous power supply. Nevertheless the majority of
the participants find this feature useful. Finally, in question 4 we inquired the participants about the
60
Figure 5.6: Chart representation of the answers given to the question 2 (yy axis: number of responses)
customization one can make in the application. Similar to the previous questions, the majority of the
participants (80,9%) find the customization useful.
Figure 5.7: Chart representation of the answers given to the question 3
Figure 5.8: Chart representation of the answers given to the question 4
As described before, the results of this initial survey show that the main features we included in the
application are useful and are suitable in the context of this work. As a summary of the answers given
in the four questions we asked, from a total of 168 given answers, 80 correspond to the useful option
(number 4) of the scale and 54 correspond to the highest positive option (number 5), summing a total of
134 (79.8%) positive answers and only 6% of negative answers.
61
5.2.2 Testing with users
The second phase of usability tests is testing with users. This is important to evaluate aspects of the
application such as how the information is presented or if it is easy to use. We selected a group of
ten people where half of them are experienced users and the other half is not. An experienced user is
a person that interacts with smartphone applications everyday and an inexperienced user is a person
which does not have much knowledge with application interaction, although four out of five inexperienced
participants own a smartphone.
In these tests we aim to learn if both types of users can easily adapt to the application after using it
a couple of times. To do this we measure the time it took for the participants to complete each scenario
and after completing all three scenarios they answered a quick survey. Besides being able to determine
if the users can learn to interact with the application easily, we can also retrieve from the survey aspects
that need to be corrected.
Before the beginning of the tests we set up the testing area. We used the Nexus 6 for testing to
improve the user experience during the scenarios. We connected it to the AC charger and the charger
to a power outlet with a on/off switch in order to simulate the outages. Additionally we equipped the
smartphone with a SIM card and configured the application with the e-mail credentials needed to send
the e-mail alerts.
After setting up the testing area, we made an introduction of the objective of the work to each user,
as well as an explanation of the application and its features. This explanation was focused in what each
feature does without giving any hints on how to do it, so we would not influence the testing. Furthermore,
the application was previously configured in terms of e-mail account and web server settings since these
configurations are not needed to validate the application and therefore, we can minimize the difficulty of
completing the scenarios.
For each scenario described previously we handed out a script containing the actions that each user
should perform during the scenarios. The scrips do not teach the user on how to use the application, in-
stead they describe all the actions that need to be performed in order to complete each of the scenarios.
The scrips are described as follow.
Scenario 1
1. Add a new house area called bedroom
2. Add two devices to the bedroom (<device A, 1 minute >, <device B, 3 minutes >)
3. Choose to receive the alert defined in the scenario description
4. Start the monitoring
5. An outage occurs and after one minute the user is alerted
62
Scenario 2
1. Add a new house area called bedroom
2. Add two devices to the bedroom (<device A, 1 minute >, <device B, 3 minutes >)
3. Choose to receive the alert defined in the scenario description
4. Start the monitoring
5. An outage occurs and after one minute the user is alerted
Scenario 3
1. Check the Activate Web Server via SMS
2. Send an SMS to the phone running DroidEnergy
3. Go to the web server and select ”Receive reestablishment alert”
Prior to start testing, the users had two minutes to interpret the scenario and clarify any doubts
about the context of the application. After this, each user completed each one of them individually.
Figures 5.9(a) and 5.9(b) show the measured time that each user took to completed each scenario. The
measured time presented in the figure does not include the time that users had to wait for an alert to be
sent. For instance, in Scenario 1 the user had to wait one minute for the alert for device A to be sent,
but since this time is independent of the user which is testing the application, it was subtracted from the
measured time.
(a) Representation of the time each experienced usertook to complete the three scenarios
(b) Representation of the time each inexperienceduser took to complete the three scenarios
Figure 5.9: Time each user took to complete each scenario in mm:ss
As we can see in Figure 5.9(a) the experienced users took average of 3 minutes and 16 seconds
to complete scenario 1. If we compare to scenario 2, which is very similar to the first one, we see a
63
reduction of approximately 27% (one minute) in completion time. When comparing the average time be-
tween scenarios 1 and 3 the time was almost equal, differing in only two seconds. These two scenarios
tested different features and the results show that the users took almost the same time to adapt to the
execution of new objectives, although the third scenario was harder than the first.
Regarding the inexperienced users, on average each user took 5 minutes and 54 seconds to com-
plete scenario 1, 3 minutes and 23 seconds for scenario 2 and 4 minutes and 43 seconds for scenario 3.
Comparing the first and seconds scenarios, we see a noticeable difference, where the users took almost
45% less time completing scenario 2. We observed another noticeable difference between scenarios
1 and 3, where the third took almost 20% less time. This difference is justified by the adaptation effort
users with low or no experience have in using smartphone applications. Although they take almost 45%
more time to complete the first scenario compared to the experienced users, they reduce the time in
approximately 15% in the other two scenarios. One interesting observation is that User 2 of the inexpe-
rienced group took only 3 minutes and 1 second to complete scenario 3, which is less than the average
for the experienced group in the same scenario.
After the test phase each user was asked to fill a survey regarding their experience using the ap-
plication and how difficult they found the scenarios to be. Figures 5.10(a) and 5.10(b) show the results
of the scenario difficulty evaluation for the experienced and inexperienced users. As we can see in the
green bar in figure 5.10(a) the experienced users found on average all the scenarios easy, being the
second scenario the easiest. We can directly relate these results with the time spent by the users in
each scenario. The users found scenario 2 as the easiest and took less time completing the scenario.
Regarding scenarios 1 and 3 the time spent was almost the same and as we can see, both scenarios
were rated with an average of 4. Analyzing figure 5.10(b) we can see the inexperienced users also found
that scenario 2 was very easy but found the other two more difficult when comparing to the experienced
users. This is an expected difference, since users with less contact with these technologies take more
time to adapt to new scenarios, but inexperienced showed throughout the tests that they were able to
rapidly learn the application with only a few guidelines.
The second part of the survey has the objective of knowing the general opinion about the system
after completing the tests. Figures 5.11(a) to 5.11(c) show the results of the survey. As we can see in
Figures 5.11(a) and 5.11(b) all the users that participated in the tests had a positive experience using
the system. Regarding the final survey question three of the users felt that the information was not clear.
These users belong to the inexperienced group (Users 1, 3 and 4 in figure 5.9(b)) and justified their
choice for the time it took to find the path to complete the scenario. However after the initial adaptation
period, they lowered the completion time in the remaining scenarios for values near the rest of the
participants.
64
(a) Results of the scenario difficulty for the experi-enced users
(b) Results of the scenario difficulty for the inexperi-enced users
Figure 5.10: Rated scenario difficulty by user
5.3 Summary
In the previous sections we describe the methodologies to evaluate the proposed solution. These
methodologies are divided in performance and usability tests. In terms of performance, we measured
the RAM and CPU usage as well as the battery power drain. Regarding the CPU, the measured value
was around 2% in the Nexus and peeked at 20% in the other phone. The occurrence of these peeks
was sparse and they had a duration of only a few seconds, so we determined that the CPU usage was
not able to significantly influence the battery duration. To evaluate the RAM usage of the system we
first determined the interval where the system could have memory problems by gathering the maximum
heap size and memory threshold of the two devices we used to test the system. The results show that
the average RAM usage throughout the test was 12% for the Nexus and 10% of the heap size for the
other phone. The last performance test consisted in profiling the battery usage using BatteryStats and
BatteryHistorian. The results show that the estimated power consumption is 0.14% which is very low.
This value can be justified by the RAM and CPU measures and the fact that the application does not
need constant rendering of the views.
The second part of the evaluation are the usability tests which we divided in two sections, (i) Vali-
dation survey 5.2.1 and (ii) User testing 5.2. In the first one we inquired a group of 53 people where
we presented the idea behind this work and asked them a few questions. From the 53 initial we sub-
tracted 4 that did not own a smartphone and from the 49 we subtracted 7 that would not use a system
like DroidEnergy. The follow-up questions were made for the users to evaluate some of the features of
DroidEnergy and overall the answers positive.
The user testing was made with a group of experienced users and another of inexperienced users.
During these tests we measure both the time to complete each scenario and the overall reaction and
difficulty while using the system. The experienced users had a time reduction of 27% from the first to the
65
(a) Representation of the overall reaction to the appli-cation
(b) Representation of the user satisfaction
(c) Representation of the information organization
Figure 5.11: Results of the post-testing survey
second scenarios while the inexperienced users had a noticeable reduction of 47%. The inexperienced
users took on average 37% more time completing the scenarios although they improved throughout
the tests. Finally, in terms of satisfaction while using the system, the majority of the users found the
experience very good.
66
6Conclusion
Contents
6.1 System Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
67
68
In this chapter we describe the system limitations and the future work. We also present the conclusions
we take from this work, which can be considered as a summary.
6.1 System Limitations and Future Work
Although our system is able to detect power outages only by being connected to a power outlet, there
are a few limitations regarding the solution design. The main limitation of the solution is the handling
of false positives. Our architecture was designed to be used in a infrastructure where all the electrical
appliances are connected to the same electrical switchboard. In places where this does not occur, if
the switchboard that provides energy to the outlet where DroidEnergy is connected fails, the system will
assume that an outage occurred when actually it did not. One may argue that although the outage does
not affect the whole building or house, there are still devices that may be affected by this partial outage,
but if we take into account the worst case, all the devices that the user configured in the system will still
be powered and the user will receive false alerts.
Another case of a false positive is when the user connects the AC charger of the smartphone to an
extension cord. If the cord has a problem and stops powering the devices that are connected to it, the
system will not be able to determine that the failures occurred in the cord and will treat the event as an
outage.
Regarding the monitoring of devices, the limitation is closely related with the previous one. While
the system may detect false positives, there are cases when it does not detected power failures. For
instance, the user configured a device in the system and that device has an electrical problem. Since
the system is still being powered, it is unable to detect that the device had a problem.
Finally there is a limitation in the web server when an outage occurs. The user can freely access
the web server from outside the LAN while the smartphone is connected to the same network. When
an outage occurs, there is a high chance that the local network router is affected and therefore the
web server will not be available. Ideally the web server would switch to the mobile network to remain
available but the mobile infrastructure does not have the same approach as a Wi-Fi network has. While
in the Wi-Fi network we can set a static IP address and port forward the external requests to the same
address, the mobile network address are constantly changing and can not be easily set to static.
In terms of future work, regarding the web server limitation, we do not consider its resolution to be
future work since it depends on the mobile carrier itself. Regarding the monitoring of devices the system
could be extended so it would include a special wireless network which would integrate all the electrical
devices so the monitoring could be more accurate. There is a high number of systems that use this
approach to interconnect devices, using for instance a ZigBee network [42,52]. This would add an extra
layer of complexity but it would also tackle an important limitation.
69
6.2 Conclusion
Developing systems that are able to detect power outages without constant user interaction is still a
world to explore, although in recent years attention to this problem has been growing. In spite most
existing researches are related with monitoring systems that help users to have a better energy efficient
profile, solutions that deal with power outages are emerging. This may have to do with the fact that
smart houses are yet to be deployed in commercial market and most of the equipment that create a
smart house are still expensive. Nevertheless, this problematic still represents an important flaw which
needs to be mitigated.
We present an overview of the various techniques and approaches that exist to deal with power
outages, as well as solutions that focus on some of the objectives we defined for our solution. We
address this problematic by presenting a system that is capable of detecting power supply failures and
can alert the user, independently from his location. The solution was designed to have a low price and
able to be deployed in a unmodified Android smartphone, since most existing systems require additional
equipment to properly function. Although the system is unable to determine single points of failure we
chose this design in virtue of lower complexity.
We evaluated the system in terms of performance and usability. In the first evaluation we evaluated
the system performance in terms of RAM usage and battery duration and had results that point to a
battery duration of 0.14% per hour, which represents an excellent performance. The usability tests
revealed that the majority of the inquired users would use such system. It also revealed that the users
which tested the system adapted very easily and were able to reduce significantly their time of scenario
completion. They also pointed out that the information in the system is organized and overall the system
is easy to use.
70
Bibliography
[1] “Advanced metering infrastructure (ami),” Electric Power Research Institute, 2007.
[2] S. Folea, D. Bordencea, C. Hotea, and H. Valean, “Smart home automation system using wi-fi
low power devices,” in Automation Quality and Testing Robotics (AQTR), 2012 IEEE International
Conference on, May 2012, pp. 569–574.
[3] T. G. Holmes, “Eco-visualization: Combining art and technology to reduce energy consumption,”
in Proceedings of the 6th ACM SIGCHI Conference on Creativity &Amp; Cognition,
ser. C&C ’07. New York, NY, USA: ACM, 2007, pp. 153–162. [Online]. Available:
http://doi.acm.org/10.1145/1254960.1254982
[4] Y. Agarwal, T. Weng, and R. K. Gupta, “The energy dashboard: Improving the visibility of energy
consumption at a campus-wide scale,” in Proceedings of the First ACM Workshop on Embedded
Sensing Systems for Energy-Efficiency in Buildings, ser. BuildSys ’09. New York, NY, USA: ACM,
2009, pp. 55–60. [Online]. Available: http://doi.acm.org/10.1145/1810279.1810292
[5] A. Jarrah Nezhad, T. K. Wijaya, M. Vasirani, and K. Aberer, “Smartd: Smart meter data
analytics dashboard,” in Proceedings of the 5th International Conference on Future Energy
Systems, ser. e-Energy ’14. New York, NY, USA: ACM, 2014, pp. 213–214. [Online]. Available:
http://doi.acm.org/10.1145/2602044.2602046
[6] C. Harris and V. Cahill, “An empirical study of the potential for context-aware power management,”
in UbiComp 2007: Ubiquitous Computing, ser. Lecture Notes in Computer Science, J. Krumm,
G. Abowd, A. Seneviratne, and T. Strang, Eds. Springer Berlin Heidelberg, 2007, vol. 4717, pp.
235–252. [Online]. Available: http://dx.doi.org/10.1007/978-3-540-74853-3 14
[7] M. C. Mozer, “The neural network house: An environment hat adapts to its inhabitants,” in Proc.
AAAI Spring Symp. Intelligent Environments, 1998, pp. 110–114.
[8] D. P. Seetharam, A. Agrawal, T. Ganu, J. Hazra, V. Rajaraman, and R. Kunnath, “Hidden costs
of power cuts and battery backups,” in Proceedings of the Fourth International Conference on
71
Future Energy Systems, ser. e-Energy ’13. New York, NY, USA: ACM, 2013, pp. 39–50. [Online].
Available: http://doi.acm.org/10.1145/2487166.2487171
[9] V. Kontorinis, L. Zhang, B. Aksanli, J. Sampson, H. Homayoun, E. Pettis, D. Tullsen, and T. Simu-
nic Rosing, “Managing distributed ups energy for effective power capping in data centers,” in Com-
puter Architecture (ISCA), 2012 39th Annual International Symposium on, June 2012, pp. 488–499.
[10] S. Govindan, J. Choi, B. Urgaonkar, A. Sivasubramaniam, and A. Baldini, “Statistical profiling-
based techniques for effective power provisioning in data centers,” in Proceedings of the 4th ACM
European Conference on Computer Systems, ser. EuroSys ’09. New York, NY, USA: ACM, 2009,
pp. 317–330. [Online]. Available: http://doi.acm.org/10.1145/1519065.1519099
[11] A. Fuchs, S. Gurgens, D. Weber, C. Bodenstedt, and C. Ruland, “Formalization of smart metering
requirements,” in Proceedings of the International Workshop on Security and Dependability for
Resource Constrained Embedded Systems, ser. S&D4RCES ’10. New York, NY, USA: ACM,
2010, pp. 4:1–4:6. [Online]. Available: http://doi.acm.org/10.1145/1868433.1868439
[12] S.-W. Luan, J.-H. Teng, S.-Y. Chan, and L.-C. Hwang, “Development of a smart power meter for
ami based on zigbee communication,” in Power Electronics and Drive Systems, 2009. PEDS 2009.
International Conference on, Nov 2009, pp. 661–665.
[13] D. Ramirez, S. Cespedes, C. Becerra, and C. Lazo, “Performance evaluation of future ami applica-
tions in smart grid neighborhood area networks,” in Communications and Computing (COLCOM),
2015 IEEE Colombian Conference on, May 2015, pp. 1–6.
[14] V. Gungor, D. Sahin, T. Kocak, S. Ergut, C. Buccella, C. Cecati, and G. Hancke, “Smart grid tech-
nologies: Communication technologies and standards,” Industrial Informatics, IEEE Transactions
on, vol. 7, no. 4, pp. 529–539, Nov 2011.
[15] L. De Russis, D. Bonino, and F. Corno, “The smart home controller on your wrist,” in Proceedings
of the 2013 ACM Conference on Pervasive and Ubiquitous Computing Adjunct Publication, ser.
UbiComp ’13 Adjunct. New York, NY, USA: ACM, 2013, pp. 785–792. [Online]. Available:
http://doi.acm.org/10.1145/2494091.2497319
[16] N. Banerjee, S. Rollins, and K. Moran, “Automating energy management in green
homes,” in Proceedings of the 2Nd ACM SIGCOMM Workshop on Home Networks,
ser. HomeNets ’11. New York, NY, USA: ACM, 2011, pp. 19–24. [Online]. Available:
http://doi.acm.org/10.1145/2018567.2018572
[17] ThinkTank. (2016) Watts up? Online; accessed 19-September-2016. [Online]. Available:
https://www.wattsupmeters.com/secure/index.php
72
[18] J. K. Dobson and J. A. Griffin, “Conservation effect of immediate electricity cost feedback on resi-
dential consumption behavior,” Proceedings of the 7th ACEEE summer study on energy efficiency
in buildings, vol. 2, 1992.
[19] M. Chetty, D. Tran, and R. E. Grinter, “Getting to green: Understanding resource consumption
in the home,” in Proceedings of the 10th International Conference on Ubiquitous Computing,
ser. UbiComp ’08. New York, NY, USA: ACM, 2008, pp. 242–251. [Online]. Available:
http://doi.acm.org/10.1145/1409635.1409668
[20] X. Jiang, M. Van Ly, J. Taneja, P. Dutta, and D. Culler, “Experiences with a high-fidelity wireless
building energy auditing network,” in Proceedings of the 7th ACM Conference on Embedded
Networked Sensor Systems, ser. SenSys ’09. New York, NY, USA: ACM, 2009, pp. 113–126.
[Online]. Available: http://doi.acm.org/10.1145/1644038.1644050
[21] K. Aberer, M. Hauswirth, and A. Salehi, “A middleware for fast and flexible sensor
network deployment,” in Proceedings of the 32Nd International Conference on Very Large
Data Bases, ser. VLDB ’06. VLDB Endowment, 2006, pp. 1199–1202. [Online]. Available:
http://dl.acm.org/citation.cfm?id=1182635.1164243
[22] J.-Y. Cheng, M.-H. Hung, and J.-W. Chang, “A zigbee-based power monitoring system with direct
load control capabilities,” in Networking, Sensing and Control, 2007 IEEE International Conference
on, April 2007, pp. 895–900.
[23] Y.-W. Bai and C.-H. Hung, “Remote power on/off control and current measurement for home electric
outlets based on a low-power embedded board and zigbee communication,” in Consumer Electron-
ics, 2008. ISCE 2008. IEEE International Symposium on, April 2008, pp. 1–4.
[24] P. Rohitha, P. Kumar, N. Adinarayana, and T. Rao, “Wireless networking through zigbee technology,”
vol. 2, no. 7. IJARCSSE, Jul. 2012, pp. 49–54.
[25] J. Han, H. Lee, and K.-R. Park, “Remote-controllable and energy-saving room architecture based
on zigbee communication,” Consumer Electronics, IEEE Transactions on, vol. 55, no. 1, pp. 264–
268, February 2009.
[26] S. Resendes, P. Carreira, and A. C. Santos, “Conflict detection and resolution in home
and building automation systems: a literature review,” Journal of Ambient Intelligence
and Humanized Computing, vol. 5, no. 5, pp. 699–715, 2014. [Online]. Available:
http://dx.doi.org/10.1007/s12652-013-0184-9
[27] A. T. Kaliappan, S. Sathiakumar, and N. Parameswaran, “Flexible power consumption management
in smart homes,” in Proceedings of the International Conference on Advances in Computing,
73
Communications and Informatics, ser. ICACCI ’12. New York, NY, USA: ACM, 2012, pp. 161–167.
[Online]. Available: http://doi.acm.org/10.1145/2345396.2345424
[28] S. N. Patel, T. Robertson, J. A. Kientz, M. S. Reynolds, and G. D. Abowd, “At the flick
of a switch: Detecting and classifying unique electrical events on the residential power
line,” in Proceedings of the 9th International Conference on Ubiquitous Computing, ser.
UbiComp ’07. Berlin, Heidelberg: Springer-Verlag, 2007, pp. 271–288. [Online]. Available:
http://dl.acm.org/citation.cfm?id=1771592.1771608
[29] S. Gupta, M. S. Reynolds, and S. N. Patel, “Electrisense: Single-point sensing using emi
for electrical event detection and classification in the home,” in Proceedings of the 12th ACM
International Conference on Ubiquitous Computing, ser. UbiComp ’10. New York, NY, USA: ACM,
2010, pp. 139–148. [Online]. Available: http://doi.acm.org/10.1145/1864349.1864375
[30] L. Jiang, S. Luo, and J. Li, “An approach of household power appliance monitoring based on ma-
chine learning,” in Intelligent Computation Technology and Automation (ICICTA), 2012 Fifth Inter-
national Conference on, Jan 2012, pp. 577–580.
[31] G. W. Hart, “Nonintrusive appliance load monitoring,” Proceedings of the IEEE, vol. 80, no. 12, pp.
1870–1891, Dec 1992.
[32] M. Zeifman and K. Roth, “Nonintrusive appliance load monitoring: Review and outlook,” IEEE Trans-
actions on Consumer Electronics, vol. 57, no. 1, pp. 76–84, February 2011.
[33] F. Englert, T. Schmitt, S. Koßler, A. Reinhardt, and R. Steinmetz, “How to auto-configure your
smart home?: High-resolution power measurements to the rescue,” in Proceedings of the Fourth
International Conference on Future Energy Systems, ser. e-Energy ’13. New York, NY, USA:
ACM, 2013, pp. 215–224. [Online]. Available: http://doi.acm.org/10.1145/2487166.2487191
[34] X. Jiang, S. Dawson-Haggerty, P. Dutta, and D. Culler, “Design and implementation of a high-
fidelity ac metering network,” in Proceedings of the 2009 International Conference on Information
Processing in Sensor Networks, ser. IPSN ’09. Washington, DC, USA: IEEE Computer Society,
2009, pp. 253–264. [Online]. Available: http://dl.acm.org/citation.cfm?id=1602165.1602189
[35] Y. Kim, T. Schmid, Z. M. Charbiwala, and M. B. Srivastava, “Viridiscope: Design and
implementation of a fine grained power monitoring system for homes,” in Proceedings of the 11th
International Conference on Ubiquitous Computing, ser. UbiComp ’09. New York, NY, USA: ACM,
2009, pp. 245–254. [Online]. Available: http://doi.acm.org/10.1145/1620545.1620582
[36] A. Fuchs, S. Gurgens, and C. Rudolph, “A formal notion of trust – enabling reasoning about security
properties,” in Trust Management IV, ser. IFIP Advances in Information and Communication
74
Technology, M. Nishigaki, A. Jøsang, Y. Murayama, and S. Marsh, Eds. Springer Berlin Heidelberg,
2010, vol. 321, pp. 200–215. [Online]. Available: http://dx.doi.org/10.1007/978-3-642-13446-3 14
[37] N. LLC., “No Outage,” accessed: 2015-12-23. [Online]. Available: http://www.nooutage.com
[38] N. Klugman, J. Rosa, P. Pannuto, M. Podolsky, W. Huang, and P. Dutta, “Grid watch: Mapping
blackouts with smart phones,” in Proceedings of the 15th Workshop on Mobile Computing Systems
and Applications, ser. HotMobile ’14. New York, NY, USA: ACM, 2014, pp. 1:1–1:6. [Online].
Available: http://doi.acm.org/10.1145/2565585.2565607
[39] Chacon, “Chacon Energy Meter,” accessed: 2015-11-26. [Online]. Available: http://www.chacon.
be/en/
[40] HomeSeer, “HomeSeer,” accessed: 2015-11-26. [Online]. Available: http://www.homeseer.com
[41] S. N. Patel, K. N. Truong, and G. D. Abowd, “Powerline positioning: A practical sub-room-level
indoor location system for domestic use,” in Proceedings of the 8th International Conference
on Ubiquitous Computing, ser. UbiComp’06. Berlin, Heidelberg: Springer-Verlag, 2006, pp.
441–458. [Online]. Available: http://dx.doi.org/10.1007/11853565 26
[42] A. Das and A. Ganesh, “A control mechanism for power management of electrical devices using
android phone in a zigbee network,” in Proceedings of the Third International Symposium on
Women in Computing and Informatics, ser. WCI ’15. New York, NY, USA: ACM, 2015, pp. 79–86.
[Online]. Available: http://doi.acm.org/10.1145/2791405.2791436
[43] T. Weng, A. Nwokafor, and Y. Agarwal, “Buildingdepot 2.0: An integrated management system for
building analysis and control,” in Proceedings of the 5th ACM Workshop on Embedded Systems
For Energy-Efficient Buildings, ser. BuildSys’13. New York, NY, USA: ACM, 2013, pp. 7:1–7:8.
[Online]. Available: http://doi.acm.org/10.1145/2528282.2528285
[44] Google. (2016) Dashboards — Android Developers. Online; accessed 12-June-2016. [Online].
Available: https://developer.android.com/about/dashboards/index.html?hl=en
[45] ——. (2016) BroadcastReceivers — Android Developers. Online; accessed 19-September-2016.
[Online]. Available: https://developer.android.com/reference/android/content/BroadcastReceiver.
html
[46] ——. (2016) AsyncTask — Android Developers. Online; accessed 19-September-2016. [Online].
Available: https://developer.android.com/reference/android/os/AsyncTask.html
[47] D. Hipp. (2000) About SQLite. Online; accessed 19-September-2016. [Online]. Available:
https://sqlite.org/about.html
75
[48] NanoHTTPD. (2016) NanoHTTPD – a tiny web server in Java. Online; accessed 19-September-
2016. [Online]. Available: http://nanohttpd.org
[49] Google. (2016) Services — Android Developers. Online; accessed 19-September-2016. [Online].
Available: https://developer.android.com/guide/components/services.html
[50] ——. (2016) IntentFilter — Android Developers. Online; accessed 19-September-2016. [Online].
Available: https://developer.android.com/reference/android/content/IntentFilter.html
[51] ——. (2016) Manage Your App’s Memory — Android Developers. Online; accessed 6-October-
2016. [Online]. Available: https://developer.android.com/topic/performance/memory.html
[52] D. Tudor, A. Stancovici, B. Popescu, V. Cretu, D. Tudor, and G. Reisinger, “Zombee:
A home automation prototype for retrofitted environments,” in Proceedings of the 2Nd
International Conference on PErvasive Technologies Related to Assistive Environments,
ser. PETRA ’09. New York, NY, USA: ACM, 2009, pp. 25:1–25:7. [Online]. Available:
http://doi.acm.org/10.1145/1579114.1579139
76