Technical article I wrote for CE Pro

Dean Roddey

Senior Member
@Dean
 
I read the article without logging in to the site just fine.  Just a piece here of the article as I personally enjoyed reading your entire article.
 
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.
 
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. 
I think you are being short-sighted.  "Home automation" products have existed for decades but have achieved nearly zero in terms of mass market penetration.  Homekit and Thread could gain 100X the market penetration of the existing HA market in their first couple of years.  There will still likely be a pro install market--for the sliver of the market that is willing to throw unlimited money at the ultimate in connected systems.  That pro market, however, is going to be under tremendous pressure as mass market solutions deliver 80% of the functionality for a tiny fraction of the cost.
 
...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.
Do you always have to toss in the "fan boy" pejorative?  Yes, Apple is in business to make money.  Yes, tying iOS customers more deeply into the ecosystem is in their interests.  Big deal.  People are free to vote with their wallets.
 
As far as the 'rest of the world', you ought to know that Homekit defines "bridges"--devices that support bi-directional translation of other protocols.  AIUI, the "Weave" proposal has essentially the same scope as Homekit.  When (if?) Thread/Weave/Brillo gains traction, a Weave/Thread/Brillo bridge with Homekit would be an attractive business proposition for somebody.  Not such an either-or problem then, is it.
 
The HA needs a gorilla (or two) to throw its weight around and get the device manufacturers to conform to some standards.  Perhaps those standards won't be all-encompassing to begin with.  Any step in that direction is a big improvement over the current situation.  
 
Craig
 
Dean, nicely written and a lot of truth embedded in your paragraphs.  Perhaps more dialogue on the futility of proprietary systems will cause someone to wake up.
 
l
 
I'm curious about Tinker's thesis in the comment/reaction to the article: "Without a central controller, there can be no automation."
 
That's been a dominant paradigm, and I can see advantages to it.  It seems to work.  Yet, lately, there seems to be some movement away from that.  e.g. Nest thermostat deciding to turn off your HVAC if the smoke alarm goes off, and a Nest-compliant irrigation system deciding to turning itself on in response to the same event.  Those actions aren't being centrally controlled--at least not in the conventional sense.  One reading on MQTT is that automation components subscribe/publish with other automation components, and then perhaps those components individually act on that information, but not necessarily under central control.  That fits with what's happening in Nest scenario I've just given.  My initial reaction is that this is a recipe for chaos, with the left hand not knowing what the right hand is doing.  Or is that wrong, and there's a new paradigm emerging?
 
[SIZE=14.6666669845581px]I've read that CQC is distributed, and if so, it must have already addressed this issue.  I'm merely trying to understand the direction things may be evolving.[/SIZE]
 
Without some kind of non-end point controller you can't do things like:

1. Have things happen on a schedule
2. Have things happen in response to other things happening
3. Monitor the status of the system or the devices controlled on an ongoing basis
4. Coordinate access to devices
5. Keep the customization in a single place, separate from any of the actual devices (which may die, be replaced, etc...)

Because they all require that there be some always available, always home, always listening device.

In a world without a local controller, you could only do those things with a cloud based system, which means all of that is completely dependent on your network connection, and of course it also means that some company knows almost everything that happens in your home.

And of course, as I said, the only way some of that could be done without a controller at all (i.e. your Nest scenario) is if every single device speaks the same language, and that's just not going to happen, ever. No one is going to be that dominant. And of course even the cloud based systems are likely to only support their own specific ecosystem, which would still mean the vast majority of devices will be left out.

Without a central controller, you aren't really doing automation, so much as having a fancy remote control on your phone, with some very limited automatic functionality perhaps in some of the devices themselves.
 
I think you are being short-sighted.  "Home automation" products have existed for decades but have achieved nearly zero in terms of mass market penetration.  Homekit and Thread could gain 100X the market penetration of the existing HA market in their first couple of years.  There will still likely be a pro install market--for the sliver of the market that is willing to throw unlimited money at the ultimate in connected systems.  That pro market, however, is going to be under tremendous pressure as mass market solutions deliver 80% of the functionality for a tiny fraction of the cost.
You maybe don't appreciate what fully customized systems can do. It won't be close to 80%, and certainly not remotely as robust.

Anyhoo, it doesn't really matter to pros what the market penetration of Homekit is, any more than they really care what the penetration of bubblegum into the broader market is, because it doesn't really target their customers, many of which you have to remember are also commercial and industrial customers. And the companies that make Homekit devices aren't going to become the next Crestron or Control4, because they'll be dealing in a commodity market with low margins mostly.

Consider Z-Wave, for instance, which for many years now has effectively been offering what Homekit only even distantly promises. It's been widely sold and advertised, and supports a range of devices from a range of vendors that Homekit probably won't rival for a long time. If you think that Homekit maybe eventually will end up being 80% of a good professional system, then clearly Z-Wave would have been such for a long time now. Has it made even the slightest dent in the pro market? No, not really.
 
Dean Roddey said:
1. Have things happen on a schedule
2. Have things happen in response to other things happening
3. Monitor the status of the system or the devices controlled on an ongoing basis
4. Coordinate access to devices
5. Keep the customization in a single place, separate from any of the actual devices (which may die, be replaced, etc...)
 
1) devices can set their own specific schedules, why complicate it by dumping that load off onto the HA controller
2) yes, even the IFTTT would be your 'central controller'
3) devices that have their own apps almost always have their own status system, either via alerts or emails
4) devices that have their own apps have their own device specific access
5) there is definite value in this, but everyone has to go through a customization process with new equipment anyways, so why does it matter where?
 
The paradigm must shift.  As devices become connected, the only value in a central controller is for device to device logic; and even right this minute IFTTT can be considered the central controller and do this.  All of this discussion rests elsewhere - and would be more towards how the DIY/CI market can adapt to changing market forces.  I just don't think anyone has asked the right questions yet.
 
1. But that means every device has to redundantly implement that functionality (cost), and it also means that there's no such thing as a schedule that coordinates multiple devices. And of course what happens when that device goes belly up and that work is lost?
2. It could, but no professional system is ever going to do that, so it's only relevant to the DIY crowd
3. There again, possibly true, but not really very relevant to those creating serious (aka customized) solutions. And it doesn't address doing something in response to such an event, which is a lot more useful than just reporting it.
4. And ditto on that. That's not automation, that's just remote controls on the phone. It doesn't provide coordinated control over devices
5. Look at the Z-Wave things you just went through. Even the very small bit of configuration that goes into the individual Z-Wave modules becomes a problem, because it's easily lost if you have to reset the device or a device goes missing or whatnot. You spent the time to set up all those modules, then reset the network and all of that was lost, because it's not stored in a central place where it can be backed up. And of course there's no way to even store that kind of configuration in a device if it requires talking to another device of another type.

I would argue that, the more devices there are, the more important the centralized controller becomes if you are looking to do real automation, and you want it to work whether your internet connection is up or not.
 
JK, regarding your #1 comment, I'm curious.  I have lighting conditions that I change at different times of the day on a schedule.   Are you suggesting that in a non-central controller environment each light would be programmable to do different things at various times.  Taking that further, if an occupancy sensor was to be programmed to do multiple things, such as turn on lights, perhaps activate a voice warning, maybe add a siren and make a phone call notice to a smartphone, wouldn't that have to be a sensor with a complete controller built in.
 
What I am getting at is isn't the central HA controller that can talk to devices with a more universal protocol still the simplest and most versatile way to go?
 
I'll toss in another example.  My home theater.  I have several different lighting scenarios.  One is an iPad widget labeled "preview level".  Nothing more than a number of different lights running at about 15% brightness while the previews are running and all of the other nonsense on a DVD before the feature. It let's everyone get settled just like in a real theater before the room goes totally dark for the feature.  Then another widget that gives me full lighting.  And another that turns off the theater completely and sets the lighting for the post-movie mood.  I can't imagine programming this stuff without a central HA controller such as CQC.
 
Quote
I would argue that, the more devices there are, the more important the centralized controller becomes if you are looking to do real automation, and you want it to work whether your internet connection is up or not.
Personally and mostly I think because it is a hobby for me (and I started to automate in the '70's) I concur with said statement.

That said in our internet wherever you go world it is just too difficult of a ideological concept today (not yesteryear) for folks to comprehend. (a centralized at home controller with no internet dependencies - geez how can that be?).

Life does truly does exists outside of the use of the internet today. That said take the internet away from one person and watch what happens to them.

The assumption is that everybody has a little computer these days and everybody is using the cloud for anything and everything.

Well its just easy peasey stuff, no thoughts involved as it just works.

Nobody really cares about the grey areas of function or wants to know about the grey areas of function.

I had a friend that was headed towards retirement. He was going to build a home off of the grid and did want to automate. I told him he could automate just fine without the internet.

He had a hard time understanding how that could be done. (well along with the architect and GC).

Curious about whom first used the term "fanboy" as they should get credit for it.

I remember writing about a visit to a local big box store a while back and watching a couple of folks just about doing a genuflect in front of the Nest display. Personally I chuckled when I saw this and was amazed what a thermostat display could illicit. Were these folks "fanboys" of the Nest thermostat?
 
But that still leave the issue of devices that 1) aren't IP enabled which is a huge number of devices and will remain so and 2) devices that are outside of either the HomeKit or Thread ecosystem. Are you going to try to control those devices from the cloud as well? That doesn't seem very practical. And anyone who thinks they are going to, any time in the next 10 years, just go out and buy all the gear they want and have it all implement some magic protocol like HomeKit or Thread (and all of them implementing the same one) is being very optimistic. 
 
As someone who has been on the losing end of custom acceptance (for various reasons, as any product vendor is) for a long time now, I can tell you that people will generally not buy any piece of gear just because it supports HomeKit or Thread. They just won't, just as they won't buy it because any system supports it. They want what they want because it supports the features the application specific features they want. So support has be as broad as possible, or the goals of the customer won't be met. And it's going to be so long before either of those standards can even remotely come close to that, that there will be no way they can compete with existing controller based systems that are 'slutty' enough to talk to anything.
 
Now of course someone can say, as was already said above, that there will be 'bridges', but of course that ignores the fact that, for those bridges to erase my concern above, that someone will have to spend a LOT of time and money to create all of the necessary drivers and maintain them over time, and there will need to be a local controller to run that stuff. And now you are pretty much right back to where we are now, but with just a lot less consolidated system.
 
Dean Roddey said:
You maybe don't appreciate what fully customized systems can do. It won't be close to 80%, and certainly not remotely as robust.

Anyhoo, it doesn't really matter to pros what the market penetration of Homekit is, any more than they really care what the penetration of bubblegum into the broader market is, because it doesn't really target their customers, many of which you have to remember are also commercial and industrial customers. And the companies that make Homekit devices aren't going to become the next Crestron or Control4, because they'll be dealing in a commodity market with low margins mostly. ...
 
Re the 80%, I think you need to catch up on Homekit in iOS 9:
 
 
https://developer.apple.com/videos/wwdc/2015/?id=210
 
"Custom triggers" enable true automation; not just remote voice control.
 
The current 'pro install' market is made up of a range of folks.  Some of them are going to choose the far less costly option.  Homekit and Thread are going to expand in capability far faster than the pro install market can so the gap is going to continue to narrow.  This leads to a declining market and customers familiar with inexpensive alternatives.  Not exactly the market segment I'd like to participate in.
 
Craig
 
Deane Johnson said:
What I am getting at is isn't the central HA controller that can talk to devices with a more universal protocol still the simplest and most versatile way to go?
 
.
Maybe yes, from your perspective, since you already have a central HA controller.  However, I think what's driving the shift is the simple fact that 99%+ of people don't.  It's also the shortest path (however short sighted it may turn out to be in the long run) toward "just get it done and move on."  I mean, if you're the irrigation controller, do you really want to write plug-ins for all of the centralized HA systems just to do that simple thing (turn on the irrigation if the smoke alarm activates) within each of their respective software architectures?
 
I think Dean Roddey gives good criticisms above to this approach, yet for the many without a central HA, that's how it has to happen. 
 
Custom triggers hardly gets it anywhere close to the capabilities of customized systems. It's the extensive customization that makes the difference.
 
As to the customers familiar with inexpensive alternatives, it makes no difference. They can either do it themselves, which most of them still will not do, or they can pay for something that a professional can actually make a living from doing and feels comfortable supporting. That's been the case for a long time now. The vast majority of people will still not set up anything beyond trivial on their own, neither HomeKit nor Thread is likely to change that. 
 
Back
Top