Smart plug for autonomous energy management
A smart plug that recognises the appliance from its harmonic signature and forms a relay network with its neighbours. An undergraduate project at Yıldız Technical University, published as an IEEE paper.
Why I was here in 2018
This was my first serious piece of machine learning work. It was 2018, I had no plan to end up in product management, and I was studying electrical engineering at Yıldız Technical University. Machine learning was still mostly an academic subject then. The libraries existed, but running a model inside an embedded device, collecting the data and labelling it were all manual jobs.
Our question was simple. Can you tell how much energy each appliance in a home uses without putting a meter on every socket?
The work was done with Barış Eroğlu, Safa Karip and our advisor Uğur Savaş Selamoğulları, and written up as an IEEE paper: Machine Learning Integrated Smart Plug Design for Autonomous Demand Response Implementation.
The problem
Demand response has been discussed on the grid side for a long time. The idea is that if you trim some loads at peak hours and shift them to other hours, the pressure on the grid drops. Residential demand is around a fifth of the total, so it is a share worth working on.
To automate that, the system has to know what is plugged in. Delaying the washing machine by an hour makes sense, delaying the fridge does not. Asking the user what they plugged in does not work either, because nobody fills that in and the thing in the socket keeps changing.
Our goal was to bring user involvement down to zero. The plug should recognise the appliance by itself.
The system
Three parts: the hardware that measures, the network that carries the data, and the model that recognises.
Measurement
Inside the plug there is a CS5490 energy metering chip. It measures voltage, current, active power, reactive power, frequency and power factor at 1% accuracy, over windows of 4000 samples by default. The property that mattered to us was that it also reports harmonics. The success of the model ends up resting on that.
The readings go over UART to an ESP8266 ESP-01 module, and from there over wi-fi to the central server. The ESP side was written in MicroPython.
Relay network
The problem we did not expect in the prototype was coverage rather than measurement. In larger homes some sockets do not see the house wi-fi well enough, cannot send data, and the system loses that appliance.
To fix it we built a relay network in which the plugs help each other. Every plug measures its own signal strength (RSSI) and takes a role based on a threshold.
A plug with a signal above the threshold switches to access point mode and behaves like a socket server, and its weaker neighbours connect to it. The server plug then sends its own data together with the client data to the API over the house wi-fi. The API waits a set time for each plug, and if nothing arrives that device is marked missing and the user is told.
That part taught me more than I expected. Whatever the accuracy of the model, if the data does not arrive the system does not work.
Interface and data
The API is four routes. Plugs write through /esp, the interface reads power values through /getPowerValues, /turnOnOff switches a device, and /missingPlug runs the relay network. The data sits in two MySQL tables: readings per plug and consumption per device.
The interface is a React web app. Live current, consumption and electricity price sit at the top, with per-plug charts below and a control panel where you can switch devices on and off with one click.
The model
For appliance recognition we used k-nearest neighbours through scikit-learn. The inputs were current, power, active power, reactive power and harmonics. Measurements were collected in the smart house laboratory at Yıldız Technical with typical household appliances such as a washing machine, a vacuum cleaner, an oven and a kettle.
We compared three datasets.
The first set contains the 3rd, 5th, 7th and 9th harmonics, and the best result is 64.3%. The second set has no harmonics, only voltage, current, power and power factor, and it stays flat at 51.6% across every K value. The third was a control run. We trained on the test set and evaluated on the training set, and accuracy fell to 47.5%.
The gap is the actual finding. Harmonics tell you more than current and voltage do. That makes sense: two appliances can draw the same power, but the distortion a motor driven vacuum puts on the line is not the same as the distortion from a resistive heater. The harmonic signature carries the character of the device rather than its power draw.
K has to stay odd so the vote cannot tie. A small K is exposed to noise, a large one to overfitting. In our runs, values around K=7 looked reasonable.
What did not work
I would like to tell this as a success story, but 64% is not enough for a product. If the system is going to run demand response on its own, the misrecognition rate needed to be far lower.
The paper lists K optimisation and a deeper dataset as the next steps. Looking at it now, the first thing I would try is collecting more data and using a time series instead of a single instantaneous reading. Appliances behave differently while starting, running and shutting down, and we were giving the model only one frame of that behaviour.
Looking back
Two things stayed with me.
First, the accuracy of the model was not even the most fragile part of the system. Wi-fi coverage, lost data and what the user saw in the interface mattered just as much. The argument I still make about AI products comes from here: the model is one component, the product is another thing.
Second, choosing the data mattered more than choosing the model. Same algorithm, same appliances, same house, and adding harmonics to the input moved 51% to 64%. That has repeated everywhere I have worked since.
This project is also where my interest in on-device AI started. Seven years later I am choosing the same constraint again with Tacet: keep the processing on the device that produces the data.