Apple's Next Big Thing?

As a longtime Apple user and semi-fanboi, I follow news of the company and its products (wish I had hung onto that stock I bought for $16 a share!).

These days (nearing the second anniversary of Steve Jobs' death), a rising chorus of self-appointed experts is declaring the company washed up, because it hasn't invented an entirely new market for, oh gosh, three years now! They have already declared that next week's product announcement will consist of nothing more than trivial permutations of the current iPhone. "Where's the Apple that changed the world?" they demand to know.

Mainstream speculation about the company's future "killer" products centers around a watch and a TV set. Perhaps so, and no doubt these marvels will feature Apple's trademark innovation and elegance if and when they appear. I currently don't see myself as a customer for either one, though of course one shouldn't forget that Apple's genius consists in large part of inventing things we didn't know we needed.

I'd like to discuss something that at least some of us know we need, and suggest that filling this need could indeed be Apple's Next Big Thing. I've been trying to promote this idea for a few years now without much success, but maybe its time has finally come. In any case, it looks to me like a giant, virtually untapped market that's simply waiting for some influential player to finally address it seriously. And I think nobody is better positioned to do that than Apple.

I'm talking about Home Automation and Control.

I'm going to use this term—abbreviated as "HAC"—to cover a fairly wide spectrum of things, from automatic control of lighting, to energy-saving thermostats, to interfacing to the coming "Smart Grid," to sophisticated remote control of entertainment systems, to advanced telephony, to home security, to "smart" appliances, and lots of similar, often narrowly-defined applications.

The thing to realize is that there is already a plethora of single-purpose gadgets on the market to perform these kinds of automation and control functions. HAC hobbyists (HACkers?) like yours truly typically own several of them (my longtime favorite is a tiny box that plugs into a phone extension jack and lets me control lights, my computer, and other things by punching buttons on any phone in the house.)

But there are several longstanding problems that will need to be solved before HAC can really take off. I've already alluded to one: it's essentially a hobbyist diversion. If you don't have the free time and technical chops—including writing software—to cobble together a working (if too often clumsily-integrated) system out of the various bits and pieces, well, you're probably not going to see game-changing benefits. Yes, the various single-purpose doodads can make certain aspects of life more convenient and energy-efficient, but the fact that they don't readily talk to each other misses any opportunity for synergy, and can even lead to devices fighting over control of some function. This inevitably gives rise to the dreaded phenomenon of "low SAF", where the acronym stands for "Spousal Approval Factor": if the lady of the house discovers at 3AM that flipping the bathroom light switch doesn't actually do anything because hubby has been tinkering with "the system" again, and she is not amused by this development, you can imagine hubby's eventual incentive to just forget the whole thing. I suspect that the top shelves of many closets contain boxes of HAC equipment pulled out of service for just this reason.

No, HAC will have to be foolproof and accessible to non-programmers, not to mention acceptable to the non-hobbyists in the house, before it has a chance at mass adoption.

The next problem is with the HAC devices on the market and their failure to interoperate. Although there have been numerous attempts to create "networked" control devices that play together nicely, they have typically been developed and promoted by small, struggling "niche" companies. No one company has enjoyed sufficient clout to promulgate and enforce comprehensive interface standards, which would enable any developer who is willing to conform to the standard to produce a device that "just works".

Related to this is the problem that, because HAC devices are typically so specialized, and sold to a tiny market, they are manufactured in small quantities and at correspondingly high cost—leading to the familiar "chicken–egg" problem: costs won't come down until volume grows, and volume won't grow until the equipment is more affordable. The few examples of HAC equipment that have achieved anything like low-cost production scale—I'm thinking of halfhearted efforts from companies like Radio Shack, GE, and at one point even IBM—have suffered from other problems…

…including deal-breaking unreliability. Let me illustrate with an anecdote: my personal HAC system includes an interface to the smoke detectors in an outbuilding on our property. In theory, this is awesome: if a detector is triggered, an alert is dispatched to my central control computer, which can sound alarms in the house and even send a text to my cell phone to alert me. There's just one problem: in the dozen years the system has been in place, it has thankfully never detected any smoke, but every few months it generates a brief flurry of false alarms for entirely inscrutable reasons. I tolerate this because, well, in theory the setup is great and it appeals to the nerd in me. But other members of the household aren't so forgiving—the SAF problem again—and besides, after all those cries of "wolf" I myself have been conditioned to pretty much ignore the alarms, meaning they have little practical value. The unavoidable fact is that a system that only works most of the time is often worse than useless (human cognition plays a role here: we tend to forget the 99% of times when things work the way they're supposed to, and remember only the 1% when, annoyingly, they don't). In any case, too much of the programming I do on my system involves things like transmitting a signal several times, in the hope that at least one of the messages makes it through.

Much of this flakiness can be blamed on the fact that early generations of HAC networks used the home's AC power wiring as a pathway for their signals. This is a notoriously dicey proposition, and a technical challenge that to this day hasn't been completely solved. AC lines were never intended to carry data, and they're subject to levels of noise and interference that make communications engineers cry. If you're building a new house, a reasonable solution is to install special wiring just for HAC signals, but the cost of rewiring existing homes makes this a nonstarter for all but the most committed (and affluent) homeowners—and no HAC scheme can possibly attain mass adoption unless it can be retrofitted to the existing housing stock with a minimum of fuss.

The savior, it is hoped, is low-power wireless communication. Newer generations of HAC devices can radio signals to each other, and even automatically configure themselves into "self-healing mesh networks" that can get a message through even if one of the relay nodes along the way fails or its battery goes dead. By eliminating the need for new wiring, this seems like the ideal solution, and in theory it is. But, much as with the AC powerline, there is interference to contend with, arising from the growing repertoire of cordless phones, cell phones, baby monitors, WiFi routers, microwave ovens, and other devices that generate radio waves in our homes.

We can be reasonably confident that the interference issue is a soluble problem—as is the potential lack of security in any wireless transmission. Modern encryption and error-detection techniques should be able to give us devices that are easy to set up, reliable, and secure. But the development, testing, and implementation in low-cost chips that this will require may tax the resources of most of the players in today's HAC market. Greatly complicating this process is the need to deal with multiple and widely-varying home construction techniques, building codes, RF spectrum allocations, and other variables of the global market.

Finally, there's the issue of the user experience. Today's systems are too technically demanding, too hard to set up, too hard to modify (say, to make the porch light go off at midnight instead of 11:00PM), too hard to troubleshoot, and too hard to operate on a daily basis. For remote control, they've tended to rely on TV-style hand-held remotes with dozens of obscure buttons. It can be a major undertaking to debug a function that isn't working the way you expected.


These are the major problems with today's HAC systems. So why do I think that Apple is uniquely positioned to solve them? Let's take them in reverse order:

User Experience
It pretty much goes without saying that Apple rules the roost in developing devices that are simple to understand and use. HAC offers some definite challenges in this area (one reason it pays to be a programmer if you want to play), and previous efforts have foundered on the problem of making it possible for mere mortals to customize the behavior of their systems.

Programs for Macs and PCs already exist that make it easy to, say, turn on lights by pointing and clicking. But if you want to do something more complicated, involving logic, you'll quickly find yourself mired in efforts to write and debug some kind of program or script. Implementing something as simple as "If either car is not in the garage a half hour after sunset, turn on the driveway light until it is" is beyond the ability of most potential users.

Here, something like Mac OS's Automator could be a lifesaver. By arranging blocks of pre-built functions, and entering a few site-specific details, users could create exactly the behavior they want without any programming. Apple and third parties could provide libraries of easy-to-customize Actions to accomplish common routines. Manufacturers of specialized peripherals and accessories could write simple drivers to enable their equipment to participate.

Many HAC functions benefit from some kind of hand-held controller. Apple's iDevices are the obviously superior replacement for the traditional multi-button remote. Of course, iOS apps already exist that interface with single-purpose infrared remote controllers, but this concept could easily be extended to control an entire HAC system.


A perfect example: the Nest learning thermostat. Invented by ex-Apple employees, it is by all accounts a wonderful device. But it suffers from the same single-purpose limitation and lack of system integration that affect so many HAC products. It can't for example, log into the Weather Service, receive a warning of a coming cold snap, and turn on enough heat in a normally unheated garage to keep the pipes from freezing. It can't determine that a bedroom window has been left open on a hot summer day, and avoid the waste of trying to cool the room (while texting a notice to the occupant to close the window).