[X] I am not using Home Assistant. Or: a developer has told me to come here.
[X] I have checked the troubleshooting section and my problem is not described there.
[X] I have read the changelog and my problem is not mentioned there.
Deploy method
Docker
Z-Wave JS UI version
9.13.1.b613753
ZwaveJS version
12.9.1
Describe the bug
When editing a provisioning entry for a normal node, I am allowed to change the protocol from Z-Wave to Z-Wave Long Range (ZWLR). At least with this device, it causes the inclusion to fail and it will repeat this continuously. There is no indication in the UI that this is happening, so it just appears like the node never joins. It's only visible with driver logs.
To Reproduce
Add a QR code for a normal ZW device
Edit the QR entry and notice you can switch to ZWLR. Switch it to LR and save.
Notice the node never includes, see errors in driver logs.
Expected behavior
I would expect that a device that does not claim to support ZWLR should not be allowed to be configured with ZWLR protocol. E.g. the menu option should not be visible for these nodes.
And/or the driver should provide some feedback that a node is joining with the wrong protocol?
But, I don't know if there are LR devices that are missing the supported protocol information. Should some kind of force override be allowed in that case? What if a vendor adds LR support in a firmware update (per DrZwave you can OTA devices in the field to add ZWLR)? Are they required to generate a new QR code for you? The existing QR code would be missing the protocol info.
So you can see there is no supportedProtocols field that lists Long Range as available, it's simply omitted. I would presume this means LR is not supported, otherwise it would indicate so.
I added the QR code, and you can see the same in the debug logs, no support for LR:
Now I power on the node and can see it attempts to join, but the driver ignores it. This particular device will continue this non-stop.
2024-05-31T05:42:34.317Z SERIAL « 0x012100498500001aedaa9f62120407015e858e595586725a73809f71873070846 (35 bytes)
c7a1d
2024-05-31T05:42:34.319Z SERIAL » [ACK] (0x06)
2024-05-31T05:42:34.322Z DRIVER « [REQ] [ApplicationUpdateRequest]
type: SmartStart_HomeId_Received
remote node ID: 0
NWI home ID: 0xedaa9f62
basic device class: 4
generic device class: 7
specific device class: 1
supported CCs:
· Z-Wave Plus Info
· Association
· Multi Channel Association
· Association Group Information
· Transport Service
· Version
· Manufacturer Specific
· Device Reset Locally
· Powerlevel
· Battery
· Security 2
· Notification
· Indicator
· Binary Sensor
· Configuration
· Wake Up
· Supervision
· Firmware Update Meta Data
2024-05-31T05:42:34.323Z CNTRLR Received Smart Start inclusion request
2024-05-31T05:42:34.323Z CNTRLR NWI Home ID not found in provisioning list, ignoring request...
I go back and edit the provisioning entry to switch back the protocol to ZW, and it includes successfully.
2024-05-30 22:45:12.777 INFO Z-WAVE: Success zwave api call getProvisioningEntries [
{
dsk: '58377-61804-47150-09794-28074-40802-36595-16642',
securityClasses: [ 1, [length]: 1 ],
version: 1,
requestedSecurityClasses: [ 1, 0, [length]: 2 ],
genericDeviceClass: 7,
specificDeviceClass: 1,
installerIconType: 3078,
manufacturerId: 634,
productType: 28672,
productId: 57345,
applicationVersion: '1.30',
manufacturer: 'Zooz',
label: 'ZSE41',
description: 'Open/Close XS Sensor',
status: 0,
protocol: 0
},
[length]: 1
]
2024-05-31T05:45:24.597Z DRIVER all queues busy
2024-05-31T05:45:24.599Z SERIAL » 0x0103003bc7 (5 bytes)
2024-05-31T05:45:24.600Z DRIVER » [REQ] [GetBackgroundRSSI]
2024-05-31T05:45:24.606Z SERIAL « [ACK] (0x06)
2024-05-31T05:45:24.606Z SERIAL « 0x0107013b9596969ec9 (9 bytes)
2024-05-31T05:45:24.607Z SERIAL » [ACK] (0x06)
2024-05-31T05:45:24.607Z DRIVER « [RES] [GetBackgroundRSSI]
channel 0: -107 dBm
channel 1: -106 dBm
channel 2: -106 dBm
channel 3: -98 dBm
2024-05-31T05:45:24.609Z DRIVER all queues idle
2024-05-31T05:45:25.064Z SERIAL « 0x012100498500001aedaa9f62120407015e858e595586725a73809f71873070846 (35 bytes)
c7a1d
2024-05-31T05:45:25.065Z SERIAL » [ACK] (0x06)
2024-05-31T05:45:25.067Z DRIVER « [REQ] [ApplicationUpdateRequest]
type: SmartStart_HomeId_Received
remote node ID: 0
NWI home ID: 0xedaa9f62
basic device class: 4
generic device class: 7
specific device class: 1
supported CCs:
· Z-Wave Plus Info
· Association
· Multi Channel Association
· Association Group Information
· Transport Service
· Version
· Manufacturer Specific
· Device Reset Locally
· Powerlevel
· Battery
· Security 2
· Notification
· Indicator
· Binary Sensor
· Configuration
· Wake Up
· Supervision
· Firmware Update Meta Data
2024-05-31T05:45:25.068Z CNTRLR Received Smart Start inclusion request
2024-05-31T05:45:25.068Z CNTRLR NWI Home ID found in provisioning list, including node...
2024-05-31T05:45:25.069Z CNTRLR Including SmartStart node with DSK 58377-61804-47150-09794-28074-40802-36595-1
6642
2024-05-31T05:45:25.070Z DRIVER all queues busy
2024-05-31T05:45:25.071Z SERIAL » 0x010d004ac801edaa9f620ef3410374 (15 bytes)
2024-05-31T05:45:25.072Z DRIVER » [REQ] [AddNodeToNetwork]
action: Add Smart Start node
NWI Home ID: 0xedaa9f62
high power: true
network wide: true
protocol: Z-Wave Classic
callback id: 1
2024-05-31T05:45:25.077Z SERIAL « [ACK] (0x06)
2024-05-30 22:45:25.078 INFO Z-WAVE: Controller status: Secure inclusion started
Checklist
Deploy method
Docker
Z-Wave JS UI version
9.13.1.b613753
ZwaveJS version
12.9.1
Describe the bug
When editing a provisioning entry for a normal node, I am allowed to change the protocol from Z-Wave to Z-Wave Long Range (ZWLR). At least with this device, it causes the inclusion to fail and it will repeat this continuously. There is no indication in the UI that this is happening, so it just appears like the node never joins. It's only visible with driver logs.
To Reproduce
Expected behavior
I would expect that a device that does not claim to support ZWLR should not be allowed to be configured with ZWLR protocol. E.g. the menu option should not be visible for these nodes.
And/or the driver should provide some feedback that a node is joining with the wrong protocol?
But, I don't know if there are LR devices that are missing the supported protocol information. Should some kind of force override be allowed in that case? What if a vendor adds LR support in a firmware update (per DrZwave you can OTA devices in the field to add ZWLR)? Are they required to generate a new QR code for you? The existing QR code would be missing the protocol info.
Additional context
I ran driver code to decode the QR code:
The output is:
So you can see there is no
supportedProtocolsfield that lists Long Range as available, it's simply omitted. I would presume this means LR is not supported, otherwise it would indicate so.I added the QR code, and you can see the same in the debug logs, no support for LR:
But then edit the entry and am allowed to change it:
The logs confirm the change was made, now protocol is LR.
Now I power on the node and can see it attempts to join, but the driver ignores it. This particular device will continue this non-stop.
I go back and edit the provisioning entry to switch back the protocol to ZW, and it includes successfully.
Attached is a fully log of the above activities.
zwave.log