Either the typing for RouteStatistics is incorrect or there is a bug in the statistics logic?

[raman325]

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?

As reported in home-assistant/core#108021 the HA integration expects protocolDataRate to be provided in the lwr and nlwr statistics objects based on the typing: https://github.com/zwave-js/node-zwave-js/blob/master/packages/zwave-js/src/lib/node/NodeStatistics.ts#L56

So to me it sounds like either the typing is wrong or there is some state that statistics get put in that is incorrect.

What did you expect to happen instead?

I think that either the typing needs to be updated to make protocolDataRate optional or the logic that is leaving the object in a bad state is updated.

Steps to reproduce the behavior:

Hard to say since it is happening on initialization. It's also not a widespread error as this is the first report we've seen.

Anything else we should know?

The user mentioned that it was not an issue in HA 2023.9.X which was released on September 6th. Looking at the zwave-js-server release logs, that suggests that this was introduced in zwave-js 12.x. I did try to run 2023.9.3 using the latest node-zwave-js just to make sure it wasn't some sort of backwards compatibility issue, but I was able to bring up my network fine

cc @maheus

Software versions

Driver (node-zwave-js): 12.4.1
Z-Wave JS UI: 9.6.2.6e369a1

Home Assistant Z-Wave Integration: Home Assistant 2023.11.3

Home Assistant Z-Wave JS Addon: ...

ioBroker.zwave2 Adapter: ...

If you are using something non-standard, tell us here: ...

Device information

Unknown at this time

Manufacturer: ...
Model name: ...
Node ID: ...

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

Waiting for the user to provide debug logs as they have stated they are worried about leaking personal information, but logging the issue anyway as a placeholder

[zwave-js-bot]

👋 Hey @raman325!

Thanks for opening an issue! It doesn't look like you provided a logfile though. While not strictly necessary for every issue, having a driver log on loglevel debug is required to diagnose most issues.

Please consider uploading a logfile that captures your problem. As a reminder, here's how to create one:

• Z-Wave JS UI
• Home Assistant Z-Wave Integration
• ioBroker.zwave2 Adapter

[AlCalzone]

According to that issue, the statistics only contained the repeaters. The only way I can imagine this to happen is if the response to GetPriorityRoute is one byte short (e.g. caused by a controller bug), and therefore the routeSpeed is undefined here:

node-zwave-js/packages/zwave-js/src/lib/serialapi/network-mgmt/GetPriorityRouteMessages.ts

Lines 87 to 92 in 9549a04

	if (this.routeKind) {
	this.repeaters = [
	...this.payload.subarray(offset, offset + MAX_REPEATERS),
	].filter((id) => id > 0);
	this.routeSpeed = this.payload[offset + MAX_REPEATERS];
	}

Could that be? Does HA even use this method?

[raman325]

no we don't use this, at least not directly. This is happening on initial startup on the client side so this is coming from the initial state (we grab the statistics attribute directly from each node as part of the state). Just looking through the code, this is coming from StatisticsHost which the mixin for the Node class NodeStatisticsHost extends. I don't know if that's helpful or not, just not sure where to go from here

[kpine]

It looks like zwave-js will grab a "route cache" from the NVM? Could it have bad data?

node-zwave-js/packages/nvmedit/src/convert.ts

Lines 365 to 380 in fb93b59

	if (routeCacheExists.has(id)) {
	let routeCache: RouteCache | undefined;
	if (protocolFileFormat === 0) {
	const fileId = nodeIdToRouteCacheFileIDV0(id);
	const file = getFile<RouteCacheFileV0>(fileId, protocolVersion);
	routeCache = file?.routeCache;
	} else {
	const fileId = nodeIdToRouteCacheFileIDV1(id);
	const file = getFile<RouteCacheFileV1>(fileId, protocolVersion);
	routeCache = file?.routeCaches.find((i) => i.nodeId === id);
	}
	if (routeCache) {
	node.lwr = routeCache.lwr;
	node.nlwr = routeCache.nlwr;
	}
	}

[AlCalzone]

initial startup on the client side

Does that mean Z-Wave JS UI was already running? In this case getPriorityRoute may be getting called.

Will need the driver logs to confirm though

[maheus]

Hi @AlCalzone my log is already in debug, but the file is very big. Can I give you the last 1000 line or first 1000 lines ?

[maheus]

                                    node ID:     49
                                    route kind:  LWR
                                    repeaters:   none
                                    route speed: unknown (undefined)

zwavejs_2024-01-17.log.gz

[maheus]

all nodes has the value unknown (undefined) for the field route speed

[maheus]

@AlCalzone my logs helps you ?

[raman325]

please be patient, he is on paternity leave and is not paying attention to github like he normally would

[maheus]

yes no problem

[AlCalzone]

Thanks, that confirms my suspicion. Very old Z-Wave SDK on the stick, apparently does not include the byte for the route speed.

[AlCalzone]

Escalated to an issue: #6616

@raman325 seems like applications have to consider the protocolDataRate field to be optional.