Daniel Myers
The Internet of Things and the Internet might seem inextricably linked, but, increasingly, there are questions centered around how IoT devices should work with one another — and what happens when the Internet connection goes down?
Users also are concerned with the privacy implications of having their data stored on a corporation’s servers, and they don’t like having an Internet connection as a potential point of failure. These reactions are rational, but reminiscent of online shopping circa 2000, which, ironically, might now be more secure than shopping in physical retail stores.
To understand why device makers are relying on an Internet connection and cloud services, we need to look at how our IoT devices work. We need to understand data sources, processing, device to device communication and, ultimately, how one device can leverage another device.
Data sources
As a maker of climate control devices, there are only a few critical sources of data: humans, their environment (indoor and out) and energy utilities.
There are humans who have a desire to be comfortable, which boils down to having a certain air temperature, radiant temperature and humidity, among other things. Humans live in a variety of geographies, meaning there are often large differences between what they like inside and actual outdoor conditions. Imparting comfort into a space with a large indoor/outdoor difference takes energy, and because energy is subject to supply and demand forces, using it intelligently means understanding its price at any given time.
Let’s distill these down to some concrete data sources. Phones, as arguably today’s ultimate wearable, are a source of data, including location, both macro level (at home or away) and micro level (in a particular room for more advanced systems like ours). They also provide information from human input, accelerometer movement and, in some cases, their microphone.
Sensors provide environmental data (indoor and outdoor) about raw physical conditions and, often, because of cost and power constraints, have little-to-no processing onboard. In our case, temperature, humidity, ambient light and more all give a digital view of what is going on in a space. There are external sources of data, as well, like electricity and gas rates from utilities, or weather conditions observed by third parties.
Already, you can see cases where a system at home can operate most ideally with offsite data sources: phones reporting their location when you run out to get groceries, weather from Yahoo and utility rates from PG&E, for instance. This raw data leads to the next question of where it should be sent and how it should be used.
All this data needs a place to go. Although you could host a server farm in your home, you probably don’t want to invest in one — economies of scale dictate that Amazon will be much better at it, and configuring your router to accept data pushes alone is the stuff of consumer tech nightmares. An always-on, scalable cloud, redundantly backed up on Amazon, is much better than virtually anything you might practically have in your home.
Processing
But what about processing? Something needs to take your physical GPS location, understand how it relates to your home’s location and translate that into how long it will take you to get back if you left now. It needs to combine this with information about how long it takes to make your apartment comfortable in different weather conditions, then adjust the set point accordingly.
This logic is complex, and only gets more complicated when you add more data sources from sensors and context (time of day, sunlight, etc.). Again, you could host a server at home that processes this, but a server must exist for each IoT device or needs to host “apps” for each device in the home. One might argue this is precisely what smart hubs do (or should do), but as numerous hubs have cropped up, is it practical for every device maker to build an app for every hub just so that it can consume data from external data sources?
Effectively, the storage space on a smart hub is 0 compared to an infinitely scalable database on a cloud service, and you often want your processing in close proximity to your data to avoid wasteful data transport. Sure, you don’t need temperature data every second, but think about the amount of data coming from your Dropcam and how much processing is needed to turn that video stream into actionable notifications and triggers for automation.
Communication
And what about how devices talk to one another. Does it really make sense for every device to have a Wi-Fi chip in either itself or in a gateway, or should all devices route through some always-connected gateway? Based on the growing number of “standards,” varying power, range and data rate requirements, it’s evident there is likely not going to be any sort of IoT topological convergence. This is because, in some cases, a device simply needs to report its proximity to a phone (think beacons), or because a device operating in a challenging RF environment struggles with higher frequency radios used by Thread or Zigbee and are not the ideal technical selection.
In many cases, a gateway and a variety of sensors makes total sense. But unless that gateway has overwhelming market penetration and support for a wide variety of protocols, it’s a hard sell for a device manufacturer to place a bet or choose sides when they can now buy $1 Wi-Fi chips and produce their own gateway for between five and 10 dollars.
So what does this mean? Does every flick of a light switch need to go to the cloud and come back down to turn on your light bulb? Of course not. It means manufacturers will still continue to preference HTTP integrations instead of offering Intranet of Things solutions, and it means sane fallbacks and behaviors are needed for when your Internet connection is interrupted.
Internet companies need to meet 5 nines-support levels more than ever, and it means perhaps there is a case for a second Internet connection in the home (like many businesses already have). It means the Internet of Things will not exist sans the Internet.
Comment