[RELEASE] Z-Wave Firmware Updater

Hello! This is me. I had a Zooz Zen27 that I flashed to a v2.03 firmware yesterday just fine, and now when I tried to upgrade to v2.08 I get the error about waking up my sleepy device. Flipping it back to its original device type I've discovered it's not responding to anything.

If I don't follow up, assume I've re-enrolled it successfully and the world is back to normal. You may want to add a step to the process where we verify it's still paired before flipping device types.

Thanks for putting this together!

FWIW, and I think this should be a sticky note someplace, Zooz devices must always be excluded and reincluded on a firmware update.

I'm not sure if its entirely by design, but the Zooz firmware updates effectively result in a factory reset, and they are essentially a "new" device.

S.

2 Likes

Maybe @danabw can put together a document for the Zwave firmware updater and all the quirks related to it :slightly_smiling_face:

A call for volunteers! A moment for me to shine!!

I tensed, poised for action, muscles like steel springs, and with lion-like grace and speed, lept two paces back.

So some dumb schlep next to me who wasn't paying attention got the job... :wink:

I've never used the FW updater (not sure if that's fortunate or unfortunate) so, at least for now, I'll humbly decline. Thank you so much for thinking of me. :smiley:

2 Likes

I'm trying to update some Inovelli LZW30 switches from the factory loaded 1.11 to 1.19 in order to disable the 700ms delay. I managed to get some of my switches updated on my PC using my Z-Stick, but get nowhere using the driver here, and would rather not go through the pain of excluding them and breaking rules I've already established on the hub.

First indication of an issue is that when I run the getVersionReport, there is no response (nor is anything reflected in the logs), but when running the latest driver code from Inovelli, I can clearly see the 1.11 firmware version being reported. When I try to actually update the firmware, I get the wake sleepy device error, but I don't think that's the issue considering I can't even get getVersionReport to provide any output.

This is on a C-7 HE running 2.2.3.145. My LZW30-SN switches had the same issue, but I was smart enough to get all of them updated before applying rules. I had no issues updating an LZW31 using this driver.

Some options:

  1. Include Z-Stick to Hubitat as secondary controller. Then flash from PC Controller software. You don't have to exclude/reinclude the switches from the Hubitat network.
  2. If you do exclude switches you can preserve the rules by following the instructions:
    Migrating a Z-Wave Network
  3. I haven't used it, but I think the "replace" button on the Z-Wave details page on the C7 will also work as long as you don't exclude the device from the Hubitat network before flashing

@bill.d Thank you! I will definitely give that a shot this evening! I'm new to Z-Wave outside of my alarm system, so have little idea of what is possible.

I did notice that the Inovelli driver has some logic using either applicationVersion or firmware0Version to obtain firmware version while this driver is using applicationVersion only. Could that be the issue?

No idea. I've only upgraded using the Z-Stick method.

I monkeyed with the Inovelli driver code enough to tell me which command is being used, and sure enough the switch is reporting its firmware version using firmware0Version, which tells me the switch is returning a null value using applicationVersion probably causing issues with this driver. @bcopeland do you think there is anything to this?

Inovelli driver code snippet:

def zwaveEvent(hubitat.zwave.commands.versionv1.VersionReport cmd) {
if (debugEnable) log.debug "${device.label?device.label:device.name}: ${cmd}"
if(cmd.applicationVersion != null && cmd.applicationSubVersion != null) {
def firmware = "${cmd.applicationVersion}.${cmd.applicationSubVersion.toString().padLeft(2,'0')}"
if (infoEnable) log.info "${device.label?device.label:device.name}: Firmware report received 1: ${firmware}"
state.needfwUpdate = "false"
createEvent(name: "firmware", value: "${firmware}")
} else if(cmd.firmware0Version != null && cmd.firmware0SubVersion != null) {
def firmware = "${cmd.firmware0Version}.${cmd.firmware0SubVersion.toString().padLeft(2,'0')}"
if (infoEnable != false) log.info "${device.label?device.label:device.name}: Firmware report received 2: ${firmware}"
state.needfwUpdate = "false"
createEvent(name: "firmware", value: "${firmware}")
}
}

I'm stuck on "Padding hex bytes" while trying to update the firmware of an Inovelli LZW36 switch according to Inovellis' instructions (.gbl file). What do you suggest? Can I abort without bricking the device? How do I get past that padding hex bytes?

From my experience with the same LZW36 problem, yes, you can abort. You really don't have a choice.

I tried that same update multiple times from Hubitat. Unfortunately, it just doesn't work (and it does not matter if you pair it with or without security - I tried). You'll need to use either the Z-stick method or some other system to do the update until the firmware updater is fixed (assuming the problem is in the firmware updater driver -- but maybe the problem is in the Hubitat main platform firmware and you'll have to wait until firmware 2.2.4 or later). I'd suggest just waiting until after the next Hubitat firmware update and try again, then do the Z-stick method if you have a USB Z-wave stick.

This is actually a pretty major update for the LZW36. Without it, the wall switch can lose connection with the canopy module. After I installed the LZW36 update, no more problems.

So, can I abort at this point without bricking it?

Yes, abort. You have no choice. From my experience, it will never finish the LZW36 update, even if you leave it for hours. If you look at the log, there's a code error that it doesn't recover from. Aborting is your only choice.

As an FYI - the Z-Wave standards (For those geeky enough to care, "Z-Wave Command Class Control Specification", Z-Wave Standard No. SDS14223, Version 9, Section 5.5) specify a command report to let the controller know that a firmware update aborted prematurely by the end user during the transfer. I understand this to mean that a firmware update can be aborted at any time -- i.e., the node doesn't actually attempt to do the update until the entire firmware file transfers successfully.

1 Like

Make sure you have the newer version of the updater. The first version you cannot use gbl files.

I can confirm that the LZW36 will not update with the newest version (V1.0.0) of the updater, but will update with "Z-Wave PC Controller" version 5 which is available for free from silicon labs (you have to sign up for an account) and need a USB Z-wave stick.

The basic update procedure that I followed using Z-Wave PC Controller (from memory, so I hope I don't get anything wrong) is:

  1. If the LZW36 is already jointed to Hubitat, first shut down Hubitat and unplug it
  2. Factory Reset the LZW36 -- instructions are in the user guide
  3. Start up the "Z-Wave PC Controller", then join the LZW36 to that USB stick
  4. Do the update
  5. Factory Reset the LZW36 again.
  6. Restart Hubitat
  7. Do a "repair" on the "old" device. The "repair" will fail, and you'll therafter see a "Replace" button
  8. Re-Join the LZW36 using the "Replace" button to start a re-pairing (inclusion) process.

Both of Bryan's releases are the same version number. He updated it in a hurry to get us all going for this switch.

This is the one I am using and it worked no issues.

https://raw.githubusercontent.com/djdizzyd/hubitat/master/Drivers/Z-Wave-Firmware-Updater/zwaveFirmwareUpdater-test.groovy

I tried the version on github about 3 weeks ago. Github says it was last updated 4 months ago, so I think I did try the latest. Note that I'm on the C7 hub and I think I was at version 2.2.3.119 when I last tried. There are a number of C7 hub issues that are being chased down, so maybe its a hub-version dependent problem.

yeah, that may be I have mine on the C5

So do I use that one (-test) or the absolute newest, which is named binaryUpdater? And what do I put for "target"?

See my post upthread that explains the different types of files handled by each version of the driver.

Each of those two posts explains the file types and issues.

1 Like