MCO Home MH-S312 and MH-S314 - Anyone has these working properly?

Running the zwave tweaker and verifying which parameters are supported should tell you which switch you have. Almost all 300 series chip devices are not plus, but some were.

If it supports the central scene configuration and values show for parameters 16-36 you should have the newer switch.

1 Like

When you first assign the device to the tweaker DTH, have another live log window open. Then you will see this in your logs:

2:39:04 PM: info Supported Command Classes: [APPLICATION_STATUS (0x22), SWITCH_BINARY (0x25), SCENE_ACTIVATION (0x2B), SCENE_ACTUATOR_CONF (0x2C), TRANSPORT_SERVICE (0x55), ASSOCIATION_GRP_INFO (0x59), DEVICE_RESET_LOCALLY (0x5A), CENTRAL_SCENE (0x5B), ZWAVEPLUS_INFO (0x5E), SUPERVISION (0x6C), CONFIGURATION (0x70), MANUFACTURER_SPECIFIC (0x72), POWERLEVEL (0x73), FIRMWARE_UPDATE_MD (0x7A), ASSOCIATION (0x85), VERSION (0x86), SECURITY_2 (0x9F)]

2:39:04 PM: info Device has new-style fingerprint: zw:L type:1001 mfr:0063 prod:4952 model:3135 ver:5.53 zwv:6.04 lib:03 cc:5E,25,85,59,86,72,55,5A,73,5B,9F,6C,70,2C,2B,22,7A

You’ll see the command classes supported right in the log - look for central scene. You can paste the log here.

Hi @mwav3 - tried this without success… Kept a tab open on Chrome in Live Logging on the IDE, then assigned the Z-Wave Tweaker DTH to the Dining Room switch, nothing happened on the log - and I mean zero…

When I switch it back to its original, the log is filled with numerous entries, but not when I assign to it the Z-Wave Tweaker DTH. I did this several times to be sure, and can confirm that assigning the Z-Wave Tweaker DTH produced zero entries in the log.

And now I have a further concern at the back of my mind… I am going around the house removing devices from my old (non-Smartthings) controller and adding them to the Smartthings one, but it all seems a little bit shaky. Many of my devices are a bit old - installation was towards mid-2017, and I have had to find and use Groovy DTHs on here for quite a few devices… So when Smartthings eventually does pull the plug on the Groovy cloud, will I lose all these devices? That’s quite an expense for me, and not one I’d be willing to go into for sure. But I digress, even though it’s connected in a way - as I am trying to solve the problem with these MCOs only to have them stop working a few months down the line.

Anyhow, back to the Z-Wave Tweaker - any ideas on this?

Also, reading back in the original post of the DTH, I see there were others who faced same issue, and they only solved it by associations.

Maybe, we just don’t know yet. Smartthings still hasn’t published details on how hub connected Device DTH ‘s are going to work on the new platform, and whether custom code will even be possible For those. :thinking:

Or whether they might instead provide stock zwave DTHs which are comparable to their competition, thus removing the need for some of the custom code. (There has been some speculation that the Aeotec partnership would tend to lead them in this direction, but again nothing official has been announced.)

We just don’t know.

One alternative for most zwave Devices would be to add a Hubitat hub as your Z wave controller and then integrate that back to smartthings through the API. It would be a little clunky, but it should be doable even if smartthings drops groovy all together.

1 Like

That’s a horrifying prospect for me… I seem to have joined the party late in the day, and I’d hate to have to go through the pain again - but worse than that - the idea of suddenly losing numerous wall-switches, open/close sensors, combustible gas sensors, motor controllers, sirens, etc… in one fell swoop, that’s just unthinkable in terms of expense and effort.

Just hope you’re right about this - my devices appear to be pretty standard in functionality, so I don’t expect highly customised code beyond stock Z-Wave DTHs… I have no guarantee that these devices would integrate well with Hubitat either, and to think I would need a second hub to integrate with Smartthings, after all the pain of setting up Smartthings and learning WebCoRE (which itself may be biting the dust), it’s just a lot…

1 Like

The zwave tweaker was written for the classic app, and the developer no longer updates it. I found a workaround to still use it now using an option in the IDE called "the simulator ". I posted about it here. [OBSOLETE] Z-Wave Tweaker - #207 by mwav3 with screenshots. The simulator will be under the device handler for the zwave tweaker. It will ask to select location, then a device. Pick one of your 4 button switches. Then click the commands- log info will be right on that same page. The simulator is a tool for developers to test codes and commands and will work well in this case.

We can keep our fingers crossed this custom code will work some other way after the ide phaseour. If not though, you’d probably be better off just getting another hub that works for theses switches instead of replacing everything else. Hubitat, Openhab, and zwavejs in home assistant should all support these switches. I run home assistant with Smartthings so if everything goes south here I’ll just move everything over to that. We can be optimistic for a bright future with Smartthings, but a “plan b” is good to have.

2 Likes

@martin.borg I updated the Zwave Tweaker to work with the new Smartthings app. I posted about it here - [BETA] Z-Wave Tweaker - #209 by mwav3 and you can get the updated version here on my Github - SmartThings-1/zwave-tweaker.groovy at master · mwav3/SmartThings-1 · GitHub

You should be able to use this updated tweaker now to perform scans of your switches to try and gather more information on them. The scans we are most interested in are “perform general device scan”, “association scan”, and “endpoint scan”. You can perform those then perform “Prints” (ie print endoints) on each one to put the values out to a live log.

2 Likes

Lovely… Thank you very much, will try this out as the current Z-Wave Tweaker I have is severely reduced in functionality. Many, many thanks.

I’ve been busy adding more and more devices to my Smartthings and so far it is handling them decently, though I hope one day they will allow clustering of hubs as I can tell it’s feeling the load somewhat… That said, my testing is intensive and when I test these MCOHome swithces - many at one go, in rapid succession, each button press generates 2 refreshes (one by the handler, one by WebCoRE), so yeah, it’s clunky, but works somewhat. Real life use will be a few button presses at a time at most - there can only be so many people in a house…

Anyhow, I will try this out as it would be great to get association to work… My only worry is the hub not knowing that a button has been pressed if there are associations, and I might have to live with that.

I checked out the Hubitat forums… Users seem to have had problems integrating these switches with that hub as well. I’ll stick to Smartthings for now until I have no option, but if I see things going south, I will of course consider, Hubu=itat especially because I can keep the pistons I am creating and they have a ton of logic inside them.

Many thanks, once again!

1 Like

The hubitat forum shows a little more success with this switch for some people. Looking at the post here - MCOHOME Touch Panel Switch - Support - Hubitat has a link to one of their drivers. Their driver appears to successfully pull the endpoint out of the basic report command. Hubitat works in a similar way to Smartthings, but the code is just slightly different. Changing this code might work to pull the endpoint from the basic set, and update the corresponding child device, but I don’t know if I have the syntax right:

def zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicReport cmd, endpoint = null) {
    log.debug "BasicReport() called - ${cmd} to endpoint ${endpoint}"
    zwaveBinaryEvent(cmd, endpoint, "digital")
    // createEvent(name:"switch", value: cmd.value ? "on" : "off")
}
def zwaveEvent(physicalgraph.zwave.commands.switchbinaryv1.SwitchBinaryReport cmd, endpoint = null) {
    log.debug "SwitchBinaryReport() called - ${cmd} to endpoint ${endpoint}"
    zwaveBinaryEvent(cmd, endpoint, "physical")
    // createEvent(name:"switch", value: cmd.value ? "on" : "off")
}
def zwaveBinaryEvent(cmd, endpoint, type) {
    log.debug "zwaveBinaryEvent cmd ${cmd}, endpoint ${endpoint}, type ${type}"
    def childDevice = childDevices.find{it.deviceNetworkId.endsWith("${endpoint}")}
    def result = null
 
    if (childDevice) {
        log.debug "childDevice.sendEvent ${cmd.value}"
        childDevice.sendEvent(name: "switch", value: cmd.value ? "on" : "off", type: type)
    } else {
        result = createEvent(name: "switch", value: cmd.value ? "on" : "off", type: type)
    }
 
    result
}

Here’s a link to the test code you can try - maybe it will work? If not, can you post the logs when you try and push the buttons now with this updated code?

2 Likes

I added this to the file posted above as well to see what it does:

def zwaveEvent(physicalgraph.zwave.commands.basicv1.BasicSet cmd, endpoint = null) {
    log.debug "BasicSet() called - ${cmd} to endpoint ${endpoint}"
    zwaveBinaryEvent(cmd, endpoint, "physical")
}
1 Like

Hi Tim

So I tried the code - I set up a new handler and dedicated one switch to it, and these are the results. First off, I deleted all child switches from the parent, and assigned your code as its DTH, but it would not create the children, no matter how many times I updated. So I assigned to it hongtat’s initial DTH, allowed it to create the children, went back to the parent, and assigned to it your DTH.

I tried to switch on button 3 and button 4 on the physical switch… On the app, it showed only the parent going on - that represents the first button, though physically this was off. Then after a while (several seconds) the app refreshed and showed the actual buttons going on (3&4) and button 1 going off. I could see from the log this happened because of a refresh having been called.

The log shows this:

8:06:27 AM: debug Parsed zw device: 6E, command: 2001, payload: FF to BasicSet(value: 255) to [‘name’:‘switch’, ‘value’:‘on’, ‘type’:‘physical’, ‘linkText’:‘Test Switch 1 Light 1’, ‘descriptionText’:Test Switch 1 Light 1 switch is on, ‘isStateChange’:false, ‘displayed’:false]
8:06:27 AM: debug zwaveBinaryEvent cmd BasicSet(value: 255), endpoint null, type physical
8:06:27 AM: debug BasicSet() called - BasicSet(value: 255) to endpoint null
8:06:27 AM: debug Event: zw device: 6E, command: 2001, payload: FF
8:06:19 AM: debug Parsed zw device: 6E, command: 2001, payload: FF to BasicSet(value: 255) to [‘name’:‘switch’, ‘value’:‘on’, ‘type’:‘physical’, ‘linkText’:‘Test Switch 1 Light 1’, ‘descriptionText’:Test Switch 1 Light 1 switch is on, ‘isStateChange’:true, ‘displayed’:true]
8:06:19 AM: debug zwaveBinaryEvent cmd BasicSet(value: 255), endpoint null, type physical
8:06:19 AM: debug BasicSet() called - BasicSet(value: 255) to endpoint null
8:06:19 AM: debug Event: zw device: 6E, command: 2001, payload: FF

The above is the log of 2 button presses: button 3 and button 4 switched on, consecutively, within seconds. So I believe that endpoint “null” is sort of messing things up, and therefore the hub is not getting to know which endpoint to address, thus addressing only the parent. The refresh likely happened because somewhere during testing I excluded and re-included the switch and, assigned and unassigned your and hongtat’s original DTH several times, and in the process it reverted to its original check-in frequency of 1 minute, therefore resulting in an automatic refresh.

And yet I see Hubitat’s community has had some success with this, about that you are right. Also, my current (soon to be previous) Zipato controller can see these switches being turned on and off, and the response is almost instantaneous and, I would say, correct almost every time - and that is with the same switches, same version switch, same version firmware, all bought in one single large batch. So for sure, the endpoint IS being sent, otherwise this (i.e. Zipato controller correctly reflecting physical button presses) wouldn’t happen.

Anyhow, sorry for my long posts, just trying to be clear.

1 Like

Hi again, finally installed Z-Wave Tweaker 2 DTH as well - well done, it seems like a superb piece of work now that it’s running decently on the new app!.. And so I ran it on the test switch. I will post the logs here:

GENERAL DEVICE SCAN:

10:20:47 AM: info Version Report: Application Version: 1.04, Z-Wave Protocol Version: 3.67, Z-Wave Library Type: 05 (Installer)
10:20:45 AM: info Switch All Mode: 255: Device is included in the all on/all off functionality.
10:20:43 AM: info Manufacturer-Specific Report: Manufacturer ID: 015F, Manufacturer Name: null, Product Type ID: 3141, Product ID: 1302
10:20:41 AM: info scanGeneral(): Scanning for common device attributes.

ASSOCIATION SCAN:

10:24:14 AM: info scanAssocGroups(): Scanning Association Groups (#0 to #10).

ENDPOINT SCAN

10:30:31 AM: error parse(): Could not parse raw message: zw device: 6E, command: 600A, payload: 0A
10:30:31 AM: warn Exception ‘java.lang.IndexOutOfBoundsException: toIndex = 4’ encountered parsing ‘cmd: 600A, payload: 0A’
10:30:30 AM: error parse(): Could not parse raw message: zw device: 6E, command: 600A, payload: 09
10:30:30 AM: warn Exception ‘java.lang.IndexOutOfBoundsException: toIndex = 4’ encountered parsing ‘cmd: 600A, payload: 09’
10:30:30 AM: error parse(): Could not parse raw message: zw device: 6E, command: 600A, payload: 08
10:30:30 AM: warn Exception ‘java.lang.IndexOutOfBoundsException: toIndex = 4’ encountered parsing ‘cmd: 600A, payload: 08’
10:30:28 AM: error parse(): Could not parse raw message: zw device: 6E, command: 600A, payload: 07
10:30:28 AM: warn Exception ‘java.lang.IndexOutOfBoundsException: toIndex = 4’ encountered parsing ‘cmd: 600A, payload: 07’
10:30:28 AM: error parse(): Could not parse raw message: zw device: 6E, command: 600A, payload: 06
10:30:28 AM: warn Exception ‘java.lang.IndexOutOfBoundsException: toIndex = 4’ encountered parsing ‘cmd: 600A, payload: 06’
10:30:28 AM: error parse(): Could not parse raw message: zw device: 6E, command: 600A, payload: 05
10:30:28 AM: warn Exception ‘java.lang.IndexOutOfBoundsException: toIndex = 4’ encountered parsing ‘cmd: 600A, payload: 05’
10:30:27 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 4, specificDeviceClass: 1, commandClass: [37])
10:30:27 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 3, specificDeviceClass: 1, commandClass: [37])
10:30:26 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 2, specificDeviceClass: 1, commandClass: [37])
10:30:20 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 1, specificDeviceClass: 1, commandClass: [37])
10:30:19 AM: error parse(): Could not parse raw message: zw device: 6E, command: 600A, payload: 00
10:30:19 AM: warn Exception ‘java.lang.IndexOutOfBoundsException: toIndex = 4’ encountered parsing ‘cmd: 600A, payload: 00’
10:30:18 AM: info scanEndpoints(): Scanning for Endpoints (#0 to #10).

As you can see, the last one returned a few errors and I noticed they were likely related to the fact that the range it was scanning was 0 to 10, so I set that in the tweaker to be 1 to 4, and the new results are:

10:33:18 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 4, specificDeviceClass: 1, commandClass: [37])
10:33:18 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 3, specificDeviceClass: 1, commandClass: [37])
10:33:17 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 2, specificDeviceClass: 1, commandClass: [37])
10:33:16 AM: info zwaveEvent(): Multi Channel Capability Report received: MultiChannelCapabilityReport(dynamic: false, genericDeviceClass: 16, endPoint: 1, specificDeviceClass: 1, commandClass: [37])
10:33:16 AM: info scanEndpoints(): Scanning for Endpoints (#1 to #4).

As you can see there are no associations set as yet… I hope this helps get down to why this is happening.

Many thanks!

Your logs show no endpoint is coming through on the BasicSet command. So this code doesn’t throw an error and crash that whole section, the “null” value is handled to default to the 1st switch turning on and off.

Your device also does not send a binary report when a switch is pressed, or a even a basic report when a switch is pressed. All the device currently is doing is saying to the hub “something was pressed” with no additional information to say what it is, and the only way to get the extra information is triggering a refresh to query the status of the device.

At this point, the only thing I can think of is other hubs automatically associate the hub to the endpoints, and the Smartthings hub is not doing this automatically. I can’t see anything else in that Hubitat code that I can think of to try that your existing handler from @hongtat isn’t doing.

Your code from the tweaker confirms you have the older switch and central scene is not supported. So, my best guess at this point, is the only possible way to get this working other then a refresh is to figure some way to do multichannel association between each endpoint in the device with the hub itself. The Zwave Tweaker can configure these multichannel associations. From reading more about multichannel association from information provided by @JDRoberts , my guess is that the device gets associated to the hub without multichannel association (just basic node association) at initial install, and only getting the basic sets. It needs to be associated to the hub using multichannel association to the endpoints as well. To associate the multichannel endpoints in the hub, you can try going into the Zwave Tweaker and under the settings “association group members: Enter a comma-delimited list…” try and associate the hub (node ID 1) to each endpoint by typing in exactly:

1:1, 1:2, 1:3, 1:4

If it doesn’t work automatically, try taking some new logs from the button presses after setting these multichannel associations from the hub to the endoints.

If that doesn’t work, we could also use a little more information though from the tweaker to figure out some other possible path forward. What you will want to do is perform the general device, association, and endpoint scans, but then you need to click the other “print” options in the Zwave teaker to fully log the results of those scans. From that information we can confirm what if any associations the hub currently has to your switches. Do a “perform general print”, then "print association groups, then “print endoints”, then “print parameters”. This should get us a lot more information on the device.

2 Likes

You also may need to follow the instructions in this post for the new associations to stick [RELEASE] Neo Coolcam / MCO Z-Wave Light Switch - #52 by dranizt

2 Likes

Hi @mwav3

So I tried the above, and this is what the Z-Wave Tweaker 2 looked like on the app:

I am not sure what I am doing, this is all new to me. I assigned Association Group 1, but not sure that should be the case.

I also followed the link you sent and amended the DTH so it now looks like this:

Then I tested physically, on the switch - by the way, I commented out the refresh() part of the DTH so I do not get an automatic refresh after each BasicSet command… I pressed buttons 1, 2, 3 & 4 in succession, and the log shows this:

7:46:00 PM: debug Parsed zw device: 6E, command: 2001, payload: FF to BasicSet(value: 255) to [:]
7:46:00 PM: debug Command () called - Pool Area Sw. 2 Light 1 BasicSet(value: 255)
7:46:00 PM: debug Event: zw device: 6E, command: 2001, payload: FF
7:45:57 PM: debug Parsed zw device: 6E, command: 2001, payload: FF to BasicSet(value: 255) to [:]
7:45:57 PM: debug Command () called - Pool Area Sw. 2 Light 1 BasicSet(value: 255)
7:45:57 PM: debug Event: zw device: 6E, command: 2001, payload: FF
7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 04 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 04 20 01 FF
7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 03 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 03 20 01 FF
7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 02 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 02 20 01 FF
7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 01 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 01 FF

On the app, only button 1 appears to be on, until the next scheduled refresh - and then of course all buttons appeared to be on.

As you can see from the log, the sourceEndPoint is not changing - always 1, whereas the DestinationEndPoint is changing, 1 through 4. Hope this helps a little, but things have certainly changed a little.

Many thanks for reading through all my cryptic posts… :slight_smile:

EDIT:

Just realised though, this entire block is sent when you press the first button:

7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 04 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 04 20 01 FF
7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 03 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 03 20 01 FF
7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 02 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 02 20 01 FF
7:45:51 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 01 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
7:45:51 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:45:51 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:45:51 PM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 01 FF

The rest of the lines are for the other button presses, and they’re pretty dumb and lacking in information.

Good, it looks like we are making progress. We are now getting multi channel encapsulated commands that can actually be differentiated by which button is pressed, and it looks like we’ve accomplished what was written about in this post now - How to set Multichannel Associations to endpoints of a device - #8 by zcapr17

The destination endpoint is changing based on each button you press so the different button presses can now be differentiated. It looks like we have to make changes to the code in defzwaveEvent(physicalgraph.zwave.commands.multichannelv3.MultiChannelCmdEncap cmd) between lines 202 and 233 to properly decode this. Instead of the sourceendpoint changing the destination endpoint is changing with each button press. I think that is because we are actually seeing the code from the hub which is the destination now instead of the source.

Hopefully this doesn’t mess up other parts of the code process here, but just to try it out, lets try and replace references related to source endpoint with destination endpoint. Try making these changes in that section of code around lines 202-233 to say the following and see what happens now:

def zwaveEvent(physicalgraph.zwave.commands.multichannelv3.MultiChannelCmdEncap cmd) {

    def map = [ name: "switch${cmd.destinationEndPoint}" ]

    def encapsulatedCommand = cmd.encapsulatedCommand([0x32: 3, 0x25: 1, 0x20: 1])
    log.debug "MultiChannelCmdEncap called - ${cmd.inspect()}"
    if (encapsulatedCommand && cmd.commandClass == 50) {
        zwaveEvent(encapsulatedCommand, cmd.destinationEndPoint)
    } else {
        switch(cmd.commandClass) {
            case 32:
            case 37:
                if (cmd.parameter == [0]) {
                    map.value = "off"
                }
                if (cmd.parameter == [255]) {
                    map.value = "on"
                }
                log.debug "MultiChannelCmdEncap mapped - ${map}"

                if (cmd.sourceEndPoint == 1) {
                    sendEvent(name: "switch", value: map.value)
                } else {
                    def childDevice = childDevices.find{ it.deviceNetworkId == "$device.deviceNetworkId-ep$cmd.destinationEndPoint" }
                    if (childDevice) {
                        childDevice.sendEvent(name: "switch", value: map.value)
                    }
                }
            break
        }
    }
}

I am not sure you saw the second part of my post, after the EDIT - as I realised later that the chunk of text in the log with the different DestinationEndPoints were all sent upon the press of the first button, not necessatily because the switch is sending different commands that differentiate between button presses. Unfortunately it seems not to be the case in the logs I sent, sorry, my mistake…

BUT, I have made some progress. By changing the Association Group ID to 2, the switch reflects correctly on the app for physical presses of buttons 1 & 2, and I tried with Association Group ID 3, 4 and 5, with varying degrees of success - the latter three IDs all resulted in 3 buttons working, never 4, and never extremely reliably (you press 2 a little too fast and the result gets skewed).

Should I still try the code above in the light of this info.?

Yeah I just saw your edit and now have doubts if what I posted above will work. From reading posts about these switches it appears there’s two older versions - one has association groups 1-5 where group 1 is the “lifeline” group and designed to get information to the hub, and then buttons 1-4 are actually assocation groups 2-5. The older switch just has endpoints 1-4 with no lifeline group.

It can’t hurt to try the code and just change it back if it doesn’t work. If not, maybe try running the prints from the Zwave tweaker with the log output like I posted above to see if we can get more clues?

Edit - Also, what’s the log’s when you just press the 4th button only?

So that’s what the device looks like on the IDE, I went back to Association Group ID 1, but maybe even that is wrong, not sure. I wish I understood Z-Wave better and there weren’t so many differences between versions and manufacturers…

I tried with the above settings and I am getting a different behaviour now - it’s not something I can explain. With the above settings, button press 4 on and off gives:

9:21:42 PM: debug Parsed zw device: 6E, command: 600D, payload: 04 04 20 03 00 to MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [0], sourceEndPoint: 4, command: 3, commandClass: 32, bitAddress: false) to null
9:21:42 PM: debug MultiChannelCmdEncap mapped - [name:switch4, value:off]
9:21:42 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [0], sourceEndPoint: 4, command: 3, commandClass: 32, bitAddress: false)
9:21:42 PM: debug Event: zw device: 6E, command: 600D, payload: 04 04 20 03 00
9:21:42 PM: debug Parsed zw device: 6E, command: 600D, payload: 04 02 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false) to null
9:21:42 PM: debug MultiChannelCmdEncap mapped - [name:switch4, value:off]
9:21:42 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false)
9:21:42 PM: debug Event: zw device: 6E, command: 600D, payload: 04 02 20 01 00
9:21:42 PM: debug Parsed zw device: 6E, command: 600D, payload: 04 03 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false) to null
9:21:41 PM: debug MultiChannelCmdEncap mapped - [name:switch4, value:off]
9:21:41 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false)
9:21:41 PM: debug Event: zw device: 6E, command: 600D, payload: 04 03 20 01 00
9:21:41 PM: debug Parsed zw device: 6E, command: 600D, payload: 04 01 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false) to null
9:21:41 PM: debug MultiChannelCmdEncap mapped - [name:switch4, value:off]
9:21:41 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false)
9:21:41 PM: debug Event: zw device: 6E, command: 600D, payload: 04 01 20 01 00
9:21:38 PM: debug Parsed zw device: 6E, command: 600D, payload: 04 02 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false) to null
9:21:38 PM: debug MultiChannelCmdEncap mapped - [name:switch4, value:on]
9:21:38 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false)
9:21:38 PM: debug Event: zw device: 6E, command: 600D, payload: 04 02 20 01 FF
9:21:38 PM: debug Parsed zw device: 6E, command: 600D, payload: 04 01 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false) to null
9:21:38 PM: debug MultiChannelCmdEncap mapped - [name:switch4, value:on]
9:21:38 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 4, command: 1, commandClass: 32, bitAddress: false)
9:21:38 PM: debug Event: zw device: 6E, command: 600D, payload: 04 01 20 01 FF

You can see SourceEndPoint is always 4 now. Moreover, it reflects on the app. To confirm this, I tried with button 3 as well:

9:25:08 PM: debug Parsed zw device: 6E, command: 600D, payload: 03 03 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false) to null
9:25:08 PM: debug MultiChannelCmdEncap mapped - [name:switch3, value:off]
9:25:08 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false)
9:25:08 PM: debug Event: zw device: 6E, command: 600D, payload: 03 03 20 01 00
9:25:08 PM: debug Parsed zw device: 6E, command: 600D, payload: 03 03 20 03 00 to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 3, command: 3, commandClass: 32, bitAddress: false) to null
9:25:08 PM: debug MultiChannelCmdEncap mapped - [name:switch3, value:off]
9:25:08 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 3, command: 3, commandClass: 32, bitAddress: false)
9:25:08 PM: debug Event: zw device: 6E, command: 600D, payload: 03 03 20 03 00
9:25:08 PM: debug Parsed zw device: 6E, command: 600D, payload: 03 02 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false) to null
9:25:08 PM: debug MultiChannelCmdEncap mapped - [name:switch3, value:off]
9:25:08 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false)
9:25:08 PM: debug Event: zw device: 6E, command: 600D, payload: 03 02 20 01 00
9:25:08 PM: debug Parsed zw device: 6E, command: 600D, payload: 03 01 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false) to null
9:25:08 PM: debug MultiChannelCmdEncap mapped - [name:switch3, value:off]
9:25:08 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false)
9:25:08 PM: debug Event: zw device: 6E, command: 600D, payload: 03 01 20 01 00
9:25:04 PM: debug Parsed zw device: 6E, command: 600D, payload: 03 03 20 03 FF to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 3, command: 3, commandClass: 32, bitAddress: false) to null
9:25:04 PM: debug MultiChannelCmdEncap mapped - [name:switch3, value:on]
9:25:04 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 3, command: 3, commandClass: 32, bitAddress: false)
9:25:04 PM: debug Event: zw device: 6E, command: 600D, payload: 03 03 20 03 FF
9:25:04 PM: debug Parsed zw device: 6E, command: 600D, payload: 03 03 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false) to null
9:25:04 PM: debug MultiChannelCmdEncap mapped - [name:switch3, value:on]
9:25:04 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false)
9:25:04 PM: debug Event: zw device: 6E, command: 600D, payload: 03 03 20 01 FF
9:25:04 PM: debug Parsed zw device: 6E, command: 600D, payload: 03 02 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false) to null
9:25:04 PM: debug MultiChannelCmdEncap mapped - [name:switch3, value:on]
9:25:04 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 3, command: 1, commandClass: 32, bitAddress: false)
9:25:04 PM: debug Event: zw device: 6E, command: 600D, payload: 03 02 20 01 FF

And yes - the sourceEndPoint is always 3 now! And the app also reflects it.

Two considerable drawbacks though. Firstly, pressing button 1 did not reflect on the app:

9:27:11 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 02 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
9:27:11 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:off]
9:27:11 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
9:27:11 PM: debug Event: zw device: 6E, command: 600D, payload: 01 02 20 01 00
9:27:11 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 01 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
9:27:11 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:off]
9:27:11 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
9:27:11 PM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 01 00
9:27:11 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 03 20 01 00 to MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
9:27:11 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:off]
9:27:11 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
9:27:11 PM: debug Event: zw device: 6E, command: 600D, payload: 01 03 20 01 00
9:27:11 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 01 20 03 00 to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 1, command: 3, commandClass: 32, bitAddress: false) to null
9:27:11 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:off]
9:27:11 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 1, command: 3, commandClass: 32, bitAddress: false)
9:27:11 PM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 03 00
9:27:11 PM: debug Parsed zw device: 6E, command: 2003, payload: 00 to BasicReport(value: 0) to [‘name’:‘switch’, ‘value’:‘off’, ‘linkText’:‘Pool Area Sw. 2 Light 1’, ‘descriptionText’:Pool Area Sw. 2 Light 1 switch is off, ‘isStateChange’:true, ‘displayed’:true]
9:27:11 PM: debug BasicReport() called - BasicReport(value: 0)
9:27:11 PM: debug Event: zw device: 6E, command: 2003, payload: 00
9:26:54 PM: debug Parsed zw device: 6E, command: 2003, payload: FF to BasicReport(value: 255) to [‘name’:‘switch’, ‘value’:‘on’, ‘linkText’:‘Pool Area Sw. 2 Light 1’, ‘descriptionText’:Pool Area Sw. 2 Light 1 switch is on, ‘isStateChange’:false, ‘displayed’:false]
9:26:54 PM: debug BasicReport() called - BasicReport(value: 255)
9:26:54 PM: debug Event: zw device: 6E, command: 2003, payload: FF
9:26:54 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 02 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
9:26:54 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
9:26:54 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
9:26:54 PM: debug Event: zw device: 6E, command: 600D, payload: 01 02 20 01 FF
9:26:54 PM: debug Parsed zw device: 6E, command: 600D, payload: 01 04 20 01 FF to MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false) to null
9:26:54 PM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
9:26:54 PM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 4, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
9:26:54 PM: debug Event: zw device: 6E, command: 600D, payload: 01 04 20 01 FF

SourceEndPoint is correct even for button 1, but the app in this case did not budge. I notice the difference mainly is that button 1 sends a BasicReport, and to be honest, I just checked settings for these switches, the remaining ones I have on the old Zipato Controller have a setting that says “KEY 1 WILL NOT SEND BASIC REPORT”. That is likely a parameter that requires to be set.

Secondly, pressing the buttons in quick succession will lead to discrepancies between the app and physical reality. I am not sure why, perhaps the DTH cannot handle such quick key presses, or the hub, and it’s not like you can tell everyone to pause 1 second between button presses so the home automation system can handle it…

Anyhow, hope all this helps. It’s getting very late for me, perhaps tomorrow morning I will have some time to also run the scans and send them over. Many, many thanks for your assistance!

For sure - there is improvement and we can see the sourceEndPoint changing, and that seems like a huge step forward :slight_smile:

I missed flipping source and destination on the line of code that handles switch one. Try the code below.

I do have a concern with so many logs and commands this seems to be generating of creating too much zwave traffic and messing up your network with slowdowns. The hub spaces zwave commands to I believe allow them only once every 500 milliseconds, and it appears multiple commands happen with each press now. So pressing multiple buttons quickly in a row will create problems.

Try the code change and let me know how it works. We could possibly throw in a delayed refresh that occurs 30 seconds after the last command is received to sync everything back up if status is still incorrect.

def zwaveEvent(physicalgraph.zwave.commands.multichannelv3.MultiChannelCmdEncap cmd) {

    def map = [ name: "switch${cmd.destinationEndPoint}" ]

    def encapsulatedCommand = cmd.encapsulatedCommand([0x32: 3, 0x25: 1, 0x20: 1])
    log.debug "MultiChannelCmdEncap called - ${cmd.inspect()}"
    if (encapsulatedCommand && cmd.commandClass == 50) {
        zwaveEvent(encapsulatedCommand, cmd.destinationEndPoint)
    } else {
        switch(cmd.commandClass) {
            case 32:
            case 37:
                if (cmd.parameter == [0]) {
                    map.value = "off"
                }
                if (cmd.parameter == [255]) {
                    map.value = "on"
                }
                log.debug "MultiChannelCmdEncap mapped - ${map}"

                if (cmd.destinationEndPoint == 1) {
                    sendEvent(name: "switch", value: map.value)
                } else {
                    def childDevice = childDevices.find{ it.deviceNetworkId == "$device.deviceNetworkId-ep$cmd.destinationEndPoint" }
                    if (childDevice) {
                        childDevice.sendEvent(name: "switch", value: map.value)
                    }
                }
            break
        }
    }
}
2 Likes