Can Hubitat determine the firmware version of a device


#21

What about zigbee :smile: just realised I also wanted to check my new spot lights.


#22

I didn't see anything in the spec that says I'm supposed to div the subversion by 100...

Application Version (8 bits)
Returns the Application Version and can have values in the range 0 to 255. The manufacturer assigns
the Application Version.
Application Sub Version (8 bits)
Returns the Application Sub Version and can have values in the range 0 to 255. The manufacturer
assigns the Application Sub Version.

So unless anyone can point me otherwise (as in a manufacture doc showing the subversion as a decimal), I'd rather display the data per the spec (which means I should remove the "." in the report), rather than presuming these two attributes are supposed to be concatenated into a decimal.


#23

I guess what we have is a couple of manufacturers that assigns sub versions in 1/100ths. I'll see if I can find the Aeon doc, but I'm not sure I'll be successful.

@ericm does a similar thing in his Multisensor6 (Advanced) driver...

def zwaveEvent(physicalgraph.zwave.commands.versionv1.VersionReport cmd) {
    logging(cmd)
    if(cmd.applicationVersion && cmd.applicationSubVersion) {
        state.rawFW = "${cmd.applicationVersion}.${cmd.applicationSubVersion.toString().padLeft(2,'0')}"
        state.needfwUpdate = "false"
        updateDataValue("firmware", "${state.rawFW}${getOverride()}")
        createEvent(name: "currentFirmware", value: "${state.rawFW}${getOverride()}")
    }
}

#24

so says the the driver reporting it this way...


#25

I do know that the latest firmware version from the Aeon site is v1.10 and I know that the previous versions were 1.06, 1.07, 1.08. Meaning for this particular device, I know what the answers are supposed to be.

The Aeon doc I found only reveals the command classes, no detail

COMMAND_CLASS_VERSION V2,

https://s3.amazonaws.com/cdn.freshdesk.com/data/helpdesk/attachments/production/6058085299/original/ES%20-%20MultiSensor%206%20V1.10.pdf?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAJ2JSYZ7O3I4JO6DA%2F20181109%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20181109T180259Z&X-Amz-Expires=300&X-Amz-Signature=7dd013b55038652602bb52bfbf54a23440c82f95ba085582a379378bb3b36706&X-Amz-SignedHeaders=Host&response-content-type=application%2Fpdf

And in looking that up, I was reminded there is a v1.11 for the EU ZWave version. And a HK version of 1.09

Plenty of indication for this one manufacturer, they treat sub version as 1/100ths.

Perhaps the best that can be done is to output the two fields and not concatenate them, let the human do the conversion based on "likely values." ??


#26

you could be correct, just making sure...


#27

I don't remember reading it in any official documentation, but the z-wave alliance shows firmware levels padded with two digits. If an application sub version is reported as 1 it is .01. If it is reported as 10 then it is .10.

I don't think it matters that much, but if you want what Hubitat displays to match what you see on manufacturers websites and the z-wave alliance website then padding it is the way to do it.


#28

I added some code to all my custom drivers to show the versions on Refresh and save it to State Variables.

Basically added this to the Initialize method:

state.zWaveProtocolVersion = "Unknown"
state.applicationVersion = "Unknown"

Added this method:

def zwaveEvent(hubitat.zwave.commands.versionv1.VersionReport cmd) {
	state.zWaveProtocolVersion = "${cmd.zWaveProtocolVersion}.${cmd.zWaveProtocolSubVersion}"
	state.applicationVersion = "${cmd.applicationVersion}.${cmd.applicationSubVersion.toString().padLeft(2,'0')}"
	createEvent(name: "deviceVersion", value: "zw: ${cmd.zWaveProtocolVersion}.${cmd.zWaveProtocolSubVersion}, fw: ${cmd.applicationVersion}.${cmd.applicationSubVersion.toString().padLeft(2,'0')}")
}

And this somewhere in the list of commands to be executed in the Refresh method:

zwave.versionV1.versionGet()

Very useful. Also tweaked my copy of the SBZT to save the version the same way for Devices using built-in drivers...


#29

When I shut down the Wink Hub recently, I decided to move some leakSmart sensors over to HE that were paired with the Wink hub, but I wasn't actively using. I noticed that @ericvitale 's driver is showing the firmware version, which is really nice because I don't recall being able to see it when I used to have them paired with SmartThings, and I could only see it in the Wink hub after a period of time has elapsed following paring. In HE, it show up immediately. Its the value listed after "application" in the screen shots below. That is indeed the correct firmware version number for each of those sensors.

Here's the link to Eric's driver code.


#30

I didn't think it was possible to write variables in there, I though this is populated from the data the device sends during inclusion regardless of the driver and maybe these devices are sending that... if that's the case then it would probably be static and not update after a device firmware upgrade like with ST...

Just speculating here, not an expert in groovy but I could not find anything in that code that does that.


#31

Well that's why I posted the code. I could look at it all day and not have a clue. SmartThings can't update the firmware for these if that's what you're referring to. Only the Waxman leakSmart bridge and the Wink hub can, but that's the reason I have two of them, and one doesn't have updated firmware. Was working with Waxman support for a few weeks to try and get this updated and they couldn't figure out why it wouldn't work so just sent me a replacement with the v35 firmware on it.

I'm not using the v21 sensor for detection. Just have it paired right now to see how long the battery would last when paired with HE, as that was the primary issue with the v21 firmware when paired with Wink and ST.


#32

No, what I meant is that ST does show these versions for every device but they query it during inclusion and save it in the fingerprint which is static, so if you upgrade the firmware in your device the fingerprint will continue to show the old version...


#33

Oh I see. Well that's not possible with these on ST. They are for sure the correct firmware versions as well. Had them paired with the Wink hub and it showed the same. They've only been paired since November 27. Both paired one after the other. The v34 firmware battery level is 100. The v21 is already 67%


#34

Ask them for new firmware, IF they send you the hex file you can upgrade them using the HomeSeer Z-Flash software... not likely they'll give it to you but does not hurt to ask...


#35

@mike.maxwell added device version polling to the Super Basic ZWave tool.

Can get confirmation that way I think.


#36

these are Zigbee sensors


#37

hahahaha.. what a noob mistake.. sorry. :frowning: I'll try to read more next time. :slight_smile:


#38

Lol, me too... yes the code I posted and the Z-Flash tool is for Z-Wave devices only, I do not have any ZigBee device...


#39

SmartThings can read the firmware level on demand when you use the 'Check now' feature for Zigbee devices in the SmartThings IDE.

Interesting... I had Waxman update my LeakSmart sensors last year (were at 21, came back at 34). I still have them on ST and notice that when I now look at them in the ST IDE that SmartThings now shows
Current Version: 0x00000034 / Target Version: 0x00000034. I'm quite sure that it used to say 'N/A' for target version. Seems like they might be enabling OTA firmware updates for these, if they haven't already. BTW, battery life with the 34 level is stellar; I got a full year after they were updated vs. the 3 month life with the previous version.


#40

Yeah there was a fairly long thread about this (probably you were part of) and how people were offering to send a Wink hub around to one another to get them upgraded, etc. But I recall the consensus (and Waxman confirmed) that ST could not upgrade them at the time. The guy I was working with thought that maybe Iris hubs could upgrade them and was really interested to find out, but didn't want to buy an Iris hub to test that :rofl:

I offered to send the v21 back to them, but they said no thanks and just sent me a new one.
Couple of things I like better about these vs the Centralite and Xiaomi is that they use AAA batteries, they beep and they have a light that flashes during an event. Would be nice to get that other one to upgrade to v34, but it doesn't want to go there. Not a big deal. The other sensors I have work fine.