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”
to
name: “Z-Wave Lock”
Save and 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.
2 Likes
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)
@maddie I found out that my problem was a webcore piston messing up my setup. I paused it and everything is working as it should be. Thank you for your reply.
1 Like
Will panic mode works?
If your question is does the DTH report (and display) when the Panic button on a supported keypad is pressed, yes, the DTH does that. It is reported as a button pressed event (button no 1).
You need a SmartApp that makes use of that button pressed event to do something with it (like trigger an alarm etc).
1 Like
Enhanced ZigBee Keypad Lock - Version 01.03.01
- Added support for AA Alkaline and Rechargeable (NiMH/NiCd) batteries for UEI Keypads, select the correct battery type in the device preferences page for accurate battery level reporting
- Optimized single beep for UEI Keypads
The UEI/XHK1 keypads use 4 AA batteries and last about 3-8 times longer than the other Keypads which use 2 CR123A batteries.
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 62 from
name: “Enhanced ZigBee Keypad Lock”
to
name: “ZigBee Lock”
Save and Publish → viola, real time updates in SmartLocks
1 Like
Hey @RBoy, @maddie, I’m trying to figure out some odd behavior here with the Iris CentraLite 3405-X keypad and the current status it displays.
I’m currently using the @RBoy Keypad DTH and the v07.07.06 Lock User Manager app. I’m using the app in a manner to allow for special keypad users at 4 digits while allowing the external locks to have more than 4 digits - this part is all working fine. In the app I have the Manage Users → [keypad users] → Custom actions → Keypad Unlock actions → Control SHM/ADT using keypad option enabled. I also have the General Settings → Lock/unlock actions → [keypad device] → Keypad Unlock Actions → Disarm Smart Home Monitor option enabled and the inverse Arm Smart Home Monitor to Away enabled on the Lock actions. On the keypad, when I enter the code and do an Off (Disarm), Partial (Arm-stay), or On (Arm-Away), the SHM transitions and the Iris status light is green when SHM is Disarmed and red when Armed. So far so good.
The issue is when the SHM transitions either through a manual state change in the ST app or by a phrase (Good Night!, Goodbye!, I’m Back!, etc.) the keypad doesn’t update to show the current status and it just stays in whatever mode it was last put into. So, for instance, I execute Goodbye! and SHM transitions to Armed-Away but the keypad still shows as Green / Disarmed.
I attempted to resolve this by having the various phrases execute a lock on the keypad (just like it does on the door locks) but that doesn’t seem to do anything.
In the IDE logging, when I do say a manual transaction in the ST app from Armed-Away to Disarmed, no events are written to the keypad device’s log. But, when I do a Disarm from the keypad, the SHM Disarms and I see "Sending acknowledgeArmRequest(0) " and then “Sending status to device, Arm mode: disarmed” messages in the device log.
Is there something off here or am I missing something?
That is expected behavior. DTH’s by ST’s design cannot subscribe to events (for example changing of SHM states). Hence when you manually change the SHM state the DTH doesn’t know about it and consequently it cannot change the keypad current state. It’s upto the apps (SHM) to update the keypad state.
Apps like SHM Delay on the other hand subscribe to the SHM state and update the keypad state when they detect a change. I can log this change request for LUM but the with an unlimited number of custom use actions it may be impractical to implement this.
An easy fix for this would be create a CoRE/WebCoRE piston that monitors the state of SHM and updates the keypad state with SHM.
Thanks Maddie. I thought I had read that somewhere but in this Community soup I must have lost it.
One thing I don’t quite understand is that if I have the LUM issue lock to the keypad, I do see a “Executing lock() for device [name of keypad]” but the visible state of the keypad doesn’t change. Could another alternate solution be to simply rev the DTH to update its status when it gets a lock()?
I really like the LUM app so I would love to submit an RFE to propagate status to the managed devices but I agree there is some complexity there.
So would you recommend WebCoRE over the RBoy SHM Routines, Notifications and Actions solution? Or did you mean someone else’s SHM Delay (this is my guess)? I have used WebCoRE but never used that particular RBoy app or the other “3rd-party” one so I’m curious.
Not sure what you mean by this. The lock state of the keypad updates after executing the lock command. If the screen state on the mobile doesn’t change that would likely be an issue with the ST mobile rendering server and you may need to refresh your screen or close/restart the app.
It was a bit unclear the way I wrote that but what I was mentally thinking/hoping at the time was that if I issued a lock then the DTH would initiate the SHM arm sequence on the keypad and update the visible state on the keypad itself. That probably should be the case since locking a non-physical keypad doesn’t really mean anything.
But the way the DTH is written now, it doesn’t have the capability to issue the ZigBee command to change its own visible status, even if the SHM is armed as you already mentioned. Debugging the DTH tells me it is more than possible but honestly the code is a bit of a mess in spots (missing/misnamed enum variables in the sendStatusToDevice() function for example). I was able to force it issue a command to physically change its own state but the effort would be in getting a state machine that tracks the mode carefully.
Enhanced ZigBee Keypad Lock - Version 01.05.04
- Added support for the new IRIS v3 White Security Alarm Keypad (IL021 / iL02_1) model
- Added support for Alarm capability for supported keypads (Iris v3)
The Iris v3 IL021 keypads use 4 AA batteries (Lithium, Alkaliine or NiMh/NiCD)
It also has a unique built in 80dB Alarm feature which can be activated through the tamper switch or through SmartThings UI/SmartApps as an Alarm capability device
NOTE:
- This device does NOT use a pin/user code to Arm (ON/Partial). You press the
ON/Partialbutton directly to arm it - To Disarm enter the 4 digit pin and press the
OFFbutton - After installing the DTH/device, open the device preferences page (
gearicon on the top right corner) and set the battery type (default is Lithium but many devices ship with Alkaline).
A SmartApp like Lock User Management or SHM Delay etc is required to arm/disarm SHM directly from the keypad.
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 68 from
name: “Enhanced ZigBee Keypad Lock”
to
name: “ZigBee Lock”
Save and Publish → viola, real time updates in SmartLocks
2 Likes
I can’t get my v3 iris IL021 keypad to arm stay or partial from the keypad. I can disarm but not arm. If you press either of the buttons it just says “Invalid Pin”. Anyone have any success getting a V3 Iris keypad to work properly?
I’m a bit confused here regarding the lack of a pin for arming on the V3, by simply tapping the On or Partial key. The V2 also has this feature, but it has to be activated when using SHM Delay by adding a user pin 0000. This is because the keypad hardware sends 0000 as the pin when pressing the On or Partial key without entering a pin.
Are you saying the V3 cant be armed using pin numbers? Auto arming without a pin something I won’t use, since anyone with access to the keypad is able to arm the system.
2 Likes