[RELEASE] Enhanced ZigBee Keypad Lock - Centralite Keypad, Lowe IRIS Keypad, UEI Keypad and Xfinity Keypad Device Handler

[LLwarrenP]

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?

[maddie]

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

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.

[LLwarrenP]

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.

[maddie]

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

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.

[LLwarrenP]

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.

[maddie]

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/Partial button directly to arm it
• To Disarm enter the 4 digit pin and press the OFF button
• After installing the DTH/device, open the device preferences page (gear icon 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

[Steven-Pierce]

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?

[maddie]

The V3 device behaves differently from the V2 devices. From the release post above:

NOTE :

• This device does NOT use a pin/user code to Arm (ON/Partial). You press the ON / Partial button directly to arm it
• To Disarm enter the 4 digit pin and press the OFF button

[arnb]

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.

[maddie]

The keypad does not use codes for Arming (away or partial).
However if SHM Delay requires a pin we can have the DTH report 0000 as the default pin when armed using this keypad model.

This won’t impact the functionality of other apps such as Lock User Managment or SmartLocks and they will continue to work (i.e. direct arming without pin codes but need a pin code to disarm)

Do note however that the keypad does not accept or report a pin while arming as this is how the hardware is designed.

[arnb]

Do note however that the keypad does not accept or report a pin while arming as this is how the hardware is designed.

I don’t like the fact that anyone can arm the system. It makes no sense to me.

This contradicts the device’s product description

• Arm and disarm your Iris smart home security system with personalized access codes for several users
• Receive alerts from Iris when a user arms or disarms your system

[LLwarrenP]

I’d say that being able to have PIN-less arming is fine as I don’t see a disadvantage other than a child doing it and causing the sirens to go off and so on. Granted you might want to know who armed it but really all you probably care about is that it is armed.

In other news, I just dumped the V2 Centralite and got the V3 iMagic GreatStar (really, WTF?). It’s acting odd (misbehaving and seems to have a poor connection) for me with the @RBoy DTH but I’ll need to collect some more data and possibly do a reset before I comment further.

[LLwarrenP]

@maddie I’m having little to no joy with the Iris v3 Keypad. I did a reset and the behavior is the same afterwards so something is funny…either I am doing something wrong, there is something up with the way that the keypad is working with Lock User Manager, or maybe a bad unit.

Setup:
I did the join per the updated instructions at the top of the thread. Unit blinks blue, I pair, and then I set the battery option (Alkaline). To keep it simple I am using the latest Lock User Management for these tests and I set up a new user that is only applicable to the keypad and at the bottom of the user profile I select the Custom actions/notifications and have Unlock Actions options “Disarm SHM” and “Control SHM” as well as Lock Actions options “Arm SHM to Away” and “Control SHM” all enabled and that is it. At this point the battery light glows green, the Iris logo purple, and the pairing light is off when I wave my hand in front of the keypad. In the IDE, I get motion active events. All is seemingly good.

DTH Use:
From the device view, if I press either the Beep or Alarm button, the device responds as expected. I can also see the current temp and battery without issue. If I do a lock, the SHM tells me it is Armed (Stay). If I do an unlock, the SHM tells me it is Disarmed. Seems good so far.

Keypad Use:
With the SHM Disarmed, I press the On button on the keypad and SHM tells me it is Armed (Away) and the DTH shows Locked. I then enter the user code and Off but nothing appears in the logs except some Motion Active events. I also notice that the On, Partial, and Off buttons all blink red at the same time. This seemed odd to me but after some period of time (or keystrokes, not sure) I tried it again and it disarmed. I tried this a few times and each time, the On button works immediately and the Off button does seemingly nothing. No errors in the IDE for the DTH or LUM. At some random point later, the unlock does work.

I’m at a loss. It’s like the keypad goes into some mode and has to do a reset before it will talk to the hub again or something but I just don’t know.

[RBoy]

I then enter the user code and Off but nothing appears in the logs except some Motion Active events. I also notice that the On, Partial, and Off buttons all blink red at the same time

When all 3 lights (On, Partial and Off) are blinking, this means the keypad has lost communication with the zigbee mesh. This is confirmed by your first statement that nothing appears in the logs. If the keypad is connected to the mesh you should always see a log entry, even if the code is invalid. We internally refer to this as a “stuck” keypad.
There are a few ways to “unstuck” the keypad (i.e. resume communication with the mesh)

1. Bring the keypad closer to the hub
2. Remove the battery from the keypad for a few seconds and then re-insert it (this forces it to reestablish a connection). Then tap the refresh tile on your ST mobile app to resync the settings
3. Finally reboot the hub and check your ZigBee mesh repeaters or maybe add one

The v3 keypad is little more sensitive to the mesh than the v2. I’ll also update the instructions in the first post to reflect to how handle a “stuck” keypad which has lost comms.

[LLwarrenP]

Ok, I did the refresh. I’ll see if that has any long term help.

It’s not encouraging if it’s losing signal as it is about 10 feet from the hub and about 3 feet from a Halo device. I like the look of the newer one but I may have to go back to the v2 if it’s a constant thing. And by chance I happened to do a reboot Friday due to replacing the batteries in the hub.

Also I still think it’s odd that On/arm always seems to work reliably as well as the beep and slarm but who knows.

[LLwarrenP]

So seems like the latest rev of the DTH, 01.05.04, is working much better with the v3 IRiS keypad, at least for me.

One thing that I noticed when messing with the Panic button is that if you clear the panic, which is doing an disarm / unlock, the Panic state doesn’t reset as visible in the app. You have to go into the ST app and click on the button.

Could you tweak the code to add the ability to clear the panic after a disarm / unlock? This would (apparently, from some testing I was just doing) allow it to work seamlessly with the Intruder Alert with Alarms, Lights and Camera Pictures app to trigger and silence the panic alarm from the keypad.

[mejifair]

This would be awesome!!!

[mejifair]

Also - what is the size difference between V2 and V3? I am hoping that V3 is smaller in order to fit inside a weatherproof box outside.

[LLwarrenP]

Well, if you look at the top of the thread you’ll see a summary and pics from @RBoy but sadly other than being a bit more sleek and rounded looking it’s almost the same size (approx. 3 1/8” x 4 7/8”). But, it does allow you to use regular batteries instead of the expensive CR123 ones which is a plus and the button layout is better. So cosmetic mostly. But since the v2 is on its way out you can also get it for much cheaper at Lowe’s. One negative that I have experienced is that the v3 connectivity seems to be not as great as the v2. It seems to drop its ZigBee connection and take time to regain it.

[LLwarrenP]

Could you tweak the code to add the ability to clear the panic after a disarm / unlock? This would (apparently, from some testing I was just doing) allow it to work seamlessly with the Intruder Alert with Alarms, Lights and Camera Pictures app to trigger and silence the panic alarm from the keypad.

I peeked and the change was pretty simple:

if ((device.currentValue("button") == "pushed") && (map.value == "unlocked")) clearPanic()		// Clearn panic alarm if it was triggered

This would be after line 1208 in createCodeEntryEvent(). It’s probably unnecessary to check to see if the panic was already going as you could assume you blindly want to clear it but security-wise I guess you never know was my thought.

Works nicely to stop the panic alarm for all sirens - as long as you’re using the @RBoy Intruder Alert with Alarms, Lights and Camera Pictures app or similar to stop all the sirens.