11436 SSO

APIs and the Connected Home

Mar 04, 2014

Home remodeling projects always seem to present some unexpected and unnecessary (particularly in the mind of the frustrated do-it-yourselfer) complexities and headaches. I recently ran into such an issue during my effort to transform my house into a connected home—and it’s a problem that can be solved by APIs.

In researching connected lamps, outlets, and switches, I was amazed at the number of products out there, including smart lamps from Philips, TCP, Holi, LIFX, AppLamp, LimitlessLED (there are even smart sockets); smart outlets from Modlet and Iris (by Lowe’s); and smart switches from Belkin and Insteon.

Because all of these use a wide variety of wireless technologies (Z-wave, Zigbee, Bluetooth, and WiFi), they connect either directly or indirectly (via a bridge) to my WiFi router. Despite the complexity and variety of products available, the connectivity aspect and physical implementation is getting better, making DIY installations achievable and actually fun to do.

A tangle of apps

There’s still a major problem, however: all of these smart devices in a home (especially when you add Nest, smart garage doors, connected cars, and security systems) have their own app that enables control of the devices from a smartphone either at home or when traveling. So in order to have full control of my house, I end up with a mess of apps. It’s gotten to the point that I’ve had to create special folders on my iPhone and iPad.

I have to juggle between apps (with different UIs—some bad, some very good) to perform specific actions. Sometimes they even conflict with each other: turn off the Belkin WeMo switch and, because it controls the Philips Hue lamps, they turn off too. There also is no way to perform aggregated actions. For example, when I’m five miles from my house I’d like the thermostat to set itself to a higher temperature, and when I turn the corner of my street, I want lamps go on, the garage door to open, and the security system to disarm (I’m not lazy—just a geek). Then there are also the myriad passwords and accounts I’ve had to create in order to make everything work.

Device aggregation

So while it’s important to make sure that all of these products are independent (variety is a key factor in innovation), there must be an easy way to create some complex aggregation. I like how Revolv (this is my next device acquisition) or SmartThings scan all the frequencies in the home, register all detected devices to a bridge, and then provide a single app to control them.

While this simplifies the physical aggregation, it still does not solve the overall device aggregation problem. Some products offer an IFTTT connectivity, which allows the creation of recipes based on the “if <action> then <action>” pattern. This is a good start because it provides the ability to create great demos, but again still does not solve the overall problem of logically bringing many devices together in a single solution.

The rendezvous point

APIs have been disruptive and have changed the game at many companies in many industries, so why not in the connected home? Each smart device could come with an API that is accessible through the cloud. To achieve this, the connected devices need to speak to a rendezvous point that implements a device API (if this isn’t already done by the device itself or by the bridge to which the device is connected). More importantly, the API would be exposed to application developers.


A good rendezvous point should be : 

  • secure, because I don't want my light switch to be hacked or controlled by someone other than me
  • multi-tenant at the user/device level, because data from one device belonging to a specific user should not leak to another user or device
  • distributed, because the speed of light is not enough
  • massively scalable, because we are talking about billions of devices
  • always available, because a lack of device access is unacceptable

Beyond simple API management

Once implemented, a device API can be exposed the same ways that many of the APIs are already exposed through developer programs, which goes beyond simple API management because it also includes a whole set of tools, including: a security framework (via OAuth); push notifications; connections to social and contextualized data; the capability to create loosely coupled aggregation of device and cloud services; and data collection.

On top of all this, a very good analytics platform can generate insights for the different parties of the API value chain (users, application developers, and device manufacturers).

Apigee Edge provides the capability to develop such rendezvous point:

  • API Services can help transform basic signals or complex commands coming from a connected device to a proper REST API; it can help to properly expose these APIs to a wide variety of developers; and it can help developers write mobile applications
  • Advanced Developer Services can create an ecosystem of device APIs and a managed environment for application developers to use this ecosystem
  • Analytics Services can provide the necessary feedback on the device-side or the application for improving the device ecosystem

Omnichannel, omnidevice

By exposing device APIs, companies will enable innovative solutions for their own device (I, of course, trust device manufacturers to develop nice applications, but it's difficult to compete against the millions of developers out there). More importantly, exposing device APIs enables innovation for a collection of devices accessible on a wide variety of channels (omni-device and omni-channel solutions). For example, when my connected car is in the garage of my connected house, I’d like to create new types of interactions:  starting the engine causes the garage door to automatically open, or, when the power grid fails, the battery of the car is used as back up for essential electric devices in the house.  When the battery drains to certain level, the car starts automatically to act as a generator for the house. The results of these interactions would be visible or accessible from any channel (phone, tablet. or TV).

The proliferation of connected devices does not have to mean a proliferation of apps to control these devices, but it definitely should mean that devices will be accessible through APIs to create many user-friendly, omni-device experiences.

image: GS+/Flickr


Scaling Microservices