#remote kettle boiling

[jamesmedd]

'Return of the Mutant Kettle!' - developing my Geo Kettle

The main benefit of the idea was that I could switch on the kettle without dropping whatever I was doing, and save a bit of time when going to make a cup of tea. The idea wasn’t complete however, as I’ve often felt it would be useful to save this time when I get home and make myself a brew (pretty much the first thing I do when I walk through the front door…whatever the weather). Even back in February, I envisioned a more responsive, data-informed version of the remote activation, and that’s what I’ve just put together over the past couple of days.

I’ve started including a suite of extra features that should make the remote activation respond to both my needs, and the needs of the kettle. For a reason I won’t disclose in this post, I’ve even put together some informal diagrams to set out the functionality I’m trying to achieve:

Application Flowchart/State Machine Diagram

I’m not that well versed in formal UML, but the flowchart below partially adheres to the conventions of a state machine diagram, describing the various stages and states* encountered when using the remotely operated kettle application:

The crux: the user can open the web app on their mobile, and tell the kettle where they are – determined automatically using the phone’s GPS location – and concentrate on getting home. The back-end of the system will work out when it needs to switch the kettle on – based on the user’s location, and data from the kettle – so that it will be coming to the boil as they walk through the front door.

Hardware Overview

In lieu of a formal UML deployment diagram, I’ve made a diagram outlining roughly ‘what does what’ in the overall remote activation process. The images are ‘for illustrative purposes only’, as there are numerous alternatives to what equipment I’m using (in fact, I’m not even using an Uno), hence I’ve labelled them fairly generically:

A little more detail about the technology: the user front-end is just a basic webpage, using the HTML5 geolocation API to locate the user, and the Google Maps API to offer some visual feedback. When the user confirms that they’re heading home, their coordinates are forwarded to a Flask application – running on a Raspberry Pi, served using Apache – and the user’s interaction with the system effectively ends. The Flask script relays the coordinates to the Directions API to determine the journey time, and gets information about the kettle’s water level and temperature from the microcontroller – in this case the AlaMode Arduino shield that I’ve posted about before – thus determining how long the kettle will take to boil. This data allows the application to make an informed decision about when to tell the Arduino to switch the kettle on.

I tested the system out earlier today after walking out to pick up some groceries. Despite having already tested it with a few dry runs – no pun intended – I was still in awe of the fact that it was coming to the boil the moment I entered the kitchen**. There are still a few elements missing – detailed below – and I’m sure there are plenty of improvements I will make, but the prototype is certainly working exactly as I’d expect it to!

Current Status

Right now I’m basing the activation time solely on the phone’s GPS location and static water data, meaning I’m not actually taking any data from the kettle yet. I’ve measured an average boil time at the kettle’s minimum water level – which happens to be just enough for about two cups – so I’ve only been testing it with around 500ml of water in for the time being. I had thought about using a voltage divider and measuring the water level via an analogue pin on the Arduino, but it’s a little impractical having additional wires running into the kettle. I’ll probably end up using a load cell to determine the amount of water externally, and I’ll also try to position a temperature sensor such that it can give as accurate a reading of the water temperature as possible.

As I expected, the geolocation API isn’t without its caveats, and I occasionally have to update my location a few times before it’s accurate. Obviously, a full-blown native iOS application would allow me to continuously track the user, but the web app is working well enough at this stage. Happily, it grabbed an accurate location instantly on my test run earlier, which contributed to my satisfaction with its first perfect field test. I could also do with adding more style to the web app anyway, and I’m still yet to implement the option to cancel the current boil request.

Finally, as a hangover from my previous artistic sentiment, I’m still using a little micro servo to flick the switch. While a little impractical, this does allow standard use of the kettle when I’m not activating it remotely. I’ll be considering if there’s a more sensible but non-invasive way to change this part of the mechanism.

I’ll see what I can do about capturing some video footage, although it might have to be heavily edited so I’m not revealing, to the Internet, where I live! Code will appear when it's finished!

*There’s actually a step missing at the beginning to let the user cancel the ‘in progress’ state.

**Remember Doc Brown at the end of Back To The Future when he dances down the street after transporting Marty through time? I was almost that hysterical.

[jamesmedd]

For the love of moving parts

This is the first thing that I’ve made since coming out of hospital recently. It’s not overly ambitious but it’s fun, and has raised (or re-raised) some interesting questions for me:

Last night I quickly knocked together something that I’ve been thinking of creating for a while: a remotely boilable kettle, that is, a kettle I boil from anywhere I that can access the Internet. The hack was super simple, but it worked exactly as I planned, and I was able to turn the kettle on from all of the rooms in my house in under an hour; 10 minutes more work and I’ll be able to access it globally.

Americans: I understand that electrical kettles aren’t the norm in the US – something to do with your 110v power, perhaps – but that’s how most of make our tea here, so that’s what I’m using.

My pleasure at remote boiling aside, what really got me thinking was something I that typed into the YouTube description box after I posted a quick 30-second clip of the hack, which I’ll get to shortly. When I first voiced my idea to friends – at the pub, where all of the best ideas are born – the first suggestion given for realising the task was to use a power relay. While this will probably be a pretty obvious solution to most engineering types – it even crossed my mind, briefly – the picture in my mind was different, and that picture was of the kettle’s existing ‘on/off’ switch still being pressed, even when I’m 100 miles away from it.

I didn’t want to control the kettle directly, I wanted a middleman, and that’s exactly what I made.

Using some electrical tape, I attached a micro servo to the top of the kettle and positioned the attached lever so that it would press the button when rotated (see video below). I plugged the servo into my trusty Arduino Duemilanove – still going strong after nearly 4 years – and wrote a quick Python script incorporating pyFirmata to tell the board what to do, and used Flask to create a remotely accessible web interface. The operation couldn’t be simpler: press the button on webpage and the motor presses physical button on the kettle.

At this point, the electrical engineers are probably a little nonplussed – as well as being aggravated by my use of a servo without a protective diode – and wondering why I didn’t just go with the power relay option. In my YouTube description I say “because servos are more fun”, but I think it goes a little deeper than that. The majority of my recent artworks and creations have included some kind of physical actuation or moving part to do what they do, and when things move – and I’m talking about physical movement, not just the changing of pixels on a screen – my brain gets excited.

Maybe it’s my inner artist – or roboticist – but the technically unnecessary inclusion of a moving part made the process so much more interesting and visually entertaining, and enhanced the satisfaction of the task being performed. I touched on this subject in my accompanying paper for my recent Masters project, and argued – in a few thousand words – that this was the ‘human’ element of the machine’s operation. In the case of my remotely boiling kettle, the machine performs the human version of the task, not the machine version. Efficient or not, it appeals to our fascination with all things robotic and mechanical, presenting an analogue process that we can decode visually*.

*In part, I think this methodology adheres to Rafael Lozano-Hemmer’s proposed concept of ‘Adapting the Digital to Reinterpret the Analog’, something that I’ve been keeping in mind when making anything recently.