@bthrock you may be interested in this driver. @philh30 is fixing what the team at SmartThings didn’t.
I didn’t know that… Could you capture logs while triggering it and PM them to me?
1 Like
From where did it get the name ‘Jake’? Is it from previous designation through groovy app like rboy’s?
Thanks. I’ve been flipping back and forth between stock and @philh30 's driver almost daily in my testing, but wasn’t aware of any ongoing update efforts. Thanks for bringing this to my attention.
I had forgotten about getting “locked out” after three attempts. I’m also curious if and/or how this might be reflected in the logs. Let me know if you find something, otherwise I’ll take a look at the logs myself when I have time later today. Could be useful.
1 Like
Still present with reloadAllCodes and requestCode commands. This affects the BE469 only, not the ZP.
I think @orangebucket may be onto something with regard to the codeNames that would preclude the need for adding another custom capability to the driver. See his two posts here. This is over my head, but thought it might be worth a look.
What @orangebucket found is fixed in the beta - that’s what’s allowing “Jake” to show. There’s still something wrong (maybe something similar) in the lockCodes defaults.
3 Likes
Can I make a suggestion to change something in the details. Change the label “Code name used to unlock” to “Last code used to unlock” or “Last code name used to unlock”.
Also listing the last method used would be nice as well.
What’s showing currently when it’s locked? Or when unlocked manually? I tried to have it show Locked if locked, the method if no user code for unlock, and the code if unlocked by one.
That is the correct behavior. However if you unlock it with the app, no information is provided by the lock.
{"thing":"Garage Door Lock",
"attribute":"lock",
"state":"unlocked",
"method":"",
"codename":"",
"codeid":""}
So maybe add a label if method code name and code ID are all blank have it display " App"
1 Like
I do hope so, and it may be irrelevant to anything going on in this thread, but it remains in the libraries that were uploaded to GitHub last week.
1 Like
@orangebucket Fixed in the beta driver currently being tested/discussed in the thread. Definitely still a problem in the Lua libs. Thanks for identifying the issue and sharing!
1 Like
Ah yes, I forgot I’d found myself in a different thread.
Gotcha. I just saw the new “unlockCodeName” capability and assumed that was part of the fix. I hadn’t had time to delve into the capability itself.
Thank you so much for working on this.
I also jumped to the conclusion that it would fix that part. Thinking it through though, it has to be happening in the handler for the User Code command class.
Yep. When I switched to the beta driver, all my lock code names were reset. It’s nice that @philh30 is providing the fix for unlock events, but it’s generally broken in the library and needs to be fixed there to handle all the use cases.
I’ve gotten in trouble myself that way. Worse is conflating a forum thread and PM. 
Either way, I hope somebody at SmartThings is looking at your fix for the stock driver.
2 Likes
Do you have both? It’s a bit odd that you’d see the behavior on the older one and not the ZP model - they both use the same handlers. The only difference would be that they probably have some differences in the z-wave commands they use. Could you capture logs on both models when you trigger the function(s) that reset the code name?
Nothing is jumping out at me in default handler, but there are a lot of moving parts. One possible cause, since you said you’ve been swapping drivers, is that the driver stores and retrieve code names by using set_field and get_field. Those values aren’t supposed to persist when you swap drivers, so it would make sense if that’s what clears the codes. A test to see if that’s the only cause of this would be to trigger the function that normally resets the name. Then name a code. Then trigger it again. All while using the same driver. If that’s the root cause though then I would expect both models to behave the same…
I have one BE469 and the rest are BE469ZP. And this behavior has struck me as terribly odd. I never saw this when I was using the RBoy DTH.
Sending them now via PM.
I followed the same procedure on both. (a) Swap to beta driver, (b) reset all code names, (c) requestCode per test above, (d) reset codeName - only on BE469, (e) run requestCode 5 again.
Once again, only the BE469 cleared codeName 5.
1 Like
@philh30 I had to remove and renter new codes in SLGA. Not a big deal. After that everything works as expected on BE469. This is what is showing in SLGA history which is match what is showing in your custom field
Locked and unlocked Manually is on inside.
Locked by Master code is locking on keypad from outside.
Unlocked by Names is on keypad from outside.
This is history from the lock.
For now works as expected. 
I have tested couple automations, and they all work fine.
Thank you very much.