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

martin.borg · March 11, 2021, 7:30am

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.

martin.borg · March 11, 2021, 9:43am

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!

mwav3 · March 11, 2021, 6:04pm

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.

mwav3 · March 12, 2021, 2:19am

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

martin.borg · March 12, 2021, 6:58pm

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…

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.

mwav3 · March 12, 2021, 7:42pm

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
        }
    }
}

martin.borg · March 12, 2021, 7:53pm

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.?

mwav3 · March 12, 2021, 8:03pm

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?

martin.borg · March 12, 2021, 8:37pm

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

mwav3 · March 12, 2021, 10:50pm

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
        }
    }
}

martin.borg · March 16, 2021, 8:02pm

Hi again @mwav3

Sorry I had not replied to your latest post… I intended to do this over last weekend but other stuff took priority… Needed to move the blinds to Smartthings and a number of door/window sensors, and other stuff. I now have almost 60 devices on Smartthings and the hub is getting a bit too busy - likely because of these switches mostly. Nothing else seems to generate this much logging…

Anyway, meanwhile, as I joined more of these switches, I happened upon one that surprised me by getting a stock DTH attached to it automatically, and appearing as a WYFY Switch (or Touch Panel, not sure)… So I compared the Raw Description. The old ones (all switches I included so far bar one) have this:

zw:L type:1001 mfr:015F prod:3141 model:1302 ver:1.04 zwv:3.67 lib:05 cc:25,27,85,60,8E,72,86,70 ccOut:60,20 epc:4

This latest switch has this:

zw:L type:1001 mfr:015F prod:3141 model:5102 ver:5.02 zwv:4.62 lib:03 cc:5E,85,59,8E,60,55,86,72,5A,73,25,27,70,2C,2B,5B,20,7A ccOut:5B,20,26 epc:4

It immediately and automatically created 3 child switches. The type of stock DTH was listed as Z-Wave Multi Metering Switch, whereas all child buttons appeared as separate devices of type Child Switch. I tested - all buttons worked and reflected on the app, though any fast switching on and off of buttons would still, invariably end up with discrepancies between the app and the physcial switch. Also tried assigning the same stock DTHs to the older switches, at firs tit worked and I had a little eureka moment, but ultimately after some testing, the results were so choppy that I reverted to @hongtat 's DTH (with added refresh() ).

Anyhow, I will find the time to test your piece of code and to see how it can help, will get back to you soon. Thank you!

martin.borg · March 17, 2021, 9:10pm

Hi @mwav3

Finally found a bit of time to play around with the code… At first it wouldn’t save for me, was throwing an error, then realised there was another method with the same name - I commented the entire method out, and inserted your code instead. Keep in mind that for this testing, I have eliminated the refresh() part - I created a specific DTH for your code and assigned one switch to it for the sake of testing.

I have mixed results… For one, and on a positive note, the app does realise something is happening, and unlike the refresh, the reaction of the app is visibly faster. Near instantaneous. However when I press any button, all four switches were turned on in the app. Same when I turned it off… and there were inconsistencies… Sometimes only three went on. Sometimes the actual button I pressed went on, only (not sure if by luck or otherwise). Even when turning buttons off, the reactions on the app, albeit instantaneous, were a little inconsistent and hardly ever reflected exactly what I did.

What is for certain is - the switches are sending something. And I am certain it can be deciphered and avoid the refreshes… That would be fantastic if we can manage that!

Tomorrow I will send you more details - some logs as I press the switches. Once again, really appreciate your help.

mwav3 · March 18, 2021, 2:04am

There’s one part of the code that might be responsible for too many commands. You can try this instead but I’m not sure it will work:

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

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

    log.debug "MultiChannelCmdEncap called - ${cmd.inspect()}"
        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
        }
    }
}

martin.borg · March 18, 2021, 6:29am

Hi, tried this (replaced previous method)…

Hitting button 1 produced the following log:

7:22:54 AM: 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:22:54 AM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:22:54 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:22:54 AM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 01 FF
7:22:54 AM: 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:22:54 AM: debug MultiChannelCmdEncap mapped - [name:switch2, value:on]
7:22:54 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:22:54 AM: debug Event: zw device: 6E, command: 600D, payload: 01 02 20 01 FF
7:22:53 AM: 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:22:53 AM: debug MultiChannelCmdEncap mapped - [name:switch3, value:on]
7:22:53 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [255], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:22:53 AM: debug Event: zw device: 6E, command: 600D, payload: 01 03 20 01 FF
7:22:53 AM: debug Parsed zw device: 6E, command: 600D, payload: 01 01 20 03 FF to MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 3, commandClass: 32, bitAddress: false) to null
7:22:53 AM: debug MultiChannelCmdEncap mapped - [name:switch1, value:on]
7:22:53 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [255], sourceEndPoint: 1, command: 3, commandClass: 32, bitAddress: false)
7:22:53 AM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 03 FF
7:22:53 AM: 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’:true, ‘displayed’:true]
7:22:53 AM: debug BasicReport() called - BasicReport(value: 255)
7:22:53 AM: debug Event: zw device: 6E, command: 2003, payload: FF

On the app, buttons 1, 2 & 3 appeared to go on, rather than just 1. (On a previous test all four seemed to go on). Physically, only button 1 is on.

I then switched that one off again, and it produced the following in the log:

7:26:56 AM: 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
7:26:56 AM: debug MultiChannelCmdEncap mapped - [name:switch1, value:off]
7:26:56 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:26:56 AM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 01 00
7:26:56 AM: 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
7:26:56 AM: debug MultiChannelCmdEncap mapped - [name:switch3, value:off]
7:26:56 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 3, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:26:56 AM: debug Event: zw device: 6E, command: 600D, payload: 01 03 20 01 00
7:26:56 AM: 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
7:26:56 AM: debug MultiChannelCmdEncap mapped - [name:switch2, value:off]
7:26:56 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 2, parameter: [0], sourceEndPoint: 1, command: 1, commandClass: 32, bitAddress: false)
7:26:56 AM: debug Event: zw device: 6E, command: 600D, payload: 01 02 20 01 00
7:26:56 AM: 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
7:26:56 AM: debug MultiChannelCmdEncap mapped - [name:switch1, value:off]
7:26:56 AM: debug MultiChannelCmdEncap called - MultiChannelCmdEncap(destinationEndPoint: 1, parameter: [0], sourceEndPoint: 1, command: 3, commandClass: 32, bitAddress: false)
7:26:56 AM: debug Event: zw device: 6E, command: 600D, payload: 01 01 20 03 00
7:26:56 AM: 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]
7:26:56 AM: debug BasicReport() called - BasicReport(value: 0)
7:26:56 AM: debug Event: zw device: 6E, command: 2003, payload: 00

All 3 buttons went off on the log… I can see some endpoint information in there, but the app does not reflect what is happening in the real world… Hope this helps somehow.

EDIT

I removed the Association Group ID (1) and the Association Group Members (1:1, 1:2, 1:3, 1:4) from the switch with Z-Wave Tweaker 2, in order to ascertain they were not causing some anomalous behaviour, but the behaviour is more or less the same.

a) Press button 1: only 1 comes on in the app.
b) Press button 2: all 4 buttons appear on in the app.
c) Press button 3: first 3 buttons appear on in the app.
d) Press button 4: all 4 buttons appear on in the app.

Turning them off produces the exact reverse. Also - the above is if you wait several seconds in between button presses. Any faster and the behaviour quickly becomes very inconsistent.

mwav3 · March 18, 2021, 10:28am

If you go back to the code I posted 6 days ago, it looked like buttons 2-4 worked fine, and just button 1 didn’t work. Can you confirm that’s still the case? This was the original code.

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
        }
    }
}

JDRoberts · March 18, 2021, 3:56pm

Devices listed in an association group will be targets. That is they will receive commands to turn on/off. Not send them.

I can’t follow all of the code, so I’m not sure exactly what’s going on, but I have seen people unintentionally set things up so that one endpoint of a device was sending commands to the other endpoints rather than to the target device, which then caused the kind of multiple events you’re seeing.

Remember that when you are creating an association all you are doing is telling the trigger device what targets it is allowed to talk to directly. So direct association is a list of targets stored in the firmware of the trigger device. The list of targets is differentiated by group so that you can have different Tap patterns Control different targets.

Again, no idea if that applies, but I wanted to mention it just in case.

@mwav3

p.s. I also just remembered that some hubs do use fake endpoints on the hub to capture some additional information, so I don’t know if that’s what you’re doing here.

mwav3 · March 18, 2021, 8:25pm

Its what I was hoping to try, but the more I try and wrap my head around what’s going on the more confused I get. It doesn’t seem possible to differentiate which endpoint is going to which command, and the association with the hub is causing commands to bounce back and forth. @martin.borg has a newer switch that seems to work fine with a stock DTH. My guess is the older switch doesn’t have a lifeline association (still have no logs from the Zwave tweaker to even confirm its capabilities, association groups, etc), but has a “group 1” that is switch one. Whether at the DTH code level or the hub’s firmware itself, it doesn’t like that group 1 isn’t the lifeline group and is being used for another purpose.

So, I think I’m in over my head here. The best case scenario is go back to the beginning and use the BaseicSet to just trigger the refresh, and any critical use scenario where that is too slow to do a direct zwave association between the other switch and the correct endpoint using the zwave tweaker. Trying to associate the hub to all the endpoints seems to be hitting a dead end.

Once the BasicSet triggers refreshes with any press automatically, the device’s refresh that is occurring at regular intervals through settings can be increased and doesn’t need to refresh every minute, which will dramatically cut back on Zwave traffic and should increase overall speed and reliability of the network.

barron · September 4, 2021, 6:43pm

Hi,

Could someone please send me a link to the best DTH for this device?

Is it @hongtat or @mwav3 ?

I’m very concerned what happens to this when it moves to edge? Will it be easier to write them in edge and do we still have ppl with the drive to make new DTH’s?

Thanks in advance

JDRoberts · September 4, 2021, 11:27pm

The current public beta for edge does not support multiendpoint Switches so we just don’t yet know how these are going to work in the new architecture.

martin.borg · October 21, 2021, 7:45am

Hi @JDRoberts - long time no speak.

I had abandoned getting the device handlers in this topic up to scratch as my project had become more and more complicated. I was converting over (from an alternative home automation controller to Smartthings) more than 100 devices, and it quickly became clear that I couldn’t do half a home as everything is interconnected. So I spent a couple of months dedicating all my free time to the project. It was exhausting - but I have a network that responds well, most of the time.

These MCO switches remain the biggest headache (I am forcing them to refresh twice for every button pressed, and the whole thing lags - sometimes by several seconds), but by the end of integrating the 100+ devices, I realised it was not going to be worthwhile fixing the Groovy device handler for just a few months. I am reading up now on what Smartthings is doing with Edge, but it seems you always have a good source for this information.

Might I ask you about this:

How do you know about this? Can you point me to a good source - not that I doubt you, it’s for me to stay abreast and hoping they eventually introduce support for such devices.

Even then, I doubt any developer on the community will take up the task of writing a Lua driver for these devices.

So a few more questions:

Is there a centralised list of device drivers for Edge?
Is there any possibility of crowd-funding (or funding in any way possible) the writing of a device driver?
Is Groovy going to be killed off completely? In other words, is there a cut-off date when Groovy device handlers will simply cease working, rendering my 40+ switches completely dumb?
I have a ton of piston code on webCoRE - what will happen with that once devices used in webCoRE are ported over to Edge (whenever such device migration is possible)? Will the pistons stop working?
Is there any real alternative for webCoRE that runs locally?

I know, it’s a lot of questions, and I have read already the post at Announcement | SmartThings Edge for Devices and Automations - #22 by posborne, but so many questions remain unanswered.

Many thanks, as always!

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

Customers

Developers

Download the SmartThings App