Well, my Wi-Fi (Plume) hub finally updated to 47.10 and promptly reset all my lock code names to “Code X”. This release was supposed to prevent that, but apparently whatever they changed in the default handler may not have set well with the Z-Wave Lock PH Edge driver (or something in the cloud was reset by the library changes in this release).
Oddly, it only happened on one of my locks. However, if I issue a requestCode command from the Advanced Web App or the CLI, the codeName is also reset to “Code X”.
With some more tinkering, I found that the lockCodes.lockCodes capability was not populated with my previous set of lock code names. For my one lock, once I changed the name from “Code X” to its proper code name for each slot, subsequent requestCode and reloadAllCodes commands did not reset the code names.
For my other lock, there was a code name set for the slot I did the requestCode command, but none in the other slots. I could not set the code name using the nameSlot command or SLGA until I did either a requestCode for the slot or reloadAllCodes which then set the code slot name to “Code X”. Once I repopulated the names for all the slots on that lock, subsequent requestCode and reloadAllCodes commands did not reset the code names for that lock either.
I also did a reboot of my hub after resetting all my lock code names and they were preserved over the reboot.
@nayelyz Can you confirm with the team if indeed the lockCodes.lockCodes capability was cleared out in the cloud as a result of the changes in the library for this release to fix the lock code names being reset to “Code X”?
Do all your devices use the Community driver from @philh30? @philh30, I bring you into this conversation to get more info about how you handle the events of adding codes to the lock.
Are you using only the default handlers or do you make any other configuration on your side?
It enhances the stock zwave-lock driver, which has quite a few instances where the default handlers aren’t used (see below). When I’ve looked at this before, it seemed like the root cause of the user code names resetting was that whoever wrote the default handlers couldn’t decide whether code_id should be an integer or a string. Compounding that, @h0ckeysk8er has a lock model that has buggy special handling in the stock driver. I took a quick look this morning and I don’t see any new improvements in the stock driver or the default handlers. Tough to tell though since the way ST posts the Lua libraries doesn’t provide a change log.
