Appliance Detection on Smart Meter

The appliance detection module provides two major functionalities in real-time

monitoring phase:
(1) With the help of a pre-calculated appliance state table, it identifies the current states
of appliances upon receiving an edge event from the edge detection module.
(2) Detects state table errors, such as some unknown major appliances being added to the
house. This triggers the meter to enter the relearning phase, and eventually receive an
update-to-date state table from the AMI headend.
The module is currently running on the AVR32 simulator with chip UC3A0512. The
design of the meter is shown in Figure 1 with the corresponding data flow in. One
primary design principle of our framework is to shift the intelligence, which requires
heavy computation, to the headend due to the limited resources available in the meter.
Even given this constraint, the meter should still be able to perform more than simply
telling whether a certain amount of load increase/drop is seen. The design of the
detection module takes two inputs: the current total real power from an edge event and
the known appliances profiles stored in the state table, which is derived from the AMI
headend in the learning phase. The detection module then efficiently finds the optimal
combination with a modified 0-1 knapsack algorithm, and updates the states of all
appliances in the state table. This ensures that that the most recent state information is
always ready for headend to query.
The state table in the meter looks like the following:
App Index

#States

State 1 Mean
Power (W)

Monitoring
period (s)

Acceptable
Change rate

5745

State 1
Std
Power
(W)
200

1 (dryer)

3600

2 (toaster oven)
3 (garage)

1
1

1475
905

45
100

3600
21600

8
20

4 (first oven)

5735

55

3600

5 (second oven)

2205

55

3600

Table: A Sample State Table for Carls Kitchen

Each record is the profile of one appliance and includes the number of states as well as
the mean and standard deviation of the real power (W) of each state calculated by
clustering module in headend. The per-appliance attributes monitoring period and
acceptable change rate are used in state table error detection, which will be discussed in
details in section X.X.
There are two commonly used methods to detect the states of the existing appliances: a
knapsack algorithm and incremental analysis [cite michaels paper]. The knapsack
algorithm tries to find the combination of states whose sum power is maximized under
the constraint that the total power is less than current observed power. The incremental

analysis determines which appliances changed their states based on the total power
change observed in each edge event. Error propagation is one major drawback of the
incremental analysis, while running knapsack algorithm continuously (3 times per second
in []) in real-time monitoring phase requires large amount of computation. Therefore, we
proposed a hybrid scheme, which is to run a modified knapsack algorithm on each edge
event.
The above problem can be formularized as a 0-1 knapsack problem:
max pi x i , where wi x i W T
W:
T:

x i {0,1}
wi
pi

real power observed in edge event.

tolerance value, which is the sum of the standard deviation of all possible

appliances
given the current load. The appliance whose mean power
consumption is larger than the current load is automatically eliminated.
on/off of a state of an appliance
weight of appliance i
value of appliance i.
In this case, both wi and pi are the real power consumption of appliance i.

The following pseudo code shows how the knapsack algorithm works in the detection
module, where B[#appliance][W+T] is the benefit table keeping track of the best subset
of appliances that has a total weight w [0, W+T].
//initialization of Benefit table
for (w = 0 to W+T)
B[0,w] = 0
for (i = 1 to n)
B[i,0] = 0
// recursively finding the optimal value from a subset of appliances for every weight w
for (i = 1 to n)
for (w = 0 to W)
if (wi <= w) // item i can be part of the solution
if (bi + B[i-1,w-wi] > B[i-1,w])
B[i,w] = bi + B[i-1,w- wi]
else
B[i,w] = B[i-1,w]
else
B[i,w] = B[i-1,w]
//finding the list of selected appliances
i=n, k=W
while (i,k > 0)
if (B[i,k] != B[i -1,k])
mark the ith item as in the knapsack
i = i -1, k = k-wi
else
i = i -1

A brute force algorithm to detect the optimal combination [michaels paper] given a total
of n states across all appliances in the state table requires complexity O(2n). By
comparison, the algorithm described above has complexity O(n(W+T)/M), where W+T is
the total weight, and M is the minimum detection power unit. For example, if we have 10
appliances with 2 states each (i.e. n=20, W = 5000W, T = 500W, M = 100W), the brute
force method requires O(220), while our algorithm requires only O(20*55), which is much
more desirable to run on low-end meters. The detection algorithm was tested on the data
collected using a TED1000 from Prof Gunters kitchen (Figure X). 90% detection
accuracy can be achieved under the conditions (1) that we use an accurate state table and
(2) that all appliances have discrete finite states.
The detection module also detects possible errors in the current state table. These errors
can exist due to the fact that appliances in the household may change frequently and also
due to the learning phase not being to capture all states of all appliances. Three types of
errors can be detected in the detection module at present:
1. If the absolute difference between the observed total load and detected total load
is greater than some threshold, then it indicates that some appliances are missing
from the current state table. Currently, the threshold is set at two times of the sum
of the standard deviation of all possible states of all appliances.
For example, the point labeled C1 in Figure X is supposed to be an event for
turning on the toaster oven. If the toaster oven was missing in the state table, a
missing appliance error would be generated from the detection module due to the
perceived power difference.
2. If an appliance changes states unreasonably often, it is a strong indication of error
in the state table. The acceptable change rate is appliance-specific. For example, it
is reasonable to observe frequent change in an air-conditioner or a heater, but it is
unreasonable for a car battery charger.
For example, an alert was generated at the point labeled C2 in Figure X. It
occurred due to the dryer changing state eight times with in 15 minutes, which we
purposely made it do during the controlled test.
3. If the number of appliances changing states within one edge event is greater than
a threshold, say 5, it is another possible indication of error. Further analysis will
be required to verify if such a combination of appliance changes violates normal
human behavior, in order to avoid false positive alerts.

Real Power (W)

Carl's Kitchen
E2

10000
9000
8000
7000
6000
5000
4000
3000
2000
1000
0

E1

raw data
edge event

C1

5:54:14

5:57:07

6:00:00

C2

6:02:53

6:05:46

6:08:38

6:11:31

6:14:24

6:17:17

Time (s)

Figure X

Real Power Data collected by TED1000 in Carls Kitchen (Dec 2nd)

If any one of the three behaviors is observed, the detection module will trigger its alert
routine and send a request to headend, indicating there is a need for re-learning the state
table.
Re-learning phase

Power Company

Smart Meter
Reactive Re-learning

Headend
Controller

rning
Re-lea

Reque

State Table

Waiting Time for load

balancing of mesh network
Learning Period

st

Learning Sta

Learning En

rt

Appliance
Detection

d
Edge Dectection

Learning Period

Learn

ing St
art

Learn

ing En

Proactive Re-learning
(periodically)

Headend-Controlled Hybrid Scheme of Re-Learning Phase

Figure Y shows the scheme of the re-learning phase. It is a hybrid scheme of both
reactive learning initiated from meter and proactive learning initiated from the headend.
The meter sends the re-learning requests to the headend whenever it detects an error in its
state table. However, the meter detection is not perfect due to the complexity of
appliances power profiles and limited resources available in the meter. For example, at
the point labeled E1 in Figure X, the meter cannot tell if the dryer or the first oven is on,
because those two appliances have very close real power consumption. We also perform
poorly at the point labeled E2 in Figure X, where we turned on and off several lights
many times in the house to generate some background noise. The meter thought the
garage was on at this point due to the missing detailed profiles of all those lights. It is
also impossible for the meter to detect that an appliance has been removed without
analyzing a large amount of data. Such appliances should be removed from the state table
to increase detection efficiency in the meter. Therefore, it is necessary to introduce
periodic proactive learning into the scheme.

The frequency of the proactive learning depends on the size of the mesh network and the
amount of data needs to be transferred. The data are the edge events rather than the
instant load values in our case. Also, it is not necessary to be sending data 24 hours a day,
since off-peak hour data may not be as useful as peak-hour data. (got any number to
estimate the frequency? E.g. bandwidth? Compression rate?)
There are several directions to enhance to this scheme:
1. The meter may assign reasoning (a label containing the type of error) and priority
(urgent or not-so-urgent) for each detected error and embed these labels into the relearning request. This would facilitate the headend in coordinating and prioritizing the
(re)learning phase of the entire AMI mesh network.
2. Both the meter and the headend may intelligently ask themselves if the error detected
is important, since we only care about those major appliances registered for loadshedding. Therefore, if the errors are caused by other appliances, which have very
distinctive power profiles from the ones we care, it is reasonable to ignore those errors.