diy-smart-laundry-room

KO | EN

gitlite — search

#hacktoberfest #react #typescript #golang #android #rust #linux #windows #awesome #cli #kubernetes #awesome-list #vue #ios

diy-smart-laundry-room

(★ 21)

DIY Hardware/Software solution for monitoring remote washing machines/dryers

diy-smart-laundry-room Latest Version Download

Download Latest Version (.zip)

// repository documentation

Was this content helpful?

★ 0 (0 ratings)

# Laundry!

### Video
[![Making my building's laundry room SMART Thumbnail](http://img.youtube.com/vi/uBQprP1Wlas/0.jpg)](http://www.youtube.com/watch?v=uBQprP1Wlas "Making my building's laundry room SMART")

This repo contains the software/hardware source for my DIY smart laundry room. I live in an apartment building with ~15 units. We all share two industrial washers and two industrial dryers in the basement. I wanted to give us all an easy way to know which machines are currently in use so A) folks don't have to lug their laundry down x flights of stairs just to find out that they cannot start a load and B) folks can know when their laundry is done so they can go down and clear it for the next person. The end product is a simple website that shows the state of each machine, as well as an approximation of how long it has been in that state.

// TODO screenshot

### Constraints

1. Given that I do not own these machines, I cannot modify them in any way. Non-invasive tech only, and nothing that might get in users' way.
1. I was asked by the building manager not to touch mains power (I wouldn't want that liability anyways). This meant no current sensing.
1. My unit's WiFi does not reach down to the basement, which made it challenging to keep the web page up to date.
1. I obviously want to respect my neighbors' privacy. Some might try to argue that my final solution here crosses that line, but I hope I can convice you otherwise (See FAQ). I drew the line at "no cameras".

## High Level Design

- Each washer/dryer gets a `sensor module`. Each module contains an nRF52840 development board, a PDM MEMS microphone breakout, an 18650 battery cell (+ holder), and a 3D printed enclosure to hold all of it together. The module is held against the machine using small rare earth magnets. Roughly once a minute, the nRF wakes up, records ~0.75 seconds worth of audio from the microphone, and then starts a Bluetooth Low Energy advertisement signaling that it has data available. It waits 10 seconds for the `brain` (see below) to connect and read that data, otherwise it goes back to sleep and tries again in 30 seconds.

- The `brain` is an internet connected computer that hides in the laundry room. It runs a software stack that continually scans for advertisements from the `sensor modules` in the room. Each time it finds one, it connects to that device over BLE and uses the nRF UART Service to read the audio recording. After reading the data, the brain tells the sensor module how to long sleep for before waking up to record again. This allows for dynamic scheduling without having to update the firmware on each sensor module! At night, for example, the modules are instructed to sleep for hours at a time to save battery (nobody is supposed to be doing laundry after 11PM here).

The brain runs each recording through an ML classifier to determine what state each machine is in (there are several different state classes, but they get boiled down to "running" and "idle"). For each classification, the brain sends an update to the `website` with a timestamp, the machine's id, and the machine's state. I used a Particle Tachyon for the brain, since it is small, power efficient, and most importantly - comes with a cellular modem that gets service in the basement. **Particle was nice enough to send me this device to play with. I am under no obligation to say anything about using it. I think it's really great!** That said, there are probably cheaper ways to implement the brain.

- The `website` is a web application with a simple frontend, a sqlite database, and an an API to update/fetch machine states. The API takes in snapshots from the `brain` and serves up the frontend, which shows the current state of each machine. I have the website hosted on val.town. The source code lives there as well.

### Why I Like This Design

- **Repairability/Expandability:** One of the things I prioritized was making it as quick and easy as possible to add a sensor module to the netowrk (or similarly - to repair one that gets broken). The BOM cost for a single sensor module should fall between $15-$20. There are really only 3 electrical components, and less than 10 easy solder connections. The nRF firmware is written in CircuitPython and can be dragged and dropped right onto each board with no special configuration. A new module will automatically be picked up by the brain without having to disrupt service.

- **Low Maintenance:** The nRF boards draw very little power, especially while sleeping. I measured the current draw of a single sensor module and saw an average of about 700uA @ 3.9V (battery voltage) during normal operation, and significantly lower than that overnight while they sleep. With an 18650 cell, each module should last _months_ before needing a charge. And because the nRF dev boards have a built in charger circuit, I can literally just plug in a USB battery pack and leave it behind the machine when they get low (or just as easily swap out a cell).

### Things I Might Change

- **Microphone:** I really do think audio is a _great_ choice for this (come and fight with me in the FAQ about that), but the microphones I chose are not not ideal. I love that they're completely digital - I dont have to deal with any ADCs _and_ CircuitPython lets me record a buffer of n samples in like 2 lines of code. BUT They're omnidirectional, which means they pick up sound from all around. I was able to compensate for this a bit by adding a layer of foam to the sensor enclosure on the outward-facing side of the microphone breakout. Still, I think a piezo-based contact microphone might make classification a bit simpler and more accurate, at the cost of making the hardware/firmware a little more complex.

- **Tachyon:** Don't get me wrong, I _love_ my Tachyon. It's working great and cut down a ton of complexity. But I got mine for free and I'm feeling a little bit locked into Particle's system (what if they change prices down the road?). For an open source project like this, I feel like it may have been better to pick something a little more accessible. Also - I was lucky to find an outlet that I could use to keep it powered. The battery life on the Tachyon is really impressive, but I'd probably have to change it every other day at this usage. I wonder if there's a lower power way to implement the brain.

## FAQ (actual Q's from social media)

- **Aren't there privacy concerns putting microphones in public(ish) spaces?** Sure! But you're ignoring so much important context.
    1. The project is open source, so anyone concerned can verify that the rest of the items on this list are actually true.
    1. The nRF boards can literally only record ~0.9 seconds of audio at a time with this setup. That eats up all the RAM. So for every minute of laundry room time, I am only gathering about 3.5 seconds of disparate audio samples.
    1. In practice, the mics don't pick up human voices with much fidelity. They are smooshed up against the machines and have a foam dampener placed behind them. You _can_ hear things that are obviously human voices, but it's hard to make out any words.
    1. The audio never leaves the laundry room. All processing is done on the Tachyon, only classification _results_ are posted to the backend.
    1. The user-facing website has a link at the very top that goes to a page explaining exactly how everything works. My contact info is also right there if folks have concerns.

- **Why not just use (x) instead of a microphone?**
    1. **Accelerometer:** I think an accelerometer _might_ work just fine! I would love for someone to try one and get back to me. Here's why I don't think it's ideal: **The first portion of these machines' wash cycle is literally just a few minutes of filling with water. The energy produced by this water spraying is concentrated at higher frequencies than your average accelerometer's max data rate. I was seeing peaks at 2-3kHz (think about the hiss sound of water traveling through a metal pipe)**. You'd need to be able to sample your acc at 6kHz to really capture that, and most hobbyist chips don't go that high.
    1. **Camera:** I bet you could get the most accurate results this way - literally just read the machines' displays. BUT A) much larger privacy concern and B) would be hard to guarantee line-of-sight. People hang clothes in the laundry room and often pile things on top of the machines.
    1. **Vibration Sensor:** Assuming you are talking about one of those continuity-based "knock" sensors, I really don't think these would be terribly accurate. If you had one that was sensitive enough to pick up when the washing machine was filling with water, I have a strong suspision that it would also pick up a ton of false positives (people moving in the room, neighboring machines working hard, etc). Would love to be proved wrong but... I'm not going to try!
    1. **Current Sensor:** Again, I was asked not to touch the machines' power, so inline "smart plugs" were out of the question. A bunch of folks suggested CT clamp sensors. I actually _did_ try these but what I learned (and what I think most don't realize) is that **these are designed to be wrapped around a _single_ conductor, not an entire power cable**. If your power cable contains both hot/neutral wires, the EM signal might cancel itself out at the point of reading! Folks have suggested that they can still get a reading using them this way, but I found that it did not work with our dryers here.

I was kind of surprised how many people found my choice of microphone to be... puzzling? upsetting? I got some strong reactions. I have a strong audio background and have done a bunch of processing in my work so I'm sure that's why my mind went there first but... think about it! Go to your washer, put your ear against it, and close your eyes. Can you _easily_ tell if the machine is doing something or not? (Assuming your ears work like the average person's) Of _course_ you can! These are noisy machines. **Microphones _are_ vibration sensors!!**

- **Why not use LoRa instead of cellular to get data out of the basement?**
    I actually think this is a great idea - could probably strap a LoRa HAT on to a Raspberry Pi and save a bunch of money on the brain. The downside is that you'd still need to set up a LoRa -> Internet bridge device somewhere to keep the website updated. Not hard or expensive, but an extra thing to keep up and running.

- **Why use Machine Learning? If the signals are so clear can't you just use some thresholds?** My first, and perhaps unsatisfying, response to this is... why _not_ use ML? Check out the implementations of the training pipeline and classifier. This is not heavy duty stuff - we're running an FFT on a sub-second audio clip and feeding 5-ish features (RMS, high-frequency energy, zero-crossing count, etc) through a random forest classifier. It's all handled by great Python libraries and transparently - Claude Code wrote most of the boilerplate. The big advantage is that I don't need to manually figure out where my "machine on/machine off" thresholds for various signal components are. And when I inevitably got some false negative/positive results during the first few days, I didn't have to go back to the drawing board. I just added that new data into my training pool and spun out a new model.

# Code

**Disclaimer - I used Claude Code (Sonnet 4) to generate a portion of this code, particularly the Docker stuff and much the source in `local_tools`. I review each diff - I am definitely not a "vibe coder" currently (but no judgement towards those who build that way!)**

## Sensor Module
Schematics and CircuitPython code for the sensor module will be in the [`sensor_module`](./sensor_module/) directory. See instructions there for getting that up and running.

# The Brain

## Training a model

1. Install Python (3.10+) dependencies described in [`requirements.txt`](./requirements.txt) (`pip install -r requirements.txt`).
1. Create a directory of all your pre-labeled training .wav files. That directory should contain one subdirectory for each of your classes. In my case, the subdirectories were `idle` (for recordings from machines that were off), `dryer` (recordings of dryers that were running), `wash_rinse` (recordings of washers that were filling with water), `wash_spin` (recordings of washers that actually had the motor running). Fill each of those subdirectories with the appropriate audio files.
1. `cd` into the [`local_tools`](./local_tools/) directory and run `python python ml_training_pipeline.py /your_training_directory --skip-processing`. Note that if you omit the `--skip-processing` flag, each file will will have a high-pass filter and volume boost (8X) applied before training.
1. This will dump model files into a new `model_out` directory. You can see the classes and features used in the file `ml_output/random_forest_summary.json`. If you want to re-run with different features - add/remove from the `SELECTED_FEATURES` list at the top of `ml_training_pipeline.py`.

## Running the main processing loop

Assuming:
    1. You are running this on a Particle Tachyon board running Ubuntu, with an internet connection.
    1. You have Docker installed.

1. `cd` into this project's root directory (where this README is!)
1. Create a `.env` file with a `BACKEND_URL` and `SNAPSHOT_ENDPOINT` strings. This is where the machine state snapshots will be sent via HTTP. It's ok to use a fake endpoint, the updates will just fail quietly.
1. Move all model files output from the section above (likely in `local_tools/ml_output`) into a directory called `model`
1. run `bluetoothctl` and within that, run the command `power on` to ensure that BLE is enabled on the Tachyon. Then run `exit` to get out of `bluetoothctl`.
1. run `docker compose up -d` - this should start each of the components defined in [`docker-compose.yml`](./docker-compose.yml) and run the entire stack!
1. run `docker compose down` to stop everything. Add `-v` to remove all recorded data.

# The Website

The user-facing website (as well as its source code) is hosted on [val.town](https://val.town).
// TODO link to VT project

diy-smart-laundry-room

diy-smart-laundry-room Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

diy-smart-laundry-room

diy-smart-laundry-room Latest Version Download

Today's picks

Was this content helpful?

Recent Feedback

Download README