94
DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc ¸ alo 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 Valadas Supervisor: Prof. Paulo Jorge Pires Ferreira Member of the Committee: Prof. Ricardo Jorge Feliciano Lopes Pereira November 2016

DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

  • Upload
    others

  • View
    11

  • Download
    0

Embed Size (px)

Citation preview

Page 1: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 2: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina
Page 3: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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.

Page 4: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina
Page 5: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 6: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina
Page 7: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 8: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina
Page 9: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 10: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 11: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 12: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

x

Page 13: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 14: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

xii

Page 15: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 16: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

xiv

Page 17: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 18: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 19: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

1Introduction

Contents

1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3 Proposed Solution Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.4 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1

Page 20: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

2

Page 21: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 22: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 23: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 24: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

6

Page 25: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 26: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 27: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 28: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 29: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 30: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 31: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 32: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 33: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

• 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

Page 34: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 35: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

3Architecture

Contents

3.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2 Application components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3 Algorithm overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 User configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

17

Page 36: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

18

Page 37: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 38: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 39: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

(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

Page 40: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 41: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 42: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 43: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 44: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 45: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 46: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

28

Page 47: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 48: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 49: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 50: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 51: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 52: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 53: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 54: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 55: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 56: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

• 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

Page 57: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 58: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 59: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 60: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 61: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 62: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 63: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 64: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

• 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

Page 65: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 66: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

(a) Preferences main screen (b) E-mail configuration screen

Figure 4.4: Examples of the preferences screen

48

Page 67: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

5Evaluation

Contents

5.1 Performance tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5.2 Usability tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.3 Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

49

Page 68: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

50

Page 69: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 70: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 71: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 72: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 73: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 74: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

• 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

Page 75: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 76: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 77: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 78: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 79: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 80: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 81: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 82: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 83: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

(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

Page 84: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

(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

Page 85: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

6Conclusion

Contents

6.1 System Limitations and Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

6.2 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70

67

Page 86: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

68

Page 87: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 88: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 89: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 90: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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&#38;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

Page 91: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

[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

Page 92: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 93: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

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

Page 94: DroidEnergy - Detecting and Alerting Users of Power Supply ... · DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonc¸alo Nuno de Brito Galado da Costa Grazina

[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