Hello, everyone.
I've noticed something lately with the response of a versionGet.
It used to be that the firmware version was:
applicationVersion.applicationSubVersion
Those appear to be null now and the correct values are in firmware0Version and firmware0SubVersion. Are they also supposed to be in the original location? Should we correct this in our drivers? Is this a bug?
I should probably tag @mike.maxwell.
You are correct. I noticed this yesterday in a driver I was working on. Took a look at my older drivers and they were all using the applicationVersion like you said.
Will wait on word before I start updating them.
The version class versions were extended, if you want the v1 report you will need to specify that version in parse, otherwise you'll get v3.
I have just noticed this too, and i get that we should be setting the version in the Parse, but in this case it still seems strange.
The only function i have for a version report is
def zwaveEvent(hubitat.zwave.commands.versionv1.VersionReport cmd) {
log.info("versionv1.VersionReport '${cmd}'")
}
And this appears now to been called with a hubitat.zwave.commands.versionv3.VersionReport object.
how can that happen ?
I assumed this would end up calling the catch all function as there are no functions matching the command
def zwaveEvent(hubitat.zwave.Command cmd) {
log.warn("Unhandled event $cmd")
}
All the other times i have put the wrong version in the driver (and i have done it wrong a few times 
) it ended up calling the catch all
Cheers
I think this was something that Mike did to minimize the impact it would have on drivers that didn't specify the version in parse. While I understand (and even appreciate) that in the short term it caused most of the drivers to not break (which is good) I'm not sure I like the solution long term. I would rather my version3 VersionReport hit my version3 method overload rather than my version1 method and just act differently.
Is this change going to be undone at some point, @mike.maxwell ? It feels a little messy and I think it will continue to get messier as the Z-Wave protocol continues to update the command classes to newer versions.
Also, at some point (if there isn't already) there is going to be a device across multiple firmware and command classes versions (or a device driver that handles multiple models across command class versions) and having version3 and version1 separated into different overloads (I think) is a much cleaner approach to handling them rather than riddling the code full of checks for firmware versions and handling conditions one-off.
If that’s the case, then I’m not sure it works, the V3 class doesn’t just have new properties, some existing properties have changed names, so it caused problems anyway
But I agree if this by design it feels a little messy
well we didn't make this up, this is how another platform deals with it, and we followed suite so drivers would be easier to migrate. Said other platform hasn't updated any of their zwave classes since before I was born, hence the issue hasn't cropped up over there (yet)...
It's pretty straight forward to identify and include the command class versions that your driver and device are expected to deal with, this is how all our built in drivers are written.
Personally I think the entire zwave schema sucks, however that's not going to get us any closer to S2 certification, which is what most of this class business is about anyway.
I agree that is pretty straight forward to include the command class versions you want. That part is nice. But how would you deal with the situation where you have a driver that spans two command class versions of the same command class? That's where the mess comes in.
I get what you are up against though. It's not something I feel strongly about so I'm not going to go to war over it. Especially if this is the way a certain other platform deals with it. Might as well not deviate too far. The similarity is one of HE's largest strengths.
not following, if you specify v1 of something in your parse options, then anything parsed (irrespective of what the device sent version wise) will be returned in the v1 class.
You can also send v2 commands (assuming HE and device support), but parse their responses as v1...
Nice
I don't have any tangible example or evidence of this being a problem. I don't know what I don't know. But in my mind it would be possible for a different version of a command class to have necessary information for a driver to function. For example and I'm making this entire example up, if a switch on firmware 1.0 used v2 notification to send some event (like double tap or something) and then a different switch or firmware 2.0 required of the same device used a different field of not-existent-yet spec v24 of notification in a field that doesn't exist in v2 to send the same double tap event.
I'm guessing in this very fake example that you would have to specify v24 in the parse, right? So, in that scenario, the new switch of firmware v2 switch would be parsed correctly and you could check the new field for the double tap event. But for the old switch in the same driver you would have to have logic to go check the old field for the event.
I guess I also don't really know what happens when you parse up a lower version to a higher version. Maybe you guys will handle all of that somehow and even if the firmware v1 was putting a notification at event 0, type 8 and the v2 firmware was putting it at newattribute 15 and another-new-attribute 3. Maybe the parse up will handle putting the old event and type data in newattribute and another-new-attribute.
Anyway, like I said, I'm not too worried about it. I don't want to pull you any farther down the rabbit hole.
Yeah, exactly.
Download the Hubitat app
