i see bots

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?

 

I writ large rambling the other day regarding my own hands-on experience with cascading failures due to, among other things, the perils of pushing large, complex, irreversible, and required updates to IoT appliances - such as “Connected TVs” and the like.

In order to try to move the ball forward here (and not just complain!), here’s my contribution… some ideas on rules/policies that device designers should follow when it comes to “update architecture”:

• Reversible: Updates should be reversible, in case of external compatibility issues (the update introduces changes in its external interface that breaks its integration with other systems) or internal issues (the update fails to install completely, or otherwise renders the device unusable)
• Predictable: Users / controlling systems should be in control as to when an update cycle (and any ensuing device reboot) is initiated.
• Non-intrusive: Updates should download in the background and if possible install in the background
• Preserves durable settings / state: Updates should respect existing settings and configurations where possible

Obviously, not every “thing” in the “Internet of Things” will have enough memory or CPU power available so that its software engineer will be able to reliably follow the rules above… for some “things”, there may not be any “background” in the process model, or enough memory to store a complete operating system / firmware image during a background download, or even a UI with which to offer the user a choice in the matter.

But you get the general point: keep the user or controlling system in control of the update process, and make it reversible in case there are problems.

The natural presumption is that, when it comes to updates, a “thing” doesn’t exert an outsized negative effect on the operation of the hierarchy / network that it’s a part of. You wouldn’t expect a low-level leaf “thing” in a constellation of “things” to require a reset of the entire system just to take an update. The amount of risk that it injects into the system should not be larger than its role in the system.

Conversely, the more intelligent “things” out there - “Connected TVs”, for instance - which are sold like appliances but in reality are complex, stateful, devices - represent large challenges for “update architecture”. These devices are complex enough that updates can take many minutes (40 in my Apple TV example) and induce significant risk. But, to the user, these “things” are “appliances”, so the average person’s expectations do not match the complexity of the device. I just want to watch a movie - tell me why I need to wait 40 minutes for an update that I didn’t ask for, can’t postpone, don’t understand the value proposition for, and am, in fact, leery of?

Getting the “update architecture” right is challenging. Look at Microsoft’s recent stumble here (where Microsoft had to withdraw its major Windows 8.1 update). I’d argue that it’s taken years for Microsoft to get their approach to updates right, and that they generally do a pretty good job at it, which makes this failure stand out even more.

PS: As I write this, I’m thinking that there might be other sets of rules to think about here… such as how to archive the state/settings of a system of “things”, and how to apply such an archive to a system (to restore it to a previous known state)? A post for another time.

Over at GigaOm, Mike Harris, CEO of Zonoff, kicks off a survey of recent “Connected TV” efforts with this comment:

“But how will the connected home make the jump from a favorite toy of the tech elite or a status symbol of the wealthy to be a ubiquitous technology that reaches the broad mass market of consumers? As usual, history offers some valuable lessons. In fact, we only have to go back a few years and look at how the connected TV market took shape to get a sneak peek of what will soon unfold for the connected home.”

http://gigaom.com/2013/10/19/connected-tv-points-the-way-forward-for-the-internet-of-things/

In the article, the author posits a case for the future of “Connected TV” that has something to do with making the “Connected Home a reality for everyone”, presumably through the software platform his company offers.

I found the premise jarring, though, for other reasons: I happened to read the article after having experienced a kind of triple witching hour in our own house involving “Connected TV” (or, as it turns out, “Not Connected TV”).

Here’s the full story, in the hopes that there might be a moral in here somewhere…

The family had been talking all day about what movie to watch during “Family Movie Night”. Given this, we were all aware that any candidate offered for approval had to be first vetted for availability on either Amazon Instant Video or Netflix’ streaming service. After some discussion, we settled for “The Fantastic Mr Fox”, a totally excellent (says me) flick that the whole family can enjoy (as long as the adults in the room don’t snicker too much when the default expletive, “cuss”, is used in various forms… “What the cuss is going on here?!?”, “Who the cuss…”, and so on).

On a PC, I browsed to the requisite page on Amazon’s site (here), selected the HD version, and rented the movie. By then, the family had gathered in the living room, and the 15 year old had fired up the Sony BluRay player that we use for streaming Amazon content.

However, when the clumsy Sony software repeatedly indicated that it couldn’t access the movie service (or some variant of that generic message), we realized to our horror (yes, #firstworldproblems) that we might not be in for smooth sailing. Sure enough, a Twitter check revealed that we weren’t the only ones having difficulty. I believe the issue was that the Sony service - the Playstation Network - that the player relies on for handling requests was down. Good for Sony - they have a “network status” page, but - Bad for Sony - it showed “green”. Not for me, or other folks, apparently.

OK, family getting mildly restless. I head down to the basement to reset the router and cable modem, knowing that that wasn’t really going to make any difference, but it bought some time.

I turned to the Xbox. We hadn’t used it for a while, and so - knew this was coming - there was a huge update that it had to take before I could sign into Xbox Live. About 8 minutes later, the Xbox rebooted, and when I fired up the Amazon app, it failed to launch (with a hexadecimal error code - only MSFT would do that). I rebooted the Xbox but still no joy.

Family still in their seats, but making noises like “should we be making popcorn?” (from the 9 year old) and “the state of IT around here” (from the wife).

Then, inspiration struck, as I remembered reading that the latest iteration of the Amazon Instant Video app for iOS added support for AirPlay! Of course - that’s the ticket. Apple stuff always works!!

I fired up the iPad, installed the app, and switched the A/V receiver over to the Apple TV unit. Because the Apple TV unit is in the rack in the basement, I’ve been using the Apple Remote app for iOS to interact with it. (I do have an IR receiver in the Living Room and IR emitters on other equipment in the basement rack, but just not on the Apple TV unit as yet.)

I used the Remote app to wake up the Apple TV, which promptly realized that - wait for it - it, too, needed an update!

Now this was bad news, because (i) there’s been a history of botched Apple TV updates from Apple and (ii) in my experience, the updates take a long time. Sure enough, once the updated started, the nearly imperceptible updates to the progress bar predicted a long wait this time. The family decided to sit down to dinner instead of staring at the progress bar.

The Apple TV update took 40 minutes, but it didn’t brick the device. So, we were in business, right? No, not quite. The iPad version of the Amazon Instant Video app found our rental, but wouldn’t play it (suggesting that we try again later - how thoughtful!).

Now we were desperate, but there was one more device/path to try: I installed the Amazon Instant Video app on my iPhone 4S, found the rental, and fired it up over AirPlay, and it worked - for about 10 seconds, then stalled due to buffering. We paused the stream to let it buffer a bit, but then - more horrors! - I saw that the phone’s battery was down to 10%. That’s red territory. In one last clutch save of the evening, I found and deployed my external battery, a HyperJuice model MBP-100, typically used to augment my MacBook Pro; it also has a USB port, and when connected to a phone or iPad, can power it for days. (Actually, I think it could even start our car).

So, we were in business… mostly. The Amazon app on the iPhone would stall occasionally, and the device got alarmingly hot. But still, it was impressive: the iPhone 4S could pull down an HD stream and then sent it over the Apple TV device, delivering a reasonable experience.

At the popcorn break, I tried the iPad again (a 3rd generation unit), and for some reason, it was now willing to stream the film, so we resumed the movie on that device.

OK, so what’s the moral here?

I really wonder if Sony should ever write software or operate services… In opinion, they just don’t see very good at it, and the requirements of, and stakes in, operating services just keep going up.

On the other hand, I think Amazon and Netflix do a pretty good job with their steaming services. (And note that Netflix itself relies on Amazon’s AWS infrastructure.)

Beyond the initial failure, the issues revolved around the need for the devices to take large, mandatory updates that users have learned to fear due to the possibility of instability (or worse).

For instance, how is it acceptable that an appliance like the Apple TV could require a 40 minute update? Why is that acceptable? Or that the Amazon app simply fail to launch on Xbox?

If people are to trust the “Connected TV” scenario, the people supplying the software for the devices have to think different.

Perhaps updates need to be divorced from the UX path, with downloads and updates happening asynchronously in the background. It might require more storage on the device (extra space to download, unpack, and organize the update).

And when an update is “required”, that’s not very friendly, is it?

I realize that it’s simplest for the service provider if it can simply require that all connecting devices be operating at the latest and greatest version, requiring a download and update if not.

But as we move into a more IoT-oriented world, it’s going to get pretty messy if an update to a service causes a cascade of required device updates, which may in turn cascade to other, dependent devices. A failure somewhere in the chain - it could be as simple as a failed, or corrupted download - could disable entire scenarios (i.e., “watch a movie” or “open the garage door”), or classes of scenarios (i.e., “security”). That’s too risky to contemplate.

I think the IoT has to be able to operate in a state of partial inconsistency. Service providers and software providers for devices need to make progress here.

PS: On a somewhat related note: I was pleasantly surprised today, as we shifted off Daylight Savings Time this morning, that most of the devices in the house picked up the change just fine. Just our (stupid, unconnected) oven and bedside clocks (the parents’, not the kids’ “atomic clocks”) needed to be manually adjusted. That’s what I’m talking about. Maybe by this time next year, we will have made some progress on those laggard devices.

PPS: Thinking more about Sony… a contrarian view would be this: “Look, you paid $225 for that Sony BluRay player four years ago, and you’ve been using Sony’s Playstation Network for free since then… how do you expect them to pay for the cost of operating that service, let alone make any money from it?”. The consumer device business, especially when it comes to BluRay players, is a race to the bottom. But the expectations keep going up - the players need to support Wifi, support apps, and otherwise distinguish themselves. But no consumer is going to pay a premium at the time of purchase, nor pay a monthly subscription fee to the manufacturer (such as Sony) to run that service. Netflix or Amazon will get those dollars. So, its a loss-leader for Sony and others, I think, to operate their service networks.

When viewed in this light, I’m not surprised that the Sony service seems to be gaining a reputation for unreliability.

Having said this: How hard could it be??🙂 It’s true that the scale of the problem for Sony is much smaller than that of Netflix or Amazon… Sony “just” needs to operate a directory service for its BluRay players, to dispatch their users to, say, Netflix.

Netflix, on the other hand, has to actually operate a video streaming service, which is a planet-scale challenge.