The Wio Link is a novel IoT prototyping solution from prolific maker gear supplier Seeed studios.
The first thing to understand about Wio Link is, while it’s marketed as a simple IoT prototyping solution, it’s not really about prototyping IoT devices, but about prototyping IoT systems. Don’t think of a “device” at all, but think of overall operation of a collection of sensors and actuators placed around the world. Do you want a string of LEDs to light up (anywhere!) when a door is opened (anywhere!)? Or anything along those lines using any of the standard Grove sensors and actuators? then Wio Link could be relevant to you.
The second thing to understand is that you have the entire functionality of the product accessible via REST API, and have the ability to connect and remove endpoints on a board, but no ability to write anything even approaching application logic to the board. This results in a really interesting programming experience.
The Wio Link boards themselves do nothing but provide data transport to and from connected sensors and actuators. So in order to create even the most simple embedded system test application where you read a button and light up a LED, you are already needing to deal with more than just the board. This results in a system that can take quite a long time to respond to stimulus. But on the plus side, there’s actually no difference at all in making a button on one board flash a LED on the same board, or flash a LED on a totally different board anywhere else in the world!
After plugging my endpoints in and getting them configured in the very simple and easy to understand Wio Link App, I went across to IFTTT.com to start as Seeed have setup their own channel in IFTTT and made sure it has everything you need to work with Wio Link Grove endpoints. This means you can use IFTTT to make really simple logical constructs to connect wio-link endpoints.
The big downside with IFTTT for use with Wio link is that you’ll probably want to do some mildly complex interactions between the endpoints. Unfortunately IFTTT is not really designed for control systems. It’s actually designed for plumbing web apps together… So while it brings some fun to the party (you can log your system operation in google drive spreadsheet! or tweet at your favourite celebrity whenever anything happens with your sensors) it is also pretty simple when it comes to logical capabilities. There’s a basic “trigger on event” functionality. This is barely extended with basic comparison available for triggering from continuous levels, which is what you can use for reacting to wio-link sensor endpoints. But for level comparisons there’s not even an else clause.. so you need to set up two separate IFTTT recipes to implement a plain on/off control! As for having multiple signals controlling a behaviour…. nope.
Luckily, you are not limited to IFTTT. It’s possible to run your own code on a client machine or even maybe in a browser to access the RESTful WWW endpoints, and this will allow anything you can program in a much more featured programming system. You can also directly access the endpoints on local devices via a local IP address, which would make a localised system perform an awful lot faster and more reliable – but of course requires an application on a locally running machine. A raspberry Pi running some kind of JS or Python looks like the perfect partner here.
Now to the results you can get with wio-link. I had a pretty rainbow of LEDS lighting up in my office when the temperature went above 20 degrees C, and turning off again when it went back below that temperature. It took about 15 minutes from the unboxing, including figuring out the apps, and was setup and programmed entirely with my mobile phone.
This is unprecedentedly simple and fast. I literally can’t think of something that would be faster to get doing this out of a box that wasn’t custom built to do only that job. So it gets a lot of points for simplicity and ease of use.
The biggest issue I can see for the Wio Link is that in order to add new Wio Links to your account, configure hardware, or access the endpoints globally, you are reliant on the Seeed studio IoT cloud service being available.. if Seeed ever shutter their IoT cloud service, your Wio Link won’t run as a neatly reconfigurable set of endpoints on a globally accessible RESTful API anymore.
Of course there is still direct programming access to the board hardware, and Seeed do supply an embedded C project for the production application, that you can always edit yourself to take out the cloud stuff, perform any operations you want, and use just like any other embedded board – but under those circumstances, even though the hardware wouldn’t actually need to be binned, you’d lose a lot of what makes it unique and interesting.
Everything considered, I give the Wio Link 4 eager web app developers interested in hardware out of 5. And if you have any young children you’d like an interesting set of tools to teach simple automation concepts to, it’s probably a 5 out of 5.
It’s weird compared to anything I have used before, and quite limited… But in some situations it could be extremely useful. And since opening the box and having a play the other night I’m already thinking of a whole mess of things I could easily do to create interactive spaces, just using Wio Link. So it’s also inspiring.