Recently I got a Wio Link prototype from from a friend at Seeed Studio. It is an ESP8266-based little Internet of Things board with 6 Grove connectors for easy device connectivity, WiFi networking, and controlled over an app & the Internet. For a quick project I wanted to hook it up with Home Assistant, an open source home automation platform that I read a lot about lately. The main focus was to have a first impression of both parts, and build up some experience for future, more serious projects. The target solution: light up an LED if a particular person is at home location. Sort of a basic alarm system, though notice that the location of the LED was not mentioned – it can actually be anywhere in the world, as long as there’s Internet connectivity. I’ve used the Wio Link, a Grove LED light, an Olimex OLinuXino Lime2 board running ArchLinux for the server, and a Buffalo router with DD-WRT system installed.
The target solution: light up an LED if a particular person is at home location. Sort of a basic alarm system, though notice that the location of the LED was not mentioned – it can actually be anywhere in the world, as long as there’s Internet connectivity.
Wio Link was introduced in Seeed’s Kickstarter campaign, where they have raised more than 8x of their original target. It looks like a neat little board, and was happy to try out when I got my hands on one.
The wiki page has quite a bit of information, so it was easy to get started. Connect to power, hold down the configure button till the LED lights up in a “breathing” pattern, connect through the Wio Link app, set up the wireless network settings and so on. Once connected, can define what kind of devices are attached to the board, and it looks like most of Grove devices are represented there. I only had a Grove LED at hand, so added it (“Generic Digital Output”), updated it, which created a new firmware and pushed onto the device.
Wio Link setup process (left to right): add device, update firmware, check status
The first update took a couple of minutes, but it’s pretty straightforward. The device then also has an API link, which brings up a web page with all the options to query, control, and reset the attached accessories (in my case that’s the one digital output).
The API is pretty simple and usable, though definitely not perfect (will come back to this).
Since manual switching the light on and off worked like the charm, the next step was to enable automatic switching by the presence detection within the home automation system.
Home Assistant is an open source home automation system written in Python. There’s a lot to like about it, and a lot of people are checking it out since a number of other, closed system providers are shutting down their services. On the other hand, figuring out the configuration to implement the automation steps I came up with is far from trivial…
Setting up Home Assistant is pretty simple. Create a new directory, add a new virtualenv environment, and install home assistant (I’ve added some bonus modules that the logs recommended):
Next step is adding the actual components (the pieces of the home automation). I’ve implemented the Wio Link light as a Command Line Switch. It has two commands for “on” and “off”, plus an extra for checking the on/off status (this latter is a very nice touch, and works well checking whether the switch took effect). In the configuration.yaml file in the ~/.homeassistant directory:
Here the URLs are coming straight from Wio Link API page, and you have to add your token value and the correct channels instead of GenericDOutD0 if you plugged your light into a different connector than me. I’ve also removed their -k command line parameter (allow insecure SSL connection), and added -s (silent mode). The last section starting with “group” is not really necessary, but could group devices to be controlled together.
Adding the presence detection through DD-WRT is just the same as in their example configuration, obviously add your own parameters.
I don’t like that username/password is in clear text, so better protect your Home Assistant device and this configuration file!
By the default configuration, after restarting Home Assistant this presence detection module will create a known_devices.yaml file in the ~/.homeassistant/ directory and add all new devices (see the device tracker component page for some more info). Here I had my smartphone, after connecting it to the home network.
That file then can be edited, for example adding device name, disabling tracking for some discovered devices (eg. the small server running the Home Assistant server itself), and adding an image. I’ve added an image using a Gravatar link, where the xxxx section is just the md5 hash of your email, get it by.
Alternatively, a recent update added local file support too, as it was discussed in the Home Assistant blog, so files in the ~/.homeassistant/www/ can be linked through the http://127.0.0.1/local/ path, so no online link is necessary (but I think Gravatar is a good unified approach).
After all this, the control interface will look something like this (the Sun is added as I had my home’s longitude/latitude information in the configuration). My icon will show Home/Away status, and clicking the switch on the presence light will trigger the light on the Wio Link.
Home Assistant control interface: sun, device tracker, and switch
The final step is the automation. This was the hardest step, as the Home Assistant automation documentation and their cookbook is pretty shallow, and often feel confusing. In the end, one working result is this pair of rules, which turn the light on when status change to home , and turn it off when changes to not_home for that particular device.
I’m sure it can be done differently, but I’m also just glad it works, as it took quite a few hours of checking documentation, trying things, and reading the Home Assistant source code to come up with a working solution.
It functions pretty well, though presence (arriving) is detected quicker than absence (going away), I guess that’s part of detection method and certain timeouts within DD-WRT.
For future development, there are more components defined than I could reasonably ever try in my life, just check the component’s page!
Home Assistant components galore
This abundance also means that the number of possible combinations are astronomical. I would wager, though, that the value of those combinations follow a power-low: most of the combinations are not interesting at all, while a relatively small number of combinations are the most useful in general! I guess the Cookbook would be a good place to highlight some more “common use cases”, not just covering the bases and filling in for the lack of documentation. There are some obviously more useful components, IFTTT component on its own can add a ton of functionality, or the RESTful components.
For more info and the lessons learned, check out my original blogpost for this project: Home Automation Mix and Match!