Last i’ve tried to use both inputs enabled on the Flush Dimmer a couple months ago, i’ve had trouble with SmartThings actually executing my handler after inclusion (and didn’t have the chance to re-test it again after these updates, but plan to do so when possible), but i can show you a snippet of how i implemented Multichannel Lifeline setting on the Flush Shutter handler i’ve made, that uses a configurable endpoint 2 to control slat tilting if desired (the same approach is used on all Qubino devices with configurable Z-Wave structure).
First i use the configure capability to remove and re-set the singlechannel Lifeline (this is just for clarity’s sake to make sure it’s set in the first place) and after that i send a MultiChannel Endpoint Get command, that will return the number of endpoints the device supports in it’s current configuration (Z-Wave requires reinclusion after any changes to the device command class structure is made):
def configure() {
log.debug "Qubino Flush Shutter: configure()"
state.isMcDevice = false //Internal state used for determining if it's in MultiChannel configuration or not, initially set to false
def assocCmds = []
assocCmds << zwave.associationV1.associationRemove(groupingIdentifier:1).format() //We clear the SingleChannel Lifeline if present
assocCmds << zwave.associationV1.associationSet(groupingIdentifier:1, nodeId:zwaveHubNodeId).format() //We re-establish SingleChannel lifeline in case the device doesn't support any endpoints in it's configuration
assocCmds << zwave.multiChannelV3.multiChannelEndPointGet().format() //Fetches number of currently supported endpoints
return delayBetween(assocCmds, 500)
}
This will cause the device to respond with MultiChannel Endpoint Report if any endpoints are supported, along with the number of endpoints. In case no endpoints are supported the device won’t reply to this so it won’t execute.
I then use a Z-Wave event for that command to trigger MultiChannel Lifeline association setting like this:
/**
* Event handler for received MultiChannelEndPointReport commands. Used to distinguish when the device is in singlechannel or multichannel configuration.
*
* @param cmd communication frame
* @return commands to set up a MC Lifeline association.
*/
def zwaveEvent(physicalgraph.zwave.commands.multichannelv3.MultiChannelEndPointReport cmd){
log.debug "Qubino Flush Shutter: firing MultiChannelEndPointReport"
if(cmd.endPoints > 0){
state.isMcDevice = true; //We have a greater than zero number of endpoints supported so we mark the state parameter as true, the device is a MultiChannel device
}
def cmds = []
cmds << response(zwave.associationV1.associationRemove(groupingIdentifier:1).format()) //Here we clear the SingleChannel Lifeline since we will set up a MultiChannel one right away
cmds << response(zwave.multiChannelAssociationV2.multiChannelAssociationSet(groupingIdentifier: 1, nodeId: [0,zwaveHubNodeId,1]).format()) //Here we set the actual MultiChannel Lifeline association, note the formatting of parameters passed to nodeId field, it must match this form
return cmds
}
To elaborate a bit on the parameters for the MultiChannel Association Set nodeId property:
nodeId: [0,zwaveHubNodeId,1]
The first parameter here needs to be 0, since it’s the SingleChannel Node id (this is used for setting a SingleChannel Lifeline; in this case the other two parameters need to be omitted. This is equivalent to an Association Set.
The second parameter zwaveHubNodeId contains the Node Id value of the primary controller, to which we wish to send MultiChannel Encapsulated Reports.
The third parameter needs to be the endpoint Id that matches the above (zwaveHubNodeId) controller’s endpoint, with ST this is 1.
Now, after the MultiChannel Lifeline is set up you should receive MultiChannel Encapsulated Reports from the device. These are needed so you can diferrentiate between which endpoint sent the specific report. See here from my Shutter handler, i use endpoint Ids to separate reports for main blinds motion (endpoint 1) from the slat tilting (endpoint 2):
/**
* Event handler for received MC Encapsulated Switch Multilevel Report frames.
*
* @param cmd communication frame, command mc encapsulated communication frame; needed to distinguish sources
* @return List of events to update the ON / OFF and analogue control elements with received values.
*/
def zwaveEvent(physicalgraph.zwave.commands.switchmultilevelv3.SwitchMultilevelReport cmd, physicalgraph.zwave.commands.multichannelv3.MultiChannelCmdEncap command){
log.debug "Qubino Flush Shutter: firing MC switch multilevel event"
def result = []
switch(command.sourceEndPoint){
case 1:
result << createEvent(name:"windowShade", value: cmd.value ? "open" : "closed", isStateChange: true)
if(cmd.value > 99){
result << createEvent(name:"level", value: cmd.value, unit:"%", descriptionText:"${device.displayName} is uncalibrated! Please press calibrate!")
}else{
result << createEvent(name:"level", value: cmd.value, unit:"%", descriptionText:"${device.displayName} moved to ${cmd.value==99 ? 100 : cmd.value}%", isStateChange: true)
}
break;
case 2:
log.debug "Received command from EP2"
log.debug cmd
result << createEvent(name:"venetianState", value: cmd.value ? "Slats open" : "Slats closed", isStateChange: true)
if(cmd.value > 99){
result << createEvent(name:"venetianLevel", value: cmd.value, unit:"%", descriptionText:"${device.displayName} is uncalibrated! Please press calibrate!", isStateChange: true)
}else{
result << createEvent(name:"venetianLevel", value: cmd.value, unit:"%", descriptionText:"${device.displayName} tilted slats to ${cmd.value==99 ? 100 : cmd.value}%", isStateChange: true)
}
break;
}
return result
}
You can also find some other Qubino handlers that could serve as an example on how to implement certain features on my GitHub profile below, though for the Flush Dimmer (and other configurable input supported Qubino devices), i have a plan to rework the input detection via child devices once i have some more time, so i didn’t implement this at the moment:
