A user behaviour-driven smart-home gateway for energy management

There are three local discrete databases, an SQL, an RRD and a Policy Database. Each of them performs a specific operation and does not necessarily relate to the other two. They are all designed however, to store all necessary information locally and to facilitate the maximum programmability of the HG. It is noted that apart from the SQL database, the remaining two are file-based.

4.1.3. Policy database

The policy database contains the rules that enable the automation and machine learning operations of the HG to take place. They are written in clear text format, while the language format in which these policy rules are formulated is an extension of the approach suggested by the PANDA framework [26]. The fact that these rules are defined in a simple intuitive clear text language, greatly simplifies the system configuration. Policies can be updated or even exchanged by users, encouraging the creation of energy-aware collaborative user communities. In the future, this could be extended even more with the introduction of a Visual Programming Language (VPL) policy editor tool.

The PANDA policy rules can be explicitly defined by the user or generated by the classification algorithms running on the data collected from the home network devices. An example is presented in Fig. 3. The employed format will be referred to from now on as the Policy Definition Language (PDL). As shown in the table, the first line of each policy script defines it name. Notice that this could differ from the actual file name. The second line can contain a string that carries the description of the policy file.

OPEN IN VIEWER

Fig. 3.

An example of the format of the ‘.PSD’ policy scripts.

The remainder of the policy script is split into groups of rules (policies). Each group is defined by its name and priority value. The priority values are considered in an ascending order, meaning that rules of groups with higher priority values will be considered first. Each rule however, has its own priority value as well, for a more refined prioritization. It has to be made clear at this point that priority is always calculated in conflicting policies, not groups. As mentioned in Section 4.1, each available action in the HG SQL database might conflict with one or more other actions. When multiple policy rules are about to be executed at the same point in time, if they are conflicting only the one with the highest priority will be called. For instance, if a device is about to be both turned off and on, with the former one having a higher priority, then this device will just be turned off.

As seen in Fig. 3, each group can contain multiple policies. Each policy is describe by a unique identifier, which follows the format “PIDXXXX” (X represents a decimal number). This identifier is unique along the whole policy script, not just the group. Afterwards, the conditions and action operation are stated, following a rule-based format IF {condition(s)}, THEN {action}. The conditions can be simple or complex. Simple conditions comprise of a single mathematical relationship between a context variable (whose value can be acquired from the SQL database) and a static value. This relationship can be either true or false. In more complex conditions, multiple relationships can be constructed and combined using either the AND or the OR operators.

Running over the RabbitMQ messaging service, the DANCER middleware hides all the lower implementation details from the operating services (Serial Manager, Sensor Manager, LESDMA, etc.). This includes the SQL database updates, the communication with the home network devices, the RRD operations and the LESDMA policy script manipulations. Hence, any of these implementation specific aspects, can be altered independently of the operating applications. This improves greatly the modularity of the whole system and enables remote energy management.

Due to the highly portability of the RabbitMQ service, multiple API clients can be supported. For instance, a PHP-based web interface can be running on top of the API as a service, in parallel to another Android-based client application. This mechanism also greatly simplifies the implementation of future client extensions, as these are all just services, agnostic of the lower specifications of the system. In addition it removes any constraints imposed by implementation platforms such as OSGi. A dedicated RabbitMQ queue has been assigned to the API Server. All API messages sent to it should abide to a specific JSON format to be normally processed, otherwise they are dumped. In general there are four types of messages in the DANCER API.

Every incoming REQST message is handled and a REPLY message is send back to the connecting client if a reply queue has been registered. In cases where there was a problem with receiving the request or its execution was not successful, an ERR message is sent instead. ERR messages contain an error code describing what exactly went wrong.

4.3. Serial manager

As seen in Fig. 2, below the Action Interface several technology-dependent system components are present. They are mainly used to control and communicate with the various home-automation equipment installed in each residence. In energy management systems, apart from sensor modules, actuator devices are also required. This extends the systems capabilities from only providing feedback to the user, to actually take initiatives, preventing any energy wasting. Actuators based on technologies such as Bluetooth and NFC can be employed to achieve the necessary functionality. However, for the current system implementation, the Zigbee technology was selected, because of its extremely long battery life and easy deployment (especially taking into account that the system is to be deployed/tested in multiple residential locations). More specifically, the Zigbee devices operate under the Home-Automation profile, as defined by the Zigbee Alliance10

Communication between the Serial Manager and the other software components takes place through the RabbitMQ server, following the publish-subscribe paradigm [15]. This is accomplished using the exchange points of RabbitMQ. The Serial Manager is listening to a specific exchange for all messages that has the appropriate tag (e.g. ‘SerialMngr’). It is also able to publish in this exchange point, specific outputs from the Serial Interface, so that services that are interested in this kind of information, can subscribe to it. The incoming requests from other software components contain the Zigbee command that should be send down the serial interface of the HG. Currently the coordinator module used supports an AT command set to control the Zigbee network. The replies generated by the Zigbee network are returned via the serial interface and the Serial Manager sends them back to the corresponding client, via unicast. The RabbitMQ messages follow a JSON format, similar to the one of the DANCER middleware. The generic formats of the input (Request) and output (Reply) messages are shown in Fig. 4. This mechanism not only improves scalability, but also enables message prioritization to take place. Incoming requests are processed according to a RabbitMQ-defined routing label to a set of priority queues. In the current implementation three priority queues have been taken into account, although it is flexible enough to support any number.

OPEN IN VIEWER

Fig. 4.

The JSON format of the Serial Manager RabbitMQ Messages.

The Serial Manager can be considered as a dummy process with no knowledge of what commands are issued and what replies are gathered. It is only able to match the information received through the serial interface, to the expected replies of the proceed messages. For the AT command-set used, this is achieved through the use of regular expressions. In the request message structure seen in Fig. 4, they are stored in the ‘response_regex’ field.

The Sensor Manager is another daemon service running on the HG. Its main contribution lies on updating the SQL and RRD databases with (1) the home network actuators’ status and (2) with the current context information. In terms of energy management, the first operation defines the energy saving capabilities of the system. If for example, a device is already off, then further energy savings from it cannot be achieved. The second operation on the other hand, provides information required for the operation of the LESDMA policy engine service and the machine learning procedure of the RECAP. All energy/environmental data obtained from the deployed sensors are considered here.

The first Sensor Manager operation is achieved by periodically polling all non-sensor components defined in the corresponding SQL databased table. What is required of the Sensor Manager, is to check all context entries and identify the ones that it should update with the appropriate information from the home network devices. As mentioned in Section 4.1, the context table entries contain the ‘type’ field. In order for the service to chose the entries that should be updated, the ones whose ‘type’ is set to ‘Function’ are selected. For each of them, the function database column is then used to request the appropriate action from the DANCER middleware.

OPEN IN VIEWER

Fig. 5.

Demonstration of the procedure for saving reported data via the Sensor Manager.

The second operation of the Sensor Manager however requires a bit more careful investigation. To provide a more comprehensive description, Fig. 5 is shown, noting the procedural steps for the case of an Xbee sensor. Some of the sensor devices (components) present the home network, do not have the capability to respond to requests and just report the sensed values back to the gateway. This operational method, depicted in Step 1 of the figure, is very common in Xbee wireless modules, which may coexist with other more advanced Zigbee devices. The Serial Manager, as mentioned briefly in the previous subsection, is able in Step 2 to receive the data coming from the HG serial interface, and to publish them in Step 3 to a central RabbitMQ exchange point. For the AT command-set used by the coordinator module firmware, these data are serial inputs identified by the prefixes “RX” and “REPORTATTR”, depending on whether they were generated by Xbee or Zigbee modules respectively. The Sensor Manager, in Step 4 of Fig. 5, subscribes to the publishing exchange point and processes each input when it is received. To find out which context table entry should be updated with the new data, again the ‘type’ field is utilized. The entries acquired in Step 5 of the figure, whose ‘type’ value is set to ‘Network’ are selected and reviewed. If the incoming data have originated from a correct source with the appropriate parameters (once again specified in the ‘function’ field), then the new value for the entry is sent to the API server in Step 6, and it is updated in the SQL database in the Step 7. Notice that more than one entries can be updated via a single input. This is desirable since some data inputs may contain more that one useful pieces of information. Additionally, pre-processing of the incoming data can take place by calling actions, once again utilizing the DANCER middleware API.

Apart from updating the existing fields in the context database, the Sensor Manager is also able to record these changes in the corresponding RRD files. For this operation to be successful, the Sensor Manager should also have the ability of creating new RRD database files. For instance if a new context variable is defined and a corresponding RRD series file is not present, the service should initialize one named after the context entry, and start saving the sensor data received.

For an energy management system to make decision on when to intervene, an intelligent component is required to work alongside the monitoring operations. In DANCER this operation is performed by the Local Energy Saving Decision Making Agent (LESDMA) service. It runs as a daemon and loads a single policy script database file, as defined in Section 4.1.3. The operation of LESDMA implements the automation part of DANCER, rather than directly reducing energy consumption. It is the policy script that defines whether the selected rules will conserve or not energy. This is exactly what make personalized behavioural pattern detection so important. In cases where energy saving policies are implemented, the comfort levels of the user are directly related to the degree the system tries not to disrupt the user’s everyday habits.

During its operation, the daemon checks the SQL database periodically (approximately every three seconds, although this value is configurable) and reads the newly updated context variables. Whenever the value of a variable is updated, the policies that are affected by it are reviewed. In simple words this means that policies that include the changed context variable in their conditions are checked whether they are currently true or false. All the policies which are true for the current context are set to be executed. Execution of a policy is nothing more that requesting from the middleware to run the function which is specified in the rule, but only for the appropriate device.

OPEN IN VIEWER

Algorithm 1

Pseudo-code of the decision making operation of LESDMA

This is exactly the point where prioritization takes place. If multiple conflicting actions are true at the same time, only the highest priority one is activated. Conflicts are specified in the “conflicts” table (in terms of the SQL schema) of the database, which is also read periodically along with the “context” table. It has to be stressed that conflicts only apply to actions on the same device. Conflicting actions on different devices will still be executed. The algorithm of this operation is presented in more detail in the pseudo-code of Algorithm 1.

In the pseudo-code two procedures are visible, the ContextChangeEventDrivenPolicyReasoning and the ExecuteAffectedPolicies. The former one is called periodically to just receive the set of policies P, affected from a certain context change. If any, it then calls for their execution through the latter. Its operation is mainly related to accessing the SQL database, therefore it is not explained in any more detail. It is also reading the conflicts table, denoted as C in Algorithm 1. It has to be noted that each individual policy p of P, is also a complex structure with conditions and actions, where each action targets a specific home network device ID.

The ExecuteAffectedPolicies procedure has three distinguishable parts, placed in three serially executable for loops. The first one only allows the execution of policies which are true for the current context. The second one performs the prioritization. If there are conflicting policies, whose group or individual priorities are higher that the priority p being checked, then p will be excluded from the execution step. Finally, the last for loop executes the remaining true, non-conflicting policies. Notice however the E set. This a global variable used to indicate the actions that have previously been executed, so that they won’t get called again and again. If an affected policy is not true, then it’s action is removed from the set if it was contained. On the contrary, if the affected policy is true and is actually executed, then it’s action is added in E. It has to be made clear here that each action belongs to a specific policy, therefore even if two policies contain the same action call on the same home network device, the LESDMA service will still consider these to be different actions, as far as E is concerned.

5.1. C4.5 (J48)

OPEN IN VIEWER

Fig. 6.

Sample decision tree generated by the C4.5 algorithm.

J48 is Weka’s implementation [25] of the well-known C4.5 algorithm [20]. The C4.5 algorithm, probably the most known decision tree induction algorithm, employs an entropy-based criterion in order to select the best attribute to create a node. In essence, the entropy measures the (im)purity of a collection of examples relative to their values of the class attribute, where higher entropy values correspond to more uniformly distributed examples, while lower entropy values correspond to more homogeneous examples (more examples associated with the same class value). Hence, at each iteration of the top-down procedure, C4.5’s selection criterion favours attributes that minimise the entropy of the generated subsets – i.e., the subsets created according to the examples’ value of the selected attribute. C4.5 has been successfully applied to a wide range of classification problems and it is usually used on evaluative comparisons of new classification algorithms.

An example of a decision tree produced by C4.5 is presented in Fig. 6. It can be observed that the rule first checks if the Day of the week is greater than 6 or less than or equal to 6. Given that the first day of the week in our implementation is Sunday (Day 1), Day 6 is Friday. Thus, if the day of the Week is Saturday, then the rule says that no action should be taken regarding the TV device (TV.DoNothing()). If, on the other hand, the day of the week is Sunday–Friday, then an additional check regarding the time is made. If the time is earlier than 11:31 am, then the action is again to do nothing. On the other hand, if the time of the day is 11:31 am or any time after that, then the decision tree suggests turning on the TV (TV.TurnOn()). Effectively, the knowledge acquired from this tree is that the residents in the given house watch TV every day of the week, with the exception of Saturday, from 11:31 am onwards.

An additional information provided here is the correctness of the rules. This information is given inside the parentheses below each one of the leaf nodes. The first number is the total number of instances reaching the respective leaf. The second number is the number of those instances that are misclassified. Thus, the first rule suggests that the leaf TV.DoNothing() was reached 100 times, from which none was misclassified (i.e., all of them were correctly classified, thus 100% accuracy). The second rule suggests that the leaf TV.DoNothing() was reached 12 times, and none of them was misclassified. Lastly, the third rule informs us that the leaf TV.TurnOn() was reached 4 times, and only 1 of them was misclassified. More information about the accuracy of the rules of C4.5 and RIPPER will be given in the discussion of the experimental results in Section 7.

OPEN IN VIEWER

Fig. 7.

Sample of a set of classification rules derived from the RIPPER algorithm.

JRip is Weka’s implementation [25] of the RIPPER algorithm [5]. RIPPER sequentially creates a set of rules that is subject to a global post-processing step by implementing a rule induction procedure with a reduced error pruning strategy [20]. It starts by designating a fraction of the training examples as the pruning set, which is used to remove terms from rules in order to create simpler and more accurate rules. Then, the procedure to create a set of rules can be divided into two steps. In the first step, rules are individually created using a reduced error pruning strategy covering all training examples (excluding the training examples comprising the pruning set). In the second step, a global post-processing step adjusts or replaces rules guided by a performance measure of the modified set of rules achieved in the pruning set. The performance measure takes into account both accuracy and simplicity (size of the rules) of the set of rules.

An example of the final set of rules created by RIPPER is presented in Fig. 7. It can be observed that the algorithm has created a set of three rules in this scenario. These three rules represent the same rules that were described in Fig. 6 for C4.5. The misclassified cases are again presented inside the parentheses at the end of each rule.

5.3. Learning mechanism process

The learning process begins by forming the classification problem. To do so, the attributes that are used to predict the classes of the system need to be defined. Unlike previous approaches, where partial solutions or only a subset of the information collected is used (e.g. [7,18,22]), in our framework, the attributes are the all sensor and polling data collected by the Sensor Manager of each HG, along with their respective timestamps. This is due to residential energy management scenarios considered. The detection of personalized behavioural patterns does not allow for generic concessions on what drives an individual to perform energy-related actions/activities. The attributes are combined to predict the classes; namely the actions that can be performed by the user at any given time. As mentioned in Section 4.2.1, these action records are logged in run-time by the middleware, taking into account their availability on the gateway.

Figure 8 presents the steps of the learning mechanism process. The first step is to query the attributes data. The resolution of this information can take pretty much any value but in the considered scenario has been set to 30 seconds. However, the actions of the user are recorded by the DANCER middleware in an individual log file, at the point in time in which they took place. The first step of the pre-processing operation is in charge of merging these two data sources into a single table. Given a start and stop time of a query, each time-stamp set contains the sensor and polling data. The time-stamp values of the actions however, most probably will differ. Therefore they have to be correlated with the data at the time they were performed. Interpolation could be used in this case, but since the data resolution is quite small, the sensor data values from the exactly previous time-stamp are used to fill the missing values.

OPEN IN VIEWER

Fig. 8.

Learning Mechanism Process.

From this point on, that data for each the monitored devices is processed individually. Intuitively however, it is expected that the use of each of these appliances will only be involved in a handful of energy-related operations per day e.g., turning on/off the TV, changing the thermostat temperature, turning on/off the lights. Consequently, the number of behavioural rules extracted is by definition small. In addition, important information can be gathered for the state of the environment when there is no action in the house, and also what was the current state that led to an action. For this reason, it was deemed necessary to also take into account the states of the environment when nothing is happening; this is represented as another action, identified as DoNothing(). If no user action has taken place, then the class of the system is recorded as DoNothing().

Next, in Step 3 the learning algorithm (either C4.5 or RIPPER) runs per device. Each algorithm then returns rules in the form of a decision tree (C4.5) or as a set of rules (RIPPER). Since the algorithm is run per device, the obtained rules are also per device (Step 4). In the following step (Step 5), these rules are post-processed. This post-processing operation involves three steps. Initially, the rules generated, whether they are in the form of a tree of a set, are translated into the PDL format described in 4.1.3. Following that, the rules that involve a DoNothing() action are pruned/removed. This is necessary, as the user is only interested in rules that suggest taking a certain action. To complete the post-precessing, only the rules that have a classification performance above a pre-specified threshold r % are selected. This is because only well-performing rules are of interest, as this increases their possibility of being selected by the user. It should be mentioned that different metrics can be applied to judge the predictive performance of the rules. For the purposes of our framework, the accuracy and the F-measure (also known as F 1 score) were chosen.

The accuracy presents the correctness of each rule, while the F-measure is the weighted average of two other well-known metrics, namely precision and recall. Precision presents the fraction of retrieved instances that are relevant, and recall presents the fraction of relevant instances that are retrieved. The formulas for all these metrics are presented in Eqs (1)–(4), where TP stands for True Positive, TN for True Negative, FP for False Positive, and FN for False Negative. (1) Accuracy = TP + TN TP + TN + FP + FN (2) Precision = TP TP + FP (3) Recall = TP TP + FN (4) F 1 = 2 × Precision × Recall Precision + Recall

For the purposes of our experiments, it was decided to choose only rules of high accuracy and F 1 score, thus the threshold r was set to 50% for both of these metrics. Of course, this can be dynamically adjusted according to each deployment scenario. In cases where the users seem to accept most of the detected rules it can be lowered, while it can be increased when users only seem to consider a small subset of the provided feedback. Thus, the number of “useful” rules provided can be adjusted to the preferences of the user.

Finally, in Step 6, the remaining rules from all devices are gathered and in Step 7, the DANCER middleware API is used to temporarily store the newly discovered rules in the SQL database of the corresponding HG (whose gathered sensor data and actions generated them in the first place). Once the user connects to the user-interface platform, (s)he is informed that new rules can be applied on the policy engine. Afterwards the opportunity is given to the user to review the new rules, so that these can be integrated in the currently deployed policy script.

7.1. Bandwidth utilization & response times

The infrastructure deployed in the individual residences is composed of devices with very limited resources. The proposed system is considered to take advantage of the installed broadband connection of the house, if available. Therefore, the utilization of the user’s bandwidth, as well as the total traffic generated in the VPN server supporting the whole operation should be carefully considered. Various tests were also performed to examine the response time of the system. An important factor affecting this metric is the utilization of the limited CPU and RAM resources of the SBC employed. The status of the gateway of the prototype test-bed was monitored in a normal state where no user requests or RECAP updates were performed. This represents the normal operation of the gateway where it monitors the network devices, stores the collected information and performs the policy engine reasoning. The average CPU utilization was found to be around 9.8%, while the average active RAM utilization lied at about 38.5%. These measurements demonstrate the light weight solution.

In Fig. 10, the inbound and outbound traffic distributions are seen for the VPN server over the period of a month. Only the HG installed in the prototype test-bed is considered. However, real-world conditions were applied, where the generated traffic includes updates in the gateway’s firmware, apart from collecting the generated sensor data. The sensor data on the other hand, are collected by RECAP every two hours.

Naturally, the inbound traffic in the VPN server network interface exceeds the outbound and it lies very concisely in the area just below 500 bits/s. This is mainly caused by the 2-hour sensor data uploading operation to the RECAP. On the other hand, the inbound traffic relates to the data sent to the HGs, such as firmware updates and remote login for monitoring and testing. This is why two local maximums can be seen in the probability distribution of Fig. 10, one at around 200 and one at around 300 bit/s.

OPEN IN VIEWER

Fig. 10.

The inbound and outbound traffic probability distributions over a monthly period.

OPEN IN VIEWER

Fig. 11.

Delays for the execution of commands on the smart gateway.

The response delay of the gateway was measured in two use cases. The first one considers the amount of time spent while redeploying rule scripts on the policy engine of the HG, while the second one deals with the delay until a Zigbee command has been successfully completed by the system. According to the firmware of the HG’s Zigbee module, every command generates an output, whether it has been completed successfully or not. So the time from which a user requests a command from the web-interface, until the web-browser (using Javascript and AJAX) receives a response was measured. For both experiments 100 measurements were performed, and their distributions in milliseconds are depicted in Fig. 11. The policy engine script re-deployment is quite concise and usually takes about 0.5 seconds. The time for an action to be completed though, has a wider distribution and usually takes longer. Action requests are seen to take almost up to 1.2 seconds. This is caused by the traffic of the Zigbee network, the amount of commands being processed simultaneously, as well as the response time of sleepy Zigbee devices.

In this section, the predictive performance results for the rules produced by the two algorithms tested in this work, C4.5 and RIPPER, are presented. Experiments took place over the one month dataset mentioned earlier, by using 10-fold cross-validation. Cross-validation was used to avoid overfitting and to increase generalization of the models [9,17].

It should be mentioned that each algorithm returned a quite high number of rules: C4.5 returned 28 rules, and RIPPER returned 11 rules. However, as was explained earlier in Steps 5b and 5c in Fig. 8, two of the post-processing steps are pruning the DoNothing() rules, and also removing the rules that have a predictive performance below a certain threshold r % . Hence, the results presented are the ones produced after the above post-processing has taken place. As mentioned earlier, for the purposes of our experiments r has been set equal to 50% for both the accuracy and the F-measure.

OPEN IN VIEWER

Fig. 12.

Rule 1 returned by C4.5 for Device 2.

OPEN IN VIEWER

Fig. 13.

Rule 2 returned by RIPPER for Device 3.

Results are summarised in Tables 2 and 3 for C4.5 and RIPPER, respectively. Each table consists of 6 columns. Results are presented by device and by individual rule, so the first two columns present the device and rule number, respectively. As explained in Section 5.3, the results are presented in a per device basis, because each algorithm is run per device, so that it creates rules that are specific to the device at hand. Then, the next four columns present the following statistics: accuracy, precision, recall, and F-measure.

It can be observed in Tables 2 and 3, both C4.5 and RIPPER have performed equally extremely well in terms of accuracy, since all rules returned an accuracy above 99.9%. One should keep in mind however, that this success rate is ‘inflated’ by the high number of DoNothing() events, which dominate the datasets. To be more specific, the number of total actions in our dataset was over 80,000 entries in which most of the actions were DoNothing(). Only a few entries in each case contained actual references to the user’s actions. Due to the extremely unbalanced nature of the dataset, the high accuracy is not very informative. Consequently, the use of F-measure becomes of paramount importance.

With regards to the precision and recall metrics, results vary per algorithm and per rule. As it can be observed in Tables 2 and 3, there are certain rules that are doing extremely well in terms of precision, but not in terms or recall (e.g. C4.5: Device 1, Rule 1), and other rules that have a similar performance in both metrics (e.g. C4.5: Device 2, Rule 1). Overall, C4.5 returned an average precision of 75.25% and an average recall of 70.84%, while RIPPER returned averages of 81.29% and 46.39%, respectively. Finally, the F-Measure offers ‘combined’ information over precision and recall, as it aggregates their results. We can observe that for C4.5 the average F 1 score is 70%, while for RIPPER it is 58.21%.

Based on the above results, one could argue that C4.5 is preferable to RIPPER, since they have similar performance in terms of accuracy and precision, but C4.5 has better results in terms of recall and F-measure. However, one would have to look into the actual rules and judge if they are meaningful in a real-life situation. Figure 12 presents Rule 1 returned by C4.5 for Device 2. As it can be observed, this rule evaluates the boiler temperature from two different sensors, and advices to turn off Device 2, which is a radiator. However, there is no correlation between the boiler temperature and the radiator. Thus, this rule was coincidental, and should thus be discarded as a non-meaningful rule.

On the other hand, rules returned by RIPPER are found to be much more meaningful. To illustrate this, Fig. 13 is presented, which shows the rule returned by RIPPER for Device 3. As it can be observed, this rule advices to turn off Device 3, which is the TV, if the time is 01:00 am. This in fact was a rule that had previously been entered in the policy engine, and RIPPER successfully managed to uncover.

From the above, it can be concluded that user-comprehensible rules are extremely important. In fact, since the user is eventually going to be receiving the rules and manually evaluating them, it needs to be ensured that the rules returned are easily interpretable and comprehensible. Thus, the next section looks into the interpretability of the rules of each algorithm.

In order to quantify the interpretability of the discovered rules, a measure called prediction-explanation size [19] is used. This measure is defined as the average number of attributes-conditions (e.g., Time > 11.31) that are evaluated in the model in order to predict the class value of an example. The average is computed over all examples being classified. According to [19], the prediction-explanation size measure “provides an estimate of the number of attributes-conditions that a user has to analyse in order to interpret a model’s predictions, and those attribute-conditions can be regarded as an explanation for the class prediction”.

Table 4 presents the prediction-explanation size for C4.5 and RIPPER, under each device, the lower the value, the better the algorithm performance. As it can be observed, RIPPER outperforms C4.5 in all three devices for which they returned rules. In addition, C4.5’s prediction-explanation size is bigger in a magnitude of 3 for Devices 1 and 2, and in a magnitude of 2 for Device 3. Hence, the rules produced by RIPPER are more easily interpretable than the ones returned by C4.5.

Section 7 presented a set of experimental results generated from the prototype test-bed deployed. The system’s operation was shown to be quite light with relatively fast response times. In terms of the behavioural pattern extraction, various classification problem algorithms can be employed, provided that they generates rules that can be translated into the employed PDL. This however, lies beyond the scope of this paper, as our goal was to present the infrastructure and not look for the optimal classification algorithm. Two of the most well known examples (C4.5 and RIPPER) were tested. The interpretability of the discovered patterns (rules) was identified as significant metric of rule suitability, since it is directly relates to the comprehensiveness and usability of the produced output. In general, the computational time to return the classification rules for a 10-fold cross-validation was very fast, and took less than 1 minute per algorithm. Of course, this time depends on the length of the dataset used for deriving the rules. In our experiments, the one month dataset contains approximately 80,000 entries.

OPEN IN VIEWER

Fig. 14.

The average daily electricity consumption distribution.

In terms of energy management, users, especially of different age groups and in different locations, tend to have quite diverse daily habits. Disregarding that, while making energy related decisions, may lead to low user satisfaction and thus, complete failure of the energy consumption reduction effort. On the other hand, personalized energy reduction strategies can be much more specific and effective. Figure 14 illustrates the unique energy fingerprint of the monitored residence, depicting the average electricity consumption during the examined period, in the monitored household. The consumption displays two local maximums, one around 11:30 am and one at about 10:00 pm. The first is caused mainly by house chores like cooking and cleaning, while the latter is driven by consumption related to the lighting, cooking, heating and TV usage. Based on the general knowledge provided by the sensor data collected, there are a number of procedural steps to be taken, while devising an appropriate consumption reduction strategy.

The second and third steps of the construction of the energy management strategies are exactly the point where personalization is required. A fully generic output would normally cause great inconvenience if the provided energy saving rules did not take into account the user’s preferences. For example, one of the rules generated by JRip dictates that between 10:33 and 10:34, the thermostat should be turned on with the set-point adjusted at about 20–22C°. In these cases, the set-point could be further lowered by a degree, without any major difference in the perceivable user comfort levels.