Both are great. Both give you visibility & control into areas of your life you were previously unaware of (blissfully or otherwise).
But both are oblivious of the other - both operate in their own silos, defined by proprietary APIs, and likely different choices for radio protocol.
Because of this balkanization, interesting use cases that require coordination of the Fitbit and Nest are challenging or not even possible. For instance, if after a brisk walk on a hot day I would hope to return home to a nicely chilled house - my steps as counted by the Fitbit would need to be taken as input to a rules engine that could send an appropriate temperature adjustment message to the Nest.
In the absence of the Fitbit and Nest stacks directly communicating, the only solution is to try to layer on the necessary coordination layer, as shown below
The coordination layer would use whatever external APIs Fitbit and Nest made available in order to a) query my steps via the Fitbit cloud and b) send a directive to the nest via it's cloud to lower the temperature.
Of course, the two different API calls would need to be authenticated as
a) coming from a valid API client
b) compatible with the user's preferences
OAuth 2 satisfies both of the above requirements - giving to the user the ability to
a) tell Fitbit what parties can see their step data
b) tell Nest what parties can control the thermostat
This sort of IFTTT-style coordination is a key value proposition of the emerging IoT platforms like Xively, Thingworx etc. Application developers can build on the platform, and need not worry about the specifics of how different devices integrated into to the platform, and be able leverage the resultant cross-device coordination capabilities. Of course (unless the platform scrape the login screens) Fitbit and Nest have to buy into the above scenario and actively allow 3rd party platforms to call their APIs (as opposed to only their own native applications).
If the Fitbit & Nest business folks were to get together to 'do lunch' and agree that there was value for both in more directly working together, then a different (and arguably simpler, at least in the near term) integration is possible. This is shown below
Here the user's step data is sent from Fitbit (not necessarily from the device itself, as shown) to Nest. It is at Nest that the rule 'drop temperature when steps equals 3000' was defined - Fitbit knows only that the user has authorized this integration - this consent manifested in the issuance of an OAuth access token from Nest to Fitbit. By including this access token on its API calls to Nest, Fitbit gives to Nest the information required to look up the user in their systems. The rules kicks in, and the Nest cloud directs the appropriate thermostat (mine not yours) to lower the temperature accordingly.
NB This model is 'simpler' than the platform model above because there are only two services to coordinate (and so one less account for the user to manage). In the long run however, such pair-wise coordination won't scale well. What happens when I want a G&T ready on the counter when I walk into my comfortably cool house?
Of course, beyond agreeing to use OAuth, Nest & Fitbit would also need to agree on the specifics of the API by which the step data was communicated. And while shown here as the step data being pushed from Fitbit to Nest (perhaps triggered by a subscription), it could be a pull from Nest, based on some polling schedule.
The mirror image integration is also possible
Here the coordination logic resides with Fitbit, and it is Nest that is relatively dumb. Nest would probably feel that there is a big difference between giving 'write' access to Fitbit, whereas in the previous scenario Fitbit needed only to give to Nest 'read' access. I guess the BD folks will work it over drinks at lunch.
However architected, OAuth 2.0 stands to be a key enabler of multi-device coordination in the Internet of Things.
No comments:
Post a Comment