Sensors as a Service are a Disservice

Building up an IoT solution, at least in just about any work that I do, tends to require data from sensors.  Preferably cheap sensors.  And in many cases wireless sensors.  This has been problematic for years.  It used to be that the sensors were expensive, or the wireless was terribly unreliable but as Moore’s Law has marched forward, you can now get some reliable, inexpensive sensors with good battery life.  Unfortunately sensor vendors seem to be opting for a new type of friction – instead of making money on selling us sensors, they’ve decided that making money off of the data from the sensor is the route they should go.

It’s common to hear from the vendors that integration into your solution is simple.  After all, they provide SDKs that allow you to access your data.  Except the SDK is a REST API to their cloud.  A fair number of installations I work on don’t have internet connectivity available.  What then?  Or the connectivity is through a cellular connection, so I have to pay to send the data up to the cloud, then pay to bring it back to a gateway sitting two feet from the device?

Even when I have internet access, having the sensor data in some separate cloud just adds unnecessary complexity.  Let’s say I am working on a solution where I want to store a location and a temperature periodically.  The “sensor as a service” architecture means that I send the location data to my server, the temperature data to the sensor vendors server, then when I want to display that data in a temporally consistent manner, I have to pull from both sources (assuming both are up) and then merge the results based on timestamps (and hoping that the timestamps are identical of course)?

It amazes me that vendors think this is an elegant, or even viable solution.  Sure, I can come up with uses cases where having my sensor data in someone else’s cloud makes sense.  But for every one of those, I can think of at least ten scenarios where I just want to be able to connect right to the sensor from a gateway, very often in close proximity to the sensor, and pull the data into my own app.  From there I can do analytics, aggregation or whatever I need.

Sensors as a service are not what we need.  Proprietary APIs or vendor-only, closed source consumer mobile apps are near useless.  What we, as innovators and as a development community are simple, low-cost sensors with open (preferable standards-based) SDKs that allow our apps to directly connect to, configure and get data from sensors.  Where appropriate, I’d also like clear documentation of any packet data that gets sent to and from the sensor.  If the vendor provides an app for communicating with the sensors, I want to source for that app because it’s highly likely it does things I’m going to want to do.  Essentially, I want to take the sensor out of the box and then spend a minimal amount of time writing code to get to something that proves that it’s going to work for me.  If I can’t at least read sensor data into a console or test app in under two hours then the sensor vendor has failed.