EnergyMeter is a proof-of-concept energy monitoring system that provides realtime consumption information and appliance classification using state-of-the art machine learning/neural networks. It was built atop the EmonPi open-source platform. The experimental setup was built using a power strip to represent a single phase of a residential house. By building this atop an extensible open-source project, we hope to share this work with the energy disaggregation community.
This project was part of University of Washington's Global Innovation Exchange, as part of TECHIN 514: Hardware/Software Lab 1 as taught by John Raiti. Over the course of one ten-week quarter, students built prototypes that mixed hardware (e.g. embedded systems and sensors) and software (data collection) to be used in machine learning (ML) models. This class was broken into three milestones to present progress.
Ricky Powell, Will Buchanan, Louis Quicksell
Provide a proof of concept residential energy disaggregation feedback mechanism to provide a breakdown of appliance-specific consumption information in realtime, in a nonintrusive manner (e.g. no extra wiring/electrical work) at a low cost. Such a device would involve current and voltage sensors, which would then break down the unique signature of an appliance.
Few low-cost devices exist to inform appliance-level power consumption in real-time, providing consumers little opportunity to understand where to conserve electricity. Existing plug-level devices (such as the KillaWatt) only measure consumption of individual appliances, and require a plug at each outlet. Nonintrusive Aggregated Load Monitoring (NIALM) algorithms have not been used to their full potential value, reducing the impact of Smart Metering deployment. There is a need for an open-source real-time disaggregation monitoring for whole-home power consumption, as studies have shown that a >12% annualized savings results from realtime appliance-level energy consumption feedback [1].
The device should identify appliances being used in real-time based on their unique power consumption signatures, using ML as part of UW's TECHIN 513: Managing Data & Signal Processing, taught by Josh Fromm. The device ideally should utilize state-of-the-art ML techniques to perform the classification, with the results being sent to the user to inform behavior change.
The software components of this project collected, cleaned, and fed the data into our classification models. Below are the descriptions of our software and machine learning development efforts.
To build the electronic signature of an appliance we modified the existing firmware on the EmonPi to collect the features necessary and sample at a sufficient rate. Besides voltage and current, these features include phase angle, power factor, real power, reactive power, and apparent power. We calibrated the voltage and current measurements using a Kill-A-Watt meter to verify that our measurements were accurate. Built-in functions in the Emonpi were enabled to remove any noise present in the measurements. The measurements are made using the ATMega shield attached to the EmonPi and converted into bits to be sent to the serial port on the pi. Measurements are sent from the ATMega chip using the RF12 packet structure and we modified the firmware to send a packet containing our feature measurement data. This packet is read in through the serial port on the pi by a Python script which decodes/cleans the packet and performs the appliance classification.
Several functions were written to decode and format the collected data appropriately. The packets are decoded according to the RF12 structure and fed into a rolling window. A rolling window is used to capture data in the same shape as the time series data samples we used to train our model. Data is padded or trimmed to a set length and centered and scaled to assist with classification. After these transformations, the reshaped windows are fed into the classification model for appliance identification.
Our model was constructed with Keras & Tensorflow. This is a multi-class classification problem. There is some overlap among electronic signatures of appliances with similar electrical components (a toaster and a hot plate are both resistive loads and it follows that they would have similar load signatures). If we were implementing classification at a finer level there may be some overlap among different make/models in appliance types, however this is beyond the scope of our project.
Using the EmonPi, we collected the appliance type (input by user), and the consumption signature of the device in a CSV format. These fields include: time, power factor, phase angle, real/reactive/apparent power, and RMS voltage/current. This constitutes 8 features that are recorded in a rolling window, which is used to perform the classification:
('Time', 'PF', 'Phase', 'P_real', 'P_reac', 'P_app,', 'V_rms', 'I_rms')
Data collection was done manually. We wrote a script which automatically detects that an appliance is turned on and then prompts the user for the type of the appliance being sampled. This is used to label a window of data containing different electronic signature features over a set time period. It contains printouts to view/validate the data, and catch any errors. Each sample is saved to a CSV which is then added to the training dataset during processing.
Our approach used an event detection method which involved comparing the current reading with the average of two previous readings. An event was detected if that change exceeded a certain threshold, in our case 5W. A rolling window was constructed in the form of a numpy array, which contained 40 readings. When an event is detected, it populates the window up until the first two rows, thus allowing accurate capture of the startup sequence. The rolling window method was used for both training and classification.
Given the simplicity of our neural network, we initially attempted a run with 20 samples for each device. However, we uncovered numerous errors due to data formatting/processing in our first round of data collection & processing, and achieved only a 60% accuracy rate. This prompted us to rebuild the data processing pipeline, and collect many more samples. After tuning our model, we achieved ~90% accuracy with 100 samples per device, for a total of 700 samples. However, we futher discovered issues in our data collection script, and rewrote it to speed up the process by automatic event detection and window creation, and a state of 'none' to aid classification. We then collected a new dataset containing 800 samples. The model is now near 99% accuracy. Further refinement could be achieved, but efforts would be better spent in the functionality development, mentioned in 'Future Work' section later on this page.
Due our previously defined scope, we chose to limit the detail of the appliance classification to seven appliances for our proof of concept. Labels are used to describe the appliance class (e.g. heatpad, kettle, laptop, induction cooktop, hairdryer). During training data collection, the appliance label is input at the start of each session, and the files are automatically incremented with the run number. There is little room for interpretation regarding appliance labels on behalf of the user, so it is unlikely there is any bias inserted.
After comparing several model architectures, we optimized for performance & simplicity. There was no significant performance difference between architectures that warranted additional work.
- Optimization algorithm: adam
- Training: 20 epochs
- Regularization: relu and softmax (final layer)
Here is our final network architecture:
This is a low-precision application, as it is used to inform behavioral change. The validation accuracy will be sufficient for real-time feedback, though if this were a commercial product much more development could be warranted. Below is our validation and model comparison.
For comparison, we wrote a script that explored a variety of supervised learning techniques: GBM, Random Forest, Logistic Regression, Naive Bayes, Support Vector Machines. Ultimately, we chose to pursue the NN model, but found that comparably accurate models could be made by tweaking these models.
Due to the challenges of collecting enough data to sufficiently train a neural network, we explored the path of data augmentation to increase our dataset. Our approach to reduce overfitting involved a random application of a stretch or a shrink to the window, inspired by this paper. The function chooses a random sample equal to 1/10 of the size of the source array, and replaces sample with pair-wise average of sample indices. This was fed in using the Keras Image Datagenerator object, which performs the preprocessing function during each epoch. Given the accuracy of the model, it proved unnecessary.
Given the small size / low complexity of the model, we deployed it on the raspberry pi locally. It was saved using the Keras Model Callback/Checkpointfunction. Given the time allotted, it is not possible to deploy this product as it stands, being purely a proof of concept. The device is intended to support one household at a time, and will struggle to distinguish between appliances of similar power consumption habits.
We created a dashboard to plot the component features of each appliance's electronic signature. This dashboard was created in python using the Plotly web framework, Dash. We were able to run this on our local machines but had some difficulty deploying it using Heroku. Below are the feature plots for each appliance.
At the time of writing, real-life testing has been limited, primarily due to project timeline constraints. However, full functionality has been demonstrated, and we hope the disaggregation community takes this farther.
Above, a plot of voltage obtained over time. Note the influence of aliasing and noise in the readings.
To begin measuring voltage, we started the project from scratch following the OpenEnergyMonitor documentation, using a Raspberry Pi, an analog-digital converter, and a plug-in AC-AC adapter. Along the way we learned the fundamentals of AC power, and encountered numerous technical hurdles: ADC sampling rate, aliasing, and noise. After reeevaluating the schedule, we made the decision to transition to an open-source energy monitor, EmonPi. Below is the rationale for our decision:
| Ground-Up Hardware: | EmonPi |
|---|---|
| PROS | PROS |
| Deep-dive into hardware development | Accelerated schedule |
| Learn signal-processing fundamentals | Integrated Voltage & Current pi shield w/ dedicated ATMega328 & 10-bit ADC |
| Build custom ADC firmware to suit our sampling needs | Build atop existing development & learn from others |
| Extensible, open-source platform | |
| More time on ML and less bit-banging | |
| CONS | CONS |
| Reinvent the wheel | Firmware modifications |
| Moving slowly | Conversion from EU to US power standards |
| More time on hardware, less on ML | Modifying a complex product ecosystem |
| Less conceptual value-added |
We used an EmonPi which is an open-hardware Raspberry Pi and Arduino based energy monitoring unit, 1 clip-on current sensor to monitor a single-phase circuit, and a plug-in AC-AC adapter to measure RMS voltage. The EmonPi offers a ATMega328 shield that allowed us to build atop a significantly developed arduino firmware library, EmonLib, enabling the increase in both sampling rate and accuracy to produce more calibrated feature sets to be used for ML classification.
We trained on several common household devices which include:
- Laptop (Macbook pro)
- Cellphone (iPhone 6)
- Full UV Spectrum Light (aka sad-lamp)
- Desklamp
- Fan
- Kettle
- Monitor
We chose to keep the hardware unchanged for our third milestone for the following reasons:
- Simplicity keeps the product extensible for future development in the open-source community
- Little room for improvement in the current enclosure design, given we are building atop an existing product
- Hardware is not customer-facing, and resides in a circuit breaker, thus product design is not a priority
- The team discovered halfway through the second iteration that Sense, a similar product, currently exists on the market, and thus represents a reduced incentive to commercialize.
Quite a bit of work is needed to bring this to its full potential. Here is a roughly prioritized list:
- Develop concurrent appliance operation functionality. This would allow for overlapping signatures, thus a more realistic use-case
- Collect 'off' state appliance status, to detect when an appliance is turned off
- Develop running tally of consumption per device
- Train on multiple-state appliances (e.g. low, medium, high)
- Understand how appliance state changes over time (e.g. if it is 'warmed up', certain loads have different startup characteristics)
- Increase training dataset samples & diversity, as neural networks need more data to function well
- Build out greater current capacity. Currently limited to 20A & upgrading to a larger scale would require a burden resistor swap & calibration
- Develop two and three-phase monitoring system
- Convert EmonPi scripts to Python3
- Add front-end for visualization
- Implement behavioral change studies
- Fix MSQTT 'broken pipe' error that results from our having disabled the MSQTT server. This means the pi needs restarting occasionally. Should be an easy fix.
[1] Armel, K. Carrie, et al. "Is disaggregation the holy grail of energy efficiency? The case of electricity." Energy Policy 52 (2013): 213-234. [2]Le Guennec, A., Malinowski, S., & Tavenard, R. (2016, September). Data augmentation for time series classification using convolutional neural networks. In ECML/PKDD workshop on advanced analytics and learning on temporal data.