Right to Reply: Z-Wave Responds to Controller Compatibility Controversy

Z-Wave Controller and Sensor

It’s fair to say that our post earlier this month – Z-Wave Controller Compatibility Frustrations Grow as Dealer Vents – ruffled a few feathers.

So here’s the response from the Z-Wave Alliance. It’s full of interesting and revealing information, straight from the horse’s mouth.

Just Perception?

Is it just perception that compatibility has gotten worse?

The Z-Wave Alliance and Sigma Designs, maker of Z-Wave technology continue to work to help manufacturers move beyond interoperability to compatibility with all devices in the market. The perception that compatibility has gotten worse comes from the fact that the Z-Wave ecosystem has experienced tremendous growth in the past several years with currently over 2100 certified devices on the market. With Z-Wave Plus, an updated certification program introduced several years ago, we created categories known as “device types” which focus specifically on device functionality from the user point of view, allowing devices to be better recognized by Z-Wave controllers.

Plus or Minus

According to the Alliance, Z-Wave Plus devices now make up almost half of global modules…

In 2017, 98% of new certifications were Z-Wave Plus with overall Z-Wave Plus certifications making up nearly half of the lifetime total – and we are hopeful that compatibility will become even better in the future.

So does all that Plusness translate to better compatibility?

Certification addresses interoperability first and foremost, but Sigma Designs has taken steps to address compatibility as well.  To clarify the difference, it is important to know that interoperability ensures that Z-Wave “device types” from different manufacturers can communicate with one another, such as door locks and lighting devices. Compatibility ensures that “device types” are enabled in the gateway.

Wait what? If we’ve got to start and explain to users about the difference between “interoperability” and “compatibility” I reckon we’ve lost 99% of the population straight away.

The Controller Problem

So what about the controller issues that sparked this debate?

Last year a well-defined set of minimum required “device types” was established for manufacturers of controllers; these new requirements mean that the gateway (controller) must support lighting, thermostats, door locks, and other minimum required “device types.” Sigma Designs continues to increase these requirements and has introduced platforms for manufacturers that make it quicker and easier to create controller products, while at the same time establishing a very high level of device compatibility. Gateway manufacturers may choose to work with specific partner brands, and this is a business decision on the part of the two manufacturers beyond the control of Sigma or the Alliance.

Because of Z-Wave’s interoperability promise, they are not allowed to completely block any manufacturer’s product from working with the gateway, so what you see is a minimum level of functionality offered to non-preferred brands, and full functionality provided for preferred brands.  If the choice of brands and products offered by a gateway manufacturer are not to the consumer’s liking, they may choose to purchase the gateway or service from another brand that does not favor preferred brands. With over 230 different gateway controllers to choose from around the world, consumers have many choices when looking for a gateway provider.”

So as well as Z-Wave, Z-Wave Plus, interoperability and compatibility now we have to consider that some controllers only have a “minimum level of functionality” and not the “full functionality” of others?

How is the end-user expected to know any of this? More importantly why should they have to?


I’m really starting to believe the further we get into the 21st century the worse things are getting for the smart home owner. When there were only a dozen X10 modules to choose from at least things were simple. More choice is not translating to a more seamless smart home.

Sure, people who buy a Z-Wave socket to control an appliance remotely are probably going to be OK. But the people who want to take things seriously, the ones willing to spend lots of their hard-earned on a comprehensive system and controller are the ones that are really getting a raw deal.

Think. Improve.

This is not an attack on Z-Wave. Like I’ve said before I own plenty of Z-Wave kit myself. They are far from alone here, these issues encompass an entire industry.

But things are not improving, in fact they are getting worse. As end users it’s time for us all to put pressure on those involved in designing and building these systems.

Because this mess cannot continue.

14 Comments on "Right to Reply: Z-Wave Responds to Controller Compatibility Controversy"

  1. I agree that it is a mess..having been working on HA for 15 years I always hoped it would get better. Here’s my personal rant, not all about Z-Wave.

    Having put in a DIY solution (xAP) and written a lot of code, I wanted to move to a ‘commercial, off the shelf’ system. Ha! I’m still writing code or downloading from GitHub. And this is with both Vera and SmartThings, with mixed manufacturers Z-Wave devices. It is disingenuous of the Alliance to say if the device isn’t supported go buy another- there often isn’t another, that fits, is the right colour, etc.. How is an average consumer (or, even above average) expected to do this? And as an installer I’d go bust with support costs keeping it all running (not another Z-Wave repair….), which I guess is why very little is being put into new builds.

    Who cares there’s 2100 devices (and, BTW, see how many of those can you actually buy) or 230 controllers (ditto) when you can’t just connect and go? Why are so many designed for the retro fit market and look like the industrial design was outsourced to schoolkids with a 3D printer?

    As you say, Zigbee is no better either with lots of closed devices. I have a nice 10 zone heating installation (Salus) but it requires their co-ordinator and gateway and isn’t inter-operable with any HA system, either at device or cloud level. And where devices are ‘open’ then often only a limited set of capabilities are available from the controller implementation, same as Z-Wave.

    And whilst controller manufacturers fall over themselves to get Alexa, etc., integration and appear ‘cool’ the basics are often still missing, like decent scripting/scenes (CoRE or PLEG anyone?) beyond the most basic.

    Enough! Will I still be coding in 5 years time, you bet!

  2. Words can’t describe how I feel about this response from the Z-Wave alliance…

    The Z-Wave alliance website advertises “interoperability” as the 3rd most important reason to choose Z-Wave, shame that there is no explanation what this ACTUALLY means.

    It is such a poor testimony from a body that is to drive forward interoperability, provide a platform for manufactures to rapidly develop products and consumers to have a simple way of understanding on what products work together. Let’s draw a comparison to the cars – what is being said here about interoperability vs. compatibility is like the following statement:

    Dear valued Audi customer,

    thank you for purchasing a petrol car from us. You can fuel up at any* petrol station….

    *SORRY you can’t. When we said petrol powered, we didn’t really mean petrol powered. Please check the small, small, small print…. In case of your car we meant “Petrol from BP”. If you fill up at Shell the car only fires on 2 cylinders and the radio doesn’t work!!! We don’t know what other petrol stations are supported with your new car. You might be lucky, or not. Simply try out another if the performance is not as desired… however we will keep referring to our cars as being “petrol powered” because it sounds better and lulls customers into a false sense of “compatibility” when we actually mean “interoperability”.

    Apparently much more than semantics:

    I am strong supporter of standards and volunteer in several IET working groups to drive standardisation in the Smart Home industry, but responses like this make me wonder if this will ever happen…

    It is due to such poor considerations for customer experience that 3 years ago we chose not implement Z-Wave, Zigbee, EnOcean or any other standards backed protocol in our devices, but engineer our own wireless protocol Loxone Air. Many people have criticised us for this move, but at least this way customers can be assured that what it says on the tin is what they actually get.

  3. If you have to buy all your devices from one manufacturer to ensure full compatibility then zwave is no different from any of the other proprietary systems.

    Thats fine if thats the way they want to go (well its not fine, its stupid) but they should stop trying to pretend there are 2100 devices in one big happy ecosystem.

  4. Stephen – Funny you bring up Audi since they “require” 87 octane and “recommend” 91 for many of their models. So yes, you can fill up at any station but the gas may not work right.

    Zwave is 16 years old. That is the same timeline from Windows 1.0 to Windows XP. Let that sink in a minute. Widespread HA adoption is in the same stage as home computers were then.

    Home automation is a moving target. One that used to lumber along fairly slowly but is now changing quite rapidly. Multisensors weren’t a thing 5 years ago and now you can get motion/humidity/light/uv/temp/etc multisensors from a variety of vendors. Doorbells,RGB lighting, heck even mouse traps are available.

    What we are running into here is the demand for perfection. We want something that supports future devices we haven’t even conceived of and we want something that works reliably for years. We want all those devices to talk to each other and we want to leverage the latest best practices.

    It’s a unicorn.

    You can have the Apple/control4/insteon world of branded products that always work but only can be upgraded by the manufacturer, choices are from a pricey menu, and your stuff may be declared obsolete.

    You can have the Linux/ZigBee world where you have the freedom to do anything but there’s zero compliance testing and you are on your own. Costs are all over the place, with commodity gear being cheap but anything not in the middle of consumer space is expensive niche gear.

    Or there is the windows/zwave world, which can be extended by users and manufacturers (which creates future incompatibilities), has basic standards, a moderate level of backwards compatibility and is cheap because of volume.

    If you can find a fourth way, power to you.

  5. @james McP –

    > Multisensors weren’t a thing 5 years ago and now you can get motion/humidity/light/uv/temp/etc
    > multisensors from a variety of vendors

    Yes, but attached them to your Z-Wave controller and chances are you won’t be able to read the data for one of more of those sensors.

    > What we are running into here is the demand for perfection
    > It’s a unicorn

    I disagree. It is not a demand for perfection to think that Z-Wave kit should work together.

    And no where near the Unicorn – which is X btw.

  6. @james McP:

    I agree with Mark, this is not a demand for perfection and certainly not a hunt for the mystical Unicorn. The way Z-Wave Alliance states in the opening paragraph on their website “Over 2100 certified interoperable products”. From a consumers perspective I feel that this is false advertising. The correct statement should be: “Over 2100 certified and more or less compatible products”

    It seems that the term “interoperable” is being actively used to hide that whilst products conform to a single technical standard they don’t necessarily fully work together, i.e. in Z-Wave terms are not “compatible”.

    As a customer I don’t want to get a dictionary out to look if there is potentially a hidden meaning, but would like to take things at face value. If I cannot do that then the Z-Wave logo is pretty worthless, because you are back in the realms of trawling forums on the internet where the geeks of this world share their experience of what products play nicely together and which ones don’t.

  7. I have had Vera controllers so you would be mostly wrong. I add a parameter or three to the device settings and those sensors are visible to scenes and logic. Using the luup scripts I could change adjust unsupported settings (which is how my “unsupported” zwave doorbell plays a dozen different mp3 announcements)

    Child devices we’re not supported by the UI back then so there wasn’t a fast way to see the data; it required drilling into the device settings.

  8. What model should zwave follow? Can you point at a multi manufacturer domain with powered devices that all play so nicely together that you don’t have to validate compatibility? If this isn’t a unicorn, point me at the herd of gazelle.

    I have never, professionally or personally, been able to mix and match powered components from different sources without vetting or planning on doing my own integration. USB? Bluetooth? Printers? Modems? VoIP? Cellular? Home theater? HDMI/CEC?
    No, no, no, no,no, no, no, no.

    All those things have standards bodies too.

    You can’t even safely buy a mix of plastic plug blocks (aka Legos) if you are building large models where the tolerance for error is small.

  9. There are assumptions being made based upon the experience with only a few controllers – controllers that choose to support only certain brands or only certain sensors because their UI and trigger setups cannot handle other types. There is a controller out there (I won’t name names) that has been around almost as long as Z-Wave, and it supports every Z-Wave device and Z-Wave Command Class that it has been faced with – so to say that the issue lies with Z-Wave seems a little unfair – where is the culpability of the manufacturer in this discussion?

    It is like telling Apple that as a computer, tablet, and phone manufacturer, they can no longer use proprietary connectors that require people to buy special adapters – they are making a standard computer, tablet, or phone and therefore they must support all of the adapters used by the others. It is like telling Sony that you can’t use MemoryStick in a camera or UMD in a PSP because nobody else supports them – THEY choose what they want to support in their products, and in time if the market disagrees, then they lose.

    Z-Wave speaks a common language, which is what interoperability provides. If a manufacturer decides that they are not going to support “Humidity” sensors for example, or that they are only providing full support for sensors made by Acme Widgets, then how do you suppose the conversation between the manufacturer and Sigma Designs should go like to fix it? Let’s use the earlier automotive example and imagine a conversation between the consumer and the manufacturer that is similar to this situation:

    Car Owner: “What do you mean I can only listen to Country Music on my car radio?”
    Car Manufacturer: “We partnered with the Country Music Association because they give us money to promote Country Music, so the radio goes mute if you tune it to any other genre of music.”
    Car Owner: “But it is a standard AM/FM radio, provided by Sigma Designs so it can tune in to any AM or FM station on the dial – why doesn’t it work?”
    Car Manufacturer: “Yes, the Sigma Designs radio can receive any AM or FM station, but we added technology to make it only work with Country Music. If you want to listen to Rock-n-Roll then there are other manufacturers that allow that with their AM/FM radios.”

    So imagine if the radio supplier tried to tell the car manufacturer that they can’t do that? The car manufacturer would simply change to a different supplier.

    Sigma Designs has been making it easier for all device types to be supported by a controller, but the UI of the controller is still done by the manufacturer. The minimum set of device types that must be supported is raised by Sigma Designs, so as manufacturers update their products, they will be increasing their supported devices – supported brands however may continue to be an issue for a while.

    I have 162 nodes in my home and those represent 19 different brands. I have all kinds of multi-sensors, garage door openers, door locks, valves, switches, color switches, wall controllers, and even a Z-Wave infrared interface – they all work and are fully supported by my controller. Truly, the issue is that people get started using the least expensive controller they can find because they are not sure about the technology, but once they see how powerful and nice the technology is, they start growing their network and learn later how their choice of controller perhaps should not have been made based upon cost alone.

    With Z-Wave, you don’t have to say “which Z-Wave?” (ZigBee), WiFi and Thread do not even define anything at the application layer, Bluetooth is still not there… so the fact that Z-Wave demands interoperability and has achieved it for 16 years is quite an accomplishment that should not be ignored because of compatibility issues created by the manufacturers using the technology.

  10. Another vote here for zwave being a mess. Bought zwave socket with built in energy meter. Socket switched off and on great but the energy information was nowhere to be seen on my controller.

  11. @James McP & @Tink

    I fully understand where you are coming from and you are both making valid arguments that make technical and also business sense.

    HOWEVER, what is being missed in all of this here is that 99.9% of all consumers don’t understand any of this and probably have no desire to understand it. Right now the Z-Wave symbol on the box of my sockets that monitor energy means exactly nothing to me, because it does not tell me if the sockets are fully compatible with the other devices that I have.

    The current state of affairs form a consumers point of view is exactly one thing: ONE BIG MESS!

  12. @Philipp Schuster

    Very much agreed, it is a MESS. I am simply saying that when you speak of Z-Wave, you are preaching to the choir. Sigma Designs wants every Z-Wave device to work with every controller as much as consumers do, but they can’t dictate what happens above their technology. Z-Wave guarantees with Interoperability that a message with information about humidity or metered electrical energy will be sent to a controller and that the protocol defines how to read it and interpret it, but if the manufacturer chooses to ignore it because they do not support those sensors, then how does Sigma Designs force that?

    Saying that consumers do not understand the difference also does not help. If you own a Windows computer and you go shopping for software, you do not have to know the technical reason why a program written for Apple won’t run on it, you just know to look for the Windows compatible software. This is no different – the consumer needs to check before buying a controller to know what it is compatible with. If the manufacturers were smart and wanted to take up most of the market, they’d do the work to make sure their controller supported everything – but today they don’t do that.

    All I am suggesting is that we focus our ire toward the proper channel – the manufacturers of the controllers.

  13. And they aren’t wrong entirely. It is messy. It’s growing. That makes a mess.

    But so is everything I listed. 80% of people get by with the most common 15% bits of a technology, none of which is cutting edge.

    Why would HA be different?

    Again, you all want a unicorn. Show me another industry that does better.

    We got a pony. Keep trying to glue that horn on there because maybe you can do it and get the unicorn.

    I will cheer for you while being happy with the pony.

  14. Hi Guys
    I have a fully working HA with WiFi NodeMCUs controlling hardware of my design. I am now researching where to go with wireless devices. Zwave or Zigbee etc. Reading this forum is basically telling me to avoid Zwave. Which I think I will do. However, there is no other candidate out there that ticks all the boxes. I worked in the aircraft industry and standardisation, interoperability etc was controlled by ARINC and a manufacturer could not pick and choose what bits of an ARINC spec they were compliant with or not compliant with. Industry needs to get its act together not the custom or end user. Zwave or Zwave Plus on the box should mean it’s fully compliant with the specification and therefore fully functional and interoperable.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.