Update 2014-11-16: You should read my Twine Update if you are considering the purchase of a Twine.

Recently, my Twine came in the mail. After getting it set up, I went to work on my first project. This is a goofy little demonstration project, but it shows some of the powerful capabilities of internet connected devices–the internet of things (IoT), if you will.

The basic idea here is to make something happen when the orientation of the Twine is changed. I decided to raise and lower a flag. When the Twine is set up on end, the flag goes up, when it is placed flat, the flag goes down. This video shows the Twine and flag controller in action. Please excuse the poor overall quality of the video, and the build for that matter. Also, the very important message on the flag is just a bit out of date.

If you are still reading, I’ll assume that you want to know a little bit about how this all works. I’ll try to be as succinct as possible.

The main components are:

• Twine
• Web Service
• Arduino Uno
• Roving Networks RN-134 (RN-131) Wifi module
• Micro Servo

The Twine is set up with two simple rules, one for each orientation that should affect some change (back and top). Both of the rules fire an HTTP Request to a little web service I created in PHP. The LED also lights up, just to get some local feedback. The calls to the web service look something like this:

http://jpreardon.com/twine/data.php?key=keyValue&orientation=[orientation]

The web service is really, really basic. It just stores the last value of the “orientation” parameter, so long as the keyValue matches the stored key. If one hits the web service’s URL without any parameters, it will send back the stored value. It doesn’t do this in a nice format such as JSON or XML, just plain old text.

The Arduino is set up with a WiFly transceiver and polls this web service on a regular basis. When it sees a change in the orientation of the Twine, it will move the servo with the flag attached to it accordingly.

If you look closely in the video, you’ll notice that the breadboard containing the circuit to drive the WiFly and the servo is more complicated than it needs to be. This is because the circuit and much of the code used to talk to the WiFly was recycled from a back-burnered project. This could be a very simple circuit, even simpler if an ethernet or wifi shield is used.

To wrap it up, Twine is awesome, they did a great job with this device. Of course, there’s always room for improvement. In that vein, here are some observations/requests of this early release of Twine:

• The web service call happens impressively fast, much faster than it appears in the video above. The slowness there is due mostly to wait times in my polling code. The orientation data hits the web service almost immediately.
• It would be really nice to be able to replace the homegrown “web service” with something like Cosm or Open Sen.se. However, both of these IoT platforms require the input to be POSTed in a format like JSON, XML or CSV. Right now, Twine only does GET requests. It would be nice if one could have a bit more control over Twine’s HTTP request
• The rule set for Twine is a bit anemic right now. It would be great to be able to have access to more conditions. For instance, a “change” condition would be great for web service calls like this. This sort of condition would allow for data logging and all sorts of other things
• I think integration with sites like IFTTT is in the offing. That would really open up the possibilities for how Twine can interact with the world without being limited to sending email, SMS or writing your own web service.

Updated 2012-11-29: Added a link to the “web service” code.