I cannot figure out what I am doing wrong or how to work around this.
param is an Integer
Map args = [parameterNumber: param]
zwave.configurationV3.configurationPropertiesGet(args)
OR simply
zwave.configurationV3.configurationPropertiesGet(parameterNumber: param)
Results in:
groovy.lang.MissingMethodException: No signature of method: static hubitat.zwave.commandclasses.ConfigurationV3.configurationPropertiesGet() is applicable for argument types: (java.util.LinkedHashMap) values: [[parameterNumber:0]]
Possible solutions: ConfigurationPropertiesGet(), ConfigurationPropertiesGet(java.util.Map), ConfigurationPropertiesReport() on line 260 (method scanParameters)
Is this some sort of a bug with this method or am I doing something wrong?
The same exact things seems to work fine for other similar methods.
Example:
zwave.configurationV2.configurationGet(parameterNumber: param.num)
Ok I figured out how to work around that, had to call it a different way. The shortcut must not be setup properly.
void scanParameters(param=0) {
Map args = [parameterNumber: param]
def cmd = new hubitat.zwave.commands.configurationv4.ConfigurationPropertiesGet(args)
sendCommands(secureCmd(cmd))
}
Now when the hub gets the response back the parse function bombs out 
The 700F is the correct response which is a "Configuration Properties Report"
Not sure what input string it is complaining is "", the description string is logged right before and its clearly not blank. This same parse function works fine in this driver otherwise, and all my other drivers.
I can only assume the parse cannot handle
class hubitat.zwave.commands.configurationv4.ConfigurationPropertiesReport
Any way to work around this? besides breaking down each bit and parsing it manually?
@Hubitat_Staff ???
@Hubitat_Staff I think I got it now, I was sending a probe for param 0 per the zwave spec recommendations.
If I am reading this spec correctly the device seems to be sending back a proper payload but parse doesnt know what to do when the size is 0 (invalid param).
Payload for valid param:
00 01 09 00 04 01 00 02 00
1-2: Param reporting on
3: Reserved/Format/Size bits
4: min value
5: max value
6: default value
7-8: Next param
Payload for invalid param (I requested 14 which I knew was not valid):
Requesting 0: 00 00 00 00 01 00
Requesting 14: 00 0E 00 00 0F 00
1-2: Param reporting (14)
3: Reserved/Format/Size bits (0 per spec)
4-5: Next param
Per spec if size is 0 then the min/max/default should be skipped
@mike.maxwell I think this is your department? Any chance the issue in my 2nd/3rd post could be fixed? The original issues I ran into can be worked around but the last one is not so easy to deal with. For now if I start my probe with a known good parameter it works, but would be nice to kick it off with 0 as recommended per specs.
This is my area.. Checking into this now..
Found these issues.. will be fixed in 2.3.3
2 Likes
Thanks. See the driver I made using this? [BETA] ZWave Universal Parameter Scanner
