What do Zwave Software Developers need to do exactly?

Consider a scenario where your company makes switches and now you’re assigned with the task of adding the Z-Wave feature in it. Considering that all the required hardware changes have been implemented (ex- addition of an SoC which supports Z-Wave), what does a software developer needs to do exactly? For now we will consider that the product’s requirement is that

  1. it must be added to a Z-Wave Controller (like SmartThings);
  2. the user must be able to turn the switch on/off;
  3. the user must be able to see the current state of the switch; and
  4. must have the facility of disconnecting with the controller.

So as a software developer, my responsibilities must be:

  1. Find the SDK and example code to understand how the protocol works.
  2. Write code so that the new device of mine is able connect with the Controller. Here some logic like pressing of some GPIOs, etc. could be required.
  3. The controller must be able to get the status of the switch.
  4. The switch must be able to take the input from the controller and take actions on the input.
  5. The SW must have some routine to disconnect/unpair(?) from the controller as and when required.

This is the first time I am working with Z-Wave or any wireless protocol as a developer. I would appreciate if the community can help me fill the gaps in my knowledge!

It is not very clear whether the firmware is ready or not (as being part of the hardware).

If the firmware is the problem, I think this community won’t be able to help you much.
I have already developed some firmwares to wifi devices, atmega (arduino + wifi shield) and esp (esphome), but not z-wave.

If the firmware is ready and you want to integrate it with ST, then some will be happy to help you soon.

My question was more of a generic kind.
What should be a software developer’s responsibility while developing a new hardware which supports Z-Wave?


My first suggestion is that you start with the silicon labs resources. I suspect this is what you were looking for:

They have a very good “Discover phase playlist” for engineers with a list of resources for those just getting started with Z wave and interested in the hardware side of things.

Silicon Labs Community


In addition, you can explore the resources of the Zwave Alliance. That is the independent third-party standard organization for Z wave, and they have many resources for new device developers.


SmartThings is actually probably the worst major platform to begin exploring Zwave with because they have added their own proprietary application layer on top of zwave, which confounds The existing standard by failing to implement some of its features while also adding a bunch of required proprietary code Not required by any other Z wave platform. :thinking:

In your situation, For commercial hubs I recommend instead looking at Fibaro, Zooz, Ezlo Vera, or Homeseer, All of which have a much more standard Z wave implementation.

Once you have learned standard zwave, you can then decide if you want to go on and learn the idiosyncrasies of the SmartThings platform.

(It’s also significant that Samsung Has dropped zwave all together from its newest SmartThings hubs, including the Station And the hubs being built into Samsung smart appliances and televisions. They have chosen instead to commit to a long-term roadmap based on Zigbee and Matter. So I doubt if we are going to see any improvements in the SmartThings Z wave implementation in the future.)

But again, begin with Silicon Labs and the Z wave alliance. They have publications, courses, and events. :sunglasses:


There are some other resources, like open Zwave, Zwave JS, and domoticz, but those are more for individual DIY programmers looking at things from an application side. Since it sounds like you are associated with a hardware manufacturer, I would go straight to the source with the SI Labs and Z wave alliance resources instead.


If you want to start with a book, this is the one. However, it won’t cover the newest zwave developments, in particular, Zwave 800, but since Zwave is always intended to be backwards compatible, having a good foundation will still help.


Oh, and for firmware-specific questions, Silicon Labs has a good discussion forum once you’ve gotten some understanding of the basics:


You’re saying that

(It’s also significant that Samsung Has dropped zwave all together from its newest SmartThings hubs, including the Station And the hubs being built into Samsung smart appliances and televisions. They have chosen instead to commit to a long-term roadmap based on Zigbee and Matter. So I doubt if we are going to see any improvements in the SmartThings Z wave implementation in the future.)

How do they pass Z-Wave certification if they have made significant changes with the Z-Wave standards? My understanding is that if a manufacturer claims that the device is a Z-Wave Primary Controller, it should be able to pair all available devices (Slaves).

This brings me to another question - I have seen that manufacturers of the slave device provide a list of all the manufacturers (of PC) that are supported. I mean, shouldn’t all the slave devices compatible with all PCs? Like how all BT devices are compatible with all other BT devices (smartphones working as hosts).

Good questions.

First, zwave uses the terms”slave device” somewhat differently than you are using it:

So I think you are really asking about any of the devices on the network other than the hub.

Ok, that said: SmartThings has NOT made changes to the zwave standard. The basic messages sent to the device are still in the standard zwave format: otherwise the light switches, etc, wouldn’t understand them.

What SmartThings HAS done is add an additional application layer above that, which they call Edge Drivers, which are required to tell the hub to send that standard Zwave message. without the correct edge driver, any Z wave device connected to the network established by a SmartThings hub will only use “basic“ messages (that has a very specific meaning in Zwave). And that might cause a lot of the functionality to be lost.

Let’s use the typical post office example. You have a letter written in perfect French that you want to send to a French speaker. So far, so good. That’s the Z wave part, and the smartthings hub is acting as the post office.

But That post office is located in Spain, and your envelope doesn’t have any postage on it yet.

So you have to go to the post office and have a conversation in Spanish with the clerk there in order to purchase the right stamp and submit the letter to be mailed.

The letter itself is still in French. You haven’t changed anything about that. But before it can be delivered, you also have to have the Spanish conversation to get the postage on it.

That’s what smartthings has done. The edge driver lets you have the conversation about sending the message, rather than changing the message itself.

The Z wave independent standard allows that. It doesn’t apply until you get to the actual message, not the request to send the message. It’s just that most other zwave hubs make it easier to make that request.

It’s clear that when SmartThings first came up with the idea of their edge architecture, they intended it to work automatically (no custom code required) for most certified Z wave devices. They thought they would be able to handle the requests by identifying the “capabilities“ of a new device joining the network.

It’s just that in practice that has not worked very well. Locks get identified as light switches, multi endpoint devices don’t get treated as multi endpoint devices, sensors get identified as the wrong kind of sensor. We could all make engineering guesses as to why that happens, but the solution is almost always to take the specific “fingerprint“ (manufacturer code plus model number) and add that to the code for a specific edge driver, to ensure that the message requests trigger the right messages. And the process of adding that fingerprint is coding. Not very complicated coding, but more than a typical “plug and play“ customer can do for themselves.

So that ends up leading to a lot of frustration for both customers and device manufacturers. But it is how smartthings has chosen to design their architecture, and they do have that option, even for certified Z wave devices. :man_shrugging:t2: