The most online popular service for connecting online services together and automating tasks using them, IFTTT, or “If This Then That,” just got hooks into maker-hacked hardware.
IFTTT started off as a way to connect online tools and services, triggering one from the other. For instance, you can have a “recipe,” as IFTTT tasks are called, that automatically takes every new photo you post to Instagram and saves it to your Dropbox. If this: you post a photo. Then that: save it to Dropbox. It’s actually pretty powerful, and you can get a long way by using what, on the face of it, is a relatively simple rules engine.
In the last year or so, however, the service has become even more powerful, because the site has moved to support not just pure online services, but also things. From your Nest Thermostat, to your SmartThings, WeMo switches, and the Wink devices, the list of what IFTTT calls ‘connected home’ products that it can both receive data from and control has grown quickly.
Which wasn’t that interesting for DIYers, as most of the hardware was strongly off-the-shelf stuff. Recently however, IFTTT added something for us: a Maker Channel.
This allows you to connect IFTTT to your personal projects. You can now write recipes that can be triggered by one of your own projects, like a network-connected Arduino, or Raspberry Pi. You can also send messages to a network-connected Arduino directly from IFTTT, and triggered by any existing service. Here’s how.
How to Trigger Events
Once you connect your IFTTT to the Maker Channel, triggering an event — creating the “if” of IFTTT — is simple. All you need to do is send a GET or POST web request with an event name and secret key — the key is assigned when you connect the channel — of the form,
https://maker.ifttt.com/trigger/{event_name}/with/key/{secret_key}
with an optional JSON body consisting of up to three values, or strings, to be passed on to the action in your recipe. Since you can trigger this event with something as simple as curl from a command line this is a really powerful lever, because that makes it really trivial to trigger an IFTTT recipe from a Raspberry Pi, or even from a networked Arduino.
How to Call Services
Calling services from recipes — the “that” of IFTTT — is also very simple. You just need to provide and endpoint, a web address or URL in other words, for it to call. The recipe can take the form of a GET, POST or DELETE request, and can optionally contain variables and content. You can pass data — possibly the data provided by the triggering service, or device — to your remote web service.
Now this service can be hosted in the cloud, but if you have a static IP address at home — or make use of a dynamic DNS service like DynDNS — then it equally well could live on a Raspberry Pi, or an Arduino sitting in your home.
…and Then That, But Also That?
One of the things people complain about when it comes to IFTTT is that it lives up to its name, it will trigger an event if something happens, but you can’t chain events together, and the service has no hooks to make decisions, or to make two things happen instead of one.
With the new Maker Channel it’s actually now pretty easy to do that, we can create a recipe that fires a Maker Web Request to a remote service. The service in turn can turn around and use the Maker Channel to trigger different IFTTT actions, or even more than one action.
Proof of Concept
To test this out I set up a simple recipe. This recipe fires every time my Netatmo Rain Gauge on my home weather station detects that it is raining, and calls a simple CGI script on one of my servers — apparently I’m the sort of guy that has a couple of servers stashed away in racks, you know, just for emergencies.
The script it calls is very simple, it talks back to IFTTT, triggering two different Maker Channel recipes. Now since this is proof of concept, I’m doing this in a ludicrously insecure and dumb way — I’m using a simple Bash script, and the curl command.
#!/bin/bash echo "Content-type: text/html" echo "" echo "<html><head><title>Maker Channel" echo "</title></head><body>" secret_key="SECRET_KEY" string=$IFS IFS='=&' param=($QUERY_STRING) IFS=$string echo "<p>${param[0]} = ${param[1]}</p>" curl https://maker.ifttt.com/trigger/remote_trigger/with/key/${secret_key} echo "</p>" curl https://maker.ifttt.com/trigger/other_trigger/with/key/${secret_key} echo "</body></html>"
As you can see this script simply calls two further IFTTT recipes that I’ve set up on the service. The first toggles my Blink(1) on to let me know it’s raining.
But, since the rain outside makes my home office gloomy, the next call turns one of my Belkin WeMo switches on, the one connected to my desk lamp.
Now obviously in this case I could have just as easily set up two separate recipes that triggered on the first event — that it had started raining — one to turn my Blink(1) on, the other to turn my desk lamp on. But remember, this was just a proof of concept.
I could equally well have sent this notification — that it had started raining — to a more complicated service that made a judgment, looked at or measured other things, and then made a decision beyond the scope of IFTTT’s simple rules engine. Or trigger a piece of hardware, perhaps an Arduino, that controlled my windows, or dragged a rain cover into place. Something that IFTTT couldn’t previously talk to or control.
What About Security?
Now what I did above was horribly insecure, I basically exposed to the world a script — a web application in other words — that could toggle a switch controlling a light in my house on and off. This is obviously not something you want to do, but that’s why IFTTT’s services provides the capabilities to pass more information to the remote service.
It wouldn’t be difficult to set up a TOTP authenticated link between the two for instance, or a token or key exchange — and to protect your IFTTT account itself? They’ve just added two-factor authentication.
ADVERTISEMENT
