So I’m having some issues getting my Kwikset lock to take a 3rd code from the RBoy Lock Management SmartApp, and they suggested I ask here…
Here is essentially what I’m seeing in the logs from SmartApp and DHT:
8:34:31 AM: debug Requesting Front Door Lock to add permanent code Steveggggg to user 3, code: 557755
8:34:31 AM: debug Invalid Input: Unable to set code 3 to 557755
And for reference, here was my quick discussion over there:
I’m not in a place to be able to do detailed troubleshooting (you’ll have to wait until next week) however I will need some information from you. Please PM me the live logs for your lock. Go into IDE, go to live logs, then try and add the third code. I’ll need a capture of the output for your lock device. Hopefully it will be an easy fix.
To all. I will be limiting my support for this DTH with the release of SmartThings new lock code features. As it is, I have limited availability to locks for thorough testing. However, this DTH should continue to work with @ethayer and @RBoy’s custom lock code apps. Feel free to continue to ask for support, it just may not be in a timely manner.
As a note, since SmartThings has no Yale feature timetable, I plan to incorporate the Yale additional features to the new ZigBee lock DTH if I have time. It will be a separate release from this one.
It would have been nice if SmartThings updated DTHs followed the same format for lock code methods so they worked naitively with your SmartApp.
(www.rboyapps.com - Making SmartThings Easy!)
Yes, I had submitted a few pointers later year, looks like they took the general direction but went with their own convention. Anyways, it’s not drastically different. It’s mostly compatible, just a few tweaks and it’ll be ready to work with the new handler. However my bigger concern is an issue in the handler for which I’ve submitted a patch and as soon as that’s accepted it’ll be compatible with the SmartApp.
(www.rboyapps.com - Making SmartThings Easy!)
Just a quick note, the updated versions of the User Lock Code Management and User Unlock/Lock Notifications and Actions SmartApps are now compatible with the stock SmartThings ZigBee device handlers AND @jhamstead’s Universal ZigBee device handlers.
You can now use either one and get access to all the functionality including code based lock actions (i.e. run custom actions when users use their codes to lock the door).
Multiple responses can be returned from the lock for identical events or the responses are not needed for DTH functionality. Because of this, the DTH ignores them.
The ZigBee lock standard has three different responses: operational, attribute and command. Most devices only have attribute and command responses.
Attributes are the current value of a ZigBee setting. Attributes send responses when they change or a certain time has passed based on how you bind to them. Normally, since we actively bind or query an attribute, these responses are never ignored.
Command responses are replies from the device after issuing a command. Since many commands perform some type of action (such as lock or unlock) attributes may change. Often we just utilize the attribute response and ignore the command success response. This is what you are seeing above.
Locks have special operational responses to different actions that are always sent without needing to bind to them. For example, which code is used during an unlock. Some of those responses we use, others we ignore.
@jhamstead - hi the title says DEPRECATED - tried to scan the thread to understand why its deprecated and if there is a newer version that is available, couldn’t figure it out. Would appreciate it if you can explain that. Would be even better if you can edit the top post and point to replacement if there is one.
Hello @enis. Unfortunately I have not had a lot of time recently to work on SmartThings. The main reason I deprecated this code is that it doesn’t follow the new standard for the lock code capability (SmartThings removed the capability documentation some time ago and changed it with their recent lock releases). At some point I may have time to get back to this but the code should be stable with @RBoy’s lock management.
Also at one point SmartThings actually had a DTH with all of the features of this one at the time I deprecated this code. Unfortunately they’ve pulled that code and I didn’t get a copy of it before the removal. I have not heard of anyone else pulling a copy.
Any idea why I’m seeing my battery level showing 194%? The DTH seems to work well otherwise. I’m using the RBoy smartapp for programming. Does this have something to do with what you mentioned above about not following the new lock capabilities maybe?
Do you have one of the new Yale Assure locks with ZigBee? I have not seen anyone using one of them yet. The old Yale ZigBee locks mistakingly sent 00 - 100 for battery life. The ZigBee spec is actually 00 - 255. As a workaround in this DTH, Yale locks were calculated differently from other locks. I’m guessing Yale must have fixed the problem.