Z-Wave association groups


I’m just writing my first device handlers and learning a lot along the way. The one I’m working on now is a fork of a previous handler so I’ve inherited a lot of code that I don’t really understand that deeply. Regardless of that my question now is about the association groups.

I see many handlers register with every association group like this:

zwave.associationV1.associationSet(groupingIdentifier: 1, nodeId: [zwaveHubNodeId]).format(),
zwave.associationV1.associationSet(groupingIdentifier: 2, nodeId: [zwaveHubNodeId]).format(),
zwave.associationV1.associationSet(groupingIdentifier: 3, nodeId: [zwaveHubNodeId]).format(),

So the question is: Shouldn’t it be enough to register with group 1? Or? :slight_smile:

It’s going to vary by device, because different devices use different association groups for different things. Some of those the hub needs to know about, and some it doesn’t.

Multichannel Devices Will probably need multiple association groups in order to handle the different endpoints.

But even many single endpoint devices use multiple association groups. For example, Fibaro motion sensor uses Association group 3 to send its tamper alarm alerts. The Aeon Labs doorbell uses Association group 1 as a lifeline group for configuration changes and Association group 2 for scene control.

For the newest generation of zwave, zwave plus, The whole concept of association has changed somewhat. For many device classes, but not all, These devices are now required to support Association for association group one, which is now called the lifeline group. For example, this is how battery status is now reported. So many of the informational messages which were previously sent in Association group one I now being sent through Association group 2 in the new Z wave plus models. Again, the Aeon doorbell is a good example of this.

But the Z wave standard requires backwards compatibility, which means that all the old ways of using association are still supported for the older models of the devices. So Association group 1 will be used differently by different devices. And in a smartthings type environment, it’s now going to be common that the hub has to be in both Association group 1 and association group 2 for many Z wave plus devices. And it may need to be in other association groups as well, it just depends on exactly what that particular device does.

In SmartThings, we generally want the hub to know anytime the status of the device is changed, so things like manually flipping a wall switch need to be reported to the hub. Association group are often used for that.

So my suggestion would be to look at the user manual for a specific device using any device type handler which is setting multiple association groups. You’ll likely find that the different association groups are being used for different purposes by that particular device, or that it is a multi endpoint device.

1 Like

Awesome, thanks for a detailed explanation. :slight_smile:

The specific device I’m working on is the Fibaro ZW5 Switch . I know it needs to be tested, but would I be correct in only associating the first channel given the description at the link below? I first thought that I might lose on/off messages but from what I can gather, that will also be communicated on group 1?


If I were writing a DTH for this device, I would include all three association groups, as otherwise you would lose some functionality that the device offers.

For example, if you don’t associate the hub with group 2, you won’t be told when the manual button on the pocket socket is used.

Group 3 is a much more complex feature. It allows the option to directly turn on or off some other devices based on whether this switch turns on or off, and appears to be intended for alarm situations such as when a smoke sensor or a leak sensor sends an alarm frame.

The primary issue with all of these is that the Z wave device manufacturer thinks that these are going to be used in Z wave only networks and therefore direct association can be used.

But smartthings is a multiprotocol platform. Maybe the device that you want to have come on or off is using zigbee or Wi-Fi, not zwave. So the hub has to receive the information from the fibaro so that the hub in turn can send the messages on to those devices that are using a protocol that The Fibaro cannot speak to directly.

This is one of the most common reasons for putting the hub into an association group. It’s so that it can act as the translator to devices of other protocols.

So in general, I would say that if the device supports multiple association groups, you will want the hub to be aware of those messages. But maybe not always.

If you are only writing this DTH for your own use, and you only have zwave devices, and you don’t care if the hub doesn’t have the status of all those individual devices, then you don’t need to do the association groups.

But if you are writing the DTH for the general community, it would be best to support all the features that the device support, and because of the multiprotocol issue, to include the hub in all the association groups.

But it’s your choice. :sunglasses:

I just realized this is the device that has been giving problems in energy reporting when it doesn’t have something plugged into it.

My own approach, rather than removing Association group 3, would be to expose the parameters that allow you to set the ranges and defaults and see if that helps any.

But if the pocket socket doesn’t work the way you want when the hub is Included in Association group 3, and does work the way you want when it isn’t, then maybe it’s easiest to just drop the Association group 3 setting. But if you go that way I would include a comment in the DTH about what you did and why.

Yep, both are options. :slight_smile: I’m going to test a little bit, I suspect it sends the on/off button on group 1 too but I’ll report back when I figure it out.

As you’re basically saying: it’s quite open to interpretation how to do this stuff so it really depends on the device design. :slight_smile:


1 Like

No luck fixing the device, but at least I got round to testing the association groups. :slight_smile:

So at least for this device I get all the commands on group 1. I think 2 and 3 are only meant when the plug is controlling other devices. :slight_smile:

When you turn the device on and off with the manual “B” button on the side of it, the status in the SmartThings mobile app changes correctly? Even if you only use Association group one?

Also, did you do a factory reset on the device before you changed the DTH? Otherwise the old associations will remain active for the device even if you have changed the DTH.

Yep, did a factory reset and tested the button. :slight_smile:

1 Like

Do some of the association groups get assigned automatically?

I’ve created a lot of device handlers and I know that some of them rely on group 1 for notifications, but I think I’ve only explicitly set the group for the aeon doorbell.

The device handler worked fine before I added it, but I thought that might be the reason for the secure pairing problems some users were having, but it turns out it’s just a flaw with the device.

Edit: I just noticed the code segment below in one of SmartThings DTHs so based on that comment, it looks like it’s automatic, but it doesn’t always work for some devices.

if (msr == "011A-0601-0901") {  // Enerwave motion doesn't always get the associationSet that the hub sends on join
	result << response(zwave.associationV1.associationSet(groupingIdentifier:1, nodeId:zwaveHubNodeId))
1 Like

Having recently updated a number of my own device handlers, and in the process extensively tested the behaviour of my devices, I’ve come to the conclusion that automatically adding the hub to all association groups is generally a pretty bad idea.

Most Z-Wave devices (the ones I have anyway) seem to be designed to send all required information to the hub, with it just being in one lifeline group. For Z-Wave Plus devices, this is always Association Group #1, however for older Z-Wave devices it is often not group #1.

If you add the hub to all association groups you generally get redundant information and clog up your airwaves with unnecessary Z-Wave traffic.


As @zcapr17 said with Z-Wave Plus devices you can enable unsolicited reports to be sent to the controller by setting the association group 1 to the hub’s id. For Z-Wave Plus devices it’s always association group #1, whereas classic Z-Wave devices had the lifeline group numbered as the last group supported on the root device. In general you can spot the lifeline group via just allowing 1 node id to be entered into the group.

Additionally, you can also set a multichannel lifeline group (see one of my topics where @zcapr17 saved me a bunch of work,it has the best explanation regarding this) , that enables devices to send unsolicited reports from the endpoints of a device. This is important in case of devices like outlet strips, multiple sensor devices and etc…