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.
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...
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.
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.
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.
If you do exclude switches you can preserve the rules by following the instructions: Migrating a Z-Wave Network
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?
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?
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.
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.
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:
If the LZW36 is already jointed to Hubitat, first shut down Hubitat and unplug it
Factory Reset the LZW36 -- instructions are in the user guide
Start up the "Z-Wave PC Controller", then join the LZW36 to that USB stick
Do the update
Factory Reset the LZW36 again.
Restart Hubitat
Do a "repair" on the "old" device. The "repair" will fail, and you'll therafter see a "Replace" button
Re-Join the LZW36 using the "Replace" button to start a re-pairing (inclusion) process.
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.