Association Groups for ZMNHDA2 Qubino dimmer 2nd switch?


I am trying to get my Qubino dimmer modules to work.

The main dimmer functionality I can get to work fine. The problem I am having is regarding the 2nd and 3rd switches. The 2nd a 3rd switches are just additional inputs (no relay). I want to use the additional inputs (i2 and I3) to trigger scenes in ST. My understanding (limited) is that the I2 and I3 inputs are assigned to Association groups 2 and 3 and therefore when I try to debug any inputs there is nothing coming up when I press the switches connected to I2 and I3. I am trying to understand what I need to do to get a the device type to listen to other association groups (as well as 1) - or is this not possible? I have seen something similar for dual relay devices but not sure if the input only aspect makes a difference. Linked in @erocm1231 as he seem an expert in this area.

Appreciate any pointers that may help.

Unfortunately SmartThings didn’t correctly implement Multichannel Associations so no device handler that sets associations on endpoints can be made in order to instruct the device to send unsolicited reports from those endpoints. So i actually wonder why even state it as supported since endpoints are the point of that command class (could it be there just to confuse integrators?).

This can usually be solved via a polling loop that requests data from endpoints, but surprise surprise, neither Polling or Refresh capabilities actually work on SmartThings.

I’m currently working on integrating the whole range of Qubino devices on smartThings but as it stands currently, i’m starting to get pessimistic.

Maybe i’ll eventually get a reply to my support ticket.

Looks as though there is a “hack” way to get messages from I2 and I3 via endpoints 2 and 3 , so Qubino devices should be getting their device handlers made in the following weeks.

You can give it a shot yourself in your device handler if you use the snippet i pasted here:

Thanks for the info. I have also got a bit further - I added the following lines to my configure method:


zwave.associationV2.associationSet(groupingIdentifier:2, nodeId:[zwaveHubNodeId]).format(),

zwave.associationV2.associationSet(groupingIdentifier:3, nodeId:[zwaveHubNodeId]).format(),

This enabled me to see the switch presses coming from the main switch and the additional two switch inputs. The only problem is that the string coming from the additional switches is identical:

"description: zw device: 04, command: 2001, payload: 00 "

I wonder if there is a way to detect which group the string is coming from?

Yes, while a singlechannel Association Lifeline group (group 1) is set then all reports from the module arrive without multichannel encapsulation so there is no way to diferrentiate between the two.

If you follow my above example then each input will be originating from it’s own endpoint (and multichannel command encapsulated), thereby allowing you to diferrentiate between the two by the source endpoint. I2 should fit endpoint 2 and I3 endpoint 3.
The main switch reports will be then originated from endpoint 1.

This is the recommended way to integrate devices that support MultiChannel command class and endpoints.

Keep in mind that Configuration, Association and Multichannel Association command classes should be only sent to the device without multichannel command encapsulation.

Thanks Kjamsek, That makes sense (that I can’t determine which group while on single channel). I will follow your above example with ‘assocCmds’ - (can I define both group2 and group3 in the same config method?).

I couldn’t quite understand how to read which group the event has been triggered from - are you saying that if you trigger the Hubaction as an event (‘70050A’) that it will have different event strings based on the endpoint? - Apologies for my limited understanding.

Hi Stephen,
there is no need to directly reference association groups other than 1 when setting the MultiChannel Lifeline association group. Once the controller’s NodeId 1 and endpointId 1 are inserted into the module’s association group 1 via the MultiChannel Association command class mutlichannel fields (use HubAction(“8E0101000101”) that does exactly this), the module will push reports to the controller when inputs get activated.

Additionally all previous singlechannel reports will now be MultiChannel Encapsulated, with destination NodeId1 and destinationEndpoint 1. You can then diferrentiate between reports according to what sourceEndpoint issued the report (i assume you don’t have a temperature sensor on the module and all endpoints are enabled if you have the option to configure them), here’s an exampel from my handler:

def zwaveEvent(physicalgraph.zwave.commands.multichannelv3.MultiChannelCmdEncap cmd) {
	def encapsulatedCommand = cmd.encapsulatedCommand([0x30: 1, 0x31: 1]) //Instruction to parse MultiCh Cmd Encap as V1 version
	log.debug "Command from endpoint ${cmd.sourceEndPoint}: ${encapsulatedCommand}"
	def map = [ displayed: true]
	switch (cmd.sourceEndPoint) {
				log.debug "Msg from not defined endpoint"
		case 1:
				log.debug "Frame from EP1" //Main switch functionality in your case
				log.debug '${encapsulatedCommand}'
		case 2:
				log.debug "Frame from EP2" //Reports that should fit the I2 state
				log.debug '${encapsulatedCommand}'
		case 3:
				log.debug "Frame from EP3" //Reports that should fit the I3 state
				log.debug '${encapsulatedCommand}'

I must be doing something wrong - my handler is not calling the ‘MultiChannelCmdEncap’ method. when I press switch 2 or 3 it ends up calling my ‘physicalgraph.zwave.Command’ method instead.

In my config method I do the following:
def assocCmds = []
assocCmds << zwave.associationV1.associationRemove(groupingIdentifier:1, nodeId:zwaveHubNodeId).format()
assocCmds << new physicalgraph.device.HubAction(“8E0101000101”)
return delayBetween(assocCmds, 1000)

is there anything else I need to do to get the event to trigger the ‘MultiChannelCmdEncap’ method?

Hm, looks as though i was too eager and fed you information meant for 500 series z-wave modules, whereas the one you have is the 300 series model judging by the PN (my apologies :frowning: ).

On 300 series the Lifeline group, meant for controller reporting, doesn’t need to be set via the Multichannel Association command class in order to receive encapsulated reports and the numbering of the group is the last association group on the root device, this was changed in the protocol for 500 series z-wave modules.

You can see, in the manual you linked, this line in the association group listing:
Group 4: default reporting group (reserved for the main controller)

So in order to receive encapsulated reports from each endpoint please use this configure method, the multi channel encapsulation handler can remain the same:

def assocCmds = []
assocCmds << zwave.associationV1.associationRemove(groupingIdentifier:1, nodeId:zwaveHubNodeId).format()
assocCmds << zwave.associationV1.associationSet(groupingIdentifier:4, nodeId:zwaveHubNodeId).format()
return delayBetween(assocCmds, 1000)

Thanks a million @Kjamsek, I now get the event coming through for each endpoint :slight_smile:

No problem, glad to see it’s working on your end. The above sequence can be used on all 300 series products from Qubino, just be sure to modify the association group you are setting for that product (this is generally the last one supported on the main device in 300 series modules).