I have been using the RBoys Lock User Manager with my Yale z-wave lock for about 7 years and it has worked just fine in all that time. It even survived without problem. the SmartThings platform migration and change away from the SmartThings Classic app a while back.
A couple of evenings ago I received notifications in the LUM SmartApp running in SmartThings for every access code set in the lock saying “Code changed”. I was not making any updates to the lock codes at the time and not making any other updates to my SmartThings hub and devices. (I almost never do because everything is set up just how I need it). Neither was I making any changes actually on the physical lock.
On further investigation in the Lock Manager in the SmartThings App, for every user code there is a warning message “Back Door Lock IS CONFIGURED TO ACCEPT 0 DIGIT CODES ONLY, PROGRAMMING WILL FAIL!”.
I have checked the lock itself and the codes I set are all still working which seems to suggest that I may only run into a problem if I need to add/delete/update a code. I also noticed that unlock notifications no longer show which code was used for the unlock action.
I seem to recall all codes get reprogrammed even when only changing a single code, so I am really reluctant to make a change just to see what happens in case that ends up bricking the lock.
I can’t work out whether this is a problem with the physical lock, the SmartThings driver or Rboys LUM. One thing I did notice is that the driver information suggests LUM is using a driver from SmartThings. I seem to remember under the old platform I had to install a driver which I got directly from Rboys. Maybe this changed when the platform migration happened but I don’t remember having made a change myself.
I contacted Yale and they say the error message does not come from the lock, so I’m guessing either the SmartThings driver or Rboys LUM is generating the message based on a status code received from the lock. I have mailed support requests to Rboys and SmartThings (no response yet) so just wondering if anybody on the forum can give any pointers to help me debug and fix this problem.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
3
That notification wasn’t from LUM but from SLGA. When SmartThings migrated your lock from DTH to Driver, SmartThings forces the driver to reload all the codes from the lock and it ends up reporting each programmed code as a notification. It not new codes, just reporting existing codes.
You can use SLGA or even LUM if it’s working and it shouldn’t affect the lock operations.
@RBoy Thanks for the reply but I have some follow up observations and a whole bunch more questions
Didn’t the migration from DTH to Driver happen months ago? This issue only happened suddenly last week. Prior to that the codes were all still visible in LUM settings on the SmartThings app but now they aren’t, just the error message. Does this suggest some behind the scenes changes by SmartThings triggered the problem?
When I look at the device attributes in my.smartthings,com it says the code length is 0 and all the code positions just have the word “Code”. That seems to align with what I am seeing in the LUM smartapp UI.
I ran the setCodeLength command to set the length to 4 but nothing happened and the value remained as 0. (I tried other values as well in case the lock insisted on something other than 4).
I ran the lock and unlock commands to check whether commands were being sent and both executed successfully.
Are the attributes listed in the screenshot specific to LUM and in some way redundant since SLGA was introduced?
Does this suggest that I should switch to using SLGA for setting the code length and managing user codes?
Can I safely use SLGA and LUM to control lock settings or will that result in some kind of “deadly embrace” with the two apps in conflict?
Sorry if all that sounds dumb but obviously this is a home security issue for me so I really want to be clear in my own mind about what the problem is and what I need to do to fix it.
Thanks for your help.
RBoy
(www.rboyapps.com - Making SmartThings Easy!)
5
Everything looks fine above. Yale locks don’t support a fixed code length which is why you can’t use that command. The actually migration took place last week and most folks got the same message when the driver refresh was kicked off. When the migration kicked off the names were replaced with numbers because of the way ST has designed the new platform, unlike the old one it doesn’t preserve data while switching drivers.
If LUM is still working for you, you can continue using it and SLGA until the replacement is available.
Ah ok - sounds like it was as I thought, a behind the scenes update triggered the messages. Would have been good to get some notice of what would happen and when but I understand that sometimes things get overlooked.
Just to update. I tried to set up to use SLGA alongside LUM but without success. To get SLGA to pair with the lock it seems I have to first disconnect the lock from the SmartThings hub and then use SLGA to reconnect it. I’m anticipating that it won’t be that simple in reality but I don’t have time to do that right now so I’ll have to come back to it later.
Current status is I can’t use LUM to add or update codes because a code of length > 0 is rejected but I can do it through ST Web App Advanced settings although new and updated codes don’t synch back to LUM. e.g. I used ST Web App Advanced to add a new code and code slot name to an unused slot and this was successfully set in the lock and it works. But in LUM the code slot and values are still listed as empty.
I am also not able set a user type other than Permanent because this functionality doesn’t seem to be available in ST Web App Advanced and because I cannot create/update a user with code length > 0 I cannot achieve it by using LUM. For the same reason I can’t use LUM to define custom actions and notifications for any existing or new user.
None of this is ideal but I can live with it for the time-being. @Rboys - did I understand correctly there is a new version of LUM in the works which is likely to fix all these issues with the ST driver?
I fixed the problem by installing the migrated legacy driver Universal Enhanced Z-Wave Lock from RBoys. All LUM functionality seems to be restored.
Not sure how I missed this migrated driver but I’m very happy to have found it since I learnt while investigating this issue that the Smart Lock Guest Access app provided by ST is not available/supported in my country (UK). So without the legacy driver it seems there was basically no alternative app to provide the same functionality.
