Super basic Z-Wave parameter tool

🚧 Developers
81

I used to have a lot of that. Somewhere you have a device that doesn't repeat well or a hop that is too far and won't repair (or can't repair for lack of a repeater) or too much load on the hub (and responses are too slow and the sending device freaks out because it doesn't get a response back in time).

You can sometimes find the offending device(s) by spamming on/off and watching the results. Hopefully you're primarily working with devices that support on/off. Turn on descriptive text logging for the devices. Then I would start turning a device on/off every 3 seconds and then get gradually faster until you are doing it 2 times or so a second. If the mesh isn't stable you will start seeing descriptive text logs repeated.

If it tends to happen with almost every device it is probably a device that was added near the very beginning of all of your devices or one that is very close to the hub and handles a lot of routes.

Another thing I've found is that older Z-Wave devices tend to show the "freak out" much more commonly than Z-Wave+ devices. I'm guessing it's because Z-Wave devices just panic and try alternate routes with the same message that failed where Z-Wave+ devices send discovery frames instead which don't ever show up in the logs. They probably both generate a lot of traffic though.

If that doesn't yield any results you can start sniffing packets to see what is really happening.

1 Like
82

Thanks - that sounds like great advice....
I'll start working on that technique.
If I can't find anything, it's out with the UZB stick to start zniffering around!

85

@mike.maxwell Thanks for the reference. I will pause all automations overnight to see if that can repair the network.

1 Like
86

When I try using this tool, I get an error in the log:

[dev:1](http://IP/logs#dev1)2020-08-13 11:54:53.737 am [error](http://IP/device/edit/1)groovy.lang.MissingMethodException: No signature of method: user_driver_hubitat_Basic_Z_Wave_tool_579.zwaveSecureEncap() is applicable for argument types: (hubitat.zwave.commands.versionv1.VersionCommandClassGet) values: [VersionCommandClassGet(requestedCommandClass:37)] on line 137 (getCommandClassReport)

I'm not sure what would be causing this. Has anyone else seen it?

87

what platform version are you running?

88

2.2.2.129

89

the current posted version requires platform version 2.2.3, you can fetch the previous version via this link:

90

I upgraded to 2.2.3, now I get a different error:

`groovy.lang.MissingMethodException: No signature of method: user_driver_hubitat_Basic_Z_Wave_tool_579.getCommandClassReport() is applicable for argument types: (hubitat.zwave.commands.versionv1.VersionCommandClassGet) values: [VersionCommandClassGet(requestedCommandClass:37)]

Possible solutions: getCommandClassReport() (getCommandClassReport)`

91

I'll have a look at that.

92

I re-copied the code and that error went away; now I just don't get any output, but that's an improvement.

93

i just updated this again, as well as did some testing, works properly on c5 and c7 no matter the platform version.

4 Likes
94

I exclused and re-included my device and it works now. Thanks for the help!

95

Is it possible to add the importUrl parameter to the driver? It would be helpful for updating.

4 Likes
96

Using latest driver on latest code for a C4 Hub, I am trying to read and set parameters on a Greenwave 6-Outlet Power Strip.

I should be able to read and set paramaters 0, 1, 3, and 4, and read parameter 2.

But the sizes of these parameters are not defined anywhere, #2 gives me a negative value, (-127, so 0xb1111111) when it should read "1", and #3 and #4 do not respond at all when read. The Z-Wave tool is reporting the size of the response, so I assume that this is the proper size of the parameter.

Now, the only parameter of interest here is #0, as it is claimed to be a setting that will prompt the device to send a notification upon a current draw change of "x" percent, where the value set is the (base 10) percentage. No matter what setting I set, nothing happens when loads are turned on and off in an attempt to get reports. Using the "refresh" of the driver that we have does get one data that seems reasonable, but I'd rather not be polling the power strips.

This same Z-Wave tool worked fine with other devices, so I am wondering what I don't understand about this specific device, and how to set parameters.

There are 10 kinds of people out there:

  • Those who can work in binary
  • Those who can't
  • Those who did not consider base 3

=-=-=-= Log Snippets Below =-=-=-=-=-=

dev:3112020-08-21 11:32:51.834 am infoConfigurationReport- parameterNumber:2, size:1, value:-127

dev:3112020-08-21 11:32:48.726 am infoConfigurationReport- parameterNumber:1, size:1, value:20

dev:3112020-08-21 11:32:43.969 am infoConfigurationReport- parameterNumber:0, size:1, value:10

97

-127 decimal = 10000001 binary
Perhaps something is happening in the high bit.

98

I guess I am getting too old for this sh*t.

I would have thought 0xb 10000001 was 129...

Whatever, I have some sort of failure to comprehend sumthin or other.

99

It is for 8-bit unsigned (0..255), but is -127 for 8-bit two’s complement signed (-128..127).

There’s also one’s complement, but I haven’t used that since the PDP-1.

As you said,

100

Do these things USE 8-bit two's complement????? Is that the assumed standard?

PDPs... when my switch register callus at last disappeared sometime in the early 1990s, I knew that something very basic had changed.

1 Like
101

In most cases, if a signed value is needed, yes. If a signed value is not needed, then typically no - although I have seen some developers use two's compliment for all variables whether they were needed or not.

102

Then the driver is not reading the value as I might have hoped, as there would be no negative value possible for these parameters.

That's a clue... the 'basic z-wave tool" isn't quite basic enough, it seems. :slight_smile: