feat: support Z-Wave Long Range #6401

jtbraun · 2023-10-16T01:58:34Z

This PR adds support for Z-Wave Long Range

fixes: #5253
fixes: #6158

These are the new function types for the long range controllers

packages/zwave-js/src/lib/controller/Controller.ts

jtbraun

Here's a bunch of places where I could use some feedback, suggestions, etc.

jtbraun · 2023-10-16T02:04:07Z

packages/cc/src/cc/Security2CC.ts

+	const nodeIdSize = (sendingNodeId < 256 && destination < 256) ? 1 : 2;
+	const ret = Buffer.allocUnsafe(2*nodeIdSize + 6 + unencryptedPayload.length);
+	let offset = 0;
+	if (nodeIdSize == 1) {
+		ret[offset++] = sendingNodeId;
+		ret[offset++] = destination;	
+
+	} else {
+		ret.writeUint16BE(sendingNodeId, offset);
+		offset += 2;
+		ret.writeUint16BE(destination, offset);
+		offset += 2;
+	}
+
+	ret.writeUInt32BE(homeId, offset);
+	offset += 4;
+	ret.writeUInt16BE(commandLength, offset);
+	offset += 2;
 	// This includes the sequence number and all unencrypted extensions
-	unencryptedPayload.copy(ret, 8, 0);
+	unencryptedPayload.copy(ret, offset, 0);


If either nodeid is 256+, you have to use uint16BE to encode both.

jtbraun · 2023-10-16T02:04:39Z

packages/cc/src/cc/ZWaveLRProtocolCC.ts

+	nwiHomeId: Buffer;
+}
+
+// BUGBUG: this is exactly equal to the ZWaveProtocolCommand.SmartStartIncludedNodeInformation, can we reuse/inherit that somehow?


As comment, how much sharing do we want to do between these classes (or not)?

jtbraun · 2023-10-16T02:05:43Z

packages/cc/src/cc/ZWaveLRProtocolCC.ts

@@ -0,0 +1,238 @@
+import {


While this command class is defined in the specs, It's not exposed that I saw in any command class list, so I'm not sure where/how this would be used. Maybe if you had a secondary LR controller in the network? Unknown. We may not need to include this at all.

This may be used in our testing framework, but unless you're sure about these things, I'd leave it out for now.

jtbraun · 2023-10-16T02:06:53Z

packages/cc/src/cc/ZWaveLRProtocolCC.ts

+// BUGBUG: how much of this can we share with existing stuff? Can we use a ZWaveProtocolCCNodeInformationFrameOptions field to do the `isLongRange` stuff?
+// BUGBUG: how much can we share also with the Smart Start things below that are VERY close to this stuff?


Same, can we leverage base classes and combine a lot of this with the existing ZWaveProtocolCC?

jtbraun · 2023-10-16T02:08:18Z

packages/cc/src/lib/_Types.ts

+export enum ZWaveLRProtocolCommand {
+	NOP = 0x00,
+
+	// BUGBUG: all defined above, can they be shared?


These have the same # assignments, but are in a separate namespace. Add the missing ones to the list above, or leave these separate (or maybe just reference Foo = ZWaveProtocolCommand.Foo.value or something?

Leave separate IMO, or leave it out completely together with the CC

jtbraun · 2023-10-16T02:37:42Z

packages/zwave-js/src/lib/serialapi/capability/GetSerialApiInitDataMessages.ts

+	private listStartNode(): number {
+		return 256 + NUM_LR_NODES_PER_SEGMENT * 8 * this.listStartOffset128;
+	}
+


The equations given in the spec for this say 255 +, but the given examples result in this being 256 +. What's here is correct experimentally. Maybe the spec was using 1-based math and I missed it?

I think 256 makes more sense. Not the first time that the specs are wrong.

The * 8 seems wrong though?

The * 8 seems wrong though?

Yeah, I think that was a holdover from when I had "NUM BYTES PER SEGMENT" there instead.

packages/zwave-js/src/lib/serialapi/capability/LongRangeSetupMessages.ts

jtbraun · 2023-10-16T02:39:44Z

packages/zwave-js/src/lib/serialapi/capability/LongRangeSetupMessages.ts

+// BUGBUG:  move someplace common, see Spec 4.2.5
+//
+// Although, that section refers to a "callback message", and SetZWaveLongRangeChannel doesn't define a callback message...
+export enum ResponseStatus {
+	FAILED = 0x00,
+}


The ReportStatus here is supposed to be a common thing, but in looking through other things that use it, I didn't see one that was implemented. It's supposed to be used with messages that then have a callback message, so that a failure can stop the callback from occuring, but this message doesn't have a callback message...

Seems like a case where this should have just been pass/fail on it's own, and someone in the spec committee decided to re-use a status field that wasn't necessarily applicable?

It's supposed to be used with messages that then have a callback message, so that a failure can stop the callback from occuring, but this message doesn't have a callback message...

In that case the response indicates the final result of the command flow, not the callback.

I don't think we need the enum value or a separate field. Just do this like we do here for example:
https://github.com/jtbraun/node-zwave-js/blob/d1e23fc6a2e58c15eff86d31cf78951d8b62476b/packages/zwave-js/src/lib/serialapi/capability/SerialAPISetupMessages.ts#L899-L907

jtbraun · 2023-10-16T02:40:43Z

packages/zwave-js/src/lib/serialapi/capability/LongRangeSetupMessages.ts

+const LONG_RANGE_SHADOW_NODE_IDS_START = 2002;
+const NUM_LONG_RANGE_SHADOW_NODE_IDS = 4;


Probably should be in a header somewhere.

Also, I didn't provide an API to set this stuff. Presumably these are for when you want your LR-controller to show up with a LR nodeId? I don't know.

same as the others I suppose -> packages/core/src/consts/index.ts

IMO if we have these messages, we should expose an API on the controller for them.

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

jtbraun · 2023-10-16T02:48:04Z

I'm not sure how to request a review to get some feedback? I'm going to assume the maintainers watch for PRs occasionally. @blhoward2 ?

blhoward2 · 2023-10-16T03:39:45Z

You can summon @AlCalzone, but I'm sure he'd see it in the morning anyway. He keeps a close watch.

jtbraun · 2023-10-16T13:18:13Z

I've got a support ticket out to zooz on the "'normal' inclusion doesn't seem to respect the protocol=1 flag" issue. I suspect it's a bug in the ZST39, or undocumented behavior in SILabs' reference design.

The big issues for @AlCalzone right this second are:

Opinions on API changes for how to indicate include/exclude longrange/normal.
Opinions on names. There's a mix right now of lr*, *LR* and *LongRange*.
I haven't taken any stabs at test coverage yet... if you have preference for what and how much, let me know.

There's a ton of BUGBUG/TODO comments right now, I've tried to explain in comments what the questions/issues are.
There's also pre-existing tests that appear to be broken by this. I'll need to look into those.

With the ZST39/ZEN32 I was testing, I have to say "long range" currently looks like an over-promise/under-deliver situation. I got about twice the range of the normal AEOTEC stick in a similar location. While that's good, the star network topology means that the overall network reach is going to be smaller. It's a big shame that they didn't allow for routes, or expand the spec to allow for more than the ~240 nodes in the mesh topology. My signaling environment hasn't been optimized at all, and I am indoors, but I'd hoped for better. 👎

AlCalzone · 2023-10-16T13:23:35Z

@jtbraun thanks for this! I'll make sure to take a good look at it soon and give you some feedback, I'm currently dealing with all the weird controller firmware issues that cause problems with the new "unresponsive controller" recovery feature.

Just FYI if it wasn't clear - the ZWaveProtocolCC stuff is mostly used internally and for testing, as these classes are normally used by the controller under the hood. We use it in a few locations to hack our way around missing features in the Serial API.

AlCalzone

Thanks a lot for this. I've tried to answer most of the questions so you can finally continue. I'll probably have to play with this a bit to see how it all works out before we can merge it.

AlCalzone · 2023-10-24T09:54:57Z

packages/cc/src/cc/ZWaveLRProtocolCC.ts

@@ -0,0 +1,238 @@
+import {


This may be used in our testing framework, but unless you're sure about these things, I'd leave it out for now.

AlCalzone · 2023-10-24T09:57:33Z

packages/cc/src/cc/Security2CC.ts

+	if (nodeIdSize == 1) {
+		ret[offset++] = sendingNodeId;
+		ret[offset++] = destination;	
+
+	} else {
+		ret.writeUint16BE(sendingNodeId, offset);
+		offset += 2;
+		ret.writeUint16BE(destination, offset);
+		offset += 2;
+	}


Suggested change

if (nodeIdSize == 1) {

ret[offset++] = sendingNodeId;

ret[offset++] = destination;

} else {

ret.writeUint16BE(sendingNodeId, offset);

offset += 2;

ret.writeUint16BE(destination, offset);

offset += 2;

}

ret.writeUIntBE(sendingNodeId, offset, nodeIdSize);

offset += nodeIdSize;

ret.writeUIntBE(destination, offset, nodeIdSize);

offset += nodeIdSize;

AlCalzone · 2023-10-24T10:06:14Z

packages/cc/src/lib/_Types.ts

+export enum ZWaveLRProtocolCommand {
+	NOP = 0x00,
+
+	// BUGBUG: all defined above, can they be shared?


Leave separate IMO, or leave it out completely together with the CC

AlCalzone · 2023-10-24T10:07:23Z

packages/core/src/capabilities/CommandClasses.ts

@@ -130,6 +130,7 @@ export enum CommandClasses {
 	"Z-Wave Plus Info" = 0x5e,
 	// Internal CC which is not used directly by applications
 	"Z-Wave Protocol" = 0x01,
+	"Z-Wave Long Range Protocol" = 0x04,


The specs call it "Z-Wave Long Range" Command Class, let's stick to that.

AlCalzone · 2023-10-24T10:11:52Z

packages/core/src/capabilities/NodeInfo.ts

 		// Read either the normal or extended ccId
 		const { ccId: cc, bytesRead } = parseCCId(payload, offset);
 		offset += bytesRead;
 		// CCs before the support/control mark are supported
 		// CCs after the support/control mark are controlled
+		// BUGBUG: does the "mark" and support/control convention apply to isLongRange?


parseCCId should take care of that.

packages/zwave-js/src/lib/serialapi/capability/GetSerialApiInitDataMessages.ts

packages/zwave-js/src/lib/serialapi/capability/LongRangeSetupMessages.ts

AlCalzone · 2023-10-24T11:42:56Z

packages/zwave-js/src/lib/serialapi/capability/LongRangeSetupMessages.ts

+// BUGBUG:  move someplace common, see Spec 4.2.5
+//
+// Although, that section refers to a "callback message", and SetZWaveLongRangeChannel doesn't define a callback message...
+export enum ResponseStatus {
+	FAILED = 0x00,
+}


It's supposed to be used with messages that then have a callback message, so that a failure can stop the callback from occuring, but this message doesn't have a callback message...

In that case the response indicates the final result of the command flow, not the callback.

I don't think we need the enum value or a separate field. Just do this like we do here for example:
https://github.com/jtbraun/node-zwave-js/blob/d1e23fc6a2e58c15eff86d31cf78951d8b62476b/packages/zwave-js/src/lib/serialapi/capability/SerialAPISetupMessages.ts#L899-L907

AlCalzone · 2023-10-24T11:44:05Z

packages/zwave-js/src/lib/serialapi/capability/LongRangeSetupMessages.ts

+const LONG_RANGE_SHADOW_NODE_IDS_START = 2002;
+const NUM_LONG_RANGE_SHADOW_NODE_IDS = 4;


same as the others I suppose -> packages/core/src/consts/index.ts

AlCalzone · 2023-10-24T11:44:54Z

packages/zwave-js/src/lib/serialapi/capability/LongRangeSetupMessages.ts

+const LONG_RANGE_SHADOW_NODE_IDS_START = 2002;
+const NUM_LONG_RANGE_SHADOW_NODE_IDS = 4;


IMO if we have these messages, we should expose an API on the controller for them.

…call up

packages/core/src/capabilities/NodeInfo.ts

AlCalzone · 2024-01-16T13:32:54Z

I've updated the logic to pass the protocol selection using the provisioning entry. LR Inclusion is done exclusively via SmartStart, so this is how to include a LR node:

		driver.controller.provisionSmartStartNode({
			dsk: "...",
			protocol: Protocols.ZWaveLongRange,
			securityClasses: [SecurityClass.S2_Authenticated],
		});

Exclusion works as usual, no changes needed there.

IMO all that's missing now is a bit of cleanup and consistency - I'll do this tonight probably.

Thanks for the amazing head start @jtbraun

jtbraun · 2024-01-16T13:36:47Z

I've started taking a look at this again. @jtbraun if you don't mind, I'll take this PR over.
Thanks for the amazing head start @jtbraun

I don't mind at all, and you're very welcome, I'm happy to have helped.

outdated

AlCalzone

TODO:

split the methods in packages/core/src/capabilities/NodeInfo.ts into LR / classic
move long-range related methods out of GetSerialApiInitData.ts
fix parsing of GetNodeInfoResponse - currently it doesn't know whether the node it is for is ZWLR or classic
documentation

jtbraun · 2023-10-17T12:12:28Z

packages/serial/src/parsers/SerialAPIParser.ts

+					case 0x86: {
+						// This is _maybe_ a corrupted ACK byte from a ZST39 after a soft reset, transform it and keep it
+						this.logger?.ACK("inbound");
+						this.push(MessageHeaders.ACK);
+						break;
+					}


This is fixed in #6409. I'll need to remove this and rebase here.

jtbraun · 2023-10-24T12:20:03Z

packages/core/src/capabilities/NodeInfo.ts

-	while (offset < payload.length) {
+	let listEnd = payload.length;
+	if (isLongRange) {
+		validatePayload(payload.length >= offset + 1);
+		const listLength = payload[offset++];
+		listEnd = offset + listLength;
+		validatePayload(payload.length >= listEnd);
+	}
+	while (offset < listEnd) {


You're right, that the length check could be moved to the caller.

jtbraun · 2023-10-24T12:21:37Z

packages/core/src/capabilities/NodeInfo.ts

@@ -215,34 +230,49 @@ export type NodeInformationFrame =
 export function parseNodeProtocolInfo(
 	buffer: Buffer,
 	offset: number,
+	isLongRange: boolean = false,


See specs\Z-Wave Stack Specifications\Z-Wave and Z-Wave Long Range Network Layer Specification.pdf. Long Range added their own Node Information Frame Command in section 6.3.1.2. The non-long-range frame (section 4.3.2.1) has 3 bytes for Basic/Generic/Specific device classes, and then a list of command classes for the remainder of the packet.

The long range frame has Generic and Specific device class bytes (no basic), and then a byte that is the "command list length" (in bytes, as I recall), and then the list of command classes.

Why they felt the need to replace these fields and add the seemingly redundant length, I'm not sure.

If we don't need/want the long range command class in this change (it wasn't needed to get pairing and comms to work). I think this stuff can be backed out.

jtbraun · 2023-10-24T12:25:09Z

packages/zwave-js/src/lib/controller/Controller.ts

+				this._supportsLongRange = resp == RFRegion["USA (Long Range)"];
 			} else {
 				this.driver.controllerLog.print(
 					`Querying the RF region failed!`,
 					"warn",
 				);
+				this._supportsLongRange = false;


Oh really? When I was playing around separately with ser2net, soft resetting the controller would cause it to de/re-enumerate over USB. That would cause the file handle ser2net had open to error out, which caused ser2net to close the TCP connection, and then zwave-js/ui would get upset that the ser2net socket disappeared out from under it.

jtbraun · 2023-10-24T12:26:29Z

packages/zwave-js/src/lib/controller/Controller.ts

+			const lrChannelResp = await this.driver.sendMessage<GetLongRangeChannelResponse>(new GetLongRangeChannelRequest(this.driver));
+			lrChannel = lrChannelResp.longRangeChannel;
+
+			// TODO: fetch the long range max payload size and cache it


Ah, so that method probably needs updated to take a isLongRange boolean, and return this value if set?

packages/zwave-js/src/lib/controller/Controller.ts

jtbraun · 2023-11-15T14:06:39Z

packages/zwave-js/src/lib/controller/Controller.ts

+		// BUGBUG: fix me
+		// if (options.isLongRange && !this.isLongRange()) {
+		// 	throw new ZWaveError(
+		// 		`Invalid long range inclusion on a non-LR host`,
+		// 		ZWaveErrorCodes.Argument_Invalid,
+		// 	)
+		// }
+		const isLongRange = this.isLongRange();
+


Filling in from elsewhere:

yes, LR inclusion MUST be smart start only

LR nodes will send both normal and LR prime messages, and its up to the user/controller to respond to one or the other. So the DSK-providing API will need to include a "use LR" boolean that we honor. If the user sets it to a value that's not supported, we should probably just not include the node.

jtbraun · 2023-11-15T14:07:32Z

packages/zwave-js/src/lib/controller/Controller.ts

+		this._inclusionFlags = {
+			highPower: true,
+			networkWide: true,
+			protocolLongRange: isLongRange,
+		};


Does it hurt to just leave all these here, rather than have many places we set highPower/networkWide to true?

jtbraun · 2023-11-15T14:07:48Z

packages/zwave-js/src/lib/controller/Controller.ts

 				new AddNodeToNetworkRequest(this.driver, {
 					addNodeType: AddNodeType.Any,
-					highPower: true,
-					networkWide: true,
+					...this._inclusionFlags,


yes, I'll clean this up.

jtbraun · 2024-01-17T14:43:41Z

packages/zwave-js/src/lib/serialapi/application/ApplicationUpdateRequest.ts

@@ -28,7 +28,7 @@ import { buffer2hex, getEnumMemberName } from "@zwave-js/shared";
 export enum ApplicationUpdateTypes {
 	SmartStart_NodeInfo_Received = 0x86, // An included smart start node has been powered up
 	SmartStart_HomeId_Received = 0x85, // A smart start node requests inclusion
-	SmartStart_HomeId_LongRange_Received = 0x87, // A start start long range note requests inclusion
+	SmartStart_LongRange_HomeId_Received = 0x87, // A start start long range note requests inclusion


Looks like I left a typo in this comment.

AlCalzone · 2024-01-17T14:53:03Z

@jtbraun not sure if you just reviewed or Github is acting up - the review comments you supposedly added 6 minutes ago are weeks/months old.
Anyways, just to avoid any conflicts - I'm working on this and will deal with the remaining issues.

jtbraun · 2024-01-17T17:09:23Z

I think what happened is:

I had started an old review with a LOT of comments detailing questions for other reviewers (you).
I never hit the "complete review" button, so you likely never saw any of those comments :-(
I saw a typo in some of the code you edited today/yesterday that originated from me, so I commented about it so you'd see it, and closed my review.
Presumably because of all the above, you got spammed with a ton of comments from me, instead of the one thing about typos.

Re: typo: Search for "// A start start" in packages/zwave-js/src/lib/serialapi/application/ApplicationUpdateRequest.ts

AlCalzone

The most recent PR fixes/refactors the node protocol info parsing. The specs are a bit confusing, but all fields are always there. It's just the actual NIF that's transmitted that doesn't have everything.

However, parsing a GetNodeProtocolInfoResponse currently doesn't know whether it should interpret the contents as ZWLR or ZW classic.

TODO:

fix parsing of GetNodeInfoResponse
documentation

@jtbraun

This release adds support for Z-Wave Long Range thanks to the amazing work of @jtbraun. Application developers planning to add support should read [this](https://github.com/zwave-js/node-zwave-js/blob/release-12.5.x/docs/getting-started/long-range.md) to get started. ### Features * Support Z-Wave Long Range (#6401) ### Config file changes * Add 2nd product ID for Ring Panic Button Gen2 (#6595) ### Changes under the hood * Fix compatibility of ESLint plugin with Node.js 18 (#6580)

@jtbraun

This release adds support for Z-Wave Long Range thanks to the amazing work of @jtbraun. Application developers planning to add support should read [this](https://zwave-js.github.io/node-zwave-js/#/getting-started/long-range) to get started. ### Features * Support Z-Wave Long Range (#6401, #6620) ### Config file changes * Remove Association Groups 2 & 3 from AEON Labs DSB09 (#6691) * Correct group 3 label for GE/Enbrighten 26931/ZW4006 (#6703) * Add new Fingerprint for Ring Contact sensor (#6676) * Preserve root endpoint in Vision ZL7432 (#6675) * Add new Product ID to Fibaro Smoke Detector (#6603) * Add Product ID for Benext Energy Switch FW1.6 (#6602) * Add fingerprint for Ring Glass Break Sensor EU (#6590) * Change MH9-CO2 Temperature Reporting Threshold step size to 0.1 (#6581) * Add new product ID to Fibaro FGS-213 (#6576) * Add units, improve descriptions for Everspring ST814 (#6712) * Label and parameter definitions for Sensative Drip 700 (#6514) * Override supported sensor scales for HELTUN HE-ZW-THERM-FL2 (#6711)

jtbraun added 11 commits October 15, 2023 09:26

feat(workaround): zst39 workaround for corrupted soft reset ack

666257e

feat(longrange): add FunctionType values

acfb9ea

fix(functype): add comment about source of FunctionType=0x28

5f81ca9

feat(longrange): support encoding/parsing node information

b4ddd89

These are the new function types for the long range controllers

feat(longrange): handle node ids > 256 in S2 auth data

5eb0762

feat(longrange): add long range command class

fcaacb3

feat(squash): with other ZWaveLRProtocolCC.ts changes

29ef9af

feat(squash): with other index.ts changes

1b56690

feat(squash): with other Constants.ts

63d142b

feat(squash): with other Protocols.ts

6005dfa

feat(longrange): the bulk of long range support

cd27d02

jtbraun changed the title ~~Feature/longrange~~ feat(longrange): support for long range controllers/devices Oct 16, 2023

fix(lint): lint errors

8f15e3a

github-advanced-security bot found potential problems Oct 16, 2023

View reviewed changes

packages/zwave-js/src/lib/controller/Controller.ts Fixed Show fixed Hide fixed

jtbraun marked this pull request as ready for review October 16, 2023 02:03

jtbraun commented Oct 16, 2023

View reviewed changes

fix(lint): lint errors

d1e23fc

AlCalzone previously requested changes Oct 24, 2023

View reviewed changes

jtbraun added 5 commits November 15, 2023 05:00

Merge remote-tracking branch 'upstream/master' into feature/longrange

70038ab

feat(longrange): remove corrupted ack workaround

9b679c3

feat(longrange): remove ZWaveLRProtocolCC

9637127

feat(longrange): remove "Protocol" from the LR CC name

8223ee9

feat(longrange): move NodeInfo parsing/encoding changes one function …

e8f9023

…call up

github-advanced-security bot found potential problems Nov 15, 2023

View reviewed changes

packages/core/src/capabilities/NodeInfo.ts Fixed Show fixed Hide fixed

packages/core/src/capabilities/NodeInfo.ts Fixed Show fixed Hide fixed

jtbraun added 2 commits November 15, 2023 05:14

feat(longrange): expand LR to LongRange in smart start messages

02052ef

feat(longrange): remove comment about long range CC

c9184ef

AlCalzone added 5 commits January 16, 2024 21:44

refactor: cleanup, prevent managing routes for LR, highlight some FIXMEs

8715fce

chore: more cleanup

f9585f0

fix: default to the first supported protocol

fe446eb

chore: rework controller info message

79b1a6a

refactor: rework initialization sequence

8f22fd1

AlCalzone changed the title ~~feat(longrange): support for long range controllers/devices~~ feat: support Z-Wave Long Range Jan 17, 2024

AlCalzone requested changes Jan 17, 2024

View reviewed changes

jtbraun commented Jan 17, 2024

View reviewed changes

fix: restore original encoding of GetSerialApiInitDataResponse

a42243d

AlCalzone added 3 commits January 17, 2024 21:57

fix: typo

683db90

fix: split GetLongRangeNodes into own file, fix query loop

ea170ce

fix: node info parsing

f226a82

AlCalzone requested changes Jan 17, 2024

View reviewed changes

AlCalzone added 3 commits January 18, 2024 14:19

fix: remember node ID when requesting protocol info

1e09888

fix: cleanup

098b8d1

docs: add documentation

c58c2fa

AlCalzone changed the base branch from master to release-12.5.x January 19, 2024 12:16

Merge branch 'master' into pr/jtbraun/6401-1

01039de

AlCalzone approved these changes Jan 19, 2024

View reviewed changes

AlCalzone enabled auto-merge (squash) January 19, 2024 12:20

AlCalzone merged commit 3fd27bc into zwave-js:release-12.5.x Jan 19, 2024
14 checks passed

This was referenced Jan 19, 2024

ZWave Long Range Support #5253

Closed

switching to 16-bit node IDs is currently done twice during startup #6158

Closed

		// BUGBUG: how much of this can we share with existing stuff? Can we use a ZWaveProtocolCCNodeInformationFrameOptions field to do the `isLongRange` stuff?
		// BUGBUG: how much can we share also with the Smart Start things below that are VERY close to this stuff?

		const LONG_RANGE_SHADOW_NODE_IDS_START = 2002;
		const NUM_LONG_RANGE_SHADOW_NODE_IDS = 4;

feat: support Z-Wave Long Range #6401

feat: support Z-Wave Long Range #6401

Conversation

jtbraun commented Oct 16, 2023 • edited by AlCalzone Loading

jtbraun left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jtbraun commented Oct 16, 2023

blhoward2 commented Oct 16, 2023 • edited Loading

jtbraun commented Oct 16, 2023 • edited Loading

AlCalzone commented Oct 16, 2023 • edited Loading

AlCalzone left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlCalzone commented Jan 16, 2024

jtbraun commented Jan 16, 2024

AlCalzone left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AlCalzone commented Jan 17, 2024

jtbraun commented Jan 17, 2024 • edited Loading

AlCalzone left a comment • edited Loading

Choose a reason for hiding this comment

jtbraun commented Oct 16, 2023 •

edited by AlCalzone

Loading

blhoward2 commented Oct 16, 2023 •

edited

Loading

jtbraun commented Oct 16, 2023 •

edited

Loading

AlCalzone commented Oct 16, 2023 •

edited

Loading

AlCalzone left a comment •

edited

Loading

jtbraun commented Jan 17, 2024 •

edited

Loading

AlCalzone left a comment •

edited

Loading