Dryer Dreams, part 2: making the split extension cord

Getting the prototype to work with the kettle seemed straightforward. I was, however, concerned that the dryer would draw more current (and perhaps damage the split extension cord).

Searching for something that I now have forgotten took me to this link.

I ended up wiring a "split power cable". The colors represent the electric current (I wish I knew more about electricity terminology)? Red == hot, Black == ground, White == "not hot (?)"

Dryer Dreams, part 1: Overview

Some people dream about world domination, or the perfect margarita. I dream that my clothes dryer will tell me when its cycle is done, so I can pull my clothes out before they get wrinkled. I'm a software guy, rather ignorant on the hardware side. So I thought I'd start experimenting and learning.

I first tried putting a Quirky Spotter on the dryer to detect the sound of the buzzer. However, the sound of anyone closing the door of the room containing the dryer would set it off.

I then tried an Insteon Syncholink, but was unable to get the Android app to work. I'm guessing the lath-and-plaster walls (or something) in our old house blocked the wireless signal to my phone.

I then found this project in Make Magazine that seemed to fill the bill. Wiring diagrams are, however, Greek to me. I therefore took a weekend workshop in Ardunio programming. Luckily, I connected with one of the instructors, Michael C. Toren, who happened to be working on a similar project.

I was not looking forward to digging into the guts of my dryer as described in the Make Magazine article. Michael, however, had made (what I called) a "split extension cord" (picture to come) that worked well with our first minimal prototype. Not having a dryer handy, we used an electric kettle. The code for that prototype is here.

In future posts, I'll record (in pedantic, OCD, anal-retentive detail) the various steps I went through to get this working.

Heart-felt thanks to MCT, as well as Rolf Widenfeld, J.D.Zamfirescu, Malcolm Knapp, Lee Sonko and the rest of the team for their help.

More commute data

After changing jobs, I revived my commute time data collector for my new commute. The end-result is much the same, e.g., Google Maps underestimates the commute time by an average of 20%. The range of underestimation (from the average time) was from 4% to 48%.

I programatically collected Google Maps estimates for a few days and averaged them, while manually collecting my actual commute times. The morning commute looks like this:

The evening commute, like this (don't ask me why Google spreadsheets chose a different display format):

The underlying data is here.