@RBoy can you tell me what field is missing? I can’t change any value in the DH because it is asking for a field that is required.
[RELEASE] Enhanced ZigBee Keypad Lock - Centralite, Lowe IRIS, UEI and Xfinity Keypads Device Handler
@RBoy I also am still getting the “too many invalid user codes detected” error. This is a secondary code that I created to arm/disarm versus just opening or closing the garage door. Opening the door only works fine, but the code to arm the system is where I see the error
That message is coming from the keypad, you aren’t entering the code properly (i.e keypad doesn’t recognize a valid entry).FYI keypads only accept 4 digit codes
Thanks - I did verify that I was entering the code correctly and it is only 4 digits but I will try removing the code and adding another one to see if that helps.
@RBoy Is it possible for this DH to show correctly in the SmartLocks SmartApp from SmartThings? My Yale locks do with the tweak to the device name in the code, but can we do the same for this as well?
Same way, rename the DTH:
I couldn’t get this to work with arnb’s SHM Delay 2.0 app. Is there something I should do to make it work?
Enhanced ZigBee Keypad Lock - Version 01.01.02
- Fix for deleteCode() not working as expected when code doesn’t exist
@RBoy I just installed today an Iris Keypad and a Schlage door lock with your handlers and smartapp. Almost everything seems to be working perfectly except for the fact that I cannot disarm the SMH with the Iris keypad nor the Schlage door lock if the status is Armed (Away). It can be disarmed perfectly if the SMH status is Armed (Stay). Please take a look at these two short videos to see what I mean. Thank you.
I tested this about 20 times in different combinations and different keypads and it’s working fine here. It arms and disarms SHM as per the keypad buttons.
The option that was enabled was the Control SHM using the keypad in the User Management SmartApp
I did notice a few things however, sometimes the platform was slow to update the state (it would take up-to 5 seconds, most times it was instant). In one or two tries it didn’t update to and I had to repeat the keypad before it updated the state.
So I’m guessing this is a internal platform timing/issue, the app is sending the command to the platform.
I am unable to create new codes using Smart Locks. The Smart App shows "The Lock Code couldn’t be created and the log shows “Iris 3405-L Keypad is not ready for code creation as the lockCodes attribute is null”.
Same result but the logs now show this:
11:43:22 AM: debug Lock code set failed…
11:43:22 AM: debug Sending lockCodeChanged event with name - lockCodeChanged12 and value - 1 set failed 12
11:43:22 AM: debug 6. Checking event history for 1 set
11:43:17 AM: debug 5. Checking event history for 1 set
11:43:12 AM: debug 4. Checking event history for 1 set
11:43:07 AM: debug 3. Checking event history for 1 set
11:43:02 AM: debug 2. Checking event history for 1 set
11:42:57 AM: debug 1. Checking event history for 1 set
11:42:52 AM: debug Event Type: Enhanced ZigBee Keypad Lock
11:42:52 AM: debug In codeChangedHandler with event value := 1 set, displayed: true
11:42:52 AM: debug Setting code slot 1 with code name Todd in Garage Keypad
11:42:52 AM: debug Garage Keypad is ready for code creation as the lockCodes attribute is already populated
Smart Locks lists the lock code but it doesn’t seem to work on the keypad. I tried removing the device altogether and adding it back with the same result.
Replicated it, looks like SmartLocks has made some recent changes to how it expects the DTH to behave. Will release an updated version of the DTH to make it compatible with SmartLocks again. This is specific to SmartLocks and doesn’t affect other User Management SmartApps.
Enhanced ZigBee Keypad Lock - Version 01.02.01
- Updated DTH to comply with the new SmartLocks requirements
- Basic support for the new ST app (full support in the Classic app)
Real-time Updates With SmartLocks
TIP: While this device handler is compatible with SmartLocks, if you would like to see real time updates to the dashboard in Smart Locks (locking, unlock etc), change the name of the device handler in metadata section around
line 59 from
name: “Enhanced ZigBee Keypad Lock”
name: “Z-Wave Lock”
Publish -> viola, real time updates in SmartLocks
Is it feasible to replace Smart Locks with your manager?
Yes it supports any ST compliant User Management SmartApp (see 1st post for details). There are bunch of different user management apps depending on your needs
e.g. Basic User Management, Multi User Management, Rental Lock Automater (AirBnB/VRBO) and ofcourse SmartLocks.
You can use SmartLocks in conjunction with any of the existing RBoy Apps user management apps to “view” your users (don’t use multiple user management apps to create/modify users).
I’ve found a new issue. I don’t think the pad is completely pairing when I add it. After pairing, the network light continues to flash indefinitely. I can see activity in the log such as motion detection and adding lock codes but the light still flashes. If I momentarily pull the battery, the light stops flashing but so does all the activity.
Also found that the setting page for the handler will not save even when the settings are all populated. mejifair described this in post #32 above.
@ToddS I think the issue is that the default options for the keypad when the DH is setup are not valid to be saved. I removed all of the decimal points and was able to save everything without issue.
Yeah it looks like a bug in the ST Android mobile app, it should not be using a decimal point or even allow the user to enter a decimal
. (the default values don’t contain decimal points but the ST Android app seems to be adding it by itself)
You should report it to ST support that the ST Android Classic app doesn’t honor honor the input type
number in a DTH preferences and instead adds a decimal to the default integer value, which then leads the page throws an error while trying to save it.
EDIT: In your report to ST support reference ticket #595080 so hopefully they can prioritize it based on demand (this is a regression bug)