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:
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.
Can you share the code from the web service?
@Rick I put the code on github: https://github.com/jpreardon/twine-test
Update 2014-11-16: You should read my Twine Update if you are considering the purchase of a Twine.
Twine is great. Out of the box, it’s easy to send email and SMS messages, but to really unleash this device’s potential, one needs to explore the HTTP Request action. This makes the Twine a node on the Internet of Things (IoT) and offers a lot of flexibility as to what can happen based on physical input. I’ve written about this before in my First Twine Project, in which I had a Twine and an Arduino talking through a quick and dirty “web service”. This was a fun proof of concept, but calling the PHP I wrote in 10 minutes a web service is a stretch. So, I’ve been looking for a more substantial web service that can be used by the Twine. Twine won’t work with many web services such as cosm (f.k.a. Pachube) or Open Sense, but it does work with at least one: ThingSpeak.
ThingSpeak is quick to set up and offers a fair amount of flexibility. One can read & write data and integrate with other services such as a Twitter or Twilio. ThingSpeak also has the added bonus of being open source, so you can set it up on your own server, if you wish. In my case, I just wanted to do some temperature logging. If you’re interested in how I did it, keep reading, the instructions are after the break.
You’ll need a Twine and a ThingSpeak account. Assuming you have both of those things, the first thing to do is set up the ThingSpeak side of things. You’ll need to create a new channel on ThingSpeak, this is where your Twine will write the data. Once your channel is created, click on the API Keys tab of your newly created channel. Copy the Write API key, this is the longish (~15 characters) string. Twine will need to use this key to write data to the channel.
Now it’s time to set up some rules on the Twine, which will feed data to the ThingSpeak channel. In this case, I want temperature logging, so I want to send the current temperature to the ThingSpeak channel whenever it changes*. Unfortunately, Twine’s temperature events only trigger when the temperature rises above or falls below the value you specify. However, since more than one rule can be set up, one can cover a range of temperatures by defining two rules for each degree in the temperature range being monitored. Yes, this is a kludge, but it’s what we have to work with right now. To set up the rule, you’ll need the URL for your ThingSpeak channel, it should look something like this:
http://api.thingspeak.com/update?key=**Write API Key**&field1=[temperature]Make sure you replace
**Write API Key**with the Write API key for your channel (created above). As for the optional parameters (trigger and reset after), I left those at 0.1 and 60 seconds.Once you upload these rules to your Twine, go check your ThingSpeak channel. You should see at least one entry in your the log. A screenshot of my log from overnight appears above. So far, I’ve found that the Twine can be a bit flaky about sending out updates, even as compared to the current temperature shown on the Twine site. For my purposes, this is fine. So long as I get a reading every couple hours, I’m happy. For more precise measurements, this might not be the device for you. I do hope that the accuracy of Twine increases as they release later versions of the software.
* It would be nice if Twine supported an “on change” event, but it doesn’t–not at this time anyway. Creating a bunch of rules to track the temperature isn’t that big of deal when logging temperatures within a fairly narrow range. Doing the same for a wider temperature range of 20 or 50 degrees would just be ridiculous; I wouldn’t recommend it. Let’s hope that the Supermechanical team adds an on change event or something similar in the near future.