Help understanding zwave.parse

While working on one of my Device Handlers I noticed in my logs that one of the incoming zwave commands was generating a null result on parse.

The command is “zw device: 10, command: 3105, payload: 01 01 1A”

My parse in the DH is coded as
def map = createEvent(zwaveEvent(zwave.parse(description, [0x70:1, 0x42:1, 0x43:2, 0x31: 3])))

I have a few questions

  1. what is the second argument to zwave.parse ? I know it’s a list of zwave codes and versions from looking at it but what is it used for? What happens if the incoming command is not in the provided list of codes, is it ignored ? I suspect the second argument just lets you select the version to use for the command but I can’t find the command documented in the SmartThings documentation. It’s listed in examples a lot but never explained.
  2. What part of the incoming message, in this case “zw device: 10, command: 3105, payload: 01 01 1A” is the command? I am wondering what this command which I am currently ignoring, is sending.

Any experts out there that can help?

Is this an older generation device? The error you are seeing is common if you Are working with a device sending commands older than the most current generation. See the developer documentation for more details.

As the Z-Wave Command Reference shows, many Z-Wave command classes have multiple versions. By default, zwave.parse() will parse a command using the highest version of the command class. If the device is sending an earlier version of the command, some fields may be missing, or the command may fail to parse and return null. To fix this, you can pass in a map as the second argument to zwave.parse() to tell it which version of each command class to use:

1 Like

Thanks so now I need to figure out which part of the string is the command code.
I have two examples
description=zw device: 10, command: 3105, payload: 01 01 1A
description=zw device: 10, command: 4303, payload: 02 01 1A

I expected the command value to be the command code but 3105 = 0xC21 and 4303 = 10CF but all the codes are 2 digits. So I must be missing something here. Perhaps the command is in the payload ?

I would like to understand all the arguments device, command and payload.

I modified my code a bit to look more like the code on the page @JDRoberts linked to.

My code was doing the parse and the createEvent in one line and it turns out the parse is working. The createEvent is returning null and that was making me think nothing happened. But the logs show the event is completely processed it just doesn’t generate any result that needed to be returned. Basically the code I acquired from elsewhere was writing a warning to the logs that was confusing.

Thanks @JDRoberts for pointing me to that page. It helped out. I had found it before but kept assuming the warning was correct and that I needed to understand the parse more.

I am not complete clear on how this maps but the command 3105 parsed to 0x31 Sensor Multilevel so I guess the first two digits are the command in hex, not sure what the 05 represents but I am closing in on figuring it out in detail.


That’s correct the first 2 digits correspond to the command code. next 2 I haven’t figured it out yet but I think it may have something to do with the version of the command class.

The second parameter tells ST what version of the command class to use. By default ST uses the highest version of the command class it has (I say it has because ST doesn’t support all the latest versions, e.g. I think notifications has V5 but ST only supports V4)). However some devices only support older versions of the command class, so your limit what version you want ST to use to parse a response. This is also used in corresponding Z-Wave parsing handlers and commands.

1 Like

Could be because it’s sending the sensor multi level as V5 where as your parse is processing it as V3
You can verify with your device specs.

@RBoy thanks but looks like you didn’t read my last post. I solved the issue. It wasn’t the parse returning null it was the create event call. Which is normal for some events.


© 2019 SmartThings, Inc. All Rights Reserved. Terms of Use | Privacy Policy

SmartThings; SmartApps®; Physical Graph; Hello, Home; and Hello, Smart Home are all trademarks of the SmartThings, Inc.