The Internet of Things – If this then what?
English: A technology roadmap of the Internet of Things. (Photo credit: Wikipedia)
The “Internet of Things” (or IoT) is an evolution of microprocessor engineering, sensor innovations, wireless communications technologies, and of course the Internet itself. An IoT “thing” could be any natural or man-made object that can be assigned an IP address and provided with the ability to transfer data over a network. For example, inanimate objects (i.e. many cars have more built-in sensors than early NASA shuttles for doing everything from alerting the driver when tire pressure is low to regulating anti-lock breaking systems or airbag deployments during emergencies), animals (i.e. a wild animal tagged with biochip transponder to track position/population size or migration patterns) or people (i.e. an elderly person with a heart monitor device or any other implant or device which tracks health data). In all of the previous examples, “things” are provided with unique identifiers and the ability to transfer data over a network without requiring human-to-human, human-to-animal, or human-to-computer interaction. A major question of this Internet of Things is now what the “killer applications” will be. As in, what real-world problems will be solved, what efficiency improvements can be gained or which tangible benefits can be realized for the end user? By connecting more and more devices (thanks to the proliferation of IPv6 addresses, enough to give every atom on Earth’s surface a dedicated IP), we are of course creating more and more usage data, observational data and metadata about the interactions of these devices and users within the rest of the world, which has also placed even more importance on BigData. Certainly, a big part of IoT will be task automation (the absence of a user during operation of devices and their software), enabling devices to function more and more autonomously and theoretically freeing up users from manually entering commands via a command-line or clicking/tapping on controls within a user interface. Enter the service If This Then That (IFTTT), which enables you to “wire together” the capabilities of or otherwise integrate data from two disparate sources to accomplish a particular goal. Rules as Recipes
“Recipes” are the term used by IFTTT to refer to each set of IF <this> THEN <that> rules. The IFTTT team describes recipes as:
…a very handy tool to help put the Internet to work for you in various interesting ways. They have a wide range of selections that you can mix together to create technological recipes which can help cook up something along the lines of sending an email to alert you that it’s going to rain tomorrow or to download an image every time someone tags you in a photo on facebook. The possibilities are nearly endless yet very powerful in the palm of your hands.
While the Rules Engine is primitive at best, it proves that often times less is more. By simply enabling you to take one thing (i.e. a sensor event, monitored threshold, or manual control command sent by a user) and as a result do another (such as send a message, operate a device or log some data), IFTTT provides a much-needed integration service for the Internet of Things (IoT), kind of like the communication bus in your computer provides input/output between your computer’s various chips and from those chips to various peripheral devices (like monitors, printers, network routers to be sent on to other computers/networks, etc). Some examples of the communication technologies supported are the usual suspects, such as:
- HTTP (raw call to a web URL)
- FTP (file transfers, i.e. data backup/archiving/logging)
- SMS
- Mobile Notifications (iOS/Android/BlackBerry/WindowsPhone)
- Tweets
- Social Network posts (Facebook, Instagram, Tumblr, MySpace, LastFM, etc)
- Pull updates (via RSS)
- Push updates (via HTML5 WebSockets)
Events can be powered by just about anything that can be reached and/or share information via an API, including the following commonly-used configurations:
- receipt of a communication (any of the above forms, i.e. Email, SMS, etc)
- click of a button (i.e. in a Web or Mobile GUI)
- time (i.e. a certain scheduled day-of-week, time-of-day, or timer interval elapsing)
- temperature
- lighting levels
- noise levels
- geographical location
- any kind of basic threshold being reached (one specific value equal to something)
- more complex built-in sensor triggers (only those configurable on sensor-side)
Multiple Values and Complex Rules
Neither the monitoring of multiple values nor complex rule evaluation scenarios work particularly well with IFTTT yet though. For example, if you have both a Philips HUE Smart Lighting system and a NEST Smart Thermometer system, you would be able to separately tell your NEST to reduce temperature when you leave the house (using geo-location) and fire back up as you leave work, which is definitely handy. Likewise, you would be able to set your HUE to turn off the lights when you leave the house without needing to remember to flick the switch, and turn them back on when you arrive. However, what if you’re actually visiting your friend’s house next door. All that stuff will likely kick in when you might not necessarily want it to, because the geo-location APIs of devices and browsers are usually quite imprecise. What about having those systems cooperate together more closely? For example, you may want to tell IFTTT that if you’re away from home for an extended period of time but your plants need simulated ultraviolet light via your HUE system’s LED lights, then override any other settings which tell the lights not to turn on unless you are at home. Not possible with the current basic IF this THEN that rules configuration options. There is no real brain or intelligence in the service that could reason that your plants could die if kept in the dark for a certain number of days. Should you want more complex integration scenarios, you will have to program that on the edge directly (that is to say, within the individual sensors, devices, networks and services you are integrating) and then simply use IFTTT as the scaffolding to wire together the various parts of the overall system you’re building. So my point is not necessarily that IFTTT is completely lacking, on the contrary, its a great service; but it clearly leaves the door open for tons more innovation in the IoT space, whether you choose to build upon IFTTT as an integration platform or not, and whether you’re innovating at the integration/logic layer or on the edge by adding innovative new IoT devices/sensors/services. Some cool IFTTT Recipes You can do some really cool stuff with IFTTT, here are some of my favourite recipes:
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
Here’s the first recipe I published in order to help me remember to get enough steps per day (at least 10,000) as I was in a “FitBit Challenge” at work to log our physical activity and the winner got an extra $150 Wellness Benefit for the year: 
- if the IFTTT incoming SMS # receives any SMS text from my phone number, publish the contained text (and link) to social bookmarking tool Delicious
- remind myself to take out the trash every Friday (and if its the last Friday of the month, to pay the bills)
Here’s an excellent image from Dutch e-news service Emerce.nl which summarizes everything you could want to know about IoT nicely in a single Infographic:
IoT – Past, Present, Future (courtesy of Emerce.NL)
Conclusion
The simplicity of IFTTT makes it a popular choice among IoT tinkerers, developers and early-adopters/power-users alike. At the same time, it leaves some room for further simplifications for totally non-technical users (i.e. my grandparents or even parents would likely never sit down and write their own “recipes”); and at the same time, further complexity in the expressiveness of the “rules” to allow for the creation of more fine-grained logic branches and decision trees. With IoT what we need is not necessarily just another service in the “middle of the stack” to enable the integration of devices, we can already do that with an ESB (but it certainly helps remove the need for one-off custom API implementations in the interim); what we really need though, is a form of intelligent and responsive service that cooks up just the “integration recipe” you need, precisely when you need it. This dream IoT service (yes basically the “intelligent agent” which the Semantic Web advocated for, and which we’re starting to see form through Siri, GoogleNow & Cortana), must think carefully before firing off each and every one of its messages or device control operations. It is several layers of intelligence on top of the basic integration convenience layer that IFTTT provides.
Whether IFTTT ends up being the “killer app for IoT” or not remains to be seen; but with the API wiring they’ve already done, it could serve as an excellent platform upon which to build integrated IoT services and devices, and it is well worth a closer look for any serious technologist. That said, we should also be aware of the implications of handing over all of our account credentials and/or authorizations to a single service (even though on IFTTT such is done as securely as possible via OAuth, WebFinger, SAML and similar protocols). We are essentially creating a “key to the kingdom” type of situation wherein IFTTT or your account within it being hacked, exposes data from many other devices/services. One could even think of property-damaging implications (i.e. connected sprinkler systems, humidistats/thermostats, smoke detectors, etc) or potentially even life-threatening triggers and actions which could be fired (i.e. some are hooking up connected cars, pet feeders, heart rate moniotrs & medical devices, etc) if the system were exploited.
We can minimize these risks with a little bit of common sense, only connecting those devices which offer high levels of convenience and low risks of impacts if accessed illegitimately by another party.
