Firmware update capability for OH Zwave binding

[apella12]

Going to turn to draft. Putting out there for comment. I was primarily a challenge to see if I could get this done (with AI help). The Zwave-js app uses the file input. The is no central source that I know of, just files spread across MFG websites.

This is true to the Zwave spec and Tests work so far but relies on XML modification to get the firmware file into OH UI, so won't work with current jar build process (changes will get overridden). One thought would be to add the firmware configuration like the battery when to ZW DB is downloaded for devices that support FirmwareUpdate. There might be other options too. I have been advised that the Thing action is not input capable.

Other limitations are that I have only tested with .gbl files and zooz devices

[cdjackson]

Thanks. This would definately be cool to have, and I've only had a very quick look at this, but it doesn't look like this follows the OH firmware update concept? It looks like you're just using ZWave specific actions rather than the firmware update concept which I think is a bad idea as it means ZWave would be different to other bindings.

[apella12]

Understand. I don't have any devices that use the OH firmware update concept to follow that logic. I did glance at your Zigbee fileProvider and it seems that it relies on a central DB (could be wrong). In ZWave the firmware files I have found are spread over the MFG sites. One example is Zooz (I have a lot of these), but aeotec has a similar support page.

Anyway, used the Zwave-js logic that starts with a file import (target 0 is the Zwave chip & I limited to that in the code above).

As noted, it works (with the testing so far), but I needed to modify the device XML, so is not aligned with the OH ZW DB update process (at least now anyway). Originally, I had hoped the Thing actions could be modified to pick up the file as that could be cleaner, but probably not sellable to the OH central committee as an alternative

[cdjackson]

It's not an issue with where the firmware comes from - the point is that there is a workflow for doing firmware updates, and the UI supports this workflow. There are 2 parts to the process - one is a firmware provider - this is just a class that provides firmware - it links thing types to firmware files, and when the UI/core asks for firmware, it provides the stream. It doesn't have to be backed by any specific repository - it could just use local files on the file system if you wanted, but there still needs to be a firmware provider.

Then there is additional functionality in the Thing itself to support the firmware update and status feedback to the UI.

I personally don't think it's a good idea to bake your own system and bypass the OH firmware upgrade system and just use thing actions.

[apella12]

I did try for a while with the Firmware provider, but had issues (probably of my lack of knowledge) and I just wanted to get it working. I could take another look. Here is the AI response
firmwareProvider.txt
to "What was the problem I was having with the firmware provider?"
As to the OH structure, it seemed overly engineered to just update firmware. Maybe I'll just PR the ZWave part and leave the integration into OH for the future? That at least moves it closer.

[apella12]

1. I changed the way the firmware is loaded by extending the userdata/zwave folder. Much less complex that the config option. Still requires user to go and get it from MFG site and put it in the node's directory. 2) Added the download device firmware per the spec but couldn't test as none of my devices support it. There is a note in the docs that few devices support it, so left action as Hidden. 3) Ran more tests and made changes based on the issues primarily with battery devices. Have used hex, gbl and zip files across a half dozen zooz devices. 4) Didn't mean to disrespect the OH firmware update. ZW firmware seems more of a break-fix (or one-off) than a lifecycle with alerts about updates, etc.. 5) Still need review more, but largely in place (for the ZW binding part anyway)

[cdjackson]

I think it's fine to put the firmware in a local directory - no problem there, but you still need to support the FirmwareProvider I think - otherwise the UI doesn't know about the firmware and can't provide info to the user to allow them to manage the update.

My point about the OH firmware update lifecycle is that OH defines a mechanism to allow the user to start/stop firmware updates and to have visibility of what's happening. It's independent to the ZWave firmware update - the point is that in order to provide the same UX, you need to support these various interfaces for both firmware provision (FirmwareProvider) and the actual firmware update itself (FirmwareUpdateHandler).

[apella12]

I do understand (sort of). However, I think the same UX experience ship has sailed with the plethora of rule languages now available for OH rules and the marketplace addons that have no real consistency requirement, except that they work for a range of OH versions. When I look at the forum today the issues mostly fall into those categories.
My efforts so far have been mainly to get the ZWave firmware update working consistently and fit into the binding framework. The specs manage to be both repetitive and unclear in some cases. I still have got to try some tests with security devices. So far, the firmware updates have all been unsecured.
My thinking is the ZW user is going to have to go out and get a firmware file. So, some of the lifecycle elements like "New Firmware Available" are kind of redundant. A manual start to the upgrade also seems natural in that situation. Also, although I have actually upgraded firmware a time or two, most of the tests are "upgrading" the same version that is already there. I did add a progress % on the UI page since it takes 5-15 minutes. I haven't tried to program a "Stop" the spec says to send a bad CRC. Most devices do not seem to advertise resume but need to start over. Bottom line it may be tricky to integrate/translate the OH firmware update handler features into how the Zwave spec handles those options, but I'll look.
The last thought is I do this when the weather is bad and we are finally getting Spring weather so will have more options to be outside (yard needs work).

[apella12]

I need to do some more tests (it works, but there are AI code suggestions that needs to be reviewed). It now connects to the OH firmware framework.
Firmware updates go smoothly with direct connections but are troublesome over distances (3+ hops). There is extra code to handle delays, offline statuses and missed messages that help, but add complexity.

I'm still using the Thing action for testing but will hide that when finished. (The OH framework won't let me update if I'm already at version.)

[cdjackson]

As mentioned. I believe that this needs to support the firmware update concept. I don’t think bindings should randomly choose to support OH concepts or do their own thing - it becomes a pain to maintain in the longer term and reduces OHs standard look and feel in abstracting different technology away from the user. If OH maintainers disagree and we’re not worried about this any more, then fine, but I think it’s a bad idea that will likely cause more pain in the long run.I don’t think your example of different scripting languages is at all the same - I think these are managed as separate plugins. Sent from my iPhoneOn 31 Mar 2026, at 10:51, Robert Eckhoff ***@***.***> wrote:apella12 left a comment (openhab/org.openhab.binding.zwave#2024) I need to do some more tests (it works, but there are AI code suggestions that needs to be reviewed). It now connects to the OH firmware framework. Firmware updates go smoothly with direct connections but are troublesome over distances (3+ hops). There is extra code to handle delays, offline statuses and missed messages that help, but add complexity. OHintegration2026-03-28.182849.png (view on web) I'm still using the Thing action for testing but will hide that when finished. (The OH framework won't let me update if I'm already at version.) —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: ***@***.***>

[apella12]

I think I did support the user facing OH firmware concept with the FirmwareProvider (implemented in ZwaveLocalFirmwareProvider) and FirmwareUpdateHandler (implemented in the ThingHandler). The firmware file was ported from ZWave-js firmware update .ts code since I thought that would be most applicable. Certainly, if there is OH code that does the same, that would be a good enhancement.

Anyway, no worries, I'll clean up a bit in the next day or so to help anyone in the future (to not have to recreate the ZWave Firmware CC from the Specs) and close for now. It was a good learning experience for me.

[cdjackson]

Ok, that sounds good. I thought when I looked a few weeks back it wasn’t implemented and I understood your comments earlier as though you didn’t plan to implement these interfaces. I’ll try and take a look in more detail when I get the chance - I’m about to head off travelling (or standing in airport queues from what I’ve read with the TSA issues!).

…

On 31 Mar 2026, at 1:22 PM, Robert Eckhoff ***@***.***> wrote: apella12 left a comment (openhab/org.openhab.binding.zwave#2024) <#2024?email_source=notifications&email_token=AAH6IQ4AW75YWMY727HEDLL4TMFVPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJVHA4TONJTGE42M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4158975319> I think I did support the user facing OH firmware concept with the FirmwareProvider (implemented in ZwaveLocalFirmwareProvider) and FirmwareUpdateHandler (implemented in the ThingHandler). The firmware file was ported from ZWave-js firmware update .ts code since I thought that would be most applicable. Certainly, if there is OH code that does the same, that would be a good enhancement. Anyway, no worries, I'll clean up a bit in the next day or so to help anyone in the future (to not have to recreate the ZWave Firmware CC from the Specs) and close for now. It was a good learning experience for me. — Reply to this email directly, view it on GitHub <#2024?email_source=notifications&email_token=AAH6IQ4AW75YWMY727HEDLL4TMFVPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMJVHA4TONJTGE42M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJNLQOJPWG33NNVSW45C7N5YGK3S7MNWGSY3L#issuecomment-4158975319>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH6IQ5OBIKJB6PJOINDFFL4TMFVPAVCNFSM6AAAAACWVYPMVOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DCNJYHE3TKMZRHE>. You are receiving this because you commented.

[apella12]

With AI it wasn't as painful as I thought. I need to do some clean up anyway. They paid the TSA on Monday, so lines look better On Monday, March 30, 2026 at 08:33:05 PM EDT, Chris Jackson ***@***.***> wrote: cdjackson left a comment (openhab/org.openhab.binding.zwave#2024)Ok, that sounds good. I thought when I looked a few weeks back it wasn’t implemented and I understood your comments earlier as though you didn’t plan to implement these interfaces. I’ll try and take a look in more detail when I get the chance - I’m about to head off travelling (or standing in airport queues from what I’ve read with the TSA issues!).

[apella12]

Probably should have left PR as draft while testing, but don't see major changes now. Pretty consistent behavior. Did have a problem with one device type but tried with Zwave-js and had the same issue, so don't think it is the code. Otherwise, tested Zooz and Aeotec with varies formats to completion. I have a few more to run when I get time.
EDIT: attached is a log of the start and end sections plus a picture version of node 59. At a high level there is an update of the FirmwareMD CC, then the initial exchanges before the fragment. I cut out the in-between fragments and captured the end. After success, I run a ping and get the new firmware information.

toplog4-19.txt