It’s finally ready. I’ve been working on a Node-RED node to act on Amazon Alexa Home Skill directives since November last year. The skill was approved some time very early this morning and now should be available in the UK, US and Germany.
I’ll be mailing all the folks that have already signed up some time later today to let them know they can finally start using the skill, but for the rest of you here is a brief introduction (full details in earlier post).
Alexa Home Skill’s allow you to say the much more natural “Alexa, turn on the kitchen light” rather than “Alexa, ask Jeeves to turn on the kitchen light”, where “Jeeves” is the name of skill you have to remember. Some of the basic commands are:
With this node and service you can wire those commands to nearly anything you can control via Node-RED.
You can install the node with the following commands:
npm install node-red-contrib-alexa-home-skill
Or via the Manage Palette option in the Node-RED editor.
If you have already installed this module please make sure you update to the latest version (0.1.13) to get the best support for all the voice commands.
There are detailed instructions on how to set everything up here.
Here is an example flow using the node. This turns a light on then automatically turns it off after 5mins. It uses the switch node to detect if it’s a request to turn the light on or off. When following the On branch it uses a trigger node to first send a payload of true then, 5 minutes later it sends false to the WeMo node.
This sort of flow would be great for a set of outside lights or maybe an electric heater. I also have some updates to the node-red-nodes-wemo package to make dimming/brightening by specific amounts easier, I’ll try and get them out by the weekend.
If you have problems with this node please do not post comments here, it really isn’t the best place to work issues. Open a issue on github here then it can be properly tracked.
I’ve been playing with my WeMo Link device again. A couple of weekends ago I made a mistake, I used the Belkin WeMo Android app to turn a light on (rather than ask Alexa to turn it on via Node-RED). While doing this the app suggested I update the firmware on the Link device. I decided to let it do the update, this led to whole host of issues with the device not wanting to connect to the WiFi.
In the end I had to reset the device, and re-pair the bulbs. The re-pairing worked, but the Osram bulbs didn’t show up in the WeMo android app any more. It turns out the app no longer show bulbs which haven’t been “WeMo Certified”. They still show up when you query the API directly and I can control them via my Node-RED nodes but I couldn’t add the bulbs to groups. The WeMo Link supports the ZigBee Light Link protocol just like Osram Lightify, Philips Hue and the Innr lights so there is no reason why all of these things shouldn’t be able to play nicely with each other.
This sent me back to reverse engineering the SOAP API to interact with the WeMo Link.
I’ve had a pretty good go at working out the protocol already, resulting in the wemo-control.js script and the Node-REDWeMo nodes, but this is just basic discovery and control not really “admin” tasks. I decided to break this work out into it’s own script.
There are 2 main tasks that this script will have to do, add new bulbs and create groups.
This was actually pretty easy, the API end points were pretty obvious in the list.
OpenNetwork – allows bulbs to join the mesh
GetEndDevices – when used with the UNPAIRED_LIST filter it shows just the new bulbs.
IdentifyDevice – makes a bulb flash so you can work out which bulb is which if you discover new bulbs
AddDevice – adds a new bulb to the mesh
CloseNetwork – stops bulbs joining the mesh
None of these calls take any complex arguments and all are available either via discovery responses or other simple calls. If you chain them together in the order above you end up with your new bulbs available (at least to my scripts even if not in the WeMo app).
This one was a little harder, while the API list a CreateGroup endpoint, it says that it takes as a single argument if type ReqCreateGroup which is listed to be a string. Now from experience I can guess that this string is actually a URL encoded XML fragment. There are no hints as to what this XML fragment might look like. This led to a slight diversion down a rabbit hole to set up a raspberry pi as a WiFi AccessPoint bridged on to my local network so I could run tcpdump to make sure I captured all sides of the conversation between my tablet and the WeMo Link. A little bit of formatting and collating in Wireshark and we hit pay dirt:
A unique id for the group (looks like it’s epoch time in seconds)
Name of the group (probably should be XML escaped, but we’ll keep them simple)
The list of device IDs to include in the group
The subset of capabilities that all the devices in the group support
Some starting values for those capabilities
Now I had the format of the messages I need to send it’s time to actually write some code. The first pass is up here, it’s a little rough and ready but I’ll try and clean it up a bit later and add a command to rename devices, but it’s Friday afternoon and I’m typing this up in a bar…
To add a bulb you would follow this flow of commands: