ZWA-2 receives Z-Wave LR SmartStart request but rejects it because S2 Authenticated LR key is “not configured”

Configuration Z-Wave
1

Hello,

I am looking for assistance with a Z-Wave Long Range inclusion problem on my production Home Assistant system.

Environment

  • Home Assistant OS
  • Home Assistant Connect ZWA-2 / NC-ZWA-9734
  • Z-Wave JS UI
  • RF region: USA / Long Range
  • Existing standard Z-Wave network is working normally
  • Home Assistant, the Z-Wave app, and the controller show no available updates

Problem

I cannot add any Z-Wave Long Range devices through SmartStart on my production system.

The SmartStart entry is recognized as Long Range, but the inclusion is rejected. The Z-Wave JS log repeatedly shows:

Received Smart Start inclusion request (Z-Wave Long Range)

Ignoring inclusion request because the following security classes were granted
but have no key configured:

S2_Authenticated (Long Range)

The log also occasionally reports:

NWI Home ID not found in provisioning list, ignoring request.

What makes this unusual

  1. The Z-Wave JS UI settings page shows that the Long Range security-key fields are populated.
  2. The controller initializes successfully and reports that it supports Long Range.
  3. The controller is using the USA Long Range region and the LR channel is set to Auto.
  4. I have tried multiple Z-Wave LR devices, including Minoston devices, with the same result.
  5. The exact same LR devices and QR codes successfully join as Long Range devices on a separate Raspberry Pi 4 Z-Wave JS UI test system.
  6. Existing Z-Wave devices on the production network remain online and controllable.

This appears to rule out the devices, their QR codes, and basic LR compatibility.

Troubleshooting already completed

  • Backed up Home Assistant and the Z-Wave controller
  • Uninstalled and reinstalled Z-Wave JS UI
  • Restarted Home Assistant
  • Allowed the existing network to finish loading and interviewing
  • Confirmed that existing devices returned and are controllable
  • Confirmed that the LR security-key fields are populated
  • Confirmed that no updates are currently available
  • Removed and recreated SmartStart entries
  • Selected Long Range as the protocol
  • Activated the SmartStart entry
  • Repeated the test with multiple LR-capable devices

I have not factory-reset the ZWA-2 because the production Z-Wave network otherwise works and I do not want to destroy the network unnecessarily.

Questions

  1. Could the running Z-Wave JS driver be loading a different configuration or store directory from the one displayed in Z-Wave JS UI?
  2. Is there a known issue where the LR key appears populated in the interface but is not passed to the driver?
  3. Could reinstalling or restoring Z-Wave JS UI leave the Long Range key in an incompatible or unused configuration field?
  4. Is there a safe way to verify that the running driver actually loaded the S2_Authenticated_LongRange key without exposing the key itself?
  5. Would migrating from Z-Wave JS UI to the current Home Assistant Z-Wave JS app correct this without rebuilding the existing network?
  6. Are there additional diagnostics or configuration files I should provide?

I have attached:

Thank you for any assistance.

2

I wanted to close this out with the fix that worked for me.
Setup
Home Assistant
Home Assistant Connect ZWA-2
Z-Wave JS UI 11.19.1
Z-Wave JS driver 15.24.2
ZWA-2 firmware 1.2
Existing network of roughly 40 Z-Wave devices
Problem
Z-Wave Long Range SmartStart inclusion repeatedly failed with an error indicating that the LR S2 Authenticated key was not configured.
However, a Driver Function check showed that both LR keys were correctly saved and loaded:
lrAuthenticatedOption: true
lrAccessControlOption: true
securityManagerLR: false
The controller was also being reported as:
controllerRole: 2
isPrimaryFlag: true
isSecondaryFlag: false
isSIS: false
isSUC: false
sucNodeId: 1
After factory-resetting the ZWA-2, the controller temporarily reported role 0, created the LR security manager, and LR inclusion worked. Restoring my original NVM brought all my existing devices back, but after restarting Z-Wave JS, the controller returned to role 2 and LR stopped working again.
Root cause
The restored network had incorrect or missing SUC/SIS controller-role metadata. The adapter was physically the primary controller, but Z-Wave JS classified it as an Inclusion Controller and therefore did not initialize securityManagerLR.
Fix
After making a fresh NVM backup, I ran the following through:
Z-Wave JS UI → Advanced → Driver Function
const { logger } = this;

const c = driver.controller;

const before = {
role: c.role,
ownNodeId: c.ownNodeId,
wasRealPrimary: c.wasRealPrimary,
isSIS: c.isSIS,
isSUC: c.isSUC,
isSISPresent: c.isSISPresent,
sucNodeId: c.sucNodeId,
};

let commandSucceeded = false;
let error = null;

try {
commandSucceeded = await c.configureSUC(
c.ownNodeId,
true,
true
);
} catch (e) {
error = String(e);
}

const result = {
before,
commandSucceeded,
error,
};

logger.info(SUC SIS promotion result: ${JSON.stringify(result)});
return result;
The command succeeded. After restarting Z-Wave JS UI, the controller reported:
controllerRole: 0
isSIS: true
isSUC: true
isSISPresent: true
sucNodeId: 1
securityManagerLR: true
Z-Wave Long Range SmartStart inclusion then worked successfully, while all existing mesh devices and automations remained intact.
I also confirmed the fix survived:
A full Home Assistant hardware shutdown and restart
Stopping and starting Z-Wave JS UI
Additional LR device testing
I created a new NVM backup immediately after confirming the fix. Anyone attempting this should make a current NVM backup first, since configureSUC() changes controller network-role metadata.