Closed wrender closed 1 year ago
👋 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
[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
I'll have to rewrite the multi-target OTA update in the driver, so it deals with all the sequencing.
Thanks for taking a look at this!
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?
Oh, good point. The update information came straight from Inovelli and I didn't consider that this might be a beta.
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.
We're working on an opt-in way to do that.
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.
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
@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.
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.
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?
"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.
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.
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.
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)
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?
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 🤷♂️
@AlCalzone I have an LZW30 and an LZW31 I'm willing to send you if it will help.
Cool, please contact me on Discord or via email (see my Github profile) for further details.
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 https://github.com/zwave-js/node-zwave-js/issues/5081#issuecomment-1712128461, or unsubscribe https://github.com/notifications/unsubscribe-auth/AXFSIAVAHCK7M62PTFYRZ5LXZNWQ3ANCNFSM6AAAAAAQPRWHL4 . You are receiving this because you commented.Message ID: @.***>
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.
Thanks to @sdholden28 I finally have a device to debug this as soon as I catch up on more urgent stuff.
Thank you!!
The fix is almost embarrassing, considering it took over a year 😇 Goes to show how much having an actual device helps debugging though.
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
CC @InovelliUSA
We may have to switch the URLs to permalinks to avoid this situation in the future.
@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.
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.
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.
Can you create a 301 in a github repo?
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.
I recommend leaving a file in the old location that says that the file has moved and has a link to the new location.
Fixed in https://github.com/zwave-js/firmware-updates/commit/0751036fd4519eafb825d62ab85831dbd1187c01, 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:
and use that URL for the firmware update service.
Thanks, I will use that method in the future.
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
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem was not mentioned there.
Describe the bug
What causes the bug?
What do you observe?
What did you expect to happen?
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)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