Far too often I'm trying to figure out what version of firmware and hardware I have when looking at devices.
Two suggestions here:
Update all internal device drivers to capture this information in standard variables
Strongly suggest this as a driver functionality for all community drivers, with updated templates that include the code.
I am aware that there are drivers I can temporarily change to for this ask, but the point is to NOT always have to swap drivers to get 'standard' information.
Alternatively, I haven't found where I can do this "universally" -- maybe it's something that is queried for all devices under zwave information. It'd also be useful there to understand a list of devices that need a firmware update.
Maybe a community app can handle this. I'm not intimately familiar with Z-Wave specifically so I'm not sure that there's a universal command implemented that could support it.
@jtp10181 I see that you use this in the Zooz drivers:
Do you know if those commands are universally implemented or if they are optional for the vendor to implement? I realize there's more to the function, just the first thing that caught my eye.
As I understand it that's a standard command. There are a few community drivers that allow you to query devices of all types. I could be wrong on this part, but "where the decimal goes" seems to vary, and I don't think 100% of devices have "hardware versions" available, but firmware seems to from all I've read.
So, you're pointing out why this couldn't be done globally . If there's nuance at the device level, there's not much that can be done at the hub level outside of making some "best guess" logic like assume that firmware ###### is actually ##.##.## and stuff like that.
Either way, I'm sure an app can be written to iterate through the devices, issue the command, and provide the response in a singular table.
I already attempted to make such an app if you have seen the "Zwave Tweaker" driver, I was going to make it into in app. I managed to figure out how to send a command to a device from an app but there is no way possible to capture the reply back according to Hubitat devs. The devices driver would have to know what to do with the response. The only app which does this is the firmware updater and it uses some backend stuff not available to user apps.
The only option would be to have a driver that does it, switch to it, then switch back. I think my Z-Wave Universal Scanner has this built in for firmware and possibly serial number when you do a "Get Info".
Its not so much of where the decimal goes, the firmware is reported as two values, the Version and the Subversion. So the decimal goes between them. The confusion comes in for the Subversion which is presented as a whole number but should be 0 padded. All the devices I have seen use a firmware format of ##.## where the subversion is two digits so if a single digit subversion comes in, padding it with a 0 in front makes it correct. I would have to check the zwave specs to see if they give specific details for these values or not.
Sounds like even more reason it would be ideal to present this at the system level or in all base driver templates.
If something doesn't implement it, as I gather, it just doesn't return something or may return an error... (eg, hw version isn't present, but firmware version is, still should be able to figure and parse.)
Alternatively, as part of a base system thing, always present to use the "backend stuff" -- sounding like someone with internals knowledge needs to chime in.
For Zwave I believe all devices should supply a hardware version. Most of the commands like that the spec states the device MUST reply back with a report. It might be bogus (Zooz for example I think always sends the value of 1 back), but it will give you something.
Also worth noting, many of the system drivers just take the Subversion returned and do no formatting at all, they just join the version and subversion with a decimal. So 1.01 comes out as 1.1. Somewhere there is a thread where people were arguing with me about it saying technically both are correct.
This isn't really a thing. I'm going to assume most are like me where each dev generates their own "template" and iterates on it. That may or may not be generated based on another working driver.
That makes perfect sense. I presume that if the driver doesn't have a parse method for that specific command class (is that the right terminology) then it'll just drop the response. It would have to be captured at the driver level as an event that the app could subscribe to.
Yes but it may or may not just drop it. Some will log the report (often debug logs).
Better yet would be saving it in a standard place in the device Data so that an app can read it. I have done that on all my drivers, using the same name as system drivers for the firmwareVersion. I also added a model number in there. You can use the user app device info display (I think thats the name) to read it all and export to a CSV file.
Just because something is done a set way doesn't mean it is a best practice. If we as a community provide a template, maybe we can adopt standard namings. It also is great for somebody entering into the "dev space" for Hubitat. I thought I saw some example stuff in docs I read, but having something inclusive of this functionality in docs or available to download would be awesome. Back to this being a FEATURE REQUEST, who can do that from the Hubitat team or argue against it?
^^ This. Another point of making things more new-user friendly -- it took me a while to understand this (and why I couldn't find a version that was being discussed) but we should encourage in practice a padded version of concatenated major/minor values then.
Agree. And, encouraging this behavior, and getting the Hubitat team on board with selecting a name and putting it in internal drivers IS how we can drive consistency. If there's not a standards body that drives it, then an emerging quorum for a platform is just as good as a convention.
So, your expectation is that Hubitat puts out templates and that every dev goes and grabs that template and updates every driver they've created. Will never happen. Most also aren't going to go hunting for templates if they write up a new driver either. They're going to find a driver that does something similar to what they want, and modify that code. Or use it as a template to follow.
I'm not trying to be a naysayer...I'm just trying to point out the reality that it's not going to work like one would hope.
Yes, good, bad or indifferent unfortunately. Some of the user created apps and drivers have down right scary code that hurts my brain and I am scared to install it on my hub.
Hehe, yes, I know it's not realistic that we'll always have good code, nor people trying to adopt a standard. I wasn't tryin to shoot the messenger or yell at you about it, sorry if it was a 'statement' lol.
Just trying to move the ball forward. I'll see what I can identify and propose a template. I'm one of those 'novices' right now, not having written for hubitat. So, I'll gladly take both your input.
If you want to do Zwave drivers I have a pretty good template by just picking a similar device from one of my drivers and then customize it for whatever you want, although slightly complex the way I deal with the parameters. There is a slightly more generic one as well, but it has improved logging options. My core code is always evolving.
The real lemon to squeeze would be writing a script (python, PS, bash, pick you poison) to generate parametric drivers. Feed it what the possible device configs are through variables and whamo!
. If there's nuance at the device level, there's not much that can be done at the hub level outside of making some "best guess" logic like assume that firmware ###### is actually ##.##.## and stuff like that.
sadly.
.
