(Originally posted on November 6, 2013)
I feel that someone should attempt to define what a “thing” in the Internet of Things is, but I’m not sure it’s going to be me.
Still, at the start of all this, I did toss out a simple capability-based definition, but I’m wondering if the time might be right to take another shot at it, or to try to outline the classes of “things” that we might see in the fullness of time?
For instance, here’s a quick take on classes of “things”:
- Thing Class #1: Single-purpose device with limited state, CPU, and connectivity capabilities. Not directly addressable (requires a “hub” or the like to communicate with the outside world). No UI. Examples: Z-Wave switch or 1-Wire sensor or a Philips Hue lightbulb.
- Thing Class #2: Single-purpose device with TCP/IP connectivity (including DHCP support), with support via some protocol for control API (ideally, REST) and “content” as necessary. May have UI. Example: a smart thermostat (such as a Nest).
- Thing Class #2A: A subclass of #2, consisting of “hub”-type device whose main function is to orchestrate, and provide access to, a network of Class #1 devices. Example: a 1-Wire hub or a proprietary sensor hub or a Philips Hue controller). The hub will likely support a protocol for discovering / browsing / adding / removing / initializing the devices it manages.
- Thing Class #3: I think the main distinguishing factor here is that devices in these classes are capable of accepting and executing general-purpose code (“apps”) on a dynamic basis… in other words, these are small “computers” in the classic sense, and, as such, can be deployed to function as instances of other classes of devices (such as a Class #2A “hub” or as a Class #2 thermostat). Examples: An Arduino or Beagle board, or even a 5 year old used PC that you bought for $25 at a used computer store and installed Ubuntu on and are using for your home automation project.
- Thing Class #4: I feel like it’s important to identify the class of things that includes “Connected TVs”, smart A/V receivers, or Sonos music players. These are high-function devices that would seem to be just Class 2 things. Yet, more and more, these kinds of things include a set of apps (for, say, viewing Amazon or Netflix content, or even browsing the web), they would seem to be Class #3 things. But somehow they don’t feel that way… they seem to be single-purpose (show video content or play audio content) and are sandboxed (restricted) with regard to which apps can be installed on them.
I think that’s it (for now). This is definitely not done yet… for instance:
- I hate the “Class #1”-type nomenclature, so that will need some work
- I’ve cleverly not included any analysis of cloud-based aspects of IoT… might be orthogonal, but does need to be considered… are there any examples of “cloud-based devices”? “Virtual devices”?
- Another pivot to consider is the nature protocol for communicating with things that support TCP/IP. It seems like the world is settling on HTTP / REST as the way to access and control these devices. But there might be some important details here.
- What is the nature of the connectivity? Is it intermittent by design (because, for instance, it’s a sensor on a mobile phone, or it’s a sensor on a car that is parked at most once a day at the user’s house, which contains the Wifi access point that it is authorized to access) or due to, say, weather conditions?
In the future, you won’t think this is so weird.