multiChannelAssociation and endpoints

šŸ›Žļø Get Help Devices
1

I'm trying to configure a Qubino Dual relay module with multiChannelAssociationV2.multiChannelAssociationSet and I don't seem to be getting anywhere ..
I've played with associationV2.associationSet and multi channel commands with less than stella results. I can set the device to respond with SwitchBinaryReport, BasicSet and encapsulatedCommand:SwitchBinaryReport, but at no time can I get it to tell me the endpoint.
I've been studying many " examples" (eg: How to set Multichannel Associations to endpoints of a device - #13 by Kjamsek - Writing Device Types - SmartThings Community)
So - I used:
delayBetween([ zwave.multiChannelAssociationV2.multiChannelAssociationSet(groupingIdentifier: 1, nodeId: [0,1,1]).format(),
zwave.multiChannelAssociationV2.multiChannelAssociationGet(groupingIdentifier: 1 ).format()
], 1000)
But it just doesn't take
MultiChannelAssociationReport - groupingIdentifier:1 contains destinations: []
It does work to a certain extent if I only use Set[1]

Anybody have any pointers ?

Thanks
David

2

Reviving this instead of starting a new topic.

I have run into this issue when trying to do direct associations to the different channels of an Enerwave A-wave Dual Relay (ZWN-RSM2-Plus). According to the Z-Wave spec, an endpoint association is specified by (e.g. 0D:1, 0D:2). While various remotes and switches (Zooz ZEN34) have multichannel association capabilities listed in their clusters (0x8E), Hubitat drivers actively prevent you from specifying association node ids for multichannel endpoints. They seem to be validating the node id against the current Hubitat node list and invalidating anything with a ";" character. Right now, the only way to get a multipoint node endpoint ID into a device is to use the Z-wave tweaker port from SmartThings

Can drivers for devices with multichannel association capabilities start to allow them?

3

Adding the multichannel association support is not as easy as it seems, because the commands get sent with a different command class, and also the report received back to confirm comes in differently.

For any of the Zooz devices I have community drivers for I will probably add it in the future using the Tweaker I ported as an example. I also want to add support for the Inovelli ZWave association app, and also may fork that app and finish the multichannel support that was never completed in it (already discussed with Eric and I will send a PR back to them when done). Unfortunately the app must rely on the device driver to have the proper code in it to be able to function, so it is not universal to work on any driver.

I also would like to make the tweaker driver more user friendly eventually, it is a hot mess right now but at least it works. The handy thing about the driver is it can work on any device that supports the command classes. You just have the annoyance of switching the driver to make any changes.

4

Iā€™m not sure where this came from, but I have seen many community drivers use this same incorrect format.

Correct example:

zwave.multiChannelAssociationV3.multiChannelAssociationSet(groupingIdentifier: 1, multiChannelNodeIds: [[nodeId: zwaveHubNodeId, bitAddress: 0, endPointId: 0]]).format()

Note that the 700 series SDK (C7) requires all traffic directed towards the hub be endpoint 0 also.

5

You will also need to de-encapsulate the multi-channel received packets.. see the below example:

void zwaveEvent(hubitat.zwave.commands.multichannelv4.MultiChannelCmdEncap cmd, ep=0) {
    if (logEnable) log.debug "MultiChannel Encap Src: ${cmd.sourceEndPoint}, Dst: ${cmd.destinationEndPoint}, CC: ${cmd.commandClass}, CMD: ${cmd.command}"
    hubitat.zwave.Command encapsulatedCommand = cmd.encapsulatedCommand(CMD_CLASS_VERS)
    if (encapsulatedCommand) {
        zwaveEvent(encapsulatedCommand, cmd.sourceEndPoint)
    }
}
1 Like