[Chris] has been playing with the Amazon Echo. It’s sort of like having Siri or Google Now available as part of your home, but with built-in support for certain other home automation appliances like those from Belkin WeMo and Philips. The problem was [Chris] didn’t want to be limited to only those brands. He had other home automation gear that he felt should work with Amazon Echo, but didn’t. That’s when he came up with the clever idea to just emulate one of the supported platforms.
The WeMo devices use UPnP to perform certain functions over the network. [Chris] wanted to see how these communications actually worked, so he fired up his laptop and put his WiFi adapter into monitor mode. Then he used Wireshark to start collecting packets. He found that the device detection function starts out with the Echo searching for WeMo devices using UPnP. The device then responds to the Echo with the device’s URL using HTTP over UDP. The Echo then requests the device’s description using that HTTP URL. The description is then returned as an HTTP response.
The actual “on/off” functionality of the WeMo devices is simpler since the Echo already knows about the device. The Echo simply connects to the WeMo over the HTTP interface and issues a “SetBinaryState” command. The WeMo then obliges and returns a confirmation via HTTP.
[Steve] was able to use this information to set up his own WeMo “virtual cloud”. Each virtual device would have its own IP address. They would also need to have a listener for UDP broadcasts as well as an HTTP listener running on the WeMo port 49153. Each virtual device would also need to be able to respond to the UPnP discovery requests and the “on/off” commands.
[Chris] used a Linux server, creating a new virtual Ethernet interface for each virtual WeMo switch. A single Python script runs the WeMo emulation, listening for the UPnP broadcast and sending a different response for each virtual device. Part of the response includes the device’s “friendly name”, which is what the Echo listens for when the user says voice commands. Since the virtual WeMo devices are free, this allows [Chris] to make multiple phrases for each device. So rather than be limited to “television”, he can also make a separate device for “TV” that performs the same function. [Chris] is also no longer limited to only specific brands of home automation gear.
There’s still a long way to go in hacking this device. There’s a lot of hardware under the hood to work with. Has anyone else gotten their hands (and bench tools) on one of these?
does it even care that the IP is unique, or just the url? listening on multiple ports would be much more friendly than occupying a bunch of IPs.
In the article he says that initially he was trying to keep everything as WeMo like as possible, but now he’s going to see what he can change and have it still work (such as multiples on one IP). Too bad the source isn’t posted yet, I’m going to have to keep tabs on this.
Apparently there’s a Hue Bridge emulator that allows multiple devices with just a single ip taken. There’s a youtube video of it in action, but I can’t find any info about how it’s configured.
There’s lots of info about it in this thread: http://forum.micasaverde.com/index.php?topic=31920.0
https://github.com/armzilla/amazon-echo-ha-bridge
Wow that’s much simpler than I thought. I’ll definitely have to try this with mine when I have some free time.
Yes, each wemo switch needs to have unique IP address.
In case of WEMO light bulbs you have to buy wemo light bulb starter kit which includes wemo link(unfortunately can’t be bought separately, which I neded up finally with 3 lightbulbs because description on the box is misleading) and only takes one ip address and then communicates internally with the light bulbs.
I ended up writing my own backend+frontend in php/html+js scripts because wemo software literally sucks. It is slow, before it will discover devices through upnp it takes time, not always everything is detected, and software is only Android/iPhone there’s no possibility to run it on windows phone, or control anything from your PC.
I’ve ended up writing my own backend+frontend for Switch+Light bulbs. It’s not great, however it does the job. It is fast, it doesn’t need to go through slow process of discovery, and is compatible with every single device because it’s just a webpage which I can control from anywhere, or just invoke bash script when logged in from ssh.
But if you would like some more details, let me know, I can put code on bitbucket if anybody interested(I’m not a great coder, but I think you should understand it pretty easily as it’s not very complicated).
Absolutely put your code up. I’d suggest putting it on GitHub though so it can be searched. Even if you think your code is junk (if it works at all, it’s not) it’ll be a starting point for someone else.
Please do post your code. I just got a couple bulbs from someone who got too frustrated to make them work.
Please share your code. :)
I am interested in the code. Thx
nice effort and write-up. while I’m not sure I’d want to own an echo (unless it was 100% under my own control) it seems you are trying to at least let it control things that YOU want and that’s quite admirable.
the IoT lock-in world is annoying; and anything that increases the freedom for users is a Good Thing(tm).
Nice work, but this seems overly complicated with the requirement of individual IP addresses for each virtual device. I used armzilla’s Hue Bridge Emulator (https://github.com/armzilla/amazon-echo-ha-bridge) to set mine up with a lot less hassle (just one IP for the bridge which delegates the on/off requests to various pre-existing URLs on my network). I now have a Raspberry Pi responding to all the Echo commands and controlling ZWave, RF and IR devices throughout my house.
If you have any questions about armzilla’s bridge emulator they’ve probably already been asked and answered here: http://forum.micasaverde.com/index.php?topic=31920.0
Was wondering if you shared your project anywhere so I can take a look and hopefully duplicate for a school project. Thanks!
I’d like to get a proxy running to go between this and my SmartThings devices I already have.
finally i can add a working self destruct.
“did I fall asleep?”
“for a little while.”
“shall I go now?”
“if you wish.”
(sorry) ;)
Based on my total lack of knowledge except what is in the summary, it looks like an ESP8266 with NodeEMU firmware could emulate a WeMo device.
Or am I missing something.
I mean NodeMCU, my bad.
sure, just as soon as you write upnp support :P
You mean like this person did?
http://ovoi.ru/blog/2015/04/29/ssdp-discoverable-rgb-led-controller-on-esp8266-with-nodemcu-firmware/
yes exactly! awsome <3
Or you could just get up off the couch, walk across the room and do it the old fashioned way.
…and throw another log on the fire?
Or walk outside and adjust the solar panels for optimum angle and make sure they aren’t getting dirty. Just because we can automate things doesn’t mean we should. Oh yeah, I forgot, we need these “time savers” so we have more time for important things like checking our fbook page compulsively every 3 minutes.
…because this site should be “leave-it-alone-a-day”?
This sort of hack is exactly why I read this site. If you can’t open it you don’t own it.
Update:
Using Alexa 2nd gen in your home is not working with this coding anymore. Only with Alexa 1st gen (either alone or in addition to 2nd gen) will work.
Alexa 2nd generation won´t find any “ESP8266 hue” device :-(. Looks like SSDP request of Alexa 2nd gen is different. Working on a solution but without success so far.
Just when I thought using the wonderfull 8266 chip was good youve come along and made it great. Please publish on git hub though,and share what comes from your brain with us all.