Does the Stock DH have the facility of finding out the Firmware number of the device? I have not been able to find it.
1 Like
most drivers don't (probably all) don't query for that data.
Is there any other way of getting it? or adding it to a driver
1 Like
Additionally the Z-Wave classes for those commands are not currently implemented.
def zwaveEvent(hubitat.zwave.commands.versionv1.VersionReport cmd) { logDebug "in version report" // SubVersion is in 1/100ths so that 1.01 < 1.08 < 1.10, etc. BigDecimal fw = cmd.applicationVersion + (cmd.applicationSubVersion / 100) state.firmware = fw }
Wouldn't Super Basic Zwave Tool (driver) be able to?
The AeotecMultiSensor6 driver I found and modified does detect and display the firmware value. 1.07 in that particular case.
State Variables
Status : Current author : cSteele InternalName : AeotecMultiSensor6 sensorTemp : 74.1 version : 1.3 Copyright : Ⓒ 2018 cSteele lastUpdated : 1537417637930 Type : Driver Version : 1.3 tempOffset : 0 lastbatt : 1536476832904 firmware : 1.07
1 Like
perfect, I was looking at a different class, yeah I can add it to SBZT, hmmm, that's not going to stick is it...
how many times per day do you need to know? 
I was thinking you could use SBZT the few times you hear of a new firmware upgrade.
In my case it's in the driver so I can just look when I need it. And I haven't needed it in 6 months 
til today to answer this question!!
What is everybody (is anybody?) using to upgrade firmware?
The only things i have been able to update is the Aeotec products and for that i just turn off the hub and stick the Z-Wave stick in my PC and run the software Aeotec provide, no excluding involved. But I brought a new Nano Dimmer and needed to know if it also needed an update before i put it into service. Where as the previous one was on ST and i knew the firmware value this one went straight on to HE and i don't know what firmware its on. But i didn't want to exclude it and put it on ST just for that 
@mike.maxwell if its a easy add is it something that could be added to the stock DH? Or am i missing something what is the SBZT, is that the new name for you z-wave tweaker? Has it been added as a stock DH?
EDIT: my bad its the same thing 
Hi @kilowatts,
My house is kitted out with approx 30 OSRAM Lightify bulbs of different fittings. About once a month I disconnect a bulb and pair it back to the official Lightify Gateway to check for an update.
Before HE the bulbs were connected to ST which whilst now supporting OTA firmware updates for OSRAM, you have to wait for ST to add it to their Hub update.
Mark
Rather than doing this why don't you leave one "connected" lamp per type to the Lightify gateway by doing a factory reset on the lamp once its joined, then you can just open the app and it will tell you if it needs a update. Then you can disconnected them and move them over, rather than doing it constantly.
Trust me, that would be so much easier, but the official Lightify Gateway and App are so slow and buggy that it's not worth it.
For example, approx 1 out of 5 times GU10 spots paired to the Lightify Gateway power on in a bright daylight white disconnected state and have to be repowered again. There's a few topics on this issue on Reddit.
Mark
you missed what I said. 1st this is what i do as i also have osram lamps and spots. 2nd dont leave it connected to the gateway leave it "connected" to the gateway, by that i mean connect it, then factory reset the lamp, so you can rejoin it to Hubitat. That way it will still be "connected" to lightify but will actually be connected to hubitat. You can then still open up the lightify app and see the device but it will say not powered but it will still keep its firmware information in the app, so it will let you know if its out of date. You would need to do this one per device type ie one spot and one lamp.
also if its connected to the gateway it allows you to select the power ON default setting so if its not standard (100% warm white) then you can just set the value and store it
1 Like
Oh yes sorry!
I see what you mean by "connected" now! What a clever idea I'll set this up tonight. Thanks for the tip.
Mark
1 Like
Even on the latest firmware the old bulb will power up in daylight white in a completely disconnected state. Initially I sent about 6 GU10 bulbs back to Amazon for replacement but the new ones do it too.
Have you ever had this?
EDIT: You won't believe this... I was making a quick video of the issue to upload here. Thankfully one of the GU10's lit up really bright and disconnected as intended, but I thought I'd leave the bulb on for a few minutes to see if it attempts to find a Hub. 10 minutes later the bulb has completely blown and is super hot. Warranty claim in progress...
Mark
Slightly off topic now but
Personally I would be happy with this as thats the state i would like! But in answer to your question, yes i've had some odd things happen to them when they were on old firmware, then I still had issues with one and it turned out it wasn't on the latest firmware even though it said it was! I was chasing it for ages and gave up then the other day when I moved everything to Hubitat I did a full factory reset on it and I swapped it and used my spare. I then lent it to my mate when I set up his system and it connected and said it had old firmware! It updated and its been fine.
I updated the tool, I don't think the version report returns the device firmware version, it appears to be more about the Z-Wave software versions.
I have more testing to do, but it looks like a good start:
dev:2852018-11-09 07:21:23.421 am infoVersionReport- applicationVersion:1.10
dev:2852018-11-09 07:21:23.419 am infoVersionReport- zWaveProtocolVersion:4.54
dev:2852018-11-09 07:21:23.417 am infoVersionReport- zWaveLibraryType:Enhanced Slave
--- Live Log Started, waiting for events ---
That particular log (above) is for a Aeon Multisensor6 that is at the latest firmware version of 1.10.
The next one is at v1.07, yet it reports as 1.7
dev:2802018-11-09 07:36:35.410 am infoVersionReport- applicationVersion:1.7
dev:2802018-11-09 07:36:35.409 am infoVersionReport- zWaveProtocolVersion:4.5
dev:2802018-11-09 07:36:35.408 am infoVersionReport- zWaveLibraryType:Enhanced Slave
// SubVersion is in 1/100ths so that 1.01 < 1.08 < 1.10, etc.
BigDecimal fw = cmd.applicationVersion + (cmd.applicationSubVersion / 100)
Yeah same here it does work though thanks @mike.maxwell
should be 2.02
[dev:589](http://192.168.1.81/logs#dev589)2018-11-09 15:51:10.895:infoVersionReport- applicationVersion:2.2
[dev:589](http://192.168.1.81/logs#dev589)2018-11-09 15:51:10.892:infoVersionReport- zWaveProtocolVersion:4.54
[dev:589](http://192.168.1.81/logs#dev589)2018-11-09 15:51:10.889:infoVersionReport- zWaveLibraryType:Enhanced Slave
