Interviews failed for battery devices

[kpine]

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 re-interviewed two battery devices and just let the requests queue up for next time they wake up. Both devices failed the interview in the same way during the ProtocolInfo step. Based on the logs, it seems like it was interrupted by other activity, either a battery query or firmware check. Otherwise, I could not see a reason why it just stopped.

What did you expect to happen instead?

The interview to succeed.

Steps to reproduce the behavior:

1. Re-inverview a battery device
2. Wait for battery devices to be stale, or issue a firmware update check? Not sure.
3. See error

Anything else we should know?

I see Node 061 also had the same problems, but the interview was ultimately successful. The one difference I see is an extra WakeUpCCIntervalReport message.

Software versions

Driver (node-zwave-js): 12.13.0

Z-Wave JS UI: 9.15.0.59a1545

Device information

Manufacturer: Vision Security
Model name: ZD2102-5
Node ID: 016 and 062

See also Node 061

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.log

[kpine]

It's been one week and one of the nodes (62) finally woke up and completed the interview (7 days wake up interval). Presumably there were no battery refresh or firmware update queries to interfere.

Here's the log: zwave_js.log

Also, HA is now showing a new light entity which I believe did not exist previously, but I could be wrong. Either way, it shouldn't exist because it's not a controllable device, and the Set is mapped to a Report. At the very least it should be a sensor, but Notification already covers the functionality.

zwave_js-ef37a31dab38dcfee3fd3d1ecd1f3692-Bedroom Left Window Sensor-de7ad23696f786db7d5f05ba1622e10a.json

[AlCalzone]

Can you test this custom config file?

{
	"manufacturer": "Vision Security",
	"manufacturerId": "0x0109",
	"label": "ZD2102-5",
	"description": "Door Window Sensor",
	"devices": [
		{
			"productType": "0x2001",
			"productId": "0x0105",
			"zwaveAllianceId": 988
		},
		{
			"productType": "0x2001",
			"productId": "0x0106",
			"zwaveAllianceId": [1705, 2823]
		}
	],
	"firmwareVersion": {
		"min": "0.0",
		"max": "255.255"
	},
	"paramInformation": [
		{
			"#": "1",
			"label": "External Switch",
			"valueSize": 1,
			"defaultValue": 0,
			"unsigned": true,
			"allowManualEntry": false,
			"options": [
				{
					"label": "Disable",
					"value": 0
				},
				{
					"label": "Enable",
					"value": 255
				}
			]
		}
	],
	"compat": {
		// This device should send Notification Reports, but they seem to get lost often
		// Basic Set comes through
		"mapBasicSet": "report"
	}
}

The bundled one force-adds support for Basic CC, which is no longer correct since the recent changes to Basic CC handling.

[kpine]

I added the config override file, will report back after I get it to re-interview.

Aug 14 08:49:35.622241 zui[142575]: 08:49:35.621 CNTRLR   [Node 062] User-provided device config loaded

Is there anything I should test for the original issue? Wondering if just queuing up a firmware update check and re-interview might trigger anything. Don't think I have any control over the battery refresh interval.

Oh, I also upgraded ZUI to the latest, so now on driver v13, I wasn't expecting that to make any difference, but just mentioning.

[AlCalzone]

I'll have to look at the original issue after my vacation. The Basic CC behavior should be the same between v13 and the later v12 versions.

[kpine]

Forgot to update since it took quite awhile to get the interview to succeed, but the custom config is working well.

node_62_dump.json

[kpine]

Sorry, I was mistaken. The config only partially helps. A basic currentValue is still created along with the Notification values. This causes HA to create extra entities. My understanding is that Notification should be preferred and Basic hidden in this scenario?

[kpine]

I finally got re-interviews to occur on these devices.

• Bad news: the interview failed for the same reason (devices now stuck on ProtocolInfo last stage), so I could not test the basic cc change.
• Good news: the failure occurred with the absence of a firmware update check, and with the presence of a stale battery refresh. So I'm pretty sure the battery refresh is the culprit.

Logs: zwave_js.log

I'm also having some deja vu, I had to go back and found #3776. Not sure if it makes sense as a feature, since maybe this is an exceptional case, but a complete "restore" of the state prior to re-interview on an interview failure would be preferable to me than devices stuck in limbo.