physical setup
physical setup
dashboard live view tab
dashboard historical tab
dashbaord ML training tab to manually label data + download for local training
device uptime tab

The Dra-Washer Monitor: Giving "Dumb" Appliances a Brain

Inspiration

We've all been there: you haul a heavy basket of laundry up two flights of stairs, only to find every single washing machine is mid-cycle. Or worse, you leave your clothes in a machine for six hours because you forgot the cycle ended, leaving you with a wrinkled, musty mess.

In a world of "Smart Homes," it felt wrong that our most essential appliances were still stuck in the 1990s. So we wanted to give our existing one a brain.

What it does

The Dra-Washer Monitor is an end-to-end IoT solution that transforms ordinary washing machines into smart-monitored appliances. It uses vibration telemetry collected via an ESP32 microcontroller and MPU6050 accelerometer to detect real-time laundry cycles with machine learning. Users can monitor their machine via a responsive web dashboard with live streaming, historical analysis, and a personal ML training hub to build custom cycle detection models optimised to their specific washer's unique vibration signature.

How we built it

The Dra-Washer Monitor is an end-to-end IoT solution that uses vibration telemetry to track laundry cycles in real-time, with a custom ML training pipeline for autonomous cycle detection.

1. The Edge (ESP32 + MPU6050)

At the heart of the project is an ESP32 microcontroller paired with an MPU6050 accelerometer. The device is physically attached to the washing machine drum housing. By sampling the vibration at 10Hz, the system can "feel" the difference between a high-speed spin cycle and a machine at rest.

2. Signal Processing & Math

Raw accelerometer data is incredibly noisy. To turn "vibration" into a reliable state detection, we implemented a custom signal processing pipeline directly on the ESP32:

Magnitude Calculation: We calculate the vector magnitude of the 3-axis acceleration.
Delta Analysis: We track the change in magnitude between samples:

$$\Delta m = |m_t - m_{t-1}|$$

Exponential Moving Average (EMA): To smooth out transient spikes, we apply an EMA filter:

$$S_t = \alpha \cdot \Delta m + (1 - \alpha) \cdot S_{t-1}$$

State Machine: A final 10-second rolling window is used to confirm state changes, preventing false positives from someone walking past the machine or shutting a nearby door.

3. The Cloud (Azure Functions)

Data is batched and securely transmitted to an Azure Functions backend. We chose Azure Table Storage for its extreme cost-efficiency and schema-less design, allowing us to store thousands of telemetry points for pennies a month.

4. The Live Dashboard & ML Training Hub

The frontend is a responsive dashboard that provides:

Live Mode: A 10-second refresh "Live Tab" that streams exactly what the machine is feeling right now.
Historical Analysis: Review past cycles to understand patterns and optimize your laundry schedule.
ML Training Tab: Users can retroactively label historical data by selecting time regions and assigning cycle states (IDLE, WASH, SPINDRY). This labeled data becomes ground truth for model training.
State Visualization: Colored background "strips" (Red for Running, Green for Idle, Blue/Orange for sub-states) that align perfectly with motion data points using pixel-coordinate mapping.
Device Status: Real-time indicator showing if the ESP32 is online or offline with hysteresis to prevent flipping.

5. The Training Pipeline (Local ML Model Generation)

The train_model.py script enables users to:

Export labeled data from the dashboard as CSV
Train a local ML model on their specific washing machine using Random Forest classifier
Evaluate performance with cross-validation metrics and confusion matrix
Generate optimized C++ code that can be deployed directly to the ESP32
Achieve custom cycle detection based on their own machine's unique vibration signature

This closes the loop: User collects data → Labels it in the dashboard → Trains custom model locally → Deploys to edge device for autonomous cycle detection.

Challenges we ran into

Initially we could not even get the esp32 to run as we had naively placed the bare board with the exposed solder on the understand on top of the washing machine’s bare metal top which caused an immediate short circuit which terminated whatever code we were running on the esp32. To fix this, we implemented proper casing by mounting the esp32 inside a non-conductive 3d printed casing. This protected the circuitry from grounding out while ensuring the accelerometer remained firmly coupled to the machine to capture accurate telemetry.
The washing machine’s drum's natural resonance threw off our detection. Implementing the 10-second confirmation window was the breakthrough that made our solution usable in the real world
Streaming raw 10Hz data directly to the cloud risked rapid battery drain, Azure API rate limits, and astronomical execution costs (36,000 calls/hour). To fix this, we pushed the heavy signal processing to the ESP32. By handling the high-frequency math locally and batching payloads to our Azure REST API every 2.5 seconds, we achieved a perfect balance between delivering a "real-time" dashboard experience and maintaining cost-efficiency, battery life, and system reliability.
Getting a trained model small enough to run on an ESP32 required careful feature selection and model quantisation. We chose Random Forest for its interpretability and small footprint and because we have a member who s learning the fundamentals of Random Forest which is Decision Trees from DSA1101 and was very excited to implement it in real life :D.
Pulling long-term historical data originally caused massive browser lag, as the dashboard tried to stream and render tens of thousands of raw data points from Azure Table Storage all at once. To fix this, we implemented backend aggregation. By having Azure downsample and summarise the telemetry before sending it to the frontend, we drastically reduced network payload sizes and eliminated client-side rendering bottlenecks, ensuring a buttery-smooth user experience.

Accomplishments that we're proud of

Achieved production-grade IoT architecture: Built a complete pipeline from edge device to cloud to frontend without proprietary dependencies all using open standards and affordable cloud services with no experience in either field.
Saving my wallet from Azure bills: By processing signals locally on the ESP32, we minimised bandwidth usage and storage needs. Azure Table Storage costs for thousands of data points run at pennies per month.
Democratised ML for IoT: Created a user-friendly training pipeline that lets non-experts build custom ML models (Random Forest) and deploy them to microcontrollers, no firmware recompiling required.
Fixed signal alignment problem: Implemented pixel-to-data coordinate mapping in Chart.js to ensure visualisations perfectly sync with actual sensor data, eliminating false interpretations.
Built edge-first system: Over 90% of processing happens on the device itself, preserving user privacy and enabling offline functionality.
Closed the feedback loop: Users can label data, train models, and deploy them back to the device autonomously creating a continuous improvement cycle.

What we learned

Coming into this project as first-year data science and engineering students with zero microcontroller experience and no Azure knowledge, we had no idea what we were getting into. Here's what we learned:

1. Microcontrollers are kinda hard

We thought Arduino/ESP32 programming would be straightforward, but it forced us to think about memory constraints, interrupt handling, and timing in ways we'd never considered. A 2-line Python script became 50 lines of careful C++ just to safely read sensor data without blocking the WiFi stack.
Debugging a microcontroller is utterly humbling. No Python REPL, no print statements that always work—just Serial debugging and a lot of guesswork. We learned patience as we had to re-flash the microcontroller each time our code fail.

2. Real-world data is very noisy

The modules we took such as DSA1101 gave us clean datasets. However, real accelerometer readings gave utter chaos. Signal noise from footsteps, door slams and talking. We spent many hours just trying to understand what actual sensor data looked like before we could even think about ML.
The 10-second confirmation window wasn't a clever algorithm. it was our desperate solution when the washing machine's natural vibrations convinced our model that it was in SPINDRY mode while sitting still.

3. Cloud platforms are surprisingly approachable (once someone explains them)

None of us had used Azure before. The console terrified us at first, but Azure Functions and Table Storage ended up being kinda doable when we understood the different Azure services interact with each other and how our code talks to Azure. We realised that a cloud backend doesn't have to be a magical black box it's just code that runs somewhere else with persistent storage.
However, we quickly learned that "serverless" still has costs. Those 36,000 API calls per hour was how we learned about batching and optimisation the hard way after seeing my billing tab the next morning after leaving it on the washing machine over a full day.

4. Edge computing is not optional, it's essential

We initially tried streaming raw 10Hz data to the cloud. Our Azure bills exploded. Our dashboard lagged. The cloud functions got rate-limited :(((.
Moving the signal processing to the ESP32 wasn't a performance optimisation, but it was a survival necessity. This taught us that putting computation at the edge isn't fancy architecture; it's elementary common sense when you're working with real hardware.

5. The ML pipeline is way longer than we thought

At university, we learned: collect data → train model → done. Reality: collect → label → explore → train → evaluate → debug → iterate → generate deployment code → test on hardware → oh wait, it doesn't fit in the tiny RAM because it is not a $3000 M-series laptop...
We learned that the "ML" part is maybe 20% of the work. The other 80% is engineering: getting data off a sensor, formatting it, moving it to the cloud, storing it efficiently, aggregating it for the UI, and somehow squeezing a trained model into 250KB of ESP32 flash memory.

6. Random Forest for embedded systems is underrated

We wanted to use a fancy neural network, but with only 4MB of flash and 520KB of RAM on an ESP32, we realised that sometimes simple trees are better than deep learning. It was humbling to learn that "latest = best" is false in real-world systems.

7. Collaboration across domains is actually necessary

One of us handled the ESP32 soldering and firmware, another the cloud backend, a third the dashboard, and someone studied decision trees that was the basis of Random Forest theory. None of us could have built this alone. We learned that full-stack development is really a team sport where a team of specialist come to make something greater than the sum of its parts.

8. Feedback loop changes everything

Our original model was "okay." But once users (us testing in our RC) started labelling their own washing machine data, we could retrain on their actual data. Suddenly accuracy jumped. Permitting users to drive the ML pipeline was a game-changer we hadn't anticipated. This positive feedback loop was the very concept we learnt in Junior Seminar UTC1702E applied to the real, practical world which was an eye-opening experinece.

What's next for Dra-Washer

While our current locally-trained Random Forest model delivers solid accuracy, it is ultimately bottlenecked by the limitations of manual feature engineering. For our next phase, we plan to migrate our pipeline to Edge Impulse to achieve industrial-grade on-device machine learning. This transition will allow us to swap our manual logic for memory-optimized Neural Networks tailored specifically for the ESP32's constraints. By unlocking automated feature discovery, one-click C++ deployments, and robust model versioning for A/B testing, we can dramatically accelerate our iteration cycle. Our immediate next step is to export our labeled dataset, train a TensorFlow Lite baseline, and benchmark it against our current model to prepare for scaling across more powerful hardware like the Cortex-M7.