Home automation protocols are sort of the plumbing of the automation world: Everyone who uses a smart home system is making use of one or more control protocols, but as with plumbing we rarely think about them until something starts to really stink.

Control protocols are how automation systems talk to the devices they control, at a minimum defining the format of messages sent back and forth between the automation system and the device. The quality of those protocols plays a substantial role in the quality of automation solutions and end user experiences, no matter how much work is done to keep them hidden away under the floorboards.

Recently this uber-geeky realm has become a battle ground where some large players are attempting to put forward their own versions of the “one protocol to rule them all,” and hence to gain leverage within (or even dominate) the automation world. Apple’s HomeKit and Nest’s (aka Google’s) Thread initiatives are the most visible examples of this conflict. There are many fan boys of either who seem to think that the entire professional automation world is about to be made irrelevant by these efforts.

Leaving aside whose story is best and the politics thereof, in this article I wanted to just provide more information about control protocols in general, what types of problems they cause, how these problems limit the automation world, and so forth.

Understanding Syntax

The biggest area of confusion that I see among the laity concerning device control is the issue of syntax vs. semantics. And this division is very important to the rest of the discussion, so I’d like to cover this in some detail.

In the most general sense, syntax is related to the actual structure of communications, and semantics is related to the meaning being conveyed. For instance, syntax is how these two messages differ from each other.

POWER ZONE1 ON

0x1 0x20 0xFF

These are two different ways that an A/V receiver might expect an automation system to send it a command to power on zone 1. They say exactly the same thing, only the syntax is different, not unlike saying the same thing in English vs. Latin.

In one, it’s a text-based system and in the other it’s a binary system where the “words” are just numbers. And the order of subject and verb can change, just as it does in English vs. Latin. The first is verb, subject, and new power state. The second is subject, verb, and new power state.

One of the benefits claimed for any sort of ubiquitous control protocol is that all devices would use the same syntax. And that is certainly true. There would in fact be a fair amount of benefit to be gained by all devices using the same syntax. But syntax has never been what has held the automation world back, despite what many people think.

Yes, it can be annoying sometimes when a device uses some very ad hoc or unusual syntax that is difficult to deal with. But, for the most part, this is just an annoyance, not a real limitation. All automation systems easily hide these syntactical differences under the hood. It would cut down on some amount of time-sucking grunt work if every device used the same syntax, but it would not in any way take us to the land of milk and smart homes.

Understanding Semantics

Ultimately semantics is the real bane of automation systems when it comes to providing at least high quality, and hopefully very smart, helpful, and self-aware automation solutions.

Semantics works at the next level up from syntax and answers questions like: What is a thermostat? What is a scene? What are the possible states of a security zone and their significance? What is the range of a volume control? What makes up current weather conditions vs. weather forecast data?

An automation system can choose to be semantically agnostic and take no position on any semantic issues, essentially just exposing the bespoke details of every device. In such a system, integrators must define all of the semantics themselves in each installation they do.

A particular device may report states A, B, and C for a security zone. It’s up to the integrator to decide what that means, how to react to those states, how they might be exposed to the end user, and how to deal with the differences if you swap out the security device at some point in the future.

There’s nothing necessarily wrong with such an approach per se, and it provides maximum flexibility. However, it also means that every solution is pretty much a complete-from-scratch undertaking and any change in hardware might require extensive adjustments.

If the goal is to create smarter homes—and make the configuration of systems much more efficient (hence less labor-intensive for the integrator and less costly for the customer)—then it behooves an automation system to provide a broad range of very strong semantic definitions and force all devices under its control to fit into those semantic definitions. Once that is done many benefits accrue:

• You can swap out device A for device B and nothing has to change, or at worst the impact will be vastly reduced.
• You can create generic logic that can be reused over many installations.
• You can create generic graphical interfaces that can be more easily reused.
• Third parties can create highly refined or complex logical or graphical components that you yourself might never have the time to create, and which can actually be adopted into your own solutions with minimal effort.
• The system itself can be much more self-aware because it understands the meaning of the states of devices.
• The system can more easily self-configure, because it understands types of devices and how to integrate the functionality they provide, at least for the core device types.

The benefits are clearly quite substantial. Ultimately anything that allows the custom installer to more quickly create components that are both value added (not off-the-shelf and available to everyone) but also reusable across multiple installations and hardware, is a very good thing.

And here I am talking about not just standalone screens of the “virtual remote control” variety, but tightly integrated, activity-oriented reusable components that coordinate multiple devices.

When Semantics Don’t Mesh

Here’s the rub: As soon as any automation vendor (or third-party protocol creator) attempts to come up with a nice set of semantic definitions for thermostats, security systems, A/V receivers, sensors, irrigation systems, etc., they quickly discover that the various extant examples of any given type of device are so varied, and so inconsistently implemented, that they are forced into one of three options.

One of those options – quite popular with those who think their solutions will dominate the smart home—is to take a hard stand and say: If you want to be part of our ecosystem, you have to abide by some minimum set of semantic definitions. Any devices that cannot meet these minimum requirements cannot be supported, or at least not within this semantic framework (i.e., they can dial into the ecosystem, but they’re on their own).

This sounds like a sane approach, but a lot of devices may fall under the line, and none of those devices gets the auto-magical treatment. The customers who have those devices won’t be happy and the vendor’s claims for breadth of hardware support are artificially limited.

Another option is to set the bar very low – for example, defining “on” and “off” for light switches, but not “dim.” That can be done, and it lets a lot of devices into the party that might not otherwise have been invited. But ultimately you will have done a lot of work for limited benefit. Every drop in the bar effectively means that fewer functions can be depended on when creating reusable logic or UI components. So a large price is paid in the ultimate effectiveness of your efforts.

A third option (which has been used in some previous efforts, such as UPnP) is to go with a very flexible, dynamic definition., i.e., provide semantic definitions, but make parts of it optional, or allow it to have optional forms. What features are supported or the form in which they are exposed must be determined dynamically and adapted to. So, for instance, if volume control is supported it may be in terms of some arbitrary decibel range, or it might be a standardized percentage value.

A dynamic system might sound like the best of both worlds, but ultimately it’s probably the worst. It has the appearance of a standard, but it’s really a non-standard. If the ultimate point of semantic definitions is to allow for the creation of reusable components, then it at least partially fails, because in reality no one is going to get all of the ifs, ands and buts correct; they won’t have the gear or time to test against all of the combinatorial possibilities.

It also requires a very dynamic approach. This is perhaps fine for a standard application, which can via extensive logic adapt itself on the fly to what is available, although usually at the cost of a highly customized layout. For integrators wishing to create reusable content, within the context of the tools provided by most automation systems, that kind of dynamic approach could be quite tedious if not impractical.

{pagebreak}

Or You Could Just Own the Smart Home

I guess there is actually a fourth option, and this is the one that folks like Apple and Google are shooting for. And that is to try to be so dominant a player that you can force everyone to adapt to your scheme or die. If you can create a situation where every hardware manufacturer believes that they must support your syntax and semantic definitions of devices then the manufacturers will ensure that their hardware works with the almighty protocol, instead of just creating some ad hoc scheme of their own, as they tend to do now.

How practical that is, even for the biggest of players, is a matter of opinion. Of course Apple fan boys believe that everyone will be forced to bow down to Apple, even if Apple follows its natural instincts and keeps HomeKit purely within the iOS environment. But, if they do, that means that all of those manufacturers will also have to support something else for the rest of the world—even something of their own, or some other competing protocol like Thread.

How likely is that versus just selecting a side and supporting only one, or supporting none and remaining proprietary? It’s hard to say. And at some point the perception of a coup from outside the palace could itself breed resistance.

Do Universal Platforms Matter to Professional Integrators?

Are platforms like Homekit and Thread relevant to the professional install market? To the extent that they are oriented towards fairly simple solutions with no central controller, where the phone is effectively the center of the world, and the cost to consumers is nominal, then they are not likely to be terribly relevant to the needs of the professional installer or their clients. Such simple solutions won’t require (or perhaps financially justify) both broad and deep semantic definitions that would bring extensive benefits to the much more challenging custom solutions that are the bread and butter of professional installers.

So, then, could we justify a similar “universal” framework but something more extensive for the pro market? If we even attempted such a thing, it would only work if supported by hardware (component) manufacturers, which means yet still more standards for them to support. It’s likely that component companies would stick with the protocols backed by the biggest home automation players that open up the widest markets. Ergo, any standard just for the pro install market, no matter how technically sweet or needed, would probably die on the vine.

You’d think the entire professional automation community would band together to back some standard, but that seems unlikely.

Is a Common Language Even Necessary for Pro-Worthy Integration?

Another obvious question to ask is whether such “standards” are even necessary? Ultimately, not really—at least not in the world of serious automation where centralized controllers exist. Automation controllers are good at hiding differences and exposing them in a consistent way.

It would be sufficient just to have a “How Not to Make Automation-Challenged Hardware” guideline that manufacturers would follow. Ultimately it doesn’t really matter what syntax manufacturers use to expose the devices. But if they would just take automation seriously and avoid some basic mistakes that are always problematic for integration, the whole automation world would benefit.

RELATED: Do We Really Need a Home Automation Standard?

Most any automation system vendor or dealer could provide a Hall of Shame of seemingly diabolical attempts to make devices practically un-automatable. I’m sure these failures aren’t driven by malice, rather, from a lack of understanding of the needs of automation systems, or the inclusion of a control protocol as an afterthought instead of a driver of core design decisions. Given nothing more than a set of guidelines, supported by the automation industry, we could go a long way towards allowing automation systems to provide improved functionality and smarts, even if it is only through their own bespoke internal semantic definitions.

It might even be arguable that they should in fact be free to provide their own semantic views of the world, to allow for a variety of approaches to solving the problems at hand.

Centralized Control vs. Distributed Architecture

One reason that a common protocol is required for the broad “Internet of Things” world view, where there is not necessarily a centralized controller, is that the devices have to talk to each other directly. There is no local intermediary to act as a translator between devices of different types or make/model. A motion sensor has to be able to directly turn on a light or TV, so obviously they must talk the same language.

True, the central controllers (the translators) do exist in this scheme, but they most likely will exist in the cloud, requiring always-on cellular or Internet connections.

Conversely, since most advanced home-control systems include a local controller that can translate between the various devices, the requirement of standardized communications isn’t necessary.

A centralized controller also arguably provides for a more manageable system, where the logic is contained in one place, not spread out to individual modules or multiple cloud servers. If a light switch or sensor goes bad, part of the logic that makes up the system doesn’t get lost with it.

Security and the Central Control Paradigm

A good argument for centralized controllers is that of security exposure. Though of course automation systems are not without security vulnerabilities, it is not unreasonable to argue that an automation system vendor probably has more latitude to deal carefully with security than the vendor of a $45 sensor. But, if every device can talk to every other device directly, a security breach in any single module may expose the entire system. A centralized controller may be able to better limit the damage of a security breach in any given controlled subsystem.

Summary

Hopefully this brief overview has helped to clear up some common misunderstandings of control protocols and their problems and potentials. We are currently in a period of great development and even greater hype, with big waves breaking over the once cozy and mostly ignored world of automation.

One way or another, it appears that our world – both in a universal sense and in a custom-channel sense—is going to change, whether for the better or worse is hard to see at this point. But I guess that makes it all the more important that at least we in the industry understand these issues so as to make appropriate decisions.

• Page 1