[BETA] Updated binary firmware updater

⚙️ Custom Apps and Drivers Custom Drivers
1

I've made some updates to the original community firmware update driver written by @bcopeland to fix some bugs and add some functionality.

https://raw.githubusercontent.com/mbbush/hubitat/master/Drivers/Z-Wave-Firmware-Updater/zwaveBinaryUpdater.groovy

The bug fixed results in failed updates when firmware size is an exact multiple of 40 bytes, plus one byte. See https://github.com/djdizzyd/hubitat/pull/18 and Unable to update Black Switch firmware using Hubitat - #3 by mbbush - Firmware Discussion - Inovelli Community for more details.

The new functionality is allowing you to save the value of configuration parameters before you start the update, then do the update, then restore them back to their original values. I implemented this because many of my Inovelli LZW31-SN dimmers were setting some of their parameters to weird values when I updated the firmware, which caused unwanted behavior.

Basic instructions for how to use:

  1. Use the "get parameters" command with the range of config parameters you want to save. For my LZW31-SN I use "1-22,50-52". Setting an interval of around 400-500 ms is a good idea for reliability.
  2. Wait until you see the stored parameters show up in the "current states" section on the right. This will take several seconds, and will happen once the hub has stopped getting more parameter reports. You can view the logs if you want more detailed progress information. If you don't see all the parameters you requested, then either the device doesn't support them, or your interval was too fast. You can try get parameters again as many times as you want until you see all the values you expect in "current states".
  3. Update the firmware, just like you did before. You can optionally include an md5 checksum that will be checked against the file before flashing to ensure your download was correct. I haven't tested this yet with very many different firmware types, and it's totally optional.
  4. Use the "Restore Parameters" command with a range that includes the stored parameters you want to restore. The driver will send a set parameter command for each parameter in the range you specified that was already stored, so it won't unset something that it doesn't already have a value for.

I have not yet implemented code to save and restore the protection state (which disables local/remote control). I think I saw that get changed once by a firmware update, but I'm not sure.

The code still references @bcopeland as the author, uses his original namespace, and the import URL points to his repository. Brian wrote the vast majority of the code, and I don't want to take away from his work, but he also seems to have abandoned it. I'd be happy to move it to my namespace and take care of things like publishing to HPM, having proper versions, and merging fixes from contributers, but I also don't feel the need for any personal recognition for this. I might even unify it with the non-legacy one if I can find the time to wrap my head around this code more.

Brian, do you have a preference?

14 Likes
2

I am not sure it could be truly called abandoned when they built it into the Hubitat itself now that he joined them.

1 Like
3

But the built-in app doesn’t work on a C-5 or prior. This is a great contribution/update.

5 Likes
4

If you don't merge it with the legacy version, I would suggest changing the name in the definition to be distinct from the original legacy version. This is confusing if you install both, as they both have the same name. I renamed mine manually, not sure if everyone else is comfortable doing that. Also keeping the same name and namespace might cause HPM to match this up to Bryans repo (I think its still in HPM) and then "update" it from there. So might want to change the namespace as well, just give proper credit in the code to the original author. I have done this on a few ports from ST, per the license agreement they used, and no one has raised any concerns.

Otherwise, from what I understand Bryan has dropped all his public projects when he became staff, so it is basically abandoned and unsupported as you said. He has expressed that anyone willing to pick up any of the code could fork it and continue on his work. I wanted to fork these updater drivers but have not gotten around to it, so thanks for picking it up.

EDIT: Link to original thread with more instructions: [RELEASE] Z-Wave Firmware Updater

6 Likes
5

Had not realized Bryan completely dropped them all...

Either way, it is always good when someone is willing to help. Even if he WAS still actively working on it I do not know many developers in this community that are not willing to accept some input (or bug fixes) made freely.

2 Likes
6

@mbbush I am running an update on a Zen20 v3 HE C7. Has been on Complete device is flashing... for the last hour. How long do I wait before giving up? What is the best way to recover from this if something just went wrong?

7

It says its Complete, meaning its done. After that the device flashes itself and possibly reboots, the driver has no idea what happens after that so that's the last message you get from it. Switch back to the normal driver, power cycle the device and then run a "Configure" on the driver. If it still is not talking to the hub the update may have factory reset it and you will have to pair it again. [Guide] Updating Firmware and ZWave Replace

1 Like
8

Well, I have the device paired and online. When I press On or Off == no click and nothing happens. I have excluded and included a few times with a factory reset. No luck.

9

Re-including will make a "new" device on the Hubitat side. Make sure you're using that device and not the "old" one, i.e, that you don't still have the "old" device detail page up, which would no longer work. (Though a proper exclusion should have removed that; if you had to force, or did a reset without removing, consider checking your Z-Wave Details table for leftovers and getting those removed.)

If you're able to include and exclude, that's at least good news, as the device isn't bricked. :slight_smile:

1 Like
10

Yeah, all the old devices are gone. I did have to use the force delete. But, the exclusion worked fine and then I included. Loaded the native driver for the power strip. And just like before on off shows on screen but nothing clicks and nothing changes.

11

Make sure you remove the old nodes from Settings > Z-Wave Details then. This may not be causing your problems, but Z-Wave is known not to not play well with missing nodes, especially when those nodes are repeaters. A force remove doesn't touch these, so you'll need to.

For your actual problem, I'm not sure, but maybe see if physical changes are reported back to the hub from the device (i.e., whether them problem goes both ways), and see if "Logs" show anything from the driver/device in either case. Make sure "Enable debug logging" is turned on.

1 Like
12

Shows on screen how? If the switch state is changing, then the device is telling the hub it changed. If the device is reporting a change and not actually changing, that's a device problem.

13

In devices, the status blocks off to the right, I could hit the button for off and on and it goes off and on, it changes the status to off and on as well. But it is not transmitting to the Zen 20 or it is being ignored

14

Make a separate thread for it, (tag me so I find it) turn on debug logging and get screenshots. Typically the driver would not change the switch state unless the device is sending an update. So possibly a device problem.

15

Working on a warranty return as we speak

16

I'm happy to see my work was useful.

I'm no longer using Hubitat, having completely migrated to home assistant. I don't plan on updating this code again, but if someone else wants to fork it, update the namespace, change the name for clarity, and publish to HPM you have my blessing to do so.

I'm also not planning on taking any of my Hubitat code down from GitHub, so it can stay as a reference for anyone who finds it useful.

8 Likes