[ST EDGE] Z-Wave Lock PH

[orangebucket (Graham)]

@philh30

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!

Ah yes, I forgot I’d found myself in a different thread.

[bthrock (Bob)]

@philh30

What @orangebucket found is fixed in the beta - that’s what’s allowing “Jake” to show.

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.

[philh30]

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.

[h0ckeysk8er (Bruce Pinsky)]

@bthrock

@philh30

Fix the issue of code names being overwritten

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.

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.

[bthrock (Bob)]

@orangebucket

Ah yes, I forgot I’d found myself in a different thread.

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.

[philh30]

@bthrock

This affects the BE469 only, not the ZP.

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…

[bthrock (Bob)]

@philh30

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.

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.

@philh30

Could you capture logs on both models when you trigger the function(s) that reset the code name?

Sending them now via PM.

@philh30

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 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.

[milandjurovic71 (Milan)]

@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.

[jjsmith24 (Jeff)]

I successfully moved 3 Schlage BE469 locks to the edge drivers. Regardless of whether or not I use the Smartthing, PH, or PH Beta, I only see the first 7 slots both in SLGA and SharpTools even the codes in other slots still work. Is there some sort of arbitrary cap in what is accessible?

[General_KAOS]

@philh30 I am having a senior moment. I have 2 BE469ZP locks. On the first one, I had some issues, such as not having the chanhe driver option. After a number of attempts, I am not sure how i got it to work, but deleted the lock, readded it, and then somehow got another version of the same lock to get conne ted to your driver. Deleted original lock (again) without the change driver option. Seems to be working, other than lost names for codes on the door.
On second lock, I have added, deleted, and radded … All without any success. I moved hub near the 2nd lock.
I am running Samsung v3 on latest version.

Thanks to anyone that can help me.

Think i finally got it figured out. Need a factory reset on lock number 2.

[h0ckeysk8er (Bruce Pinsky)]

@philh30 Ok, here is one to investigate. Looks like when the door was locked manually by the turn knob, it replaced your Last Unlocked with the word “Locked”. The history shows that the field has Manual when it was unlocked. I’ve included the SLGA history as well as the lock history.

[philh30]

The logic I’m using to populate that field is:

• If locked, show “Locked” regardless of method or code used
• If unlocked by a user code, show the user code name
• If unlocked with no user code, show the unlock method
• If all of the above fail, show “Unknown”

My thinking was that you could have some weird timing results or other problems setting up an automation if you needed to use multiple different capabilities at a time, like “If Unlocked AND User code is Sally”. If the prior state is Locked/Manual and it shifts to Unlocked/Sally, it might trigger automations in that in-between state when the Unlocked event has been processed but the User code event hasn’t. Then I also figure no one really cares how the door was locked, which is how I ended up with that hierarchy.

[philh30]

These are tough to join. Bringing the hub within a few inches is my best advice.

Assuming you don’t have any custom DTHs installed that include your lock’s fingerprint and you’ve installed this driver, the lock should use the driver if it fingerprints properly. One possiblity though if it’s joining to a DTH is that the fingerprint isn’t being discovered properly - it will show as all 0s in the Groovy IDE if that’s the case. The only solution there is to rejoin.

[h0ckeysk8er (Bruce Pinsky)]

@philh30

The logic I’m using to populate that field is:

• If locked, show “Locked” regardless of method or code used
• If unlocked by a user code, show the user code name
• If unlocked with no user code, show the unlock method
• If all of the above fail, show “Unknown”

My thinking was that you could have some weird timing results or other problems setting up an automation if you needed to use multiple different capabilities at a time, like “If Unlocked AND User code is Sally”. If the prior state is Locked/Manual and it shifts to Unlocked/Sally, it might trigger automations in that in-between state when the Unlocked event has been processed but the User code event hasn’t. Then I also figure no one really cares how the door was locked, which is how I ended up with that hierarchy.

I’d be fine with the following behavior:

• Field called Code Name used to Unlock/Lock
• If locked, show the method or the user code used to lock (Manually locked, Locked by Susie, Locked with Master Code/Lock&Leave)
• If unlocked by user code, show the user code and state (Unlocked by Susie, Unlocked by Master Code)
• If unlocked with no user code, show the unlock method (Unlocked Manually)
• If all of the above fail, show “Unknown”

Or as you say, if no-one cares how the lock was locked, don’t populate the field upon locking and just leave the last unlocked method/code and don’t bother to change the field name and add the state.

[h0ckeysk8er (Bruce Pinsky)]

@h0ckeysk8er

@philh30

The logic I’m using to populate that field is:

• If locked, show “Locked” regardless of method or code used
• If unlocked by a user code, show the user code name
• If unlocked with no user code, show the unlock method
• If all of the above fail, show “Unknown”

My thinking was that you could have some weird timing results or other problems setting up an automation if you needed to use multiple different capabilities at a time, like “If Unlocked AND User code is Sally”. If the prior state is Locked/Manual and it shifts to Unlocked/Sally, it might trigger automations in that in-between state when the Unlocked event has been processed but the User code event hasn’t. Then I also figure no one really cares how the door was locked, which is how I ended up with that hierarchy.

I’d be fine with the following behavior:

• Field called Code Name used to Unlock/Lock
• If locked, show the method or the user code used to lock (Manually locked, Locked by Susie, Locked with Master Code/Lock&Leave)
• If unlocked by user code, show the user code and state (Unlocked by Susie, Unlocked by Master Code)
• If unlocked with no user code, show the unlock method (Unlocked Manually)
• If all of the above fail, show “Unknown”

Or as you say, if no-one cares how the lock was locked, don’t populate the field upon locking and just leave the last unlocked method/code and don’t bother to change the field name and add the state.

Just got a notice that the Connect Home/Wi-Fi hubs are getting an update starting today and one of the fixes is:

Fix for locks that use the LockCodes capability.

Hmmm

[JohnRichard (John Nadeau)]

@h0ckeysk8er

For both of the locks, the setting to disable “Query lock codes on refresh” will not stay set and will revert to being enabled one you leave the Settings dialog.

@philh30

Unless something has changed, the settings menu is read-only to the driver, so whatever’s happening is an app issue.

Lock Device Card > 3 Dots > Settings > Query lock codes on refresh:

I would love to be able to disable that Query lock codes on refresh. Every now & then, SmartThings/Smart Lock Guest Access queries my locks and wipes out all of the Guest Names that I’ve typed in.

Any recommendations?

[h0ckeysk8er (Bruce Pinsky)]

@JohnRichard

@h0ckeysk8er

For both of the locks, the setting to disable “Query lock codes on refresh” will not stay set and will revert to being enabled one you leave the Settings dialog.

@philh30

Unless something has changed, the settings menu is read-only to the driver, so whatever’s happening is an app issue.

Lock Device Card > 3 Dots > Settings > Query lock codes on refresh:

I would love to be able to disable that Query lock codes on refresh. Every now & then, SmartThings/Smart Lock Guest Access queries my locks and wipes out all of the Guest Names that I’ve typed in.

Any recommendations?

Yes, you must also have a value defined for lock code length. Without it, the disable refresh setting won’t stay off. Setting the code length to your current code length will not erase existing codes.

[philh30]

@JohnRichard

Every now & then, SmartThings/Smart Lock Guest Access queries my locks and wipes out all of the Guest Names that I’ve typed in.

Which model lock?

[JohnRichard (John Nadeau)]

My apologies…

Schlage BE 469 Z-Wave

[philh30]

The older non-ZP model? @bthrock has been working on the lost code names with me over PM and reports that they’re staying put now on the beta driver. I’ll move those fixes over to the non-beta driver when I have a bit of time.

For the settings menu follow @h0ckeysk8er instructions regarding filling the code length field. It’s a ST bug that you need to fully fill in any unpopulated fields in the settings menu for any changes to take - nothing I can do about it.