First up close the gap between what the doc claims the nodes do and what they actually do. This is mainly the WeMo Out node which claimed to support an input object that could set both the state and the brightness at the same time for light bulbs and groups. In actuality it only set the state. This update fixes this along with supporting setting colour and colour temperature as well if the bulb supports those capabilities.
The WeMo in node (event node) now includes the capability name as well as it’s code when a bulb or group changes.
Fixed Light groups to actually work
Automatically set the node name to the discovered device name to stop you having to set it via the name field in the config
The biggest change is the addition on the new WeMo Lookup node. This node queries a given device for it’s current state.
For Sockets the node sets the msg.payload to something very similar to the event node’s staus field, so 0 for off and 1 for on (and 8 for on/standby in the case of the insight socket.). For lights/light groups it outputs an object similar to the Event node, with keys for each capability the light/group has. At the moment the color field is still in X,Y values not RGB.
This makes it possible to implement flows that carry out relative changes without having to keep a permanent record of the state of the device in the context. This let’s you do fun things like this:
This flow looks up the current brightness level and then increases or decreases it based on the direction the Powermate is turned and toggles the light on/off when it’s pressed.
Version 0.1.11 should have gone live on npmjs.org today.
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:
A while ago I wrote a little nodejs script to control WeMo devices. At the time I only had two bulbs that I had in different rooms so it didn’t make sense to support light groups.
Towards the end of 2014 Belkin and Osram announced that Osram’s Lightify bulbs would support WeMo’s bridge controller. In this line was a GU10 bulb and I recently purchased two of these.
Both of these have been fitted into a single light fitting so it made sense to group them together, but this left me with a problem that my script wouldn’t work. After a little bit of playing (and another fruitless back and forth with @WEMOCares on twitter) I managed to get group support working properly. It could do with a bit of cleaning up and refactoring but it works: