Skip to content

Software

quicksell-louis edited this page Mar 16, 2019 · 15 revisions

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.

Firmware Modifications

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.

Default EmonPi system diagram

https://wiki.openenergymonitor.org/index.php/EmonPi

Modified EmonPi system diagram

energymeter diagram

Data Cleaning

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.

Classification Model Overview

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.

Feature Description

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.

Data Collection Procedure

Data collection was done manually. We wrote a script which 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. After the type of the appliance is entered, the script starts a short countdown before prompting the user to initiate the appliance. The script has built in error detection that halts collection for various reasons including erroneous power data, serial read errors, and output errors. Each sample is saved to a CSV which is then added to the training dataset.

Dataset Training

Given the simplicity of our neural network, we initially attempted a run with 20 samples for each device. This gave us a 60% accuracy rate. Along the way, we discovered numerous issues with our data formatting, so rewrote our data pipeline. After tuning our model, we achieved ~90% accuracy with 100 samples per device, with a total of around 700 samples.

Dataset Labels

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.

Neural Network Model Design/Architecture

For simplicity, we chose a three-layer dense network. There was no significant performance difference between architectures that warranted additional work. We are still studying our model, but focusing on real-world data collection, and less on model accuracy. Image

Hyperparameters Of Model

  • Optimization algorithm: adam
  • Training: 20 epochs
  • Regularization: relu and softmax (final layer)

Training/Validation

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 would be needed.

Data Preprocessing & Augmentation

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, thus enhancing our training dataset.

Deployment

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.

Visualization

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 plots for the electronic signature of a water kettle.

power_plot

power_factor_phase_angle_plot

current_plot

voltage_plot

Testing

At the time of writing, real-life testing has been limited, due to time constraints. We limited testing to one week at a team member's home, and at GIX. The product is nowhere near commercial-scale deployment, so testing has been limited to small-scale.

Future Work

  • Increase training dataset
  • Develop simultaneous usage classification algorithm
  • Train on multiple-state appliances (e.g. low, medium, high)
  • Develop two and three-phase monitoring system
  • Add front-end for visualization
  • Implement behavioral change studies