Dark Light

Over the christmas holidays, I generally attempt to do a technical project in something that’s new to me. I think I bit off more than I could chew with the main thing, which was a look at Amazon Lumberyard and Gamelift, so I went for something smaller scale that I was more likely to actually complete. So, the voice activated kettle:

(Yes, vertical video. Yes, I do know better. Yes, it was 4am)

I’ve previously mentioned that I own a Smarter.am wifi kettle. Well, this Christmas Santa brought me an Amazon Echo Dot, and so it’s only logical I try to join the things. (Caution: Logic is only theoretical, and can be dangerously subjective).

The Internet of Things has gained a reputation for poor security, and the iKettle specifically so a year and a bit back, but one of the advantages I’ve generally listed for the kettle is that it’s not on the public internet unless you’re stupid. If someone knows you have the kettle and can physically point a directional aerial at it, they knock it off your network, stand somewhere outside your window for four hours brute-forcing a randomised PIN, they can get your wifi password and be on your network. Also boil your kettle. I recognise it’s a flaw, but I count it an accepted risk. I believe it’s fixed in the new hardware revision anyway.

Anyway, the kettle isn’t on the public internet. A lot of IoT devices are, since their apps connect to a publicly available API (either as a primary or secondary connection option) which then connect to the devices, providing a handy access route. Most of the time these use industry-standard access key systems, and are usually secure enough. A lot of the cheaper end of the market don’t, which is why you get the “DDoSed by my doorbell” stories.

Amazon Echo uses their Alexa APIs to provide custom skills, which are centralised and don’t work over local networks, so in order to make this work I needed to be stupid, and put my kettle on the public internet.

A noddy web interface. Yesterday.
A noddy web interface. Yesterday.

Fortunately, I’ve done most of the heavy lifting for that already. A while ago I stood on Mark J Cox’s shoulders to write Retort, A Flask (of course) based app that runs on my local network and provides a REST-based API to the socket-based kettle protocol. This has been quite happily running on my home server since I built it a year and a half ago with a noddy little javascript interface. It’s accessible over the internet via SSL and basic auth, which means I can turn on my kettle from the bus home if I like.

So when on Christmas Day (shudup) I went looking for how to build Alexa “Skills”, I found that all I needed to do was to write a new endpoint to that API and give Alexa a username and password.

Configuring the actual Skill was a little trickier. Alexa uses a lot of tricks to fake natural language parsing, but basically you provide a list of possible actions (“intents”) and then a set of sample ways to trigger those actions (“utterances”), but the closer you get to colloquial or natural commands, the harder things seem to get working. The documentation for designing these interfaces suggests the format should stick to “Alexa, <verb> the <noun> to <action>” formula, and as you can see from the video that works, but when designing text interfaces I prefer being able to provide colloquial aliases, and while “Alexa, Tell the kettle to start” works, even with it defined in the utterances file “Alexa, Put the kettle on” seems to match the internal guesswork as a Smart Home defined device (the reaction is “Can’t find a device called “kettle” in Aquarion’s account”). Maybe that’s a better model to use for the Skill, and I should refactor around that. I’m also having large problems around setting specific temperature, as the API seems to send things with “?” in the temperature slot, or send a SetTemperature intent but with no slots defined, so there’s still debug to do.

The Alexa Skill is, of course, not publically available. It’s tied to my kettle, and in order to set this up for someone else they’d need a new Skill App, a full Retort installation (and, of course, the kettle). I could set up a centralised app location where you put in your IP, username and password and it brokers Alexa calls to kettles, but I’m pretty sure the technical bar to installing this app puts it in the low tens, all of which can do all this themselves.

Side note: I recorded the video at 4am (It’s the holidays, my sleep schedule is shot to ribbons). I made the tea, then started writing this up. It’s now ten past five in the morning, and third time lucky I actually got all the way from boiling the water, putting it in the teapot, remembering all this five minutes later, and drinking the tea. Voice activated kettles cannot save you from chronic disorganisation, be warned.

2 comments
  1. Hi there,
    Am setting up my home automation and am trying to get my ikettle 2.0 onto The system using Alexa and RM plugin, can you help me with the Alexa Skill you created for your kettle, would really appreciate it.

  2. My understanding is that they rebuilt the interface for the iKettle 2.0 and the current module doesn’t work, but I don’t have any more information than that. (Mine is a 1.0, I’ve not played with the 2.0). If you have coding skills, your best bet might be to use something like Wireshark to watch the traffic while you use the phone interface, and update from there. If I get an iKettle 2.0 I’ll update the skill, but that’s all I’ve got for now I’m afraid.

    I’d recommend an email to Smarter.am for documentation on their kettle API. If enough people ask, we might actually get some traction.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Related Posts
“But daddy, I don’t understand” And I hope you never need to, darling. The lesson is not for…