FAQ: Zwave Association between 2 devices

I see a lot of confusion about what zwave direct association does, so it might help just to go back to the beginning.

First, for those who don’t know how to change the parameters/associations on a Z wave device, see the following FAQ (this is a clickable link). This will also explain what we mean by “tweaker” in the remainder of this post.

Now on to how zwave association works. :sunglasses:

Back before people used smart phones and apps to control home automation, Z wave was introduced primarily for lighting control. The idea was to come up with a very low power system that could work quite quickly When a motion sensor triggered a light switch or when an auxiliary light switch triggered the Master switch.

These devices would be physically quite close together, typically in the same room.

Zwave also tried to keep its individual messages as tiny as possible, because that would require less power to transmit.

This led to the introduction of two features.

  1. “Basic” commandsets. “Basic” has a very specific meaning in zwave. The hub might send a single “basic” command to a group of devices. Maybe one is a switch, one is a siren, and one is a window shade. Normally each of those would have its own device-class specific commandset. That is, turning on a switch is not the same command as opening a window shade. But when you send a basic commands you tell the receiving device to perform its “primary” function, whatever that function is. So the light switch knows that it’s a switch and the siren knows that it’s a siren, but in that moment the hub doesn’t care: it is just telling each of them to do what it was designed to do. This keeps the message small.

  2. ”Direct association" .One of the original use cases for Z wave was having a motion sensor trigger either a light or a siren. And people wanted thIs to happen as quickly as possible, usually under one second. In order to make it very fast, “direct association“ was introduced. In direct association, a trigger device (the sensor) was given permission to send a “basic“ command directly to a nearby target device (the light switch or the siren) Without sending that message through the hub.

So the trigger device just kept a list of the device IDs of the devices that it was permitted to send the basic command to. That was all association meant. The hub approves a specific list of device IDs to be used by the trigger device to send basic commands to the target devices.

The hub doesn’t care why the trigger device Will send the command. It doesn’t need to know when the command is sent. It’s just approving the creation of the list, which is then stored in the firmware of the trigger device.

So, “Sensor 4, you have permission to send a basic command directly to light switch 2. “

Or “auxiliary switch 15, you have permission to send a basic command directly to master switch 9.”

That’s what direct association is.

Note that only the trigger device has to “support association.” Most devices can receive a basic command, so you don’t actually have to do anything special with the target device. (The exceptions are “controllers.” A lot of them won’t accept a basic command, especially if they are battery-operated. They are intended to be triggers, not targets.)

If you want two switches to be able to trigger each other, They have to each support association, and you have to set up the association twice, once for each trigger switch.

Later on more capabilities were added to association, in particular the ability to send some reports like energy levels for energy monitoring devices, but the basic concept is the same. The trigger device will decide what to send and when. It will send that message to the list of device IDs that were approved by the hub when the association was set up.

So far so good. :sunglasses:

association groups

Then device manufacturers started getting fancier. They said, “wait. I’m making a motion sensor, but it also has tamper detection. If the motion sensor detects motion, I want to immediately turn on the light. But if the motion sensor detects tampering, I want to turn on the light and the siren.”

Remember that the whole goal of all of this is to keep the messages as simple and small as possible.

So zwave introduced “association groups.” That just means that the trigger device will be allowed to keep more than one list of target device IDs. It’s still just going to send a “basic” command, but it might have a different trigger condition for the different groups as in the example we just gave.

Group 1: just the light.

If the motion sensor detects motion, send the basic command to the devices in group one.

Group 2: the light and the siren

If the motion sensor detects tampering, send the basic command to the devices in group 2.

That’s all there is to it.

Some manufacturers build devices that can only support two association groups. some can support more than a dozen.

Usually each group will be limited to a maximum of five target devices, but again that’s up to the manufacturer.

You can always look up the exact Association group details for any certified Z wave device by checking its conformance statement at the official Z wave alliance products site. (Remember that you want to look up the details for the trigger device. The target device won’t actually use its own association lists when its acting as the target. In fact, the target device doesn’t have to support association at all. It’s just going to get the basic command and then act on that.)

https://products.z-wavealliance.org

changes with zwave plus

Originally all association was optional. Some devices would support it, some would not. Manufacturers could use the association groups however they wanted to.

But by the time of zwave plus, many hubs also had mobile apps, and there was a lot more concern about keeping the hub updated with what was going on with the wall switches. So association changed a lot. Almost all devices are now required to support an association group one, which would be used only for communication with the hub itself. This is called the “lifeline” group and is mostly used for status reports.

So while we used to just ask if a device “supports association” now we have to ask if the device “supports more than just lifeline group association.”

See the following FAQ (this is a clickable link)

FAQ: How zwave direct association changed with zwave plus

Aeotec Heavy Duty Switch as an example

So now let’s look at the Aeotec heavy duty switch as an example.

We go to the Z wave product site and we look up the device and check the association capabilities.

https://products.z-wavealliance.org/products/1133/assoc?noFilename=True

Since this is a zwave plus device, we expect to see Association group one as a lifeline group, and so it is. Note that the Aeotec device is only going to send reports to this group. It’s not going to send a basic on/off command. So normally the only device ID that would be listed in this group is the hub itself.

But we also see that there is a second Association group available, group 2. You will be allowed to add five different device IDs to this Association group. And when you turn on/off the Aeotec device, it will in turn send a basic command to any target devices in this group.

So to create an association such that turning on the Aeotec would turn on the Qubino, all you have to do is add the Qubino device ID to the association group 2 list kept by the Aeotec.

( i’m guessing you will have to actually identify the Qubino endpoint, but I’m too tired to go into all that today. Just read the tweaker documentation and it should explain.)

To set up an association so that the Qubino would turn on the Aeotec, you go through a similar process. Read the user manual for the qubino or check the official zwave website and figure out which Association group you need to add the Aeotec ID to. Then assign the tweaker DTH to the QUBINO, And save the Aeotec ID in the correct Association group. That will give the Qubino permission to send a basic command to the Aeotec.

Don’t just choose an association group at random: each manufacturer will have decided how it handles each group and what the triggers will be for that specific group and what messages will be sent. (For example, it is common to put on/off switch targets in knee association group and dimmer switch targets in a different group, because the basic command for dimmers has to include the desired dim level.) So you always need to look up the details for the trigger device to make sure you understand which association group you should use for which target device IDs.

8 Likes