Inovelli 2-1: Presents as Non-Mains after Firmware Update Failure; Several Dead After Z-Wave JS Add-on Restart

[The00Dustin]

Checklist

• I have read and followed the above instructions

• 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 or the fix did not work.

Describe the issue

What is happening?
I have been installing a new firmware version on my Inovelli 2-1 switches. One of them failed to update several days ago and again today. I am going to quote my (based on memory and not necessarily 100% accurate) notes on the first failure so that they can be skipped and subsequently referenced if necessary, as the logs I am providing are for today's instance.

After the first failure, the switch showed up as a battery device that was asleep when I tried to re-interview it. I could still operate the switch locally, and it would send updates and scene commands which showed up in the events section of Z-Wave JS UI, but the re-interview would not commence because Z-Wave JS thought it was asleep. Several other switches also went dead during an interim time period here, and some of them I couldn't bring alive even with physical interaction while others came alive with a ping (both of these things never occurred with the similar issue in prior [firmware and node] versions). When I restarted Z-Wave JS UI after this, several of the switches that were already updated went to dead and behaved similar to how they would in previous firmware versions when power reporting was disabled and a power update was requested by the hub or a command to set the state equal to what it already was got sent from the hub (no response to ping so the only way to bring them back to alive is to interact with them physically) but at the same time, some of the switches which were dead that I couldn't get to respond at all were back to alive after the restart. After getting all of the "dead" switches detected as alive again, I tried again to re-interview the switch that was presenting as a sleeping battery device, and the re-interview worked, correcting the data. I did not keep notes on everything happening in this scenario because I didn't expect it to recur. I could probably find the logs for this particular instance if they are needed, but there were also other issues going on at that time that I'm not reporting here since it was less consistent (for instance, several switches went dead when I tried to send the firmware update to them the same way they previously have only under the aforementioned scenarios).

After today's failure, the switch did not present as a battery device when I tried to re-interview it, but instead reported dead. Assuming the behavior was likely similar to the first instance, I restarted the Z-Wave JS UI add-on, and after the restart, 8 switches were showing as dead and the switch that failed to upgrade was showing as a battery device again. I tried to re-interview the device in question and it was successful, so it stopped presenting as a battery device. I then collected logs for review.

What did you expect to happen instead?

1. I expect a device which is not re-interviewed because a firmware update failed to maintain its configuration values as opposed to suddenly appearing as a battery device. I am not certain whether Z-Wave JS did something wrong here or whether the device did, but considering that it happened at re-interview in the first case and at add-on restart in the second case, it seems quite feasible that Z-Wave JS could be somehow involved.
2. I expect devices that are alive prior to an add-on restart to still be alive after the restart. I am not certain whether Z-Wave JS did something wrong here or whether the device firmware did. While the behavior is similar to behavior that was previously analyzed and presumed to be a firmware bug, the manufacturer's engineers have been unable to reproduce, and it apparently only occurs with Z-Wave JS and not other hubs under similar circumstances (based solely on customer reports, though this evidence could itself be circumstantial due to low sample size). Further, I have recently upgraded the Z-Wave JS UI add-on and the Switches' firmware, so I can't tell which introduced this inconsistent and intermittent behavior (the only scenario where the current version of the Z-Wave JS UI add-on might have been restarted prior to the firmware update is when the Z-Wave JS UI update was applied).

Steps to reproduce the behavior:
I'm not sure how much of this, if any, is reproducible outside of my environment...

Anything else we should know?:
Node 84 came alive on its own while I was preparing this form, so I collected new logs that should also include ping attempts to all dead nodes after the restart and whatever lead to the alive state.

Software versions

Driver (node-zwave-js): 12.5.5

Z-Wave JS UI: 9.11.1

Home Assistant Z-Wave Integration: 1.35.0-beta.1

Home Assistant Z-Wave JS Addon: 3.5.0

Device information

Manufacturer: Inovelli
Model name: VZW31-SN
Node IDs:

• The device that failed to receive the firmware update and had the odd behavior is node 99.
• The devices with the updated firmware that went dead at add-on restart in today's instance are 59, 63, 71, 76, 79, 84, 94, and 96.
• The devices with the updated firmware that did not go dead at add-on restart in today's instance are 12, 24, 25, 26, 27, 28, 37, 44, 49, 53, 54, 55, 57, 58, 60, 61, 64, 68, 70, 72, 74, 77, 80, 82, 87, 95, and 97.

Checklist

• I made sure to provide a driver log on level debug.

• The log includes a re-interview of the problematic device (if applicable).

• The log includes the problematic interaction with the device (if applicable).

• I provided the node ID of the problematic device (if applicable).

Upload Logfile

zwave-js-ui-store.zip

[AlCalzone]

Pinging @InovelliUSA for some possible input on this

[The00Dustin]

FWIW, I restarted (as opposed to rebooted) HA today and updated Z-Wave JS UI today without devices going dead. I'm not certain whether either of those actions would be expected to trigger an add-on restart, so I'm not certain whether this changes anything (i.e. firmware failure before add-on restart somehow being related to other devices going dead).

Also, because I believe I forgot to mention it in the original submission, one other (non-Inovelli) device went dead in the first instance, but I assumed it had routing issues with so many dead Inovelli devices (as mentioned in the original submission, there was much more "mess" to the first instance).