Partly for the sake of his marriage, partly for his own sanity, Kevin came up with a plan to hack his clothes dryer for smarter notifications.

It’s something of a joke how annoying the end of cycle beeps from appliances can be. Arguably it’s not even a problem worth considering, but it’s surprising how frustrating those small things can be. No matter how convenient, we all dislike those notification noises from a dishwasher, microwave, clothes dryer, or even the fridge to tell you the door is open. While they provide valuable feedback, there’s something irritating about those beeps... especially if you leave an appliance running as you go to bed, only to be woken up at 3am like an early alarm clock!

Kevin decided to take on the challenge for more intelligent communication from his clothes dryer. We caught up with him to see how he tackled it.

What made you want to tackle this project? Was it the annoying beep you wanted to be rid of, or just to ensure a better alert when it ends?

Mostly it was the annoying beep. Every dryer we’ve owned has had the option to disable the buzzer and we always made use of that feature. When we bought the new dryer and my wife said “Is there anything you can do about that?” my maker brain translated her request to “Honey, please use your hacking superpowers to make all my dryer wishes come true.”

Well if the saying “happy wife, happy life” is true, how could you say no? Can you briefly explain the different hardware parts that are being used here?

There are two main pieces to the project, the transmitting side inside the dryer and the receiving gateway in my office. The transmitter consists of an Adafruit Trinket based on the ATtiny85 and an RFM69 wireless module. The gateway is a Raspberry Pi 2 Model B, with another RFM69 module to receive messages from the transmitter. The Pi takes the message and forwards it to the Losant MQTT broker, which then triggers a Losant workflow to send me a text message. For my project I used the 433MHz RFM69HW, which is the high power version to maximise transmit range. The RFM69 modules communicate with each other based on a common network ID configured in firmware, and data between them is encrypted with a shared 16-byte key. The only other hardware component is the AC/DC converter I used to power the transmitter from the end of cycle buzzer. For that I settled on the Meanwell IRM 05-3.3, which takes the line voltage from the buzzer signal and outputs 3.3V to power the Trinket and RFM69 module.

Sounds awesome. The MQTT prototcol is robust too, so it’s a great way to interface. Did you consider using different hardware setups, or test any? Or did you basically end up proceeding with your first choice?

For the AC/DC converter I also tried a Meanwell RS 15-3.3, which works fine but was bigger and not fully enclosed like the IRM 05. I originally considered using a Particle Photon inside the dryer, which could have eliminated the need for a gateway as it can talk to the internet directly with onboard WiFi. The problem there came down to timing; the end of cycle buzzer supplies 120VAC for 5 seconds, which isn’t long enough to establish a connection to the Particle Cloud and transmit a message. I could have wired things up so the Photon draws from the main dryer supply lines, but I didn’t like the idea of it consuming power 24/7 just waiting to detect an end of cycle signal. A goal of the project was to use power from that five-second end of cycle buzzer and I didn’t feel like I could make that happen with a Photon.

You’re relying on the buzzer power to provide supply to your transmitter. Is there a failsafe/plan B if for some reason the receiver doesn’t receive the message before the transmitter loses power again?

Currently there is not. I have a switch that allows me to choose between the old buzzer mode and the new IoT text mode, but once in text mode if the message doesn’t get transmitted for some reason, there is no failsafe. I figure this is acceptable for now since it’s just my laundry. I could add a Piezo buzzer to the transmitter that sounds for as long as it’s able, if it detects that the message failed to send; maybe in v2.

Sounds like a great future upgrade. We are of course, still talking about a dryer ending cycle - it’s not like there’s a nuclear meltdown if the message doesn’t get through! Does the receiver have a buffer in there to retry sending if your internet has a hiccup? Or is it one-try/one-fail?

The transmitter RFM69 code has retry logic if it doesn’t get an ACK from the receiving gateway. So if the first attempt fails it will try to resend the message as many times as it can before losing power. Once the Pi gateway has the message, it could handle retries to the Losant MQTT broker but that is something I haven’t implemented yet; it’s a great idea though.

It's a great demonstration of what's achievable to improve functionality of an appliance to solve your own needs, without major implementations. This one probably even still keeps the dryer in warranty!

What major hurdles did you tackle to get things working, and how much hair-pulling did it take?

Lots of hair-pulling! The biggest hurdle I ran into was getting the RFM69 module working with the Adafruit Trinket. The first major hurdle was that the Trinket doesn’t support the out-of-the-box Arduino SPI library. Since the RFM69 module relies on the SPI protocol for communication this was a complete blocker. I found a couple of raw ATtiny SPI implementations that I used as a reference to add ATtiny support to the LowPowerLab RFM69 library on GitHub. It turns out the module also has a lot of serial debug output in it, which is also not supported on the Trinket so I had to remove all of that. Ultimately I submitted a pull request back to LowPowerLab, which adds full support to their RFM69 library for the Trinket and other ATtiny85-based boards. With those changes in place I was still unable to transmit messages. After hours of frustration I used a logic analyser to discover the MOSI/MISO pins on the Trinket are labelled as if it will always act as a slave device, so my transmit and receive lines were crossed. Once I figured that out I was able to send my first message to the Pi gateway.

Oh yeah, that’ll do it! When you received your first text message from your dryer, how did you feel?

Funny story there. I had everything wired up inside my dryer for the moment of truth test. It was all still on a breadboard that I just stuffed inside. What I didn’t realise was that I had removed the Trinket from the breadboard earlier to reprogram it, and forgot to put it back in. When nothing happened at the end of cycle my heart sank. I’m embarrassed to share how long it took me to debug that “problem.” As soon as I popped the Trinket back in it worked first try. It was the most amazing feeling. I had done some testing beforehand, but had no idea if using the buzzer power was actually going to work, and was blown away when it did. It’s that feeling of accomplishment that makes you feel like you can tackle any project.

You tackled some unfamiliar technologies with this project. What unexpected challenges did you face?

I had never used an RFM69 module so there was a decent learning curve in that regard. There are lots of community examples using the RFM69 module but I didn’t find any for something as “underpowered” as the ATtiny so that took some creativity. I also expected the RFM69 integration on the Pi to go smoother. I tried several libraries in Javascript and Python but found many of them to be very unstable. I found the Python library from etrombly on GitHub to be the best option.

With the benefit of hindsight, what would you change or how would you do things differently if you were starting now?

I think the Trinket, despite the trials in getting it working, is the perfect amount of hardware to throw at the transmitter end of the project. It has just enough program memory, fits the power profile requirements, and has the exact number of pins required to pull off the approach using the RFM69 module. If I had to do it again I may consider something other than a Pi as the gateway. The idea was that I can now use the Pi as the gateway for any other RFM69-based nodes like sensors around the house. Even so though, I think it’s probably a bit of overkill on both horsepower and power consumption.

Sometimes some extra horsepower comes in handy. And if you decide to interface more devices in the same way, you can still use the same Pi gateway. Anything else you would like our readers to know about this project?

I’ve posted the transmitter and gateway code on GitHub so others can recreate the project, and I even created a Docker image for the Pi, which can be used to run the gateway code without having to manually install any of the dependencies or clone repositories. I’m happy to help anyone in the community if they have questions or get stuck.

That’s great, we’re sure some others would like to tackle this project, even if for a different purpose! What are you working on now?

Hockey season just started so I am currently working on mounting an e-paper display inside of an actual puck, to display real time player stats.

Nice one! Thanks for taking us through your project, Kevin!