When I updated to JS using the native driver the ring range extender automatically interviewed and was completed in seconds. I did not have to make any setting changes.
I simply pulled the battery compartment open and left it for 10 seconds. Closed it. The device woke up and interviewed perfectly. All 6 smoke detectors switched over no problem.
I myself initiated the transition to ZWave JS yesterday round noon. I spent the latter parts of the day going around and operating battery sensors and by the time I went to bed, the ZWave settings page said all my devices were interviewed and incorporated.
When I woke up this morning, I was surprise to see
Even though many of the devices I know I personally awakened manually (at great pains sometimes).
Does anyone know why I regressed today?
@bcopeland i have my 3rd hub in the beta program, so im happy to test fixes etc if needed.
the only weirdness iāve experienced so far is on my Kwikset Home Connect 620 zwave lock using the Generic Z-Wave Lock driver. Lock code manager is not a part of my setup. The lock seemed to have dropped its lock codes during the JS update. I noticed when i tried to lock the door manually from the outside and it would respond with 3 beeps and not lock. Lock/unlock still worked as expected from hubiat.
Issue cleared once i added back my lock codes. In my case added the code back through the driver.
A couple others, including @Sebastien, reported similar issues. Tagging @bcopeland to bring it to his attention.
No need.. I found the issue for your device.. Fix is coming
The lock codes issue has been found too.. There was a change in how ZWave-JS handles user codes for newly migrated locks.. There is a config file change to prevent that from happening.
Amazing! Thank you.
Btw, the other two issues Iāve mentioned previously havenāt resurfaced for me, Zwave-JS has been rock solid and fast! 
Thinking out loud a bit, if we go back to ZIP, does that bring back the codes? In other words, roll back now, update the hub firmware with the new config file change, and then switch back to JS.
Or are the lock codes permanently hosed?
Anyone tried switching back to ZIP to see if the codes returned?
Not great for me with a C8.
Had to delete a bunch of ghost devices, pull batteries from some devices (normal wake updates didnāt work). Re-include at least 3 devices (including an old Kwikset 910 series lock) that were stuck.
It also broke some of my scene controllers:
For me, it did not. That was the first thing I tried (like 5 minutes after the initial jump to JS and I realized there was an issue)
It not only removed the codes, but it royally messed with my S2 security devices:
3 of 4 locks had a message that they had been paired incorrectly - even though device details said the handshake was good.
Go Control garage door controller spazzed out and started alarming (tamper alert).
Switched back to ZIP, had to restart (but not repair) the Go Control and the locks were still having issues.
Decided to try to go back to JS for a second attempt, and the go control was fine, but the locks were hosed up still.
Hit Configure -> Wait 30 seconds -> refresh on each lock. This removed all latent codes and fixed the security warning message. Then added codes back via LCM.
Still, the whole process took me 45 minutes. So, not that bad overall.
Does the issue affect the secure pairing by any chance?
It won't
Can you post a screenshot of those nodes on Z-Wave Details page?
They are good now and I did not get screenshots at the time. It was in the device page that I got the message. Something to the effect that this device was paired without security but requires it.
The other symptom was that pressing any button on the affected locks resulted in three beeps and no action. Could not even push the lock button.
Google said to check in the device details for the Zwave Secure Pairing Complete flag, which stated true (even though I was getting the warning)
It said the lock's database(s) had become corrupted and that to fix it, I should click configure, then refresh, and wait for refresh to update the states (which also removes all lock codes). After that, it did work fine. I just had to do it with three out of 4 of my locks. Two of the 3 were LR, the other was mesh. The one that was unaffected was LR.
The garage door (Also S2 Access Control), was also affected on the initial switch to JS.
edited to add - There haven't been any issues since I did the configure -> refresh trick. So, not having a reason to switch back to ZIP, I doubt I will see the problem again. Also, when the garage door would not shut up, I switch back to ZIP and unplugged/replugged the garage door to silence the tamper alert. Waited a few minutes and tried JS one more time. Since the garage door was playing nicely, I went ahead with the Configure -> Refresh trick and have been good since
Well, I did the update yesterday and it was - a breeze, done within an hour. Of course I had to go around and wake up all these battery devices, but it was a good opportunity to get to know the house again... 
The migration went well for me on my C-8, although waking up all the battery-operated devices was a chore. I feel like Zwave commands execute faster now, particularly those that are triggered by the hub based on Zwave signals from other devices.
Since I see other reports of devices that are no longer showing status updates @bcopeland , I will throw in my 2 cents about the problems I am having with the ZW3004 GE ZWave Plus Dimmers on any drivers that support that device. They do not show status changes on the device page unless an explicit Refresh command is issued, and they do not trigger events although they can be controlled via the hub. Here is the Zwave log from when the device is manually turned off:
And from when it is turned on:
The 2 log screenshots you showed donāt have any reports
can you turn on debug logging from the device page and try again and capture the driver logs?
Generally went well, all mains powered devices were "interviewed" ok and worked as before. Also most of the battery powered devices changed over OK once I remembered/found out how to wake them up 
. Two devices are however giving a problem. They are both Aeotec/AEON Labs 4 Button Keyfob - Gen 5 using the built in Aeon Minimote driver. They both work using legacy Z-Wave, however after changing to ZWave-JS although they pass the "interview" they fail to trigger the various button drivers/rules that worked using legacy Z-Wave. The logs for the two devices generated when each of the 4 buttons were pressed and held are below.
For Key Fob 1
For Key Fob 2
No such log entries are generated when using legacy Z-Wave as I switched back to check.
It looks like the button presses are being transmitted to the C8 but when using ZWave-JS something is being lost in "translation".
For completeness the Z-wave details page reports :-
Firmware version: 7.18.1
ZWave-JS version: 15.29.0
and I am currently running version: 2.5.2.129 on a C8.
Any suggestions as to what to try to resolve this as it appears to a an issue with the built-in driver.
08 Oct 2026 - Fixed by update to HE Release 2.5.2.134 (see below).
@mfh.fbes .. I see that problem.. Fix is coming
