#ZWA-2, Z-Wave JS UI, and Kwikset 910 Locks - No S0 Security

1 messages · Page 1 of 1 (latest)

wide phoenix
#

Hi, this is both a hardware and software question please... I just upgraded from a HUSBZB-1 to a ZWA-2 and since the HUSBZB-1 needed a painful firmware upgrade to migrate I did it manually. At this same time I switched from Z-Wave JS to Z-Wave JS UI (so I temporarily could run both) and at this point removed and uninstalled the old Z-Wave JS instance. All my devices including a few battery powered ones paired pretty easily (with no security). But I have Kwikset 910 and 914 locks and having no luck with them and would appreciate any ideas.

The locks actually pair nice a quick, but they are missing attributes and not registering as actual locks. Which if I understand is because they are not pairing with security. They should pair in S0 mode but I just cannot get that to happen, here are some things I have tried:

  • Confirmed there is a S0 (and all) security keys in Z-Wave JS UI settings
  • Tried replacing the S0 security key with the old hubs key (minus the 0x hex bits)
  • Excluded the device multiple times
  • Reset the device multiple times
  • Moved the device within 1 foot of the ZWA-2
  • Included with Default mode
  • Included with Default mode and checking the box to prefer S0 over no security
  • Included in S0 mode
  • Enabled the setting "Increase node report timeout"
  • Increased the "Inclusion/Exclusion timeout" to 60

I read that even after resetting the lock it still could be linked to the old hub for security purposes? Is that true?

In the log I see timeouts:

  • Timed out while waiting for a response from the node (ZW0201)
  • Querying securely supported commands (S0), attempt 2/3 failed
  • The node was not granted the S0 security class. Continuing interview non-securely.

Thanks much for any ideas!

void trellis
#

Share a driver log of the inclusion process please. Loglevel debug.

Also try excluding it, then factory reset and try the inclusion again.

wide phoenix
wide phoenix
#

In addition to the timeouts I see in the logs "Node 87 was included by another controller". But then it continues on and tries to include it anyway, and does include it, short of failing the security checks. I have done numerous exclusions and full resets of the device... maybe there is something more to reset these things?

Or is there a way to increase the timeout window for the security communication when pairing?

fluid flower
#

Are you still running your HUSBZB-1? Can you unplug it and leave it unplugged while performing the exclude/reset/include?

wide phoenix
#

I was still running the HUSBZB-1 but no longer need it anymore as I just got my ZBT-2 and its migration went smooth. So unplugged it for good and rebooted HA. Unfortunately, after another exclusion/reset/inclusion of the lock it still does the same thing. And still see in the logs "Node 89 was included by another controller". New log attached.

Thanks for the help and ideas though, appreciate it!

📎 zwave-debug-2025-12-14T17-05-23-774Z.zip
void trellis
#

I have a suspicion that the device doesn't actually reset itself:

Cannot add node 89 as it is already part of the network.
#

it should be getting a new ID

#

although it's the same message on the previous attempt, just with a different ID

#

Can you share a driver log from the driver startup? I'd like to check something

#

not sure if that works already with the method you used to collect the logs though

#

So, I think this is just a bug. During the inclusion a command is received that normally means that a secondary controller has included a node for us.
This shouldn't be received while we're including a device, so it gets mis-interpreted.

wide phoenix
#

@void trellis, thanks much for helping! Let me know if this is not the log you are talking about, but I stopped the Z-Wave JS UI add-on, set the log level to debug, then grabbed the log from the add-on.

You mention you think it is a bug, you thinking in Z-Wave JS or in the Driver?

Thanks again!

📎 a0d7b954_zwavejs2mqtt_2025-12-16T03-19-10.590Z.log
void trellis
#

The unexpected command that is received in the middle of the inclusion process should not get received at all in that situation, so this part is possibly a bug in the firmware SDK.
How it's being handled by Z-Wave JS caused issues, but that's fixed in 15.18.0, released earlier. Just needs to be picked up by Z-UI and the addons.