Has anyone successfully updated their Inovelli Red Dimmer with the light bar firmware? I know the file is in .bin format and needs to be .hex. I used the Silicon Labs .bin to .hex tool and when I tried to load it onto the switch, I got the error firmwareUpdateProgress : Failed to find matching firmware.
Looking at the logs, it seems the .hex file maybe isn't in the expected format.
I still have no luck with my LZW30's. This morning i did a factory reset on one of them and still no luck.
I did find that after the first time you attempt this and get a "sleepy device" message, the switch is actually is a bad state. PRessing the config button 3 times does not initiate pairing mode. Once you air-gap it, pairing mode will work again.
I think I got past the Inovelli LZW30 issue! I noticed some LED activity during the update process and noticed the switch seems to not ever reply to two commands from this driver in a row without air gapping.
For anyone having trouble, try this:
Abort and release lock of any prior attempts
Air Gap your switch and plug it back in
Start Firmware upgrade
Watch the process, and watch for "Current Firmware version obtained" (or something similar to that)
Immediately air-gap your switch and plug it back in (it has to be fully "re-booted" while the updater is downloading/parsing the firmware)
For me the "Request to apply firmware", was then immediately successful
Unfortunately I cannot replicate again to see if it works since I dont have another LZW30 to try on.
That Worked!! I didnt even have to do step 4 & 5. i just air gaped the switch and then immediately hit the update firmware button. I missed the "Current Firmware version obtained" but the upload still went through. Thanks!
I look at your video and mine is saying that it padding hex bytes does that mean it is writing to the device? I didn't see that terminology on your video and I know that each manufacturer does things differently? I also not getting the firmware load percent? may be normal Thanks for this it will make it easier for devices updates.
The video used an OTA file which is a different format than a hex file.. hex files can contain large gaps where there should be filler 0xFF.. That's what that means.. it is filling memory any gaps in the firmware update file has with 0xFF which is what the standard calls for
Ok.. no.. it shouldn't take that long.. a minute tops.. Hit abort and start over.. I'm thinking it didn't get something right.. Maybe the hex download was missing something..
ahhh .. dropbox.. Special characters should not be an issue.. In fact my early testing all had httpget variables.. But it may be similar to the issue that another user had with google drive..
As I am not familiar with dropbox (as I don't use it) .. I'm not sure here..
Note : The original shared link URL may contain query string parameters already (for example, dl=0). App developers should be sure to properly parse the URL and add or modify parameters as needed. The links may also redirect to *.dropbox.com/s/dl
Some browsers aren't configured to correctly preview files. While certain file types can be downloaded instead of opened, others—like HTML—are not supported.
To bypass the preview page and allow your browser to directly render your files, use raw=1 as a query parameter in your URL. Adding raw=1 to a URL will cause an HTTP redirect. If you're an app developer using such a URL in your own code, please make sure your app can follow redirects.
Note: Shared links don’t render HTML content in a web browser. If you created a website that directly displays HTML content from your Dropbox, it won’t render in the browser. The HTML content itself remains in your Dropbox and can be shared. The links may also redirect to *.dropbox.com/s/raw