Updating Inovelli Red Series Fails

[wrender]

Is your problem within Home Assistant (Core or Z-Wave JS Integration)?

YES, BUT a Home Assistant developer has told me to come here

Is your problem within ZWaveJS2MQTT?

NO, my problem is NOT within ZWaveJS2MQTT

Checklist

• I have checked the troubleshooting section and my problem is not described there.

• I have read the changelog and my problem was not mentioned there.

Describe the bug

What causes the bug?

• Trying to update device "inovelli red series dimmer" from within Home Assistant

What do you observe?

• Update begins, but then the light doesn't boot with new firmware. I see the error: [Node 019] Timed out while waiting for a response from the node (ZW0201). The light then just boots with the previous firmware.

What did you expect to happen?

• Boot to new firmware 1.61

Device information

Manufacturer: Inovelli
Model name: Red Series Dimmer
Node ID in your network: 2 to 25

How are you using node-zwave-js?

• zwavejs2mqtt Docker image (latest)
• zwavejs2mqtt Docker image (dev)
• zwavejs2mqtt Docker manually built (please specify branches)
• ioBroker.zwave2 adapter (please specify version)
• HomeAssistant zwave_js integration (please specify version)
• pkg
• node-red-contrib-zwave-js (please specify version, double click node to find out)
• Manually built from GitHub (please specify branch)
• Other (please describe)

Which branches or versions?

Driver Version: 10.0.4
Server Version: 1.22.1

Did you change anything?

no

If yes, what did you change?

No response

Did this work before?

No, it never worked anywhere

If yes, where did it work?

No response

Attach Driver Logfile

2022-09-17T13:21:25.387Z CNTRLR » [Node 019] Sending firmware fragment 388 / 389
2022-09-17T13:21:25.470Z CNTRLR » [Node 019] Sending firmware fragment 389 / 389
2022-09-17T13:21:25.939Z CNTRLR « [Node 019] Firmware update completed with status OK_RestartPending
2022-09-17T13:21:25.942Z CNTRLR   [Node 019] Firmware updated, scheduling interview in 5 seconds...
2022-09-17T13:21:25.959Z CNTRLR   [Node 019] Downloading firmware update from https://files.inovelli.com/firmwar
                                  e/LZW31-SN/Beta/1.61/LZW31-SN_1.61.otz...
2022-09-17T13:21:26.739Z CNTRLR   [Node 019] Firmware update https://files.inovelli.com/firmware/LZW31-SN/Beta/1
                                  .61/LZW31-SN_1.61.otz downloaded, installing...
2022-09-17T13:21:27.841Z CNTRLR   [Node 019] Timed out while waiting for a response from the node (ZW0201)
2022-09-17T13:21:30.967Z CNTRLR   [Node 019] Beginning interview - last completed stage: None
2022-09-17T13:21:30.970Z CNTRLR   [Node 019] new node, doing a full interview...
2022-09-17T13:21:30.974Z CNTRLR » [Node 019] querying protocol info...
2022-09-17T13:21:31.043Z CNTRLR « [Node 019] received response for protocol info:
                                  basic device class:    Routing Slave
                                  generic device class:  Multilevel Switch
                                  specific device class: Multilevel Power Switch
                                  node type:             End Node
                                  is always listening:   true
                                  is frequent listening: false
                                  can route messages:    true
                                  supports security:     false
                                  supports beaming:      true
                                  maximum data rate:     100000 kbps
                                  protocol version:      3
2022-09-17T13:21:31.051Z CNTRLR   [Node 019] Interview stage completed: ProtocolInfo
2022-09-17T13:21:31.054Z CNTRLR » [Node 019] querying node info...
2022-09-17T13:21:31.144Z CNTRLR « [Node 019] node info received
                                  supported CCs:
                                  · Z-Wave Plus Info
                                  · Multilevel Switch
                                  · Configuration
                                  · Association
                                  · Association Group Information
                                  · Transport Service
                                  · Version
                                  · Manufacturer Specific
                                  · Device Reset Locally
                                  · Powerlevel
                                  · Security
                                  · Meter
                                  · Security 2
                                  · Central Scene
                                  · Supervision
                                  · Protection
                                  · Application Status
                                  · Firmware Update Meta Data
2022-09-17T13:21:31.153Z CNTRLR   [Node 019] Interview stage completed: NodeInfo
2022-09-17T13:21:31.160Z CNTRLR   [Node 019] Interviewing Manufacturer Specific...
2022-09-17T13:21:31.162Z CNTRLR » [Node 019] querying manufacturer information...
2022-09-17T13:21:31.243Z CNTRLR « [Node 019] received response for manufacturer information:
                                    manufacturer: Inovelli (0x031e)
                                    product type: 0x01
                                    product id:   0x01
2022-09-17T13:21:31.249Z CNTRLR   [Node 019] Interviewing Version...
2022-09-17T13:21:31.251Z CNTRLR » [Node 019]   querying the CC version for Version...
2022-09-17T13:21:31.335Z CNTRLR   [Node 019]   supports CC Version (0x86) in version 2
2022-09-17T13:21:31.337Z CNTRLR » [Node 019] querying node versions...
2022-09-17T13:21:31.415Z CNTRLR « [Node 019] received response for node versions:
                                    library type:      Enhanced Slave (0x03)
                                    protocol version:  6.4
                                    firmware versions: 1.52, 1.45
                                    hardware version:  1

[zwave-js-bot]

👋 Hey @wrender!

It looks like you copied the contents of a logfile. Please attach it as a file instead, so it is easier to work with.
Note: You can just drag & drop files into the textbox. Just make sure to use a supported file extension like .log or .txt

[AlCalzone]

[Node 019] Firmware update completed with status OK_RestartPending

Ahh, looks like the update of the 2nd chip (target 1) also requires a restart. @raman325 FYI

[AlCalzone]

I'll have to rewrite the multi-target OTA update in the driver, so it deals with all the sequencing.

[wrender]

Thanks for taking a look at this!

[jl-678]

I see the same thing. @AlCalzone, thank you for your work on this.

BTW, one oddity is that 1.61 is actually a beta build with 1.57 as the stable one. Should HA/ZJS be suggesting that we update to a beta build?

[AlCalzone]

Oh, good point. The update information came straight from Inovelli and I didn't consider that this might be a beta.

[MrMxyzptlk]

I want to update to the 1.61 beta, so if there is a way to have a choice on the update screen that would be great.

Thanks.

[AlCalzone]

We're working on an opt-in way to do that.

[mbbush]

Something else to consider for multi-target firmware would be tracking the two versions separately.

For example, a user wishing to upgrade from the 1.57 build to the 1.61 build only actually needs to update target 0, since the firmware specified for target 1 is identical in both. They have the same version number in the filename, report that same version number in the version command class, and have the same sha256 checksum.

You could also easily get in this kind of situation if you manually updated one of the targets but not the other, such as perhaps someone who updated only target 0 and didn't know there was a second file that needed uploading, or you were affected by the initial bug listed here and had a partially successful update.

One option I can think of for implementing this would be to add a second "version" property to the firmware update json:

{
  "version": "1.61",
  "channel": "beta",
  "changelog": "Fixed - Dimmer sending duplicate reports in certain scenarios while being controlled by certain hubs.",
  "files": [
	{
	  "target": 1,
	  "url": "https://files.inovelli.com/firmware/LZW31-SN/Beta/1.61/LZW31-SN_1.45.bin",
	  "integrity": "sha256:2a338a5f501746b69c91489efe1cb4b8b3d62a29501779943bf90625582693f1",
          "zwaveMajorVersion": "1",
          "zwaveMinorVersion": "45"				
        },
	{
	  "target": 0,
	  "url": "https://files.inovelli.com/firmware/LZW31-SN/Beta/1.61/LZW31-SN_1.61.otz",
	  "integrity": "sha256:e07cb9972bfe88e143c72c9b6ed88a640b9d969fbf09d6c1a4625f711979b541",
          "zwaveMajorVersion": "1",
          "zwaveMinorVersion": "61"
	}
  ]
}

or something like that, which the admin ui (fka zwavejs2mqtt) could compare to the response to the version command to see which firmware targets, if any, need updating, and decide which of the files to actually download and send to the device. And you could make it an optional JSON property and just skip this step for single-target devices.

[smugleafdev]

I'm having a similar issue with 2/3 of my LZW31s. I tried manually updating and it accepted the bin file but not the main file. I tried with both 1.57 and 1.61. I ran a manual update and got these logs that don't seem too helpful: https://pastebin.com/V4tKptRH

[AlCalzone]

@smugleafdev Updating the firmware is mainly driven by the device. Everything past the initial "start" commands is not in our power.
In your case the device doesn't request the firmware fragments, so the process times out.

Maybe try healing the device first so it knows where to reach the controller.

[smugleafdev]

Factory resetting fixed it all. I had given one 1.57 and the other 1.61 and they both broke. After the reset they were both on their appropriate versions and working fine.

[wrender]

I’m a bit confused. Is this now working then? So if I go into home assistant and try and update the firmware it should work?

[smugleafdev]

"Works as intended" probably not, but "works", yes for me at least. If you have attempted both files (1.61 and the 1.45 bin file) at the proper targets (0 and 1 respectively) and received the timeout error for both, try it. Factory reset your switch and re-add it to HA, then check the version.

[wrender]

In my home assistant it only seems to show 1.57 is available. I’m on 1.52 currently.

I tried excluding a switch, factory resetting it, and then re-added it but it still doesn’t seem to want to update to 1.57 in home assistant.

[kpine]

Make sure you're using the latest version of the add-on, then attach driver Debug logs of the firmware upgrade process in a comment here.

[wrender]

Addon Versions
Current version: 0.1.74.
Driver Version:10.3.0
Server Version:1.24.0

Home Assistant Versions
Home Assistant 2022.10.5
Supervisor 2022.10.0
Operating System 9.2

I just tried another switch and the same thing seemed to happen. I tried excluding a switch, factory resetting it, and then re-added. I am adding them "insecurely" since they are just lights. Here are the debug logs with the error when I try and update:

2022-10-22T14:33:18.128Z CNTRLR » [Node 033] Sending firmware fragment 386 / 389
2022-10-22T14:33:18.209Z CNTRLR » [Node 033] Sending firmware fragment 387 / 389
2022-10-22T14:33:18.290Z CNTRLR » [Node 033] Sending firmware fragment 388 / 389
2022-10-22T14:33:18.371Z CNTRLR » [Node 033] Sending firmware fragment 389 / 389
2022-10-22T14:33:18.824Z CNTRLR « [Node 033] Firmware update (part 1 / 2) succeeded with status OK_RestartPendin
                                  g
2022-10-22T14:33:18.825Z CNTRLR   [Node 033] Continuing with next part in 5 seconds...
2022-10-22T14:33:18.826Z CNTRLR   [Node 033] Updating firmware (part 2 / 2)...
2022-10-22T14:33:18.828Z CNTRLR » [Node 033] Starting firmware update...
Z-Wave error ZWaveError: Received no matching command within the provided timeout! (ZW0201)
    at Timeout.<anonymous> (/usr/src/node_modules/zwave-js/src/lib/driver/Driver.ts:4379:6)
    at listOnTimeout (node:internal/timers:559:17)
    at processTimers (node:internal/timers:502:7) {
  code: 201,
  context: undefined,
  transactionSource: undefined
}

Also, after this occurs, if I try and click to update the firmware again in Home Assistant it shows this error:

Failed to call service update/install. Z-Wave error 1500: Failed to start the update: A firmware upgrade is already in progress! (ZW1500)

[Platup]

There is a new Inovelli firmware 1.22 that is prompting to update, but is still getting the same error.
This firmware also appears to address an issue specific to Home Assistant;
"Fixed the bug that the V1 version of Protection Set Command would cause RF state of Protection to become enabled. This mostly affected Home Assistant users as it is still using V1 of this command class."

Given this issue has been open for a while, is there something blocking? Just wondering if I should go through the effort of manually updating or now that a firmware update is available if a fix would be incoming?

[AlCalzone]

is there something blocking?

Getting my hands on the device to reproduce the bug. There aren't many devices available with multiple updateable chips where the manufacturer also provides updates.
The LZW31 is more or less impossible to get in Europe, and the one Inovelli tried to send me got returned by Fedex without attempting delivery 🤷‍♂️

[sdholden28]

@AlCalzone I have an LZW30 and an LZW31 I'm willing to send you if it will help.

[AlCalzone]

Cool, please contact me on Discord or via email (see my Github profile) for further details.

[sdholden28]

Discord PM sent.

…

On Fri, Sep 8, 2023, 2:27 PM AlCalzone ***@***.***> wrote: Cool, please contact me on Discord <https://discord.gg/HFqcyFNfWd> or via email (see my Github profile) for further details. — Reply to this email directly, view it on GitHub <#5081 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AXFSIAVAHCK7M62PTFYRZ5LXZNWQ3ANCNFSM6AAAAAAQPRWHL4> . You are receiving this because you commented.Message ID: ***@***.***>

[mbbush]

If that doesn't work or you need another one I'd also be happy to send you one of my LZW31-SN red series dimmers.

[AlCalzone]

Thanks to @sdholden28 I finally have a device to debug this as soon as I catch up on more urgent stuff.

[sdholden28]

Thank you!!

[AlCalzone]

The fix is almost embarrassing, considering it took over a year 😇
Goes to show how much having an actual device helps debugging though.

[bmmiller]

This absolutely worked a few weeks ago but I installed a new switch today and it seems to be failing again. Looking at the GitHub link and it's giving a 404. Not sure how updates are pulled but did something change maybe?

This is the link it's looking to pull from: https://github.com/InovelliUSA/Firmware/raw/main/Red-Series/Z-Wave/VZW31-SN-2-1-Switch/Beta/1.02/VZW31-SN_1.02.gbl

Edit: It does look like it changed yesterday.

They changed the filename: https://github.com/InovelliUSA/Firmware/blob/main/Red-Series/Z-Wave/VZW31-SN-2-1-Switch/Beta/1.02/VZW31-SN_1.02-Beta.gbl

[AlCalzone]

CC @InovelliUSA

We may have to switch the URLs to permalinks to avoid this situation in the future.

[InovelliUSA]

@AlCalzone Do you mean to use a redirect link so it can be easily modified? Sorry, someone (I won't name names) reorganized things yesterday.

[InovelliUSA]

AS a workaround for the time being I have the file in github with both filenames. We can think through what is the best option here. One thing that makes it a little tricky is that our beta firmwares will occasionally get promoted to production . . . so in the current setup links would break when the files are reorganized in that way.

[wrender]

If you are ever re-organizing a website always make sure to add an URL redirect from the old stuff to the new stuff. I think 301 redirect is ideal.

[InovelliUSA]

Can you create a 301 in a github repo?

[AlCalzone]

You can't. We can make sure though to use unchangeable permanent links that always point to the same file, even when your repository is reorganized.

I'll do it on Monday and let you know how to do it for the next firmwares you contribute.

[stefan-sherwood]

I recommend leaving a file in the old location that says that the file has moved and has a link to the new location.

[AlCalzone]

Fixed in zwave-js/firmware-updates@0751036, the change will take an hour or so to go live.

@InovelliUSA to avoid this in the future, use this procedure to get a permanent URL:

1. Click the firmware you want to contribute:
   
2. Copy the permalink for the file:
   
3. Paste it in the address bar, you should now see the commit hash in the branch selector:
   
4. Right-click on "view raw", copy URL:
   

and use that URL for the firmware update service.

[InovelliUSA]

Thanks, I will use that method in the future.