Well I finally did it. Sigh. I am upgrading dozens of switches using the Hubitat driver method and I put LZW31-SN firmware (version 1.47 beta) onto an LZW30-SN switch. It installed quite happily, the switch turned off to restart following the flash, and now it’s totally dead.
Buttons do nothing, hub can’t talk to it, the LED does nothing, not even after an air gap reboot.
Sorry that this happened to you . Which version of the driver (updater) were you using? The latest version does both, the .otz and the .bin file but has less validation (as @bcopeland warns), so maybe that could be the difference. The airgap pull worked for me…
Thanks for the link to the thread, @Bry and the info, @rakeshg.
I am using the Binary Updater (the new one that supports multiple targets). I think the difference here and with what you experienced in the other thread is that my firmware update completed successfully. (EDIT: also, that I did a cross-model firmware application)
I fear I may have murdered it. It’s just totally off the network and doesn’t respond to physical commands. I can’t see any way to get it back short of cracking it open and somehow doing a firmware replacement right on the PCB or something like that.
Thanks. I tried changing the driver back to the Inovelli driver and resetting it but no dice. This is not very surprising to me, since after being air-gapped the switch no longer appears to even boot.
@EricM_Inovelli@Eric_Inovelli -Is this something you can ask the firmware engineers about adding a checksum to the firmware so users can’t inadvertently upload the wrong firmware?
Hmmm? Checksums are used to verify that the data has not been corrupted (usually during the transmission to the target). I can’t imagine there wasn’t a checksum already in place. It would be pretty risky to transmit firmware to a device without some data integrity check before writing it to flash.
Anyway, I’m not sure this can prevent you from writing data to the wrong device.
Yep, the hash would change with each firmware release, so can’t just store and compare. You’d have to store the model number in ROM on the switch. The application used to flash would have to read it and compare. That would require an application specifically designed to flash these switches.
Ah yea. Guess the switches would have to perform the checksum hash and either allow or disallow the upload, but that’s a bit much to ask of a switch. PC controller obviously doesn’t care what you send to it. @bcopeland tool maybe be the best way as it may be able to run an integrity check and check the device matches a pre-loaded database (list) of firmwares for that device.
It was a thought. I’m not a coder. Just someone who installs IAVAs and patches.
Anyone want the dead LZW30-SN? If you can figure out how to flash the right firmware directly onto the PCB maybe it’ll work. Or it would make an interesting project for aspiring hardware engineers.
I fear I did the same thing (but backwards) I installed the LZW30 firmware on a LZW31 device, and only the otz half. Then I applied the change and once the switch rebooted it never powered back on again. No LEDs, no zwave communication… air gap does nothing at all. I think mine is bricked also. Guess I could crack it open and see if there is an ESP32 or 8266 inside and see about physically pushing firmware to it.
That came up in the support ticket I opened but basically it’s not worth the cost of a switch to roundtrip to China. US->China shipping is bonkers (20x China->US).
After having tons of issues, I thought maybe I was installing wrong FW on what I think is a red switch. I tried the SN31 version, and bricked it after the target0 firmware finished updating. Anyone have a solution? Seems gone.
So much trouble with these switches. Works great once they work but had so many issues.
If you installed LZW31 (dimmer) firmware on an LZW30 (switch) you installed the wrong firmware. Does the device power on and/or communicate via Z-Wave at all? You could attempt to re-associate it and perform another firmware upgrade if it’s powering on.