V2.1.7.118 problems configuring z wave devices

đź“° News and Updates
1

Updated to V2.1.7.118 and now when I change a parameter on any z wave device it seems to send a random value to the device.

I changed parameters on a few devices and it’s caused all sorts of problems.
Restored to V2.1.6.118 and re-configured the devices and all is ok again.
Anyone else noticed anything strange ?
I did notice there seems to be a new basicset version 2 which wasn’t mentioned in the notes ?

Cheers

2

Basic Set v2 and Central Scene v3 were both added in 2.1.7, but I was told they weren't added to the release notes because user-perspective and even developer-perspective behavior is the same (it defaults to the previous versions unless otherwise specified in your call to zwave.parse).

I haven't noticed any problems like the above. Is this any device or just particular ones? Stock drivers of custom drivers? Does the Basic Z-Wave tool from Hubitat give the same results for the same devices? (If it's a custom driver, maybe they're doing something wonky...)

3

It was a home made driver for the first version of the fibaro motion sensors, couldn’t get them to work with any other one.

There is nothing passed to the zwave.parse function but now it calls basicset v2 instead of v1 so it failed as the function didn’t exist. So doesn’t appear to default to V1 if that’s what it’s suppose to do.

It was the same driver which appeared to be corrupting parameters with V2.1.7.118 but as no one else is having problems it must be something I’m doing, will try v2.1.7 again this weekend and see If it still happens

Cheers

4

If the default changed from basicset v1 to v2 it will break many drivers, I expect.

If that is indeed what is happening, that is likely a bug and/or specific to just some hubs.

I'm not seeing any obvious issues with my zwave devices on the new release, including with user drivers that I know don't have basicset v2 functions defined.

I'll look closer/some more though.

@mike.maxwell

5

I know you have an Aeotec Doorbell 6. I'm hoping you can take a look at this:

6

Unfortunately I only have the siren 6, not the doorbell button.

1 Like
7

yes basic v2 is now supported, however explicitly specifying v1 in the parse is not required, if the driver doesn't have a v2 method implemented basic v1 will still be returned, as you've noticed.

And yes, if it didn't do this, all sorts of things would break...

1 Like
8

Sorry, my mistake.

1 Like
9

Sorry just to confirm, I’m still new to all this.
There was nothing passed to zwave.parse but it didn’t have a v2 method defined so are you saying it should have called the v1 method and not ended up calling the catch all method ?

Cheers

10

I'm not Mike, but I play one on TV....

I believe what he is saying, is that if you do not specify a command version to use in the driver, it will/should use the system default for that command. And the default for basic is still V1 - which it probably always will be (unless it is deprecated someday).

For instance:
def cmd = zwave.parse(description, [0x20: 1, 0x25: 1, 0x56: 1, 0x70: 2, 0x72: 2, 0x85: 2])

I am explicitly specifying basic version 1 (because I'm a weirdo and always specify versions for commands), via 0x20:1. However, that should be the exact same as doing this:
def cmd = zwave.parse(description, [0x20, 0x25: 1, 0x56: 1, 0x70: 2, 0x72: 2, 0x85: 2])

If you wanted to use basic v2 for some reason, you would have to explicitly call it like:
def cmd = zwave.parse(description, [0x20: 2, 0x25: 1, 0x56: 1, 0x70: 2, 0x72: 2, 0x85: 2])

3 Likes
11

Thanks for the explanation! Really appreciate it - learned something new.

1 Like
12

Ok so I had this

    // Standard parse to command classes
    def parse(String description) {
      def cmd = zwave.parse(description)
      if (cmd) {
        logDebug("Parsed '${description}'")
        return zwaveEvent(cmd)
      }
      logDebug("Failed to parse '${description}'")
    }

    // Standard catch all
    def zwaveEvent(hubitat.zwave.Command cmd) {
      logDebug("Unhandled event $cmd")
    }

In the last version it called v1 in the latest it called v2, so should you always set a version in the zwave.parse to ensure it is consistent ?

Cheers

13

I would have expected it to call Basic v1 in that code. If it isn't then I'm confused I guess / need to test that.

It calling Basic V2 would not be how I would expect it to function based on that zwave.parse line. Am I in the ditch (again) Mike? @mike.maxwell I may be...

In the ST documents it says:

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:

If that is what is happening, then I am backwards in what I said above... :confused: Sorry if I caused any confusion... How ST describes it working is more consistent with the behavior you are seeing... Since I always specify the version, I may have remembered wrong.

EDIT: I deleted this because I think it had some incorrect info, and I don't want to confuse the discussion.

But I reserve the right to be completely wrong. I won't be in front of my hub to check until probably tomorrow.

That said, explicitly telling it to use 0x20:1 would/should fix @entire issue, too.

1 Like
14

Yes I did appear to be doing that, which would explain it, surprised more people haven’t seen some issues though

Cheers

16

please post the entire driver you're dealing with here...

17

Here it is

18

I get a 404 on that link

19

yes link has put some extra characters (25) around the spaces, not sure how to remove them. they are not there in the link when i edit it

20

https://raw.githubusercontent.com/entire-mike/hubitat/master/drivers/Fibaro%20Motion%20Sensor%20FGMS-001.groovy

21

thanks :+1: