An Energy Competition Dashboard

(1)

An Energy Competition Dashboard

Bachelor’s thesis

July 17, 2015

Student: Jeroen Brandsma, Michel Dekker

Primary supervisor: prof. dr. A. Lazovik, drs. F. Nizamic

Secondary supervisor: dr. R. Smedinga

(2)

In this thesis we will aim at the human aspect regarding energy consumption. The literature research will aim at current energy consumption reduction methods and at how to enforce the competition feeling between people. Based on these results a dashboard is build that is accessible by the test group. This test group consists of five employees of the University of Groningen, who made their office available for our experiment.

Preliminary results show that our application could work. However, we cannot give any well founded conclusion since we were not able to gather enough data because of the time constraints of this project. In the future more research should be done to get enough data to give any real conclusions.

(5)

Chapter 1 Introduction

This chapter provides some background information about the project and explains the research goals for this thesis. The primary goal for this thesis is developing a system which motivates users to reduce energy consumption.

First, section 1.1 provides the context of the research. This includes why the system is developed, where the system is tested and which previous developed systems will be used as part of this research. Section 1.2 gives a more extensive explanation about the research goals for this project. In section 1.3 the relevance and contributions are listed. Finally, section 1.4 gives an overview of this remainder of this thesis.

1.1 Context

1.1.1 The idea

In 2012 the University of Groningen organized a contest to make the University more sustainable. Faris Nizamic and Tuan Anh Nguyen proposed a prize winning plan [1] to make the Bernoulliborg in Groningen a more sustainable building. During the last few years the plan had some good results [2].

The proposal included ideas to reduce waste, water consumption and energy consumption of the Bernouilliborg. One of the ideas was to make people more aware of their energy and water consumption using a real-time utility display [1, p. 8]. A display was added to the building’s lobby to inform occupants on the building’s total energy and water consumption. This bachelor thesis extends this idea. The goal of the project is to make occupants of the building better aware of their individual energy consumption.

To achieve this goal we developed a personal energy dashboard. This dashboard informs occupants on their individual energy consumption. As an additional effort to save energy the dashboard includes features which allows occupants to compare their energy consumption to the energy consumption of other occupants of the building. This feature was added in a playful manner to even further increase energy savings.

1.1.2 Test environment

The system was developed and tested in the Bernoulliborg in Groningen. The Bernoulliborg can accom- modate 350 staff members and 500 students [3]. The building’s dimensions are 33 by 83 meter and a height

(6)

of 27 meter.

During the development of this project five offices were equipped with sensors to measure energy consumption. All the offices were occupied by members of the distributed systems group of the computing science department. The offices are located on the fifth floor of the Bernoulliborg.

1.1.3 Energy measurements

For the original proposal a system was developed to measure, store and retrieve energy consumption data.

The system developed by Marcel Jillings and Sijmon Heitmeijer, as described in their master thesis [4], meets our requirements for measuring, storing and retrieving energy consumption data. Because this system is already up and running in the Bernoulliborg and all the required hardware was at our disposal we used their system as a source for the consumption data.

During their master thesis they compared multiple sensors for measuring energy consumption. Those sensors were used as a part of a greater system, consisting of multiple loosely coupled software components. For this project we use a subset of those software components to measure, store and retrieve the energy consumption data.

1.2 Research goals

The primary goal of this project is to develop a system which encourages its users to reduce energy consumption. To achieve this we need to answer the following questions.

• Which elements and information should be part of a dashboard for energy competition between office occupants? To create an environment that stimulates users to actually think about their energy consumption and adapt their behavior in that way, we need to include the right motivating elements.

• What could be considered energy savings for a workplace and how should this be determined?

All the primary functions of the dashboard rely on the amount of energy saved. This means we have to determine if someone is actually saving energy, we need to design an algorithm that takes the consumption data of an office and calculates the saved energy.

To answer these questions, we should give a definition for the term workplace. We consider a workplace to consist of all personal electric devices, for example a PC, monitors and a office telephone. All shared electric devices like lighting or heating are not considered to be part of the workplace. The energy consumption of the equipment of this particular person is measured.

1.3 Contributions

We developed a system that can measure the energy savings of office occupants. However, there are more things possible with the developed system and algorithms.

• The system is ready for more research to see if it has long-term effects. In the time we have for doing this bachelor project, we only have time to retrieve short-term data. This means we cannot test whether the system has any long-term effects on energy consumption.

• The system could be used in any other office. Because the system is developed in an office environment, it is easy to export it to any other office building. This also includes other university

(7)

buildings.

• Potentially the system could be ported to the home environment. The requirements for such a system would be a little bit different from the office environment, however our algorithm for energy savings could be a good starting point.

• We developed an algorithm to determine if someone is saving energy or not. The most important part of the system is to determine if someone is actually saving energy or not. This idea could be applied to other systems as well.

1.4 Overview

In the next chapters we will further explain our project. In chapter 2 we do literature research on energy saving techniques and gamification. After this we define the idea and design of our project in chapter 3.

Then in chapter 4 we discuss the techniques used to develop and implement our idea. When our prototype was finished, we held a competition between the office occupants. These results are gathered and discussed in chapter 5. Finally, we come to a conclusion in the last part, chapter 6.

(8)

Chapter 2 Related work

As explained in chapter 1 the primary goal of the system is to reduce energy consumption. Section 2.1 lists different other research efforts to reduce energy consumption. Secondly, section 2.2 lists related research papers on using game concepts in non-game contexts, also known as gamification. We also tried to find research on baselines or how to determine energy savings. Unfortunately we could not find any research which focuses on determining the energy savings on an individual level. This means we have to develop this ourselves.

2.1 Energy saving

In 2030 the European Union wants to cut the annual energy consumption by 27% [5]. This is one of reasons that many research is done on energy consumption and energy savings. Many of these researches focus on automatic Building Management Systems (BMS) to cut down power consumption. However, these BMS systems mostly act on floor or wing level and therefor are not optimal [6]. It would be more efficient if it could monitor and control individual offices [4].

Besides saving energy by a BMS system, lighting is another unnecessary source of big energy consumption [7]. Many different systems have been developed in order to automatically control the lights in an office or even landscape offices. B. Roisin et al showed that is does matter where offices are located and how they are oriented [8]. When an office is located in Athens and is oriented towards the sun, it can save up to 61% only for lighting. This number decreases to 45% when an office is oriented away from the sun in Stockholm. On the other hand, when an office is oriented towards the sun, it can become hotter in the summer compared to the offices who are towards the sun, which can lead to higher energy consumption by using air conditioning.

2.2 Gamification

Research in the field of gamification is relatively new, the first documented use was in 2008 [9]. From that moment on “gamification” is a heavily contested term [9]. There are two main related concepts. The first is “the increasing adoption, institutionalization and ubiquity of (video) games in everyday life” [9].

This definition of gamification means that the adoption of games in everyday life becomes more common.

However, in our thesis we adopt the second concept that is defined [9]. This concept views gamification as a way to make everyday life tasks or products more engaging and is officially stated as follows “game elements should be able to make other, non-game products and services more enjoyable and engaging as well” [9].

(9)

In 2009 Power Agent was presented [10]. Power Agent is a game designed to encourage teenagers and their families to reduce energy consumption in the home. One of the elements to achieve this is to encourage competition between families. Two groups played the game (figure 2.1) for ten days and achieved great results. However, the researchers could not conclude any post game effects on behavior. This competition element is what we will use in our project. We want to create a competition between users of the system which ideally will affect their behavior on the long term.

Figure 2.1: Screenshots of the Power Agent competition

To develop our dashboard we want to use the most effective elements. Leaderboards, levels, badges and challenges are all received positive by the users, they also achieve good results on the short term [11]. To engage users in the long term you need internal motivation instead of external motivation [12]. This means internal motivation needs to be fueled instead of just relying on the external motivation of leaderboards and challenges.

(10)

Chapter 3 Concept

The third chapter provides information about the answers for the research questions and also for the design of our system. In section 3.1 and 3.2 some information about the user interface and the architectural design is provided. To retrieve the data that is needed for our system we use the API that is created by a former master thesis, information about this can be found in section 3.2.1. To calculate energy savings from this data we needed to develop an algorithm. This algorithm is explained in section 3.3.

3.1 Design

Our eventual goal is to create an energy competition dashboard. To do this, we have to answer the research questions. One of these questions is what elements and information we should include in such a system.

In chapter 2 we found out that the most effective gamification elements are: leaderboards, levels, badges and challenges. Since we do not have time to implement all these elements, we chose to implement the leaderboards and the badges. Besides this there is also a dashboard page with an overview for the user and a consumption page with raw data.

To make the application easily accessible for the users, we chose to make a web application. This web application needs to be simple and easy to use. Because of this requirement we chose to have just 4 view pages.

• Dashboard

The dashboard is the first that is shown when a user logs in. This page includes the most important leaderboards so a user instantly knows how well he or she did in the last period. First of all a user sees the total energy consumption of the last day, week and month. In the same table is also shown how much energy the user saved in rates. After this a summary of the leaderboards is displayed. The current and previous daily, weekly and monthly leaderboards are displayed.

(11)

Figure 3.1: Screenshot: Dashboard

• Leaderboard

On the leaderboard page we show a more detailed leaderboard than on the dashboard page. In this section you can see the leaderboards for any date. You can also specify if you want to see the daily, weekly or monthly tables. Besides the total energy consumption and the percentage of energy saved, we also show the absolute value of the energy savings. We only show the first three users. We do not show more users because we do not want to discourage users who are mostly on the bottom of the ranking. Hopefully the lower-ranked users will get motivated when do not appear in the top three.

Figure 3.2: Screenshot: Leaderboard

• Consumption

In this section we display the raw consumption data of the user. A graph with all the raw data points is displayed. The user can update the graph by changing some options. If a user wants so see the

(12)

consumption data it can simply pick another date and update the graph. A user can also change some graph render settings, which will be explained in more detail in section 3.3. Next to the graph is a table with some precise values about the energy consumption.

Figure 3.3: Screenshot: Consumption

• Medals

The medal page displays all the medals won by the users. The users are ranked first by the number of gold medals, secondly by the number of silver medals and last by the number of bronze medals.

A user will receive a medal if it is in the top three of a daily, weekly or monthly ranking. Since it is harder to obtain a medal in a monthly ranking, this medal has a higher value than a medal in a weekly or daily ranking.

(13)

Figure 3.4: Screenshot: Medal table

Besides these 4 main pages there are a few more pages. First of all there is the settings page. Here a user can change some settings like changing an avatar or reset the password. On the profile page you can view your personal account, your name, avatar and achieved medals.

3.2 Architecture

The second research question we have is to define what energy saving is. To do this we need an algorithm that takes all the consumption data and gives the amount of energy saved. So before the algorithm can be defined, we need the consumption data of all users. We have access to 5 plugwise devices [13]. These devices create a wireless network in which they send the data. The data can then be read by a plugwise stick. This stick is put in a usb port of a computer and becomes part of the wireless network. To get useful data out of this a separate system had to be developed. This was done by two former master students [4].

They developed a system that takes the data of the plugwise devices and puts it in a database. After this an API was created which gives us the opportunity to reach the data very easily. This data is specified in more detail in section 3.2.1 below. After this we can use the data from the API. How we process this data is shown in section 3.3.

3.2.1 Data description

As described in de part above we can get to the generated data by accessing the API delivered with the database. We get the results of a specified energy meter for a certain period. This period can be adjusted to our needs. The device sends data every 5 minutes, this means we have 12 ∗ 24 = 288 data points per day.

The data is delivered in the human readable data format JSON (Javascript Object Notation) [14]. Figure 3.5 shows a data point that is given by the API.

Figure 3.5: JSON object A data point consists of the following 5 elements.

(14)

• timestamp

The timestamp consists of the date and time in the Amsterdam timezone, this means UTC(Coordinated Universal Time) +2 in the summertime and UTC +1 in the rest of the year.

• process_id

The process_id is a remainder of a previous project and not relevant for our project.

• sensor_id

The sensor_id is a unique identifier for a type of sensor. This means if a sensor is of the same type, it has the same sensor_id.

• instance_id

To identify a specific sensor an instance_id is given. Every sensor has its own instance_id.

• value

The value that is measured by the energy meter in Watt(W).

3.3 Energy saving algorithm

After we received the consumption data of the offices, we could start developing an algorithm to determine energy savings. This algorithm has some requirements that all should be taken into account. For example if a user has a day off, we should not consider this as energy saving. We also want to create a fair competition so we decided to compare energy savings percentages. We calculate this percentage by dividing the energy saved by the total energy consumption the user could have made if no energy was saved. We use the following definitions:

• First time consumption

The first time during the day the energy consumption, for a certain amount of succeeding minutes, has a higher value than the consumption value at the beginning of the day. This way, users who leave some of their equipment on at night will not start their work day at 00:00.

• Last time consumption

The last time during the day the energy consumption, for a certain amount of succeeding minutes, has a higher value than the consumption value at the end of the day. This way, users who leave some of their equipment on at night will not end their work day at 23:59.

• Work day

The period between the first time during the day and the last time during the day energy is consumed.

• Consumption baseline

The user his energy consumption during normal usage.

• Energy saving

Energy will be considered “saved” when a user uses less energy than his consumption baseline during the work day.

3.3.1 Consumption baseline

As mentioned above the consumption baseline is defined as the user his energy consumption during normal usage. But since energy consumption can vary over a day, how can we determine what the baseline is? We decided to test some different consumption baselines. We used a day for where it is clearly visible what area should be the energy savings. As can be seen in figure 3.6 the user gets into his office past 9 am and turns off all his devices around 10 am. He came back just before 1 pm and around 3 pm. Just before 5 pm

(15)

he came to his office again and left around 7:30 pm. We consider most of the empty space between the first and last data point energy savings.

Figure 3.6: Raw consumption data

Previous data as baseline

Our first idea was to use the consumption data of some time before the current day. For example, if we look 5 workdays back in time, we take the average of these 5 days and take this as a baseline. This could work pretty well, however if someone adds a monitor his baseline is completely wrong for the following 5 days.

The baseline will become better day after day, but this is not good enough for us. We want an algorithm that works for all days, and is therefor not dependent on equipment.

Average consumption baseline

After rejecting the option above, we thought about a new method based on the average. To overcome the problem of adding or removing energy consumers, we decided to test the possibility of a baseline as the average of the current day. This baseline takes the average of all data points of that day. Every point where the energy consumption is below this baseline will be made green as a sign of energy savings. As can be seen in figure 3.7 this is a little above 20 Watt. If we look at this, this does not really make sense. The baseline should be higher since his standard consumption line is higher than the baseline shown. In this example the baseline was calculated with all data points of the specified day. We could modify this a bit and use only the data points that are retrieved between the start of the workday and the end of it. This way the baseline would become higher, but again not high enough since we still keep the lowest values into account.

Ranges consumption baseline

When we found the average approach will not work, we came up with something else. We do not want to take the lowest value into account since they pull the baseline down. This is why we decided to develop a range based consumption baseline. The range based baseline puts every data point into a specific range.

(16)

Figure 3.7: Average based consumption baseline

If a data point is not yet in a range, the algorithm will check if it falls within a current range. If this is the case the data point is added to this range. If it is not, we check if it is less than 10% away from a current range, if this is the case we put the data point in that range and expand the range to the value of the current point. We do this with all data points and when this is done we typically have a few ranges in which all data points fall. If a workday was detected we should have at least 2 ranges, a top range and a bottom range.

This can be seen in figure 3.8.

Figure 3.8: Ranges in raw consumption data

(17)

From the bottom range we take the highest value and set this value as the off state baseline. The off state baseline is the energy consumption when the user is not at work. From the highest range we take the lowest value and set this as the consumption baseline. Figure 3.9 shows the consumption baseline.

Figure 3.9: Consumption baseline in raw consumption data

After the baselines are calculated, we can determine the energy savings. All points where the energy consumption is below the consumption baseline and above the off state baseline, we consider energy consumption. If we add this to the graph, we get the following result in figure 3.10.

Figure 3.10: Energy savings in raw consumption data

(18)

Chapter 4 Realization

After we defined the answers for the research questions in chapter 3, we now implement these ideas to a real working system. To do this we define use cases in section 4.1 and some requirements in section 4.2.

After this we explain the techniques used in section 4.3 and the setup of the project in more detail in section 4.4.

4.1 Use cases

For our system we defined three groups of use cases: user, user management and data representation. We briefly discuss the different use cases here, for more detailed information on this, we refer to the use case document appendix.

• User

For a user we defined the standard user actions. A user has to be able to login, logout and reset his password. Besides this, we think it is a good idea to give users a profile. In this way someone can personalize his or her account and therefor become more attached to the system because they can view other accounts too. For this feature we need to implement a section where users can change their profile picture.

• User management

Users cannot add themselves to the system. In order to add someone we need to create an admin account. This account will be able to add and remove users. Besides this it should also be able to link a device to a user. We think this is more convenient than letting users do this by themselves.

Maybe if the system will be deployed in more rooms, it would be handy to change this for the sake of scalability.

• Data representation

The users can view the retrieved data in a few different ways. When a user logs in, he or she first comes on the dashboard page. This is an overview of the energy savings of that particular user and also an overview of the leaderboards of the last period. Secondly, users can view their own raw consumption data. For this we have a consumption view where users can see their own data and energy savings. This data is also used to generate the leaderboard, which users can also view.

Besides this there is also a medal page with the medals obtained by the users.

(19)

4.2 Non-functional requirements

Besides the requirements mentioned in the section above, there are also some requirements which are not functional but nevertheless very important.

• Low coupling

We want as less as possible coupling between the different components. This is because it should be easy to add or remove users and their devices. It also should be possible to change the plugwise devices of a user. If a plugwise device is in someway hardcoded for a user, this is not possible at all.

• Maintainability

The system should be easy to maintain. This requirement is especially important for this project because we do not know if someone will work on it after us. To make the code more understandable we will add as much documentation as we can.

• Robustness

If a part of the system crashes, this should not have any effect on the rest of the system. If for example a plugwise device will break down and no data is retrieved anymore then we do not want the leaderboard to rollover.

• Scalability

We assume the project could be a success and will be extended within the Bernouilliborg or other buildings. The system should be prepared for this. In this case all parts need to scale up as much is needed.

4.3 Used techniques

As defined in section 4.2 we have to create a maintainable, robust and scalable solution for our problem.

This means the code should be highly structured and logical. In this way other people could improve or expand the system if necessary. In the next subsections we will explain the techniques used to create a system that meets all requirements.

4.3.1 PHP with Zend Framework 2

We chose to develop the application in PHP since we are both very familiar with it [15]. PHP is a server- side scripting language created for webdevelopment in 1995. It is one of the most popular languages to develop webapplications with. PHP can very easily be abused to create bad and unstructured code. Since we want to avoid this, we chose to use the Zend Framework 2 [16]. The Zend Framework is one of the more popular PHP frameworks around on the internet [17]. To structure the code even more, we implemented the Model View Control (MVC) design pattern. This design pattern is standard integrated with the Zend Framework. MVC is created to separate the responsibilities of the different components. The code for the model, view and controller should not be mixed in the same files. For larger applications this would make terrible and unreadable code.

4.3.2 AngularJS

AngularJS is an opensource framework for webapplications [18]. It is developed in 2010 and maintained by Google and a group of developers and companies. AngularJS makes it very easy for us to handle data.

You can simply bind data to a variable and do computations with it, this can all be done with just a few

(20)

commands. Besides that AngularJS serves a Model View Controller (MVC) design pattern. Developing becomes easier with AngularJS due to the Model View Controller (MVC) design pattern and the testing possibilities. Unit and End to End tests can be designed and executed easily by using certain AngularJS testing tools. These tools are developed to make life easy for the programmer. Besides all this, AngularJS is a very nice framework to develop Single Page Applications (SPA). Since our goal was to develop such an application, this was one of the reasons to choose AngularJS as our framework.

4.3.3 Bootstrap

To make a good looking and intuitive User Interface (UI), we decided to use the Bootstrap framework [19]. Bootstrap is a front-end framework for HTML, CSS and JavaScript. Originally it was developed by some Twitter employees to make front-end development easier. Bootstrap is designed to create responsive applications. This means your application will look good no matter the size of your screen. Bootstrap consists of all sorts of components, which all can be used independently. For example, we used the date picker component. This is a component that gives a graphical representation of a calendar and lets a user pick a date.

4.3.4 Composer

As mentioned above, our application should be scalable. This also means it should be portable to other buildings. To make it easy to deploy our application, we decided to make a composer file. This file stores the dependencies we have with the right version numbers. If the application needs to be deployed to another server, we simply run de composer to install all dependencies. The composer tells the server we need version 2.4 of the Zend Framework and PHP version 5.3.2. Besides this we also map two namespaces to two paths. This is done to prevent us from typing the complete path over and over again.

(21)

4.3.5 d3js

To represent the raw consumption data in a user friendly way, we decided to present the data in a graph.

After some research we found the d3js library [20]. d3js stands for Data-Driven Documents, js stands for javascript. It is a JavaScript library which brings data to life by manipulating documents based on data.

It can create interactive and good looking graphs. Besides this it gives smooth transitions when switching between data sets. d3js works on all modern browsers and on many old browsers, this can be important since offices might not have the most up to date browsers. Figure 4.1 shows the possibilities of d3js we used.

Figure 4.1: Example of d3js possibilities

4.4 Project setup

We created several folders to split the code. We define a cache, config, data, module and public_html folder.

The cache folder contains the API data of the last 30 days. When we calculate the monthly leaderboards, we need the data of the last 30 days. If we have to get all this data for all users from the API again, it will take a lot of time. To set some global settings for different pages we have created the config folder. The data folder stores the avatars that the users can upload to personalize their accounts. We decided to separate the API code and the actual application code. These two folders are in the module folder. In the API folder we define the code for retrieving the data and the algorithm to perform computations on the retrieved data.

Besides this it also defines the logic for the other pages in our application. In the folder for application code we define the layout for the application. All HTML, CSS, JavaScript, images and libraries are stored here.

(22)

4.4.1 Global implementation

The consumption data for a day is stored in the ConsumptionDataDay class. Basically, it only stores the raw consumption data returned from the REST API. The class has some additional methods to add algorithms to its class. Multiple algorithms can be added to the ConsumptionDataDay class to calculate different metrics and manipulate data.

All algorithms should extend a ConsumptionDataDay/AlgorithmAbstract class. This simple class will contain the algorithm in the execute(ConsumptionDataDay $data) method. This method will be called from within the ConsumptionDataDay class to calculate the metrics. The ConsumptionDataDay class will provide itself as the parameter to the method.

At least, every ConsumptionDataDay/AlgorithmAbstract class has two methods: dependsOn() and provides(). All algorithms will provide some kind of statistic. For example, the NormalizeData algorithm will provide “normalizedData”. Other classes can depend on and require “normalizedData”. For example, to algorithm which calculates the amount of energy saved depends on “normalizedData”, “startTimeWork- Day”, “endTimeWorkDay” and “consumptionBaseline”. When this algorithm is called, all other algorithms which it depends on will be called as well.

The way the algorithms provide data and depend on other data has a few advantages:

• Multiple algorithms may depend on the same kind of data, for example the normalized data. The normalized data can be cached and can be reused by other algorithms.

• One algorithm can be changed without affecting the other algorithms. For example, let say we want to change the way the consumption baseline is determined. We can implement the AlgorithmAbstract class again and implement a different algorithm to determine the consumption baseline. This does not affect how the amount of energy saved is calculated. It will execute the algorithm which provides the “consumptionBaseline”.

• Other metrics and data may be added in the future without the need to change the ConsumptionData- Day class.

4.4.2 Energy savings algorithms implementation

We implemented a few standard algorithms. We explain every algorithm in detail and explain them in the order they are used to calculate the energy saving percentage.

• NormalizeData: (provides: normalizedData)

This algorithm will normalize the raw data. At the moment the plugwise devices will be polled about every 5 minutes. This algorithm will return 1 minute intervals. It will create data between the first date from the raw data and the last date from the raw data. For every minute it will take the last known value from the raw data before this time. Missing data and incorrect values (e.q. -1) will be set to the last known value as well.

• DetectRanges: (provides: ranges; dependsOn: normalizedData)

This algorithm creates a number of energy consumption ranges, or intervals. It will iterate over every value in the normalized data. Every value is added to a range if it falls within an already existing range or if it is close to an existing range. Close to an existing range simply means: the difference between the consumption value and the range is less than a certain percentage (default: 10%). If no existing range matches the consumption value a new range will be created.

(23)

• FindConsumptionBaseline: (provides: consumptionBaseline; dependsOn: ranges)

This algorithm will find the consumption baseline. It will iterate over all ranges and returns the smallest value from the highest range.

• FindStarTimeWorkDay: (provides: startTimeWorkDay; dependsOn: ranges, normalized- Data)

This algorithm will try to determine the start time of the work day. It will take the first value from the normalized data and find the corresponding range. As soon as a number of consecutive minutes (default: 8) the energy consumption is above this range, it will mark the first minute of those consecutive minutes as the start of the work day. If there are no consecutive minutes of energy consumption above the selected range it will return “NULL” to indicate no start of the work day could be found.

• FindEndTimeWorkDay: (provides: endTimeWorkDay; dependsOn: ranges, normalizedData) This algorithm will try to determine the end time of the work day. It works exactly the same way as the algorithm which finds the start time of the work day, with the difference that it will iterate over the normalized data in reverse order.

• SumWorkDayConsumption: (provides: totalWorkDayConsumption; dependsOn: normalized- Data, startTimeWorkDay, endTimeWorkDay)

This algorithm will sum the energy consumption between the start and end time of the work day. It asumes the values in the normalized data are given in Watt. It divides this number by 60 to get the energy consumption in Watt per hour for this minute. All those values will be summed and finally divided by 1000 to provide the energy consumption in kWh for this work day.

• CalculateEnergySaving: (provides: energySaving; dependsOn: normalizedData, startTime- WorkDay, endTimeWorkDay, consumptionBaseline)

This algorithm will calculate the number of energy saved per minute between the start and end time on the work day. Every minute between the start and end time of the work day will be given a value.

This value is calculated as the consumption baseline minus the value from the corresponding time from the normalized data. If the value from the corresponding time from the normalized data is greater or equal than the consumption baseline the value will be set to 0.

• SumEnergySaving: (provides: totalEnergySaving; dependsOn: energySaving)

This algorithm will sum the energy saving data. This is done in exactly the same way as the energy consumption is summed for the work day. The resulting number is the energy saving in kWh.

• CalculateEnergySavingPercentage: (provides: energySavingPercentage; dependsOn: totalEn- ergySaving, totalWorkDayConsumption)

It will take the total energy saving and total energy consumption and divide the energy saving value by the consumption value divide by 100 to get the percentage of energy saved.

(24)

Chapter 5 Evaluation and results

In order to determine if our solution actually works, we did a small experiment. In section 5.1 we define the goal and the set up of this experiment. The experiment gave us the opportunity to collect useful data, which we present and discuss in section 5.1.3.

5.1 Testing the application

After we finished the application, we did an experiment with a test group in the Bernouilliborg. We in- formed the users about our project, that we created an energy competition tool that implements an algorithm to determine energy savings. Before we started analyzing their consumption data, we asked if they would have any problems with this since we do not want to intrude their privacy. After all users accepted, we added them to the dashboard. To motivate users even more to join the competition, an email is sent daily with intermediate results. The competition ran a week from June 15th until June 22.

5.1.1 Test group

As mentioned in chapter 1, we have a small test group of five people at the fifth floor of the Bernouilliborg.

These five persons represent different types of office occupants. Some test persons work more than other test persons, while others have a different pattern of energy consumption. Besides this we noted during development that some users are actually already busy saving energy by turning of monitors when they are not needed and turning off computers when they leave the office for a while. All this together gives a divers group of users to test the application with.

5.1.2 Hypothesis

The energy savings algorithm as defined in chapter 3 was tested with different data sets and works correctly for most cases. Therefor we expect the algorithm will give correct values for energy savings. However, we are not sure if the users will actually save more energy then when they are not involved in the competition.

One week is too short to get enough data for a statistically well founded conclusion. That is why this experiment is only an indication whether it could be a success or not. To test if our application works, especially in the long-term, we should gather results over a significant longer period.

(25)

5.1.3 Results

When the test week was over we gathered all the data. We took the energy savings percentage of every office occupant and compared it with their energy savings percentage in the month before the test. This means we have two numbers for every office, the energy they saved in percentage before the test week and the energy saving percentage of the test week. We put these results in figure 5.1. As we can see, the first

Figure 5.1: Results of the test in the Bernouilliborg

test user already saved some energy before competing in the competition. However, while competing user one saved even more energy than he already did. User one saved around 35% during the competition. The best performing user in this competition is user two. User two increased the energy savings with a factor of around 5. The third user is the one with the least energy saving percentage. User three is also the least present in the office. This means that when he is around, he turns on the equipment, works and then turns everything off and leaves. This means he does not have much time to save any energy. The fourth user increased the energy savings, with a factor just over 3. Besides these increasing percentages, we also have user 5. This user actually saved less energy than the weeks before the experiment. Globally this means that the energy saving percentage increased from around 20% to just above 30%.

5.1.4 Survey

At the end of the test competition the users were asked to fill in a small survey. The survey consisted of several statements which could be answered on a scale from “Totally disagree” to “Totally agree”. The statements questioned various topics regarding the usability of the system, motivation for energy savings and privacy of the users and system. At total of four of the five users filled in the survey.

Usability

The users did not seem to have any problem with the usability of the system. All users thought the system was easy to use. As an improvement the rules of the competition and an explanation of the energy savings algorithm could be added to the system. Not every user thought this was very clear.

(26)

Motivation for energy savings

The survey contained several questions regarding the motivation for every savings. First of all, all users found it useful, on at least some level, to learn about their electricity consumption at work. Half of the users thought this raised their awareness regarding electricity consumption at work, the other half answered neutral.

The users answered three other questions about how different parts of the system motivated them to save energy. One of the users did not seem to be motivated at all. The other users thought the energy dashboard and the overall competition motivated them to save energy. The email notifications did not seem to motivate the users. The email notifications contained the results of the previous day and were meant to remind the users about the competition. A possible explanation for this could that some users did not work two consecutive days. At the moment they received the email notification they were not at work.

As a last question on motivation, the users were asked if they maintained interest even after 2 weeks passed. Most users were still slightly interested, but there is some room for improvements here. Some other incentives might keep the users more interested over a longer period of time.

Privacy

Finally, the survey contained a few questions regarding privacy. Most users did not think measuring their energy consumption is a violation of their privacy, although they did not totally disagree. On the other hand, none of the users thought the dashboard shared too much of their private information.

5.2 Discussion

The results we retrieved during this test are very limited. During our test we found that office occupants save more energy when competing in the competition than when they have normal consumption behavior.

However, we cannot give this as a final conclusion. The test only ran for a week with 5 different users. To get a better conclusion we should gather way more data. This means a longer test run with more and more diverse users. In this way we should get a better picture about the energy saving percentages. The current data cannot give us any statistically founded conclusion. Therefor we can only say that our preliminary results give an indication

Besides these discussion points, there are more things that are open for discussion. First of all our algorithm to calculate the energy saving percentage. Since we could not find any related work on this topic, we had to develop our own algorithm. Of course we tested our algorithm and it does what it should do. However, the algorithm could be improved to take more parameters into account. The algorithm as we developed it is vulnerable for cheaters. We did not focus on that too much, but it is possible to start your computer, let it run for 10 minutes, shut it down again and be gone till the end of the day to run the computer again. This will give a very high energy saving percentage. Maybe it would be possible to take an activity sensor into account to fix this glitch.

(27)

Chapter 6 Conclusion

The goal of our project was to develop a system that encourages users to reduce energy consumption. In this thesis we looked at research done in the field of energy saving algorithms. Unfortunately we could not find any research on this. Therefor we needed to develop an algorithm ourselves to determine the energy saving percentage. Besides this we needed to find out what gamification components we needed. We did find gamification methods and implemented these in the application.

To find out what would be a good algorithm to determine energy savings, we tested some different implementations. After we found out what the right algorithm was we implemented this and also implemented the gamification components in the energy competition dashboard. When this was done we tested the application in a real world environment in the Bernouilliborg.

Unfortunately we could only test the application for one week. We found out that more persons tend to save more energy while competing in the competition. However, there were some persons who did not save more energy. Globally around 12% extra was saved during the competing compared to the period before the test week. Since the test period is not long enough for a statistically founded conclusion, we can give an indication that our application could work, at least in the short-term. To determine if it really works in the long-term, further research should be done.

We are satisfied with the created work and learned a lot about working together on a big project and writing a thesis. Unfortunately there is no time left to expand the application. We would like it if someone else would continue with our project to expand it and test whether it works on the long-term.

(28)

Bibliography

[1] Faris Nizamic and Tuan Anh Nguyen. Bernoulliborg - the building of sustainabil-

ity. http://www.cs.rug.nl/~faris/wp-content/uploads/2013/10/

SustainableBernoulliborg.pdf. Accessed: 2015-04-16.

[2] Two years later: the green mind award 2012. http://www.rug.nl/about-us/

who-are-we/sustainability/green-mind-award/two-years-later_

-the-green-mind-award-2012. Accessed: 2015-04-16.

[3] Bernoulliborg. http://www.rug.nl/about-us/who-are-we/

discover-groningen/bernoulliborg. Accessed: 2015-05-09.

[4] Marcel Jilling and Sijmon Heitmeijer. Office energy saving potential through component based au- tomation, a design and implementation. Master’s thesis, University of Groningen, 2013.

[5] European energy efficiency. http://ec.europa.eu/energy/en/topics/

energy-efficiency. Accessed: 2015-06-04.

[6] Faris Nizamic, Tuan Anh Nguyen, Alexander Lazovik, and Marco Aiello. Greenmind - an architecture and realization for energy smart buildings. 2nd International Conference on ICT for Sustainability (ICT4S 2014), 2014.

[7] Marie-Claude Dubois and Åke Blomsterberg. Energy saving potential and strategies for electric lighting in future north european, low energy office buildings: A literature review. Elsevier - Energy and Buildings 43 2572-2582, 2011.

[8] B. Roisin, M. Bodart, A. Deneyer, and P. D’Herdt. Lighting energy savings in offices using different control systems and their real consumption. Elsevier - Energy and Buildings 40 514â ˘A¸S523, 2008.

[9] Sebastian Deterding, Dan Dixon, Rilla Khaled, and Lennart Nacke. From game design elements to gamefulness: Defining ’gamification’. MindTrek ’11 Proceedings of the 15th International Academic MindTrek Conference: Envisioning Future Media Environments Pages 9 - 15, 2011.

[10] Magnus Bang Anton Gustafsson, Cecilia Katzeff. Evaluation of a pervasive game for domestic energy engagement among teenagers. ACM Computers in Entertainment, Vol. 7, No. 4, Article 54, 2009.

[11] Juho Hamari, Jonna Koivisto, and Harri Sarsa. Does gamification work? - a literature review of em- pirical studies on gamification. System Sciences (HICSS), 2014 47th Hawaii International Conference on, Pages 3025 - 3034, 2014.

[12] Scott Nicholson. A user-centered theoretical framework for meaningful gamification.

Games+Learning+Society 8.0, 2012.

[13] Plugwise circle. https://www.plugwise.nl/producten/

apparaten-en-verlichting/energiemeters-en-schakelaars/circle. Ac- cessed: 2015-06-10.

(29)

[14] Json. http://json.org. Accessed: 2015-06-10.

[15] Php. http://php.net. Accessed: 2015-06-23.

[16] Zend framework 2. http://framework.zend.com. Accessed: 2015-06-23.

[17] Most popular php frameworks. http://www.sitepoint.com/

best-php-framework-2015-sitepoint-survey-results/. Accessed: 2015-06- 11.

[18] Angularjs. https://angularjs.org. Accessed: 2015-06-23.

[19] Bootstrap. http://getbootstrap.com. Accessed: 2015-06-23.

[20] d3js.org. http://www.d3js.org. Accessed: 2015-06-23.

An Energy Competition Dashboard