IFTTT is a great tool for end users to set up simple automations by clicking or tapping through a few options. If you want one online service to trigger actions in another, IFTTT can probably do the job. I described it in one of my first posts as a kind of ESB, with recipes (now termed applets) for linking events in all manner of services. If you want to tweet every time your IoT camera detects motion, IFTTT will probably help.
So why am I talking about resorting to IFTTT? What’s wrong with it?
I mentioned one problem in that old blog post: security. IFTTT is a third party service and you need to grant it access to the endpoints that you want to use. Want to save Facebook photos to your Dropbox account? You’ll need to give IFTTT access to both.
I’m also a tinkerer. I like writing code and I’m running an ESB on my home server. I’d prefer to have full control by writing my own integrations.
In order to be able to do that, the services must have a documented API and that’s not always the case.
You can probably spot where this is going… I’ve found an example where a documented API doesn’t exist and I wish it did.
As part of my home security drive, I decided to take a chance on NetGear Arlo cameras. I already have one IP camera outside, and running a cable for it was a pain. The Arlos are battery operated and dotting a couple of them around the house gives me better coverage without too much hassle.
As the cameras are battery operated it’s best to switch the motion detection off when it’s not needed to avoid unnecessary drain. I decided I wanted the motion detection mode on only when I’m out. While the Arlo app itself has a geofencing option, I already have a more accurate indicator in the form of my Samsung SmartThings presence sensor. All I needed was a way to get them to talk to each other.
Ideally leaving the house would cause the SmartThings hub to send an event message to my home server which would then call the Arlo API to enable motion detection, and vice versa.
The SmartThings end is achievable. While the hub won’t push events directly to the server, it is possible to get events to trigger SmartApps in the cloud which then instruct the hub to send a message to the server. It’s a bit more complicated than it really needs to be, what with the rather unnecessary round trip to the cloud, but at least it’s possible.
Unfortunately there doesn’t seem to be an open API to interact with the Arlo service. That’s really all I need – a simple API to set the mode that I can call in response to events from SmartThings.
The really frustrating thing is that there is an API. There must be, because I can use an IFTTT applet to do exactly what I want. IFTTT can receive messages from SmartThings and use them to set the mode of the Arlo system.
If IFTTT can do it, why can’t I get my own server to do it? It’s because the API is not documented. The IFTTT code might have been supplied by Netgear, or they might have provided the API details to IFTTT, but they haven’t chosen to make it public.
There are some workarounds. Someone has written some Python code that does the job by observing what calls are made to the website when you manually change modes via the web interface. It’s reverse engineering, and that means that it could break whenever Netgear make changes to their website. A proper documented API is the only reliable way to do it, and in the absence of that I’m having to resort to IFTTT.
So Netgear get a black mark from me for not opening up their API – and apologies if they have and I just haven’t found it yet. It’s not uncommon. Many internet and IoT services are effectively black boxes where the only possibility of further integration is if they implement IFTTT applets.
Perhaps I’ve been spoiled by SmartThings. While it has its quirks, it gets integration. It shows it is possible to be perfectly consumer friendly out of the box while still making an open platform for those of us who want to build on it. Kudos to SmartThings for getting it right.in Random Musings