Basics of Zwave inter-device native "association" without controller rules

I want to use native Z-wave “Association” between devices (Fibaro relays and dimmers) so that when one device’s button (Or spare input) is pushed, it automatically activates another device in the network. I’m reading the manual, but it seems to skip steps and presume prior knowledge.

How do Z-wave association and groups relate to one another in OpenHAB? I seem to always see them described together. Struggling with a lack of well-structured documentation, and with where OpenHAB ends and Z-wave begins I think :S.

I’d love for someone to point me to the right areas of the manual to read please, or to describe their understanding.

Thanks for your help!

1 Like

It’s a steep learning curve but one you can get up fairly quickly.

Groups is an OpenHAB configuration for controlling / tracking similar items

Associations is a Zwave native functionality that once configured (Habmin makes it pretty straight forward for configuring) operates independent of OH.

Yeah, I assumed that was probably the case.

Is there a walk through, or manual for building a basic Z-wave association in OpenHAB?

Just to be clear - they aren’t related in any way at all.

In HABmin, go to the device you want to SEND the command, find the relevant association group that provides the function you want to use (you need to read the device manual for this) and add the device you want to RECEIVE the command into this group in the dropdown.

Note that if you’re setting up a battery device you will need to wait for the device to wake up, or manually wake it up using the button on/in the device before the configuration will be transferred.

I would think about that twice:

You don’t have any control through openHAB in that case. On the long run you are better suited with some easy rules to perform the same function and having full control.

Actually, I will also have to agree with @sihui here, but maybe for slightly different reasons…

I can understand why you want to use associations - it removes OH from the loop when controlling basic functions like lights, so you’re not relying on a computer to be running. This is good for sure…

However, it does have some downsides - as @sihui said, you do loose some elements of control.

But, one other limitation is that you also loose status information unless you also use a rule in OH to update status… The issue here is that OH uses associations to receive notifications so it can update the UI when you change a switch state. However, devices that are controlled via an association will not send out an association themselves. So, if you turn on device2 using an association from device1, then device2 will not send any associations. What this means is that device2 will be on (which is good - it’s what you want), but since device2 doesn’t send out a notification, OH will think it’s off, so the UI will not be consistent with reality.

Maybe this is a minor issue to you, but one to remember. You can get around it with rules by setting the state of device2 whenever device1 updates - either way, you will likely need a rule I guess…

(I hope that makes sense :wink: ).


This is exactly why I don’t use Z-Wave associations (except for where necessary to send periodic sensor reports to the controller). The loss of status in OH is a deal-breaker for me. And, I’d prefer to spend my time writing rules for functionality, rather than tracking the status of all my devices.

I’ll add another"me too" on this with one caveat. I do use them for 3-way aux switches and a couple virtual switched outlets I setup just to not need to worry about delays and control when I mess up and crash my controller. i just don’t worry about including the aux switch in my siremaps. Though you will want to make sure you apply any rule based state changes to both switches.

Thanks for your thoughts. My idea was that I wanted things to continue working even if the controller was down, but realistically a constant loss of sync sounds even more annoying.

I guess I’ll fall back to the rulesets Cheers

Hi Chris! I came to this topic because off a problem that after playing with openhab, after while most of my fibaro double relays stoped to update their status when they’re manually turned On or Off. If I do that from sitemap log do shows “Corridor_DoubleSwitch2_SwitchBinary2 changed from OFF to ON” but when I fisically interact with the switches it doesn’t and so the rules doesn’t work. As I understand thats because there’s some association problems, but where should I look, i still don’t understand. I’m not looking for association between devices, just the device status update doesn’t work now for some reason. In the beginning I’m almost sure all worked fine.

Associations are used to configure the device to send status updates to the controller as well as between devices…

I would suggest to update to 2.5 snapshot if you’re not already. There have been some fixes here to try and handle various different formats of data that can be sent from the UI to try and avoid associations being lost if the UI sends incorrect formats.

After this, it would be worth initialising the devices that aren’t working (there is an option in the thng configuration to do this). The new version should then prevent removal of any associations that are required to report device status to the controller.

Hi Chris! Finally I can confirm that after I rebuild the system from scratch ( I preferred to do so) over the 2.5 snapshot, everything seams to work for a moment. I’ll keep notified you if something goes wrong. Thanks for your help!

1 Like