Zigbee HA vs. Z Wave

[Dean Roddey]

aybe a scheme like how printers have gone is the answer.  You buy a printer for your PC or Mac and they come with a driver that tells your hardware how to communicate with them.  Contrast this to how it is now with Homeseer or CQC where the driver has to be written by the controller company not the device. As we have seen, this is not really a sustainable model long-term, at least in my opinion. 
 
Instead if the controller makers could put together a driver spec. that they all followed, this might be a great start. Then it would be the device maker, not the controller maker that created the driver.  If not the device maker, other people would come forward to write drivers, but only if they worked on more than a single controller platform.  In other-words, the "driver" for an LG XYZ TV would work in Homeseer, CQC, Premise or any other controller.
 
If Dean, Mark and others could work toward this, just think how wonderful and robust the home automation market would be for us users? Will it ever happen? Probably not.

 
That's definitely unlikely. The problem is that, unless you make every automation system work the same, then they all need to consume the data from the device differently. And you aren't ever going to make every automation system work the same. 
 
You could try to come up with some layered system, like the TCP/IP stack, where you defined some intermediate form that the information is exposed as, and an API that could be used. Then automation systems could write drivers to that intermediate form.
 
But that still wouldn't get rid of the need for the automation system vendors to write drivers, because they still have provide the system specific smarts to deal with the device, even if it's via some intermediate, generic interface. I.e. unless you can make every A/V receiver work the same, then the fact that the functionality of that receiver is exposed through some intermediate form doesn't get rid of the differences between receivers. So the automation vendor still has to write another driver to sit on top of that, which can squash that receiver's specifics to fit into its own view of what a receiver is.
 
Ultimately, you'd be better off trying to get hardware vendors to standardize on certain core features and to expose them via a standard control protocol. And that gets rid of the 'what language is it written in' problem that would plague any attempt at implementing something like what you are suggesting. It pushes the standardization to the devices. Then we could write a single driver that would work with any device of a given type. But, that's even less likely because there are some many of them, and various folks trying to get them to support this or that standard. 
 
Even when it sort of happens it doesn't work. Yamaha came out with their YNC protocol, and we wrote a driver that works with it. It was great it would just adopt to any of the Yamaha models that supported the protocol. Then they promptly just completely broke it by introducing other stuff that can't be dealt with in that generic sort of way.

 

[pete_c]

We are far away from any commonality in platforms and personally I see the want for it but automation vendors are doing their own thing.
 
Personally am using Ubuntu now for laptops and desktops.  Recently dealt with getting my Canon multifunction printer to work with my stuff.  I had no issues with the HP laser printers on the network.  Not even going to attempt to connect my sub dye printer to the network or Ubuntu. 
 
(printing was easy and fax, scanning stuff was a PITA).  I wanted it to work as well as the drivers for Wintel worked.
 
I also had issues but created them connecting my Pioneer AVR to the network for remote.  Ended up sticking with the basics of using two sources of video/audio and not utilizing virtual remotes as there was too much there and not needed).

 

[LarrylLix]

Most of this protocol stuff should be supported by operating systems but Apple, Android, 10K linux flavours, and Windows have all fallen down on the job.

These new devices should have a plug in USB dongle, or PCB for the bus de jour, and the OSes should have drivers to support that hardware. Imagine that you could use a command line in your OS to operate your HA devicess. Or write code that could always operate whatever popular system you have, with code independance?
Code monkeys could not worry about hardware drivers and concentrate on AI features and real HA features.

Hell, nowadays you can't even get MS to support their own touchpad screens with their 4K resolution. I continuously hear users whining about not being able to read fonts on these high definition screens.

In the end, OSes were supposed to give device independence and they have dropped the ball. The manufacturers of every piece of softwre has to write code to support larger fonts now, since the antiquated font point size system has become unusable.

Funnny we find ourselves back into the 1970 era level with operating systems again, and HA is here to prove it.

Now back to writing code to support my new keyboard with a few different keys.

 

[Dean Roddey]

Again, you are talking about a level of integration that would only be part of the story. The automation system vendor, unless the OS manufacturers are going to force all manufacturers of a particular type of device to work exactly the same, which isn't going to happen, will still have to have bespoke code for each device in order to deal with its differences, even if it does use some sort of OS API to do the actual communications. So those types of 'solutions' really aren't the answer per se. 
 
Any actual solutions always come down to standardization among the device manufacturers, which they just aren't going to do because that would mean limiting their 'uniqueness' or feature set in order to satisfy a market that's vastly smaller than the market that they are creating all those crazy features for to begin with. Without that device level standardization, nothing else is going magically make anything understand these devices, no matter how much work you do. It's not possible to create any (useful, i.e. not completely trivial) abstraction that can be universally layered over every model of a given type of device otherwise.
 
Otherwise, you are just exchanging a USB plug for a serial cable, which doesn't fundamentally change the equation. You are just getting the data in via a different route, but not making the semantics of that data any more generically understandable.

 

[LarrylLix]

Again, you are talking about a level of integration that would only be part of the story. The automation system vendor, unless the OS manufacturers are going to force all manufacturers of a particular type of device to work exactly the same, which isn't going to happen, will still have to have bespoke code for each device in order to deal with its differences, even if it does use some sort of OS API to do the actual communications. So those types of 'solutions' really aren't the answer per se. 
<snipped>.

That is exactly the process in effect and still is in effect.
There is no "forcing" manufacturers to comform at all with a decent OS. There have been tens of thousands of different video cards, printers, modems, IO cards in the past and today. The manufacturers put out a device and they write a driver to interface to a particular OS(es). If they don't nobody is going to use their device.

In the old days I had to write my own HDD and floppy drivers for my OSes. Those days are supposed to be gone and were supposed to be enduring device independence, one of the main features of any half decent OS.

Today I have three different brands of LED lighting with an RPi driver for each that make them all appear the same style of protocol in my ISY994i.

HA devices are new yet, and the OSes just haven't caught on, to their own promoted features. After seeing the monitor resolution size examples I posted above, I doubt the OS manufacturers will continue to support the same features they sold their products with. It costs money for development time and money for support and they have become complacent with their huge sheeple based markets.

Maybe the HA market just won't exoand much more and the concept will never have enough demand.
Time will tell.

 

[Dean Roddey]

But the number of viable operating systems is small. And, even then, I'm guessing that LOTS of devices don't get drivers written for all of them by the manufacturer. Blow that up by many times over and it gets a lot worse. There are many times more types of devices to deal with the automation world, than in the computer world. And here I'm talking about those that the OS actually understands. It's really a different thing if someone just writes a driver for a device that is to be used by a specific application. So it would be worse squared. Your list of four device types above is probably the vast majority of such devices sold in the computer world. 
 
And, to be fair, the OS really doesn't understand even all of those. Every printer has its own setup dialog that the user has to manipulate manually because the OS can't really understand all of the potential features of even printers. It's really just providing the glue to handle the core operations of the printer.
 
Anyhoo, I'm obviously not against such an idea. It would make my life easier. It's just an enormous thing when you get into the really ugly details of it. I went through all of this a couple years ago, to try to come up with abstractions that we could use to represent various types of devices. And even for a small subset of them it was hugely difficult and plenty of devices still won't fit into that box, because they are just not standardized at all. Any any OS would have the same issue. It would either have to set a high bar and lots of devices would have to be left out, or set a very low bar (as with printers) and have the bulk of the features of the devices fall outside of the standard (i.e. be just like things are now.)
 
So it's a tough nut to crack.

 

[LarrylLix]

Can't respond right now...I'm busy trying to get the right handshake pin connected to the parallel port connected to my printer. LOL
 
History repeats itself.

 

[ecborgoyn]

I wonder if the new IoT efforts by some of the bigger names in networking will help the cause of the lowly HA market.  One might think (hope) that a sanctioned IoT network of your 'fridge talking with your microwave, talking with your Amazon account (all via your Verizon FiOS link) would help.  Application ideas are endless.  BUT, then how could somebody monetize apps like lighting control...  Or does it come along for ride?  Or are these 'commercial' applications going to suffer the same fate as the low-end lighting/HVAC/etc HA applications?
 
Thinking about the 'commercial' application where the 'fridge and microwave realized that you just cooked your last box of XYZ..  And now Amazon, Google, etc.  is going to target your phone and other terminal/UI devices with ad's for a new supply of XYZ..  Or maybe ad's for your local restaurant that serves an up-scale XYZ dish.
 
All of these apps are going require either e vendor-neutral transport like Zigbee, or some form of 'device driver' management.  It's hard to think that Google wouldn't want to interface with devices from other vendors like Samsun, LG, etc, etc..  And Google might have a mechanism to make advertisement dollars...   Just some random thoughts.

 

[Dean Roddey]

The whole IoT's 'this talks to that through the cloud' stuff is the opposite of what most folks around here want. It's worst of all possible worlds. You are dependent on your internet connection. Everything you do will get recorded and sold to marketers. And the configuration of your system is spread out all over the place into devices that really have no business trying to be 'smart' or in storing system configuration data.
 
It's all really the opposite of the optimal situation which is passive devices that are under the control of a central, local controller. 

 

[ecborgoyn]

I was primarily commenting from the network perspective.  If the devices expose a standard/open interface, the configuration & control does not NEED to be in the cloud.  For instance, if Zigbee HA 1.2 would be better 'established' at the endpoints, then controllers (local, not cloud) applications could get better traction.  In my (admittedly somewhat ideal) model the cloud apps are only the leverage to achieve some 'critical mass' of endpoints with a standard/open protocol (and API).  No, I'm not promoting cloud apps, but standard/open protocols on commodity endpoints.

 

[jkmonroe]

Maybe a scheme like how printers have gone is the answer.  You buy a printer for your PC or Mac and they come with a driver that tells your hardware how to communicate with them.  Contrast this to how it is now with Homeseer or CQC where the driver has to be written by the controller company not the device. As we have seen, this is not really a sustainable model long-term, at least in my opinion. 
 
Instead if the controller makers could put together a driver spec. that they all followed, this might be a great start. Then it would be the device maker, not the controller maker that created the driver.  If not the device maker, other people would come forward to write drivers, but only if they worked on more than a single controller platform.  In other-words, the "driver" for an LG XYZ TV would work in Homeseer, CQC, Premise or any other controller.
 
If Dean, Mark and others could work toward this, just think how wonderful and robust the home automation market would be for us users? Will it ever happen? Probably not.

 
but this does exist with Control4 SDDP.  great for them, but not so great for the rest of us.
 
they recognized a need and went out and sold a solution.  almost every device i have in my home would work with control4 based on their supported manufacturers list.
 
but i just absolutely refuse to have the integral workings of my home automation platform controlled by Bob in Iowa.  their model is ridiculous (and artificially priced).

 

[Dean Roddey]

But that's just a discovery protocol, it's not a universal driver or anything, right? It allows C4 to discover the devices on its own. That's cool, but it's not the same as avoiding the requirement to have drivers. Control4 still has to do lots of drivers itself, they aren't so large that manufacturers just automatically do them. And, honestly, I'm not sure that's even a good idea. The quality would likely be pretty variable, and it will be C4 who gets blamed until proven otherwise. And they've bought some drivers that have become popular as well, such as the Sonos one if memory serves.

 

[jkmonroe]

i thought it was like a pseudo-universal driver.  of course, there isn't a lot of information out there, but the general tagline is something like "to allow communications and control with your control4 system."
 
the acronym is obviously a direct rip-off of SSDP, which is just a discovery protocol, so who knows.

 

[emrosenberg]

An article about researchers exploiting the zigbee protocol in Hue lights.

http://mobile.nytimes.com/2016/11/03/technology/why-light-bulbs-may-be-the-next-hacker-target.html

 

[vc1234]

An article about researchers exploiting the zigbee protocol in Hue lights.

http://mobile.nytimes.com/2016/11/03/technology/why-light-bulbs-may-be-the-next-hacker-target.html

The Zigbee ZLL profile has several known security weaknesses, one of them and  perhaps the easiest to exploit is plaintext network key exchange on initial device configuration. Furthermore, there's no provision for the network key rotation in the standard, as far as I know.  The network key vulnerability interval is very short so it's unlikely that a casual hacker can intercept it without a serious effort.  But, it's there along with other less easy to misuse flaws.
 
Zigbee, however, at least attempts to address security concerns while Zwave had had no security provisions whatsoever (except locks) until gen5 devices.  Perhaps, 99% percent of all zwave gadgets communicate in plain text so any attack on lighting/thermostats is laughably trivial.