yeah, that would work - just explicitly set both bytes...
I was suspicious of this when I noticed the issue occurred at the 1 byte to 2 byte boundary. 
I can confirm this worked.
As an aside: Since the Aeon/Aeotec Multisensor is an officially supported device with it's own official built in driver: Could we get support for changing the motion sensor timeouts directly via the official device driver, without having to use this "advanced" Z-Wave Parameter tool? The motion timeouts are a pretty basic setting that a lot of folks might need to change and not everyone is going to have the technical know-how to set up this tool and figure out the parameter numbers, size, values etc. It looks like Aeotec has a published Device Handler on Github that supports all the config parameters that they probably wouldn't mind Hubitat copying from. I was looking at porting it but it would be great if those features could just be added to the built in driver.
Just a suggestion / my two cents.
Thanks for helping me get this sorted!
-Jeremy
2 Likes
I went back and looked, and I've actually found a few places in my drivers where this issue breaks functionality. Obviously I can re-do the driver to work around it, per above.
Any thoughts on when the fix is going to come, though? I'm surprised, there are more devices that use size: 2 for small values than I thought.
Is there any further update on being able to define associations?
Not at this time. We've talked about it, we don't have a presentation layer for this currently, right now it's not on the to do list.
I changed my Fibaro Dimmer 2 to the Basic driver. The first time clicking Get Parameter Report I got info i the log. But after that, no matter what parameter I try to view nothing showed up in the log.
Does anybody know what Im doing wrong? I have tried to switch back to Fibaro and to the Basic again, but still same.
If you run it with no parameters it will run against all possible parameters from 0 to 255 which could overwhelm your mesh. Try changing the getParameterReport method to this which adds a short pause in between each request:
def getParameterReport(param = null) {
def cmds = []
if (param) {
cmds = [secureCmd(zwave.configurationV1.configurationGet(parameterNumber: param))]
}
else {
0.upto(255, {
cmds.add(secureCmd(zwave.configurationV1.configurationGet(parameterNumber: it)))
})
}
return delayBetween(cmds, 500)
}
Also, you could run it at one known parameter just to make sure you're getting back a single parameter report. Alternatively, you could put in debug print outs to see if it's getting through the loop, etc.
I havent tried that. I have always tried with a paramterer number.
I noticed my HE run a bit slow in RE so I have just rebooted my HE (power off and removed the plug for a short time) so I will try again soon.
[UPDATE] Same after reboot. I got a read out the first time but every parameter after that isnt showing up in the log. Not even the when using the same number as the first which showed up in the log.
What if you query a different device? Maybe the Fibaro has rate limiting and doesn't like to be asked too often? I looked over the code and I don't think it would be a problem there. You can confirm by adding the additional outputs to see it getting through the loop if you want.
I would suspect that the device or the mesh is to blame if you still see issues after you put in debugging and the delay between.
I started with the Strips Guard, that behaved the same, but switched to Fibaro since I thought its a more “known brand”. Will try some other devices and see.
Nut I find it starnage that I get a response the first time but not when trying again with same parameter.
[UPDATE] Just tried a Fibaro wall plug and that one is responding all the time. Very strange. Seems to be a deivce issue...
[UPDATE (again)] My Telldus switch is also reporting on every parameter check.
It's not super strange if the device isn't really a repeating slave. I don't know what that one is but if a device is meant to sleep it might report and then go radio silent to conserve battery or energy. Maybe Fibaro didn't implement that one as a repeating slave and it's the other profile that sleeps.
Who knows. Do you know if there is a hardware button to wake it up?
The Fibaro Dimmer 2 should act as a repeter since its wired, or?
The Strips Guard is a battery contact sensor so I guess its not a repeater.
Yes. Pretty much all mains powered devices are repeaters. I say pretty much, as some devices that can be battery OR mains powered don't repeat even when mains powered.
The Dimmer 2 definitely SHOULD respond correctly with all parameters. I have several of these devices, and Get Parameter Report does work.
I have had occasions in the past where a couple of devices (I don't remember if they were Fibaros or something else) would respond erratically to the command. I don't really remember what I did to solve the issue, but if you haven't already, you could try power cycling the device, and if it's still not working, try to exclude/re-include the device.
Question.
When producing the Configuration Report, is it normal for the report to repeat lines for some of the parameters?
no, this is not not normal.
it could be the device is having some communication issues with the hub so commands to and responses from are being sent/received multiple times.
What could I do to correct this problem?
we have a best practices document for zwave mesh setup, I might have a start there.
https://docs.hubitat.com/index.php?title=How_to_Build_a_Solid_Z-Wave_Mesh
2 Likes
Ouch.. That’s a lot of repeats.. No wonder you think zigbee is faster 
