Does SmartThings fully support the ConfigurationV2 bulk operations?
I’m getting:
Parsed ConfigurationBulkReport(defaultValue: false, handshake: false, numberOfParameters: 10, parameterOffset: 1, reportsToFollow: 0, reserved31: 0, size: 2)
after asking for 10 parameters starting from parameter 1… that is the first and only report parse… and it indicates no reports follow…
Just curious… seem to be hitting a wall here.
Tagging @duncan @jody.albritton
Did you match this format?
https://graph.api.smartthings.com/ide/doc/zwave-utils.html#configurationV2
Yeah… I said start at offset 0x0001 (16 bit value as sigma defines it) and give me 10 parameters… I’d expect that to iterate through 1…10 but instead I get the output I see. I may be just misunderstanding the use? The configuration parameters I’m trying to get start at 1 and end at 10…
I wouldn’t recommend using ConfigurationBulkGet.
Very few device manufacturers have properly support this command and its not tested very well with the Z-Wave certification tool.
If you only need 10 parameters I would highly recommend just getting them one at a time using the normal ConfigurationGet command and stick to V1 if possible.
What device are you working with?
I’m trying to rethink / reinvent the way configurations are done in SmartThings. The problem with the current paradigm of handlers is they are very much “fire and forget”. I am trying to implement a full configuration polling, storage into a state array and compare with user preferences. If anything doesn’t match up then the specific parameter that doesn’t match will be updated. This is especially important for battery operated devices but handy for any. It would be nice if device preferences could be updated programmatically but that is a protected area. This will be a one direction feature then. I’m working currently in the zooZ mini plug. It has a lot of configuration parameters and not just trivial ones. Thus it can be somewhat unreliable send He and receiving so many parameters. Typically on my mesh at home I have to do my read command block which sends a configuration get times a half second apart for each of twelve parameters, two to three times to catch all of the parameters. It’s not just this device though, it happens like that for several. Even something like turning on a light isn’t always 100% successful because there is no state checking post command. The idea is an adaptive handler that just keeps trying and testing until the user specified command succeeds. The miniplug is one of a few devices I’ve seen that supposedly support configuration bulk commands. At this point I’m not sure if it is a platform issue or a firmware issue in racing. I may check using my Aron z-stick if I’m actually sending and receiving the real deal. I’m pretty sure SmartThings isn’t really supporting it yet either though. The documentation folder the class from Sigma is pretty straightforward and easy and is why I was wanting to use the class.
Sorry for the novel…