DroidEnergy - Detecting and Alerting Users of Power Supply Failures

Transcription

1 DroidEnergy - Detecting and Alerting Users of Power Supply Failures Gonç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

2

3 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 António, 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, João Miguel, Leonel, Gilda, João Paulo and uncle Hélder for also being part of my life. To my girlfriend Inês 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.

4

5 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 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

6

7 Resumo Numa sociedade em que o número de dispositivos electrónicos aumenta cada vez mais, muitos destes dispositivos não toleram falhas de energia prolongadas. Por exemplo, uma falha de energia com uma duração superior a duas horas poderá estragar a comida dentro de um frigorífico ou um sistema de videovigilância poderá ficar inutilizável. Actualmente as soluções que tentam tratar esta problemática apenas oferecem um leque limitado de monitorização e controlo de dispositivos electrónicos ou são produtos proprietários que se ligam a um servidor na nuvem e em que podem ser programados para activar/desactivar tomadas elétricas. O objectivo deste trabalho passa por desenvolver e avaliar um sistema que seja capaz de detectar e monitorizar falhas de energia, de avisar os utilizadores da ocorrência destes eventos, através de SMS ou , e que ofereça um conjunto de configurações flexíveis para que o utilizador o possa configurar de acordo com as suas preferências. A solução proposta, chamada DroidEnergy, é um sistema composto por uma aplicação desenvolvida em Android e por um servidor web para funções de back-office, em que apenas é necessário ligar o telemóvel a qualquer tomada eléctrica. Para além disso o utilizador poderá configurar várias característica de forma fácil e rápida, tanto directamente no telemóvel como também através de uma página web. Por fim, descrevemos o desenho e implementação da aplicação, assim como os desafios que terão de ser ultrapassados de modo a que o solução seja validada. Palavras Chave Detecção de falhas de energia; Android; Automação; Alerta ao utilizador v

8

9 Contents 1 Introduction Motivation Objectives Proposed Solution Overview Contribution Background and Related Work Basic Concepts Uninterruptible Power Supply (UPS) Smart Meters Advanced Metering Infrastructure (AMI) Energy Monitoring at Home Technologies Power backup solutions Home Automation Summary Architecture System overview Application components Algorithm overview User configurations Implementation Broadcast Receivers UpdateBatteryReceiver Energy Receiver IncomingSMSReceiver LoggerReceiver InternetConnectionReceiver vii

10 4.2 Alerts Data Storage SQLite Assets folder Shared Preferences Web Server Activities Main Activity Devices Activity Preferences Menu Evaluation Performance tests RAM usage Battery usage Usability tests Validation Survey Testing with users Summary Conclusion System Limitations and Future Work Conclusion viii

11 List of Figures 2.1 Advanced Metering Infrastructure (AMI) Building Blocks [1] Solution overview DroidEnergy application components Database class UML Machine state diagram representation of the proposed solution DroidEnergy modules Web server statistics page Examples of the main and location screens Examples of the preferences screen Android devices connected to the computer Information retrieved using BatteryStats Chart representation of the answers given in the validation survey Chart representation of the answers given to filter the appropriate participants to participate in the rest of the survey and to determine if they would pay for the presented system Chart representation of the answers given to the question 1 (yy axis: number of responses) Chart representation of the answers given to the question 2 (yy axis: number of responses) Chart representation of the answers given to the question Chart representation of the answers given to the question Time each user took to complete each scenario in mm:ss Rated scenario difficulty by user Results of the post-testing survey ix

12 x

13 List of Tables 2.1 Comparison between the presented solutions according to the objectives Description of each class and function in our solution Comparison between the devices used in the evaluation Comparison between the available memory in both devices Results of the three hour RAM usage test xi

14 xii

15 Listings 4.1 Code to retrieve the charging information Definition of the runnable class that is executed when an outage is detected Code used to save the log file in internal and external storage Code to verify if the external storage is available Code to verify if internet connection is available Code to authenticate the user and send the Telephony service to retrieve phone type SQL statement to create the Device table Code to retrieve a device from the database Server request handling code (excerpt) Code used to update the main screen information during an outage Adds the preference fragment to the activity Function that retrieves and outputs the memory information of the device xiii

16 xiv

17 Acronyms AoO CD AoR SMS SIM LAN LANs IP API PDU SMTP MIME APK JS CSS SQL SSL HTML HTTP Alert on Outage Check Devices Alert on Reestablishment Short Message Service Subscriber Identification Module Local Area Network Local Area Networks Internet Protocol Application Programming Interface Protocol Data Unit Simple Mail Transfer Protocol Multipurpose Internet Mail Extensions Android Application Package JavaScript Cascading Style Sheets Structured Query Language Secure Sockets Layer HyperText Markup Language Hypertext Transfer Protocol xv

18 URI XML UPS AMI MDMS NAHB HAS SeMF OS GC adb Uniform Resource Identifier extensible Markup Language Uninterruptible Power Supply Advanced Metering Infrastructure Meter Data Management System National Association of Home Builders Home Automation Systems Security Modeling Framework Operating Systems Garbage Collections Android Debug Bridge xvi

19 1 Introduction Contents 1.1 Motivation Objectives Proposed Solution Overview Contribution

20 2

21 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 techniques. Such contributions include energy monitoring systems [3 5] and context-aware power management [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 outages, 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 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

22 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 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 , 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 infrastructure, 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

23 2 Background and Related Work Contents 2.1 Basic Concepts Energy Monitoring at Home Technologies Summary

24 6

25 There is vast literature regarding energy-efficient mechanisms and power management in smart environments. 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 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 outage 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 seconds [10] Smart Meters Smart Meters are metering devices embedded in systems such as electrical meters [11]. When compared 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

26 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, providing 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

27 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

28 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 configured 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 appliance [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

29 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 appliances 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 we present Home Automation solutions that are related with this research work. We describe the various solutions according to our requirements, in order to make a proper comparison between them and the proposed solution 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 generator 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

30 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 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 $ to $1, 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

31 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 consumption, 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 installation 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

32 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

33 Configurable - Is the solution highly configurable? Notifications - Can the solution notify the user? Not applicable if information regarding the notifications is not present Table 2.1: Comparison between the presented solutions according to the objectives System Cost Detection Configurable Notifications No Outage UPS System [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] At the Flick of a Switch [41] Smart Power Meter [12] Android Zigbee network [42] Wrist home controller [15] BuildingDepot 2.0 [43] $ $1, No Yes Yes No information Yes Yes N/A No information Yes No N/A No information 2 No Yes No $58 3 No Yes No No information No Yes No 1 (Used) Price range from $60.98 to $ according to the phones used for evaluating the solution 2 There is limited information in what components were used. The price of the Zigbee s components 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

34 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 /sms. 16

35 3 Architecture Contents 3.1 System overview Application components Algorithm overview User configurations

36 18

37 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 components, 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 appliances 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 infrastructure 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 account which is used to send any 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

38 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 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

39 (ii) choosing to be alerted via and (iii) adding the 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 :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

40 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 . 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 configured 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

41 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, DroidEnergy 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 outage time of occurrence, the current outage time and which devices were affected. If none of the devices 23

42 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 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

43 Table 3.1: Description of each class and function in our solution Class Sentinel Device Function Deploy Sentinel Power On? Send Reestablishment Alert? Alert Type? Check Devices Send Alert Sleep Log Changes Description Responsible for deploying the monitoring tools Home device (e.g. refrigerator, dryer) which contains information about the device (e.g name) Description When an outage is detected, the system deploys a sentinel, that will monitor the outage Verifies if the smartphone is charging Verifies if the user chose to receive an alert when the outage ends 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 outage occurs; [check devices] - if the user chose to monitor the devices. Retrieves the device list and for each device checks if corresponding time was exceeded by the outage time Sends an alert to the user with information about the occurrence of the outage and the devices affected On success, this function sends a message according to the 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. Sentinel sleeps for a defined amount of time too emulate a realtime system 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 , or both. The user may specify a different account 25

44 from the sign in account to send the alerts. We chose this configuration option since some SMTP servers block 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

45 4 Implementation Contents 4.1 Broadcast Receivers Alerts Data Storage Web Server Activities

46 28

47 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

48 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 registered 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 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

49 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 UpdateBatteryReceiver. 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() { 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

50 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 reestablishment 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 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 getdisplaymessagebody() 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

51 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

52 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 } InternetConnectionReceiver When the application detects that an alert should be sent and the user wants to receive the alert via , 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 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

53 4.2 Alerts As stated in section 3.3 there are three different types of alerts. In the case of the alerts sent via , 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 - represents the priority of the network 5 * 1 = Wifi 6 * 2 = Mobile 7 * 3 = Both 8 */ 9 public boolean checknetworkconnectionbypriority(int priority){ ConnectivityManager connmgr = (ConnectivityManager) 12 context.getsystemservice(context.connectivity SERVICE); 13 boolean isavailable = false; switch (priority){ 16 case 1: 17 NetworkInfo networkwifiinfo = connmgr.getnetworkinfo( ConnectivityManager.TYPE WIFI); 35

54 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 . Although Android offers a mechanism to generate an and start an activity via an intent with the information, it requires the user to choose an 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 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 (SMTP), tries to connect using the credentials set by the user in the preference menu and sends the . As stated in section 3.4 some mail servers may block accounts that generate too many s, 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

55 Listing 4.6: Code to authenticate the user and send the 1 Transport transport = getmailsession.gettransport("smtp"); 2 transport.connect("smtp.mail.xpto.com", "username", "password"); 3 transport.sendmessage(generat message, generat message.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

56 Shared Preferences In the following sections we described the functionality and purpose of each one of the storage mechanisms 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 , which is also unique. Furthermore 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

57 Listing 4.9 shows an excerpt of the device repository code, which is used to get device information. 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 getdevice(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 getcolumnindex(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 } 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

58 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 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 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 Transfer 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 constructors, 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 created 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

59 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 between 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) 2 public Response serve(ihttpsession session) { 3 String uri = session.geturi(); 41

60 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 )); 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 application or one can request an account via the web server. When an user chooses the second option, an is sent to the used to log in in the application. If the user accepts the request, the application 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

61 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

62 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"; public void updatenextevent(final long time, final String type){ 9 MainActivity.this.runOnUiThread(new Runnable() { 11 public void run() { 12 TextView nextevent = (TextView) findviewbyid(r.id.next event); 44

63 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

64 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 Receiver 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 EnergyReceiver 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) 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 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

65 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 address of the first figure. (a) Home screen (b) Location screen Figure 4.3: Examples of the main and location screens 47

66 (a) Preferences main screen (b) configuration screen Figure 4.4: Examples of the preferences screen 48

67 5 Evaluation Contents 5.1 Performance tests Usability tests Summary

68 50

69 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 hardware specifications cost around 55 e in The second phone is a Motorola Galaxy Nexus 6 running Android Marshmallow (version 6.0.1) whose cost was around 600 e when it was released, also in 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 Internal Memory 4 GB 64 GB OS Version Battery capacity Battery Stand-by 1650 (mah) 3220 (mah) 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 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

70 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 we present the results of the RAM usage testing and in Section we present the tests and results of the battery profiling tests. 52

71 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 L. 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/ l+" MB"); 10 Log.i(TAG, "Total memory "+memoryinfo.totalmem/ l+" MB"); 11 Log.i(TAG, "Heap size "+Runtime.getRuntime().maxMemory()/ L+" MB"); 12 Log.i(TAG, "App Threshold "+memoryinfo.threshold/ l+" MB"); 13 } // 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

72 Table 5.2: Comparison between the available memory in both devices Devices White-branded phone Nexus 6 Total Available Heap size Threshold 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 monitoring. 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 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

73 Table 5.3: Results of the three hour RAM usage test White-branded Nexus 6 Scenario # RAM peek 1 Number of GC 2 Scenario Scenario Scenario Scenario Scenario Scenario RAM maximum value (in MB) measured during the execution of the corresponding scenario 2 Counted between the previous scenario and the end of following scenario 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 smartphones 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 smartphone. The BatteryStats is part of the Android framework and is responsible for retrieving the smartphone 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

74 Configure the 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 commandline tool that enables the communication between a computer and an Android emulator or a Androidpowered 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 command 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

75 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

76 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 Validation Survey Before the validation specific questions, we asked a few questions to characterize the group of participants. 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

77 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.99 e as we can see in Figure 5.4(c). (a) Chart representation of the answers given to the question Do you own a smartphone? (b) Chart representation of the answers given to the question Would you consider using a mobile app that detects power outages and alerts you even if you are not at home? (c) Percentage of participants that would pay for each price group Figure 5.4: Chart representation of the answers given to filter the appropriate participants to participate in the rest of the survey and to determine if they would pay for the presented system 59

78 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

79 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

80 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 credentials needed to send the 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 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, instead 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

81 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 user took to complete the three scenarios (b) Representation of the time each inexperienced user 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

82 reduction of approximately 27% (one minute) in completion time. When comparing the average time between 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 complete 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 inexperienced 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 application 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

83 (a) Results of the scenario difficulty for the experienced users (b) Results of the scenario difficulty for the inexperienced 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) Validation survey 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 subtracted 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