Using the @bcopeland firmware updater on hubitat, I tried to update one of my LZW30 switches to 1.17
The update had started, but sleepy device blocked my progress.
I’ve pulled the air gap and the switch manually works, but it’s not responding via hubitat. Last command still shows 3:14pm yesterday afternoon.
Comments suggest, “as long at the firmware updater is showing a version number when you click check version, then the switch is online”, I’m not sure about that. I’ve switched from the firmware updater driver back to the GitHub driver and back to the firmware updater and without clicking buttons, the version still shows, like it was cached from a previous request. There is no indication for how recent that response was
I think my problem sounds similar to this post, but that post is left without any resolution
But i can’t seem to find a reference anywhere on how to reset a failed firmware update. Most of the references seem to suggest that all I need to do is pull the air gap and the switch will come back online. This isn’t working for me.
Yeah - that was my post. Pulling the “air gap” switch brought my switch back to life and also back to working in Hubitat. I gave up on updating the firmware on that switch thought the tool worked for the LZW31-SN switches that I have. If the switch is not responding from Hubitat, you may need to exclude/include it again. But before you do that, you may want to try a couple of things:
When switching back to the Inovelli drivers, did you hit “configure”/“save preferences” and also “save device”?
When using the Z-Wave Update driver, keep a live log window open and hit “refresh”. You should see the version in the live log.
If you are getting a “locked” by message - hit the “clear lock”.
Hope this helps. If you can control the switch manually, at least the switch is not bricked…
Zwave excludes/includes and factory resets and damn sleepy devices are driving me nuts. I’ve successfully upgraded one of my ten switches. My second switch is right next to the first switch and it keeps yapping about sleepy switches, damnit - I just included and airgapped the switch, and checked the version before I started the firmware upgrade, how is it already asleep (I’m about 10 feet away from my hub). Seems all my switches are 1.9, well I’ve is now 1.17. pretty sure several of my hubitat rules are going to be hosed.
I’m thinking I might need to reboot my hub. All my other Inovelli seem to be slow on the double click response and I haven’t even tried to touch any of them yet
Reset didn’t change anything. I’ve got a zwave repair running at the moment.
For now, I’ve moved onto a different switch.
I’m wondering if I need to move my hub upstairs, so that it’s closer to this switch. Without doing an air gap pull, I’m reliable able to initiate an upgrade, but it’s stuck at 0% with error logs showing a repeating message
dev:495 2020-07-02 07:32:41.687 am debugGot request for fragment #:1 packing report and sending
[dev:495](http://192.168.86.34/logs#dev495)2020-07-02 07:32:29.674 am [debug](http://192.168.86.34/device/edit/495)Got request for fragment #:1 packing report and sending
[dev:495](http://192.168.86.34/logs#dev495)2020-07-02 07:32:17.679 am [debug](http://192.168.86.34/device/edit/495)Got request for fragment #:1 packing report and sending
[dev:495](http://192.168.86.34/logs#dev495)2020-07-02 07:32:05.686 am [debug](http://192.168.86.34/device/edit/495)Got request for fragment #:1 packing report and sending
[dev:495](http://192.168.86.34/logs#dev495)2020-07-02 07:31:53.682 am [debug](http://192.168.86.34/device/edit/495)Got request for fragment #:1 packing report and sending
and eventually seems to timeout as the switch stops blinking
I have followed those steps. I’ve had better success if I push the air gap back in when the status shows “requesting device to start” or something, just before it says “wake sleepy”. Most of the time it just goes to “accepted” and then starts uploading, but I consistently fail to upload, always stuck at zero percent and eventually the switch times out and stops logging “Got request for fragment #:1”
One of my switches, I don’t have to air gap, it just goes directly to accepted and uploading.
The one switch that uploaded past zero percent was my only switch to complete the 1.17 upgrade. It does or did take many minutes to complete the upload.
The only switch of mine where it failed once during the download was the furthest switch from the hub, however the second attempt worked. I figured it was due to the distance and hops through other devices. I had another that wouldn’t start just kept complaining about sleepy device but i tried it again the next day and it worked fine. All the others updated on the first try.
My switch didn’t even need an air gap pull to get to “accepted request, starting upload”. This switch didn’t need an air gap pull when the hub was downstairs. It was pretty reliable about getting to the upload step.
But my switch never makes it past " firmwareUploadPercent : 0%".
After several minutes, the switch stops blinking as it’s given up on the whole process.
I tried to load firmware a dozen times yesterday, never made it past zero percent.
Eventually, I factory reset and excluded, then included the switch. This didn’t really change anything, I still didn’t need an air gap pull to get to the"accepted request" , but I also still kept getting stuck at 0%.
This morning, I tried to air gap the switch. Maybe the airgapped switch was critical to the upload process. But this hasn’t helped either. After three or four attempts this morning, I can still reliably get to “accepted request, starting upload”, but the switch never progresses beyond 0%.
I tried a few other switches yesterday, I haven’t tried all of my Red LZW30’s, but I think I’ve tried most. To date, only two of my ten Reds have upgraded. I have another two dozen GE or HomeSeer or Innr or other switches and plugs and sensors.
I was excited that the payload changed in that last log message (the top most of entry in the list), but that was the last log message and the switch stopped blinking.
Tried to use @bcopeland’s test version of the firmware updater and this error was added to the output
[error](http://192.168.86.34/device/edit/897)groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Integer#multiply. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] on line 148 (parse)
In regular repeating fashion
[dev:897](http://192.168.86.34/logs#dev897)2020-07-05 07:58:32.224 am [debug](http://192.168.86.34/device/edit/897)skip: SwitchBinaryReport(value:0, targetValue:0, duration:0)
[dev:897](http://192.168.86.34/logs#dev897)2020-07-05 07:58:32.203 am [debug](http://192.168.86.34/device/edit/897)parse:zw device: 41, command: 9881, payload: 00 25 03 00 , isMulticast: false
[dev:897](http://192.168.86.34/logs#dev897)2020-07-05 07:58:18.591 am [error](http://192.168.86.34/device/edit/897)groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Integer#multiply. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] on line 148 (parse)
[dev:897](http://192.168.86.34/logs#dev897)2020-07-05 07:58:18.571 am [debug](http://192.168.86.34/device/edit/897)Got request for fragment #:1 packing report and sending
[dev:897](http://192.168.86.34/logs#dev897)2020-07-05 07:58:18.559 am [debug](http://192.168.86.34/device/edit/897)parse:zw device: 41, command: 9881, payload: 00 7A 05 01 00 01 , isMulticast: false
[dev:897](http://192.168.86.34/logs#dev897)2020-07-05 07:58:06.611 am [error](http://192.168.86.34/device/edit/897)groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Integer#multiply. Cannot resolve which method to invoke for [null] due to overlapping prototypes between: [class java.lang.Character] [class java.lang.Number] on line 148 (parse)
[dev:897](http://192.168.86.34/logs#dev897)2020-07-05 07:58:06.594 am [debug](http://192.168.86.34/device/edit/897)Got request for fragment #:1 packing report and sending
Thus far, I’ve upgraded three of my ten switches.
The remaining seven, all fairly reliably, without requiring the airgapped to be pulled, will get to the “accepted” stage, but never progresses beyond 0%.
