Newer posts are loading.
You are at the newest post.
Click here to check if anything new just came in.

February 19 2014

The home automation paradox

Editor’s note: This post originally appeared on Scott Jenson’s blog, Exploring the World Beyond Mobile. This lightly edited version is republished here with permission.

The level of hype around the “Internet of Things” (IoT) is getting a bit out of control. It may be the technology that crashes into Gartner’s trough of disillusionment faster than any other. But that doesn’t mean we can’t figure things out. Quite the contrary — as the trade press collectively loses its mind over the IoT, I’m spurred on further to try and figure this out. In my mind, the biggest barrier we have to making the IoT work comes from us. We are being naive as our overly simplistic understanding of how we control the IoT is likely going to fail and generate a huge consumer backlash.

But let’s backup just a bit. The Internet of Things is a vast sprawling concept. Most people refer to just the consumer side of things: smart devices for your home and office. This is more precisely referred to as “home automation,” but to most folks, that sounds just a bit boring. Nevertheless, when some writer trots out that tired old chestnut: “My alarm clock turns on my coffee machine!”, that is home automation.

But of course, it’s much more than just coffee machines. Door locks are turning on music, moisture sensors are turning on yard sprinklers, and motion sensors are turning on lights. The entire house will flower into responsive activities, making our lives easier, more secure and even more fun.

The luddites will always crawl out and claim this is creepy or scary in the same way that answering machines were dehumanizing. Which, of course, is entirely missing the point. Just because something is more mechanical doesn’t mean it won’t have an enormous and yet human impact. My answering machine, as robotic as it may be, allows me to get critical messages from my son’s school. That is definitely not creepy.

However, I am deeply concerned these home automation scenarios are too simplistic. As a UX designer, I know how quixotic and down right goofy humans can be. The simple rule-based “if this, then that” style scenarios trotted out are doomed to fail. Well, maybe fail is too strong of a word. They won’t fail as in a “face plant into burning lava” fail. In fact, I’ll admit that they might even work 90% of the time. To many people that may seem fine, but just try using a voice recognition system with a 10% failure rate. It’s the small mistakes that will drive you crazy.

I’m reminded of one of the key learnings of the artificial intelligence (AI) community. It was called Moravec’s Paradox:

It is comparatively easy to make computers exhibit adult level performance on intelligence tests or playing checkers, and difficult or impossible to give them the skills of a one-year-old when it comes to perception and mobility.

Moravec’s paradox created two type of AI problems: HardEasy and EasyHard.

HardEasy problems were assumed to be very hard to accomplish, such as playing chess. The assumption was that you’d have to replicate human cunning and experience in order to play chess well. It turns out this was completely wrong, as a simple brute force approach was able to do quite well. This was a hard problem that turned out to be (relatively) easy.

The EasyHard problem is exactly the opposite: a problem that everyone expects to be simple but turns out to quite hard indeed. The classic example here is language translation. The engineers at the time expected the hardest problem was just finding a big enough dictionary. All you had to do was look up the words just plop them down in perfect order. Obviously, that problem is something we’re still working on today. An EasyHard problem is one that seems simple but never….quite….works…..the….way….you…..want.

I claim that home automation is an EasyHard problem. The engineer in all of us assumes it is going to be simple: walk in a room, turn on the lights. What’s the big deal? Now, I’ll admit, this rule does indeed work most of the time, but here are series of exceptions that break down:

Problem: I walk into the room and my wife is sleeping; turning on the lights wakes her up.
Solution: More sensors — detect someone on the bed.

Problem: I walk into the room and my dog is sleeping on the bed; my room lights don’t turn on.
Solution: Better sensors — detect human vs pets.

Problem: I walk into the room, my wife is watching TV on the bed. She wants me to hand her a book, but as the the room is dark, I can’t see it.
Solution: Read my mind.

Don’t misunderstand my intentions here. I’m not luddite! I do strongly feel that we are going to eventually get to home automation. My point is that as an EasyHard problem, we don’t treat home automation with the respect it deserves. Just because we can automate our homes doesn’t mean we’ll automate them correctly. The real work with home automation isn’t with the IoT connectivity; it’s the control system that will make it do the right thing at the right time.

Let’s take a look at my three scenarios above and discuss how they will impact our eventual solutions to home automation.

More Sensors

Almost every scenario today is built on a very fault-intolerant structure. A single sensor controls the lights. A single door knob alerts the house I’m coming in. This has the obvious  error condition that if that sensor fails, the entire action breaks down. But the second more likely case is that it just infers the wrong conclusion. A single motion sensor in my room assumes that I am the only thing that matters, my sleeping wife is a comfort casualty. I can guarantee you that as smart homes roll out, saying “sorry dear, that shouldn’t have happened” is going to wear very thin.

The solution, of course, is to have more sensors that can reason and know how many people are in a room. This isn’t exactly that hard, but it will take a lot more work as you need to build up a model of the house, populate it with proxies — creating, in effect, a simulation of your home. This will surely come, but it will just take a little time for it to become robust and tolerant of our oh-so-human capability to act in unexpected ways.

Better Sensors

This, too, should be soon in coming. There are already sensors that can tell the difference from humans and pets; they just aren’t widely used yet. This will feed into the software simulation of my house, knowing where people, pets and things are throughout the space. This is starting to sound a bit like an AI system, modeling my life and making decisions based on what it thinks is needed at the time. Again, not exactly impossible, but tricky stuff that will, over time, get better and better.

Read my mind

But at some point we reach a limit. When do you turn on the lights so I can find the book and when do I just muddle through because I don’t want to bother my wife? This is where the software has to have the “humility” to stop and just ask. I discussed this a bit in my UX grid of IoT post: background swarms of smart devices will do as much of the “easy stuff” as they can but will eventually need me to signal intent so they can cascade a complex set of actions that fulfill my goal.

Take the book example again. I walk into the room; the AI detects my wife on the bed. It could even detect the TV is on but still know she is not sleeping. But because it’s not clearly reasonable to turn on the lights to full brightness, it just turns on the low baseboard lighting so I can navigate. So far so good — the automatic system is being helpful but conservative. When I walk up to my wife and she asks for the book, I just have to say “lights” and the system turns on the lights, which could be a complex set of commands turning on five different lights at different intensities.

At some point, a button, an utterance, a gesture will be needed because human interaction is too subtle to be fully encapsulated by an AI. Humans can’t always do it; what makes us think computers can?


My point here is to emphatically support the idea of home automation. However, the UX designer in me is far too painfully aware that humans are messy, illogical beasts, and simplistic if/then rules are going to create a backlash against this technology. It isn’t until we take the coordinated control of these IoT devices seriously that we’ll start building more nuanced and error-tolerant systems. They will certainly be simplistic at first and still fail, but at least we’ll be on the right path. We must create systems that expect us to be human, not punish us for when we are.

September 25 2013

Obstacles to future proofing home automation

When contemplating a home-automation project — as with many other technology decisions — the right place to start is ensuring you’re purchasing something that is future proof.

As a veteran of the networking industry, future proofing is a technology decision that has some well-understood rules. Computer networking benefits from open standards that drive interoperability, and our customers in turn benefit from fierce competition as well as the knowledge that an open, generally interoperable standard reduces their risk. Even if you buy an Ethernet switch from a vendor that stops supporting it (or worse, goes out of business), a switch can provide years of useful service because it, by definition, works with many devices that come after it.

Home automation depends heavily on tying together sensors, controllers, and an application framework.  Unfortunately, the lesson of having common standards to drive that networking has yet to become apparent in the products available on the market.  There are several network technologies that are used in home automation today, but none is fully suitable for creating a market.  One of the reasons why there is extensive hobbyist work done by programmers writing and modifying code on the Arduino and Raspberry Pi platforms is that the market for shrink-wrapped automation devices has been unable to grow without a technology framework that allows good ideas to be developed and “plug into” an existing system.

Home automation standards can be divided into two groups: technologies that provide a transport (call it layers 1-4 of the OSI model) and higher-layer protocols that support applications.  In this post, I’ll compare the various home automation standards and explain why there is not yet a clear winner.

Application-layer protocols

Two protocols provide both a transport layer and bundle that transport layer with a higher-layer application system.

  • X10.  X10 is transmitted on power lines or radio frequencies, and consists of a simple protocol constrained by the computing power available when it was invented in 1975.  The X10 protocol can transmit at about 20 bits per second, which constrains the size of protocol packets, limits the number of “sophisticated” protocol operations such as acknowledgements, and the number of available devices.  X10 equipment is cheap because of its simplicity, but it is basically a dead-end technology.  With such a low data rate and fossilized protocol, X10 cannot easily be connected to IP networks unless an X10 “modem” is connected to a computer.  If you want to dip your toe in the water of home automation, X10 is a good way to get started — after all, if you’re going to throw away everything you learn at first, it might as well be inexpensive.
  • Insteon.  Insteon is an evolution of the X10 protocol with significantly improved features and functionality.  With sustained date rates of nearly 2,400 bits per second, the Insteon protocol is capable of much more than X10.  It supports a much larger number of devices, and commands are acknowledged and retransmitted when necessary, leading to much-improved reliability when compared to X10.  Although it represents a large step forward when compared to X10, Insteon still has relatively low bandwidth and can only be connected to an IP network through an Insteon powerline modem, which limits its ability to be connected to sophisticated devices.  Like X10, Insteon devices are not able to use IP-based services.
  • ZigBee.  ZigBee uses the IEEE 802.15.4 transport layer, a self-organizing mesh topology that supports a data rate of up to 250 Kbps.  ZigBee devices can either be full routers that pass messages between nodes, or they can be end devices that can act only as a leaf in the mesh.  ZigBee has always had a strong focus on maximizing battery life and requires that devices operate for years on a single battery.
  • Z-Wave.  Z-Wave is a routed radio network that supports speeds of up to 40 kbps.  Coverage areas may be built out of a mesh to enable protocol messages to reach beyond the range of a single device.

Transport protocols

Transport protocols are able to connect devices to a software management system, but they provide a network connection and no more.  Mixing and matching multiple vendors is up to the software stack or two vendors working together to create interoperable systems.

  • Bluetooth.  Originally intended as a cable replacement for portable devices, Bluetooth supports data rates of up to 3 Mbps.  (Bluetooth high-speed technologies in Bluetooth 4.0 are based on Wi-Fi technology and use a co-located Wi-Fi link for high speed transfer.)  Bluetooth is a relatively short-range point-to-point technology, and connecting to an IP network requires use of a router.
  • Wi-Fi.  Wi-Fi is well-understood and proven technology.  It has the highest data rates of any common transport layers at hundreds of megabits, but that speed comes at a relatively high cost in power consumption.  (The Wi-Fi industry has developed several power-saving protocol features, and at one point I led a Wi-Fi Alliance task group that researched sophisticated power saving protocols.)  Wi-Fi’s advantages in home automation are that it is ubiquitous.  It is safe to assume that any home that is using automation will have full Wi-Fi coverage, and that Wi-Fi network will provide ready access to Internet-hosted services.  Wi-Fi’s high data rate enables it to use existing network connections from the home to process and store reams of data.  The major drawback for Wi-Fi is that many devices will need to be connected to power sources, though in the case of some devices such as automated power outlets, sufficient electrical power should be available.
  • HomePlug.  HomePlug is a power-line technology that encodes Ethernet frames over high frequency on the main carrier signal.  It supports high data rates and presents an Ethernet interface at both ends of the power line.  Extending a HomePlug network is easy — just plug in another network drop where it is required.  Many automation devices, however, need to be installed without an Ethernet cable.

There are also several commercial products that are only available through a dealer network (Crestron, Control4, and AMX).  Typically, these products are subject to tight control and do not allow for post-install modification without the involvement of the professional installer.

What it all means

Nothing’s perfect, and the state of home automation certainly illustrates the fragmented nature of the technology.  We are a long way from the easy interoperability that I am accustomed to in the networking business, where a strong de facto standard enables multiple vendors to create technology that can be mixed together based on the needs of the business.  If home automation is going to grow beyond hobbyist-driven one-off projects and become a market with off-the-shelf products, we need the home automation equivalent of what the LAMP stack was to the web: a standard set of protocols that is used by everybody.

Older posts are this way If this message doesn't go away, click anywhere on the page to continue loading posts.
Could not load more posts
Maybe Soup is currently being updated? I'll try again automatically in a few seconds...
Just a second, loading more posts...
You've reached the end.

Don't be the product, buy the product!