Wrong handling of NodeID -> End Point association

[jaroslawprzybylowicz]

This issue list is to report bugs or enhancements for the openHAB Z-Wave binding. If you're not sure about something, please consider discussing it on the forum before raising an issue - more people follow the forum than monitor the issues list, so if you are having trouble with a device, or want to ask a question, you will have a much larger audience there.

In order to ensure we have the best information to deal with the issue, please fill in the following information (delete as necessary depending on the issue).

• Binding Version (if SNAPSHOT, provide compile time as found on the filename in the console): 2.5.10

ZWave Binding is not handling group association for NodeID -> End point properly.

Scenario: Source is a Root device, with multiple association groups representing some hardware (like a push button). Destination is multi-end point device.

User want to associate, say, src group 1 with dst end point 1 and src group 2 with dst end point 2. This results in both groups pointing to end point 1 (actually, to Root device, but standard requires Root device to mirror end point 1).

Root cause:

I believe setAssociation (and sibling methods) incorrectly falls back to COMMAND_CLASS_ASSOCIATION when source device does not have endpoints. COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION documentation allows 0 root device to associate with end points:

NodeID -> End Point (V2) End Point Encapsulated *) (src≥0, dst>0)
End Point -> End Point (V2) End Point Encapsulated (src>0, dst>0)
SDS13782, page 138

while ZWaveNode.java has endpoint.size() > 1 pre-condition set.

 public ZWaveCommandClassTransactionPayload setAssociation(int groupId, ZWaveAssociation member) {
        if (endpoints.size() > 1) {
            ZWaveMultiAssociationCommandClass multiAssociationCommandClass = (ZWaveMultiAssociationCommandClass) getCommandClass(
                    CommandClass.COMMAND_CLASS_MULTI_CHANNEL_ASSOCIATION);
            if (multiAssociationCommandClass != null && groupId <= multiAssociationCommandClass.getMaxGroup()) {
                return multiAssociationCommandClass.setAssociationMessage(groupId, member.getNode(),
                        member.getEndpoint() == null ? 0 : member.getEndpoint());
            }
        }

        ZWaveAssociationCommandClass associationCommandClass = (ZWaveAssociationCommandClass) getCommandClass(
                CommandClass.COMMAND_CLASS_ASSOCIATION);
        if (associationCommandClass != null && groupId <= associationCommandClass.getMaxGroup()) {
            return associationCommandClass.setAssociationMessage(groupId, member.getNode());
        } else {
            logger.debug("NODE {}: Unable to set association group {}. Association={}", groupId,
                    associationCommandClass.getMaxGroup());
        }

        return null;
    }

[dvdp]

Looks like this still isn't fixed: I have a wall switch with 3 button pairs: 3x on-up / off-down , each pair has an associated group that can have up to 5 members. I added switch 1 endpoint of a Fibaro double switch to one group and switch 2 endpoint to another group (so just using 2 out of the 3 groups / button pairs). Turns out that the 2 corresponding button pairs of the wall switch only control the first endpoint - which is exactly what you described.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/associations-to-device-with-multiple-endpoints-not-working-correctly/138340/1

[dvdp]

The bot picked up my post in the community - some other user did a test and came to the same conclusion so this really seems to be a bug. I've seen some other mentions about associations and a reaction from Chris so got a feeling this is being looked at ...

[osalo]

During the last 2 days I've been testing OH 3.3.0 as well as 3.4.0.M2 heavily as I needed to create associations from a Z-Wave thermostat (Heatit Z-Temp2) to a floor heating controller (Heatit Z-Water) and its many different endpoints.

As discussed in this issue report, associations in the controller device (in my case, the Z-Temp2 thermostat) are not established towards the individual endpoints of the desired target device (in my case, the Z-Water controller), but instead the created associations end up controlling just the first endpoint of the target device.

I first tried this about a year ago, and again now without success: https://community.openhab.org/t/z-wave-associations-not-created/114531/2

[dvdp]

So to fix things, I used Simplicity Studio from SiLabs to create the associations manually. Not the way I prefer to do things but at least I got the configuration the way I wanted it. And as we suspected, that tool showed an association like e.g. 34 (for node 34) where I needed 34.1 or 34.2 for endpoint 1 or 2. I hope there is a plan to get this fixed ...