When it comes to the Internet of Things, industry seems to be focused on lowering the cost of creating and iterating on a hardware device so that you, as an IoT startup, can start ingesting data into your cloud as soon as possible and get going on your application.

This line of thinking is jarring to me, because my experience with DIY smart home research has resulted in a conceptual model for IoT architectures that emphasizes local computation. I have found that as soon as you incorporate control logic (in other words, programs) into a smart home, it makes a lot of sense to think of the home as a computer where the sensors and actuators are merely some of the hardware components within the computer.

Can you imagine if every peripheral in your computer was only able to communicate with a cloud service hosted by its manufacturer, rather than with the CPU and other components? Now imagine that it hardly matters, because most computers are sold without any kind of central processor in the first place. Your choices as an application developer are to interact directly with each peripheral's unique non-standard cloud interface (essentially manually performing the job of both CPU and device driver), or to buy a third-party processor, which will tie some number of your peripherals' clouds together in a rudimentary, ad-hoc fashion. That processor may not know how to access or control several of your computer's peripheral clouds. The applications you develop for one brand of third-party processor will not at all transfer to another brand. When you don't have an Internet connection, your computer will not be able to function.

Your computer probably wouldn't work very well, and it would be a nightmare for end users to interact with it to accomplish their goals.

This mindset that each IoT device will send its data off-site to its own proprietary cloud seems like a poor semantic match with the kind of behavior that end users want in smart homes. People get frustrated when they lose Internet access and their home applications break seemingly for no good reason since all of the data and behavior is local. So why do we build IoT systems this way?

It's certainly not out of technical necessity. Computation and storage are cheap now. You could easily move local computation and storage to the building itself. What the software side should look like is still an open question, but you could define a "bus protocol" of some kind that would allow for local communication with the "central processor" and access to a local datastore (there is research work in this direction). You could write a basic operating system that abstracts and exposes the hardware capabilities to a higher-level application development environment, which would allow for the creation of portable applications (write for one building, run in another with a different setup). As a company, if you need to collect data about how clients are using your product, you could have analytics or crash reports sent to you, just like with modern applications on computers and phones.

But that's not what consumer IoT looks like.

Why?

There are almost certainly a number of factors that have led to the current cloud-oriented situation, but I think one of the biggest influences has been the Big Data mindset.

We entered the era of Big Data when companies started collecting enormous quantities of data about their clients as a form of competitive advantage. Companies were getting valued not even on the useful things that they were doing with the data, but on the "potential" that could be unlocked by someone else with the right analytics and a monetization platform. Machine learning (a.k.a. computational statistics) got a ton of hype soon afterwards as a method of extracting interesting and relevant features from huge amounts of data.


Machine learning, so hot right now

Building a product that sends a bunch of data to the cloud is now a design pattern and, more importantly, a business model that Silicon Valley has come to understand, expect, and reward. The products being sold are not the apps (which are often free), but the generated datasets. There is a large workforce now trained in that approach trying to migrate from software startups to physical products. I'm not convinced it will work.

If a free app doesn't provide users with any value, or only a little value, it's no big deal to the user. It was free, it was quick to download or sign up for, it costs nothing to try.

However, the same strategies that rely upon impulsive decisions to try out free apps won't work when you're selling hardware. The high cost and long time frame make hardware much less susceptible to impulse-oriented or viral marketing schemes.

To sell hardware, the user needs to believe ahead of time that the hardware will provide real value, and enough of it to justify the high costs in time and money. Unfortunately, according to an IoT consumer report from Affinova, so far customers have found single-device-to-cloud products to be "gimmicky" and offer "no real value."

I see a few possible paths forward from here:

  1. We keep struggling along and hope we find the killer app, either succeeding or dwindling/pivoting as an industry.
  2. We get users to identify the killer app for us by making a general-purpose computing platform for smart homes.
  3. It turns out there is no single killer app, just different individual apps for everyone -- in which case, we need to make a general-purpose computing platform for smart homes.

My message to domestic IoT enterprises is this: Unless you think we'll get lucky soon with our current strategy, you should invest in creating a general-purpose computing platform for smart homes. Build products that will let people figure out the killer app for you, or at least fulfill their particular custom needs at home. Inject yourself as the platform of choice for every smart home app developer out there.

The best way to provide as much value as possible when you don't know what consumers will value is to make the hardware as versatile and reusable as possible. We shouldn't be looking to machine learning or to siloed cloud pipelines for IoT design patterns, but rather to operating systems.

Optimizing your IoT system architecture for device-to-cloud Big Data analytics when it's not even clear what the desired applications and interactions are is pretty silly. We don't even fully understand the problems that smart home end users face, much less what the killer apps are that we should provide, yet we're asking customers to invest huge amounts of money into special-purpose physical products. No wonder they've been reluctant to do so.