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

Devices & Integrations
43

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
44

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
45

Hi @mwav3

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

image
image1080×2340 328 KB

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:

image
image2480×1316 352 KB

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.

46

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

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

48

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?

49

image
image2314×620 48.3 KB

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:

50

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
51

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!

52

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.

53

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

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.

55

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

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.

57

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.

1 Like
58

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

59

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.

60

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:

  1. Is there a centralised list of device drivers for Edge?
  2. Is there any possibility of crowd-funding (or funding in any way possible) the writing of a device driver?
  3. 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?
  4. 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?
  5. 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!

1 Like
61

It didn’t in the stock drivers at the time I wrote that, and I believe it still doesn’t, but some community members have written one or two drivers for some specific Zigbee multiendpoint switches which are mostly working (with some glitches), and The Smartest House is said to be working on some for some of their zwave models. But as always, the model number matters. Here’s one example:

[Beta] Zigbee Edge Driver compatible with Lidl, Ecosmart, Osram, SmartThings & Others

  1. Is there a centralised list of device drivers for Edge?

Try this:

Edge Drivers Section Added to Wiki Quick Browse Lists

And There are discussion threads here:

Writing Edge Drivers - SmartThings Community

  1. Is there any possibility of crowd-funding (or funding in any way possible) the writing of a device driver?

Sure, many community members have patreon or other contribution accounts. You can start a thread titled: “Edge Developer needed: Name of Device” in the community-created DTH section and tag it edge-device and describe what you’d like and see if you get any responses.

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

That’s actually 3 different questions, and they haven’t publicly announced specific dates yet. :thinking: What’s going away is the Samsung-provided free groovy cloud. If you wanted to host your own groovy server and wrap an Mqtt or other interface around it you could, but it would probably be just as easy (and much more efficient) to write a new Edge Driver instead.

But yes, at some point the existing custom self-published groovy DTHs will stop working.

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

Webcore is a groovy smart app, hosted in that same free Samsung cloud. So it dies when the cloud goes away, regardless of what DTHs you use. Start preparing. :umbrella:

  1. Is there any real alternative for webCoRE that runs locally?

Too big a question: there will be multiple official alternatives (the rules engine built into the SmartThings app and the official Rules API) as well as the ability to write and host your own smartapps. Some people are adding a Hubitat hub just to be able to use Webcore there. I suggest you check the webcore forum, I’m sure there are discussions there.

Or you can start a new thread in the webcore section of this forum, maybe something like “The Future of Webcore after Edge?”

These are all very good questions, but way off topic for this thread, so please continue discussion at the various links I’ve provided.

62

Thanks a lot @JDRoberts - there’s a lot to chew on here… I’ll have to go through slowly and make a decision. Life without the complex rules I’ve set up on webCoRE sounds pretty daunting right now, and puts me in a worse situation than I was with the controller I used prior to Smartthings. Lots of thinking to do, I guess.

1 Like