[OBSOLETE] Lock User Management (LUM)

Thanks now I think I can get rid of my virtual switches!

2 Likes

Hi @maddie & @RBoy:

In my environment, I have two Yale YRD446-NR-605 locks and one Yale YRL220 lock. Thankfully, I never, ever, ever have any issues with user-configuration-request loops with the YRD446 locks whenever I make any changes or upgrade to your SmartApp. But with YRL220, I unfortunately almost always do. The one certainty I’ve been able to confirm is that the YRD446 locks do not ever require me to clear user codes — updating your app simply works just fine without that additional step. By contrast, the YRL220 does require that I always clear all user codes with each and every minor change (i.e. hitting “Save”) or upgrade to your app. It’s a painful process since there are a bunch of users, and while I do wonder if there is anything that can be done to overcome that (aside from disabling re-verification, since that seems like it would introduce a different concern, especially in this case where I have a user that never gets added), there is one remaining issue that I can’t seem to overcome: a user-configuration-request loop with the YRL220 for a scheduled user. This is a newer feature for me that I’ve only begun using recently, but with the recent upgrade to v06.02.00 even after clearing all users from the lock, it doesn’t seem to accept the one scheduled user—only the 6 permanent users.

3:51:07 PM: debug Schedule A active Front Door to add Package Delivery Companies to user 7, code: XXXXXX, because it is scheduled to work between [All Week]: 07:00 CST to 22:00 CST 
3:51:07 PM: debug Requesting Front Door to add active scheduled Package Delivery Companies to user 7, code: XXXXXX
3:49:54 PM: debug Front Door user 7 Package Delivery Companies schedule C not defined
3:49:54 PM: debug Schedule A active Front Door to add Package Delivery Companies to user 7, code: XXXXXX, because it is scheduled to work between [All Week]: 07:00 CST to 22:00 CST 
3:49:54 PM: debug Front Door user 7 Package Delivery Companies schedule B not defined 
3:47:58 PM: debug Schedule A active Front Door to add Package Delivery Companies to user 7, code: XXXXXX, because it is scheduled to work between [All Week]: 07:00 CST to 22:00 CST
3:47:58 PM: debug Requesting Front Door to add active scheduled Package Delivery Companies to user 7, code: XXXXXX
3:46:43 PM: debug Requesting Front Door to add Package Delivery Companies to user 7
3:46:43 PM: debug Front Door user 7 Package Delivery Companies no schedule C defined
3:46:43 PM: debug Front Door user 7 Package Delivery Companies no schedule B defined
3:46:43 PM: debug Front Door user 7 Package Delivery Companies schedule A is scheduled to work between [All Week]: 07:00 CST to 22:00 CST
3:46:43 PM: debug Front Door user 7 Package Delivery Companies schedule A is scheduled to work between [All Week]: 07:00 CST to 22:00 CST

It just means that your YRD220 lock is having trouble with your z-wave mesh and other lock isn’t. The app doesn’t differentiate between locks or models, it’s agnostic. The only difference is in the lock itself and the z wave mesh setup. Two most common reasons:

  1. Weak mesh - the lock should be no further than 20 from the nearest repeater (not hub, but a repeater, the more repeaters in the mesh the stronger the mesh)
  2. Defective Z-Wave module - know to happen, some locks have defective modules. Since they are both yale locks try to swap their z-wave modules or request Yale to send you a replacement z-wave module, they’re usually very good with it

That one problematic code just indicates that the lock is either losing it’s command or the response in the mesh which could be due to the reasons above. Try to delete the one code and recreate it. Also try using a different code for that user (some locks have issues with using a certain combination of numbers across users, just to rule out that quirk).

First and foremost, thank you so much for the quick reply.

Starting with the good news, changing the code resolved the problematic code which was never getting added that had previously resulted in a config loop.

With regards to the overarching problem that any upgrade or minor configuration change to the SmartApp requires a manual deletion of all user codes, I should share a couple of additional data points:

  • I actually manage two independent SmartThings hubs/networks, and by sheer coincidence, both networks have the exact same lock inventory (2 x YRD446 deadbolts and 1 x YRL220 handle/lever lock).
  • The Z-wave modules are unfortunately proprietary between the two lock models, meaning that it is impossible to interchange the Z-wave module between a YRD446 and a YRL220.
  • Here is the kicker: The behavior is exactly the same across both networks and both types of lock models, meaning that in both networks, the YRD446 deadbolts update effortlessly without any manual intervention, whereas again in both networks, the YRL220 lever-locks are guaranteed to result in configuration loops for all user codes which were not previously deleted prior to hitting “Save” in the SmartApp for any reason whatsoever—a full clear is required in both independent systems for the YRL220 locks each and every time an update is made.
  • The YRL220 locks are actually closer to the nearest repeater (within 10 feet) than the YRD446 deadbolts are (within 15-20 ft).

In addition to the above, I did have a quick follow-up question for you: When the SmartApp is saved and user codes are sent as requests to the lock, when the initial request is logged to the live log (and Notifications in the SmartThings app) the actual code itself is not included when it prints the log entry. However, each subsequent request does print the code itself to the log. That is how I can instantly tell I am in a config loop
 when I start seeing actual user codes in the log. Is that intentional behavior? I only ask because seeing a log that is overrun with codes in plain-text every couple of minutes feels a little uncomfortable from a security perspective :slight_smile: That said, I fully realize the codes themselves are visible in plain-text via the SmartApp itself, so it’s perhaps a moot point ultimately.

It could be the Z-Wave modules on the 220’s.

All debug logs, it runs every few minutes to check the health of the system. Those are to help us make sure the platform timers haven’t died, data isn’t corrupted etc. The logs are ONLY visible to ST staff and the owner of the account (you) so it’s pretty secure. We’ve included a warning as well for users who are looking at the logs to ignore it:

warn IF YOU’RE LOOKING THROUGH THESE DEBUG LOGS READ THIS BEFORE PROCCEDING. THIS CODE RUNS EVERY FEW MINUTES IN THE CLOUD TO ENSURE THAT IT IS HEALTHY. THE APP DOES NOT COMMUNICATE WITH THE LOCK UNLESS YOU SEE A ‘INFO’ MESSAGE BOX SAYING ‘REQUESTED LOCK TO XXXXX’.

RE: the Logging: Makes sense. That said, the same messages also flood the mobile SmartThings app under the three bars in the upper left-hand corner -> Notifications. But then again, if a user has access to the mobile app, then they also have access to the SmartApp config where they can dig up the same details.

Just to clarify, when you say it could be the Z-Wave modules on the 220s: Are you thinking that this may be expected behavior for this specific type of Z-wave module and there’s nothing that can be done about it from a SmartApp coding perspective? Or are you thinking that the Z-wave modules I received just happened to both be defective?

Just noticed some IDE displayed text that’s a bit confusing. We have a Schlage Connect which can be locked from the outside using the Schlage logo. The SM app displays this as “locked via keypad” which is helpful as you know someone has left the home and locked it from the outside. However, the IDE Events text states “locked manually”, which is the same as if it had been locked from the inside.

Can this be changed, so the IDE text states something more helpful like " locked via keypad" or if the user enters a code to lock it from the outside “locked via keypad by XXXX” ? Pretty sure it used to say something like this.

tagging @RahulVaish - this is to do with the device handler and the patch has been submitted to ST

New update?

Hi @RBoy — Just a quick bump on this question to seek clarity on what you meant by this. Thanks!

It could be either way. If two 446’s work good and two 220’s are spotty, honestly, without getting in deep to analyze it would be speculation as there could be multiple reasons. Maybe both the 220’s are suffering from signal reflection where they are located and the 446 are optimally positioned. It could be the z wave modules have different firmware which could explain why they react differently in the same mesh or just could be you have two bad pieces. You would need to logically eliminate the variance for each of these possibilities to conclude why the 446 and 220 are behaving slightly differently in your setup.

We’re exiting about an upcoming update, so much work and testing has gone into this - we’ve been hearing all your feedback, put the app through a user experience lab and it’s going to be such much faster and smoother


1 Like

Updated SmartApp and DTH. I get an error that 'Something’s Wrong. We can’t load your screen right now" in the smart app. The log shows:

1be85814-4500-4b8a-abaf-e58cfd5e92e7  11:24:51 AM: error groovy.lang.GroovyRuntimeException: Ambiguous method overloading for method java.lang.Math#min.
Cannot resolve which method to invoke for [class java.math.BigDecimal, class java.lang.Integer] due to overlapping prototypes between:
[double, double]
[float, float] @line 190 (doCall)
1be85814-4500-4b8a-abaf-e58cfd5e92e7  11:24:51 AM: trace Front Door Lock has max users: 30

Try to update the code again (07.00.01), we can’t replicate the issue but have put in a workaround anyways.

That worked. Thanks for the prompt reply and fix.

1 Like

The update doesn’t seem to work with Smart Locks anymore. With the previous versions the codes would show up in Smart Locks. Isn’t happening with 7.X I got notice codes were deleted and now the device shows 2 codes unset in the IDE
image

Smart Locks stopped reporting the correct status on the main page of the dashboard after the last update and in conjunction with the last ST Mobile update. Several other people reported this as well. Nothing to do with this update.

Try uninstalling and reinstalling Smart Locks first.

1 Like

I’m aware, but lock status is not what i’m referring to.

Deleting and re-installing and setting up this app seems to have done the trick with codes not showing in Smart Locks. The name of the code still doesn’t show in Smart Locks, it just says “Code 1”.

Sorry was just making point that Smart Locks is jacked up period prior to the update.

Was it slot 1 and 2 that it was complaining about?

Go into the rboy app and rename those codes and Save again. See if they get reflected and updated in Smart Locks now that you have reinstalled that.