[OBSOLETE] - Universal ZigBee Lock DTH with Lock Codes

Thanks for your help. PM sent.

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.

3 Likes

Great work BTW. Still a brilliant handler.

3 Likes

It would have been nice if SmartThings updated DTHs followed the same format for lock code methods so they worked naitively with your SmartApp.

1 Like

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.

1 Like

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

3 Likes

@jhamstead I got Zigbee module for an EasyAccess lock. I tried you handler and the stock handler. Both works fine with basic lock/unlock. Have not seen any battery reports yet.

I see in the livelog that its ignoring some responses from the lock, maybe you can tell me what this is?

From unlocking:

38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:01: debug parse() --- returned: null
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:01: debug parseResponseMessage() --- ignoring response - catchall: 0104 EACC 01 01 0140 00 2CA0 01 00 0000 07 01 010004
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:01: trace parse() --- description: catchall: 0104 EACC 01 01 0140 00 2CA0 01 00 0000 07 01 010004
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:01: debug parse() --- returned: null
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:01: debug parseResponseMessage() --- ignoring response - catchall: 0104 0101 01 01 0140 00 2CA0 01 00 0000 01 01 00
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:01: trace parse() --- description: catchall: 0104 0101 01 01 0140 00 2CA0 01 00 0000 01 01 00
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:00: debug parse() --- returned: [name:lock, isStateChange:true, value:unlocked, descriptionText:Dør Garasje is unlocked, displayed:false, linkText:Dør Garasje]
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:39:00: trace parse() --- description: read attr - raw: 2CA00101010800003002, dni: 2CA0, endpoint: 01, cluster: 0101, size: 08, attrId: 0000, encoding: 30, value: 02
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:38:58: info unlock() -- cmds: [st cmd 0x2CA0 0x01 0x0101 0x01 {}, delay 2000]

Locking:

38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:43: debug parse() --- returned: null
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:43: debug parseResponseMessage() --- ignoring response - catchall: 0104 EACC 01 01 0140 00 2CA0 01 00 0000 07 01 000004
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:43: trace parse() --- description: catchall: 0104 EACC 01 01 0140 00 2CA0 01 00 0000 07 01 000004
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:42: debug parse() --- returned: [name:lock, isStateChange:true, value:locked, descriptionText:Dør Garasje is locked, displayed:false, linkText:Dør Garasje]
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:42: trace parse() --- description: read attr - raw: 2CA00101010800003001, dni: 2CA0, endpoint: 01, cluster: 0101, size: 08, attrId: 0000, encoding: 30, value: 01
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:42: debug parse() --- returned: null
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:42: debug parseResponseMessage() --- ignoring response - catchall: 0104 0101 01 01 0140 00 2CA0 01 00 0000 00 01 00
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:42: trace parse() --- description: catchall: 0104 0101 01 01 0140 00 2CA0 01 00 0000 00 01 00
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:41: debug parse() --- returned: null
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:41: debug parseResponseMessage() --- ignoring response - catchall: 0104 0101 01 01 0140 00 2CA0 01 00 0000 00 01 00
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:41: trace parse() --- description: catchall: 0104 0101 01 01 0140 00 2CA0 01 00 0000 00 01 00
38900012-bc46-4cef-91c6-bbcc689dd7f6  10:41:40: info lock() -- cmds: [st cmd 0x2CA0 0x01 0x0101 0x00 {}, delay 2000]

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

Long Answer
The ZigBee lock standard has three different responses: operational, attribute and command. Most devices only have attribute and command responses.

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

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

What does internal LED do?
and was anyone able to get a vacation mode toggle added to the DTH?

The internal LED shows the status of the lock with a light. Vacation mode is implemented through the keypad disable. I just didn’t call it vacation mode.

2 Likes

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

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.

1 Like

thanks for the explanation - so this will still probably work but highly unsupported?

I’m sure I can offer some support if you run into issues but I do know it won’t work with SmartThings lock code integrations.

1 Like

That’s correct, we’re still retaining compatibility with legacy DTH’s so that customers don’t need to choose between feature and functionality. We haven’t heard of any issues with this DTH.

So when you say new standards is that published somewhere? Is there a standard way to build zigbee lock DTH in Smartthings?

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.

I’m running the older YRD 210 locks. Mine show the proper battery % using the above DTH, I have 2 of them

I’ve submitted a patch to allow users to select if they need to apply the battery fix for their lock. As per the Yale specs it reports battery in 1% increments (0x00 to 0x64) but it looks like they may have changed it.
There’s a better way to handle this in terms of identifying the model numbers and firmware versions and the automatically do it but this approach allows for more flexibility for users to handle it manually with little maintenance.