I’ve had two iris keypads for a while now. Frankly they weren’t very useful til @arnb developed his SHM delay app, but now they actually work really nicely with entry and exit delays.
I don’t use the lock manager smartapp but it probably works fine with the iris keypad too.
Thank you for the positive comments regarding the SHM Delay Smartapp.
Correct me if I’m wrong, but I recall reading someplace that the Iris Keypad can be armed/disarmed without a PIN. Is this true? if you are using PINs without the Lock Manager, how are you doing that?
I’m not sure if the iris keypad can be armed/disarmed without pins.
I originally setup my keypads with @mitchp’s device handler and smartapp for the 3400 keypad, which also works with the iris keypad. IIRC the smartapp binds the disarm and two arm buttons to routines, and I created routines that arm and disarm SHM.
After you released the delay smartapp, I had to update the device handler to a newer one (can’t recall who developed that one in the interim) in order to get the beep feature to work. But I’m still using the original smartapp that Mitch released since it continues to function just fine for my needs.
If I ever decide to make things a little more complex (e.g. add some different pin codes for dog walker or housekeeper) I’ll give the lock manager smartapp a try.
I probably got ahead of myself when I picked the keypads up soon after they became available at Lowe’s a couple years ago.
My goal was to increase the WAF for arming and disarming SHM, she’s not a huge fan of using the ST app, but without delays it turned out to be not that great.
We usually only arm SHM at night when we are home (goodnight routine runs either manually when we go to sleep or scheduled around midnight), and so the keypads were still usable for disarming if the dog needed to go out late at night, for example. But there were still false alarms if someone forgot to disarm before opening a door.
Now, with the addition of your smartapp, if someone comes home late while the system is armed, or needs to go outside, we get a 10 second grace period with just the beeps from the keypad before the rest of the SHM alert notifications go off. Much more user friendly!
I’ve been using ST since June, 2017. Quickly gave up on presence as a arming / disarming option, total nightmare. Decided to use a keypad–WTF no ST support for keypads. Had to quickly learn about Community Apps, and there is a ton of outdated keypad information on the forum. Finally got the keypad working with the Lock Manager app’s Exit Delay, but with no entry delay, alarms each time I entered the house. That was not good with my newly installed 105DB Siren.
Learned about “Virtual Devices” then wrote a few Core routines to handle Entry Delay. OOPS, now there were no messages when real sensor formerly monitored by SHM was left open, another Core routine.
Decided Core was a bit slow for me, it is interpreted vs compiled, so I converted everything to SmartApps (Not sure if that’s true for WebCore). Another challenge, I never coded in Groovy or Java, but know PHP and legacy IBM mainframe Cobol and Assembler. By September 2017 I cooked everything down to the Beta Version of the current SHM Delay App.
My system now runs quite well, except for the Samsung contact sensors that on occasion refuse to work. Have my old Kindle Fire tablet up and working with ActionTiles, and just got it speaking with LanNouncer and Big Talker. Totally enjoying the audio confirmation when arming/disarming and door opens/closes. Wrote a simple Smartapp to handle Chimes and speaking when the keypad is set to ExitDelay prior to arming, otherwise Big Talker does what I need.
Time for some more new sensors and a smart Thermostadt.
The Iris, Xfinity and Centralite require an identical amount of effort and understanding.
Please visit my SHM Smartapp thread for more information about using a Keypad with ST, and creating exit and entry delays.
Take a look at Xfinity/Iris/Centralite Keypad TroubleShooting paragraph in my smart app documentation. It has information about resetting the the keypad to factory State and then connecting it to SmartThings
Ok, so I went through the troubleshooting, and was able to pair the keypad. Thanks. After adding the DH, I noticed that the temperature keeps up, and it even logs history of motion, but nothing else works. The “Motion Tile” on the app always shows motion, even when there is none. On the Device, None of the other text items show up like “Updated…” or if the state is Disarmed, Armed or anything else. I have a bad feeling the keypad I have isn’t quite the same as the one your describing. Also, I haven’t a clue on how to set the keypad code sense I reset it. I no longer have any of XFinity’s instructions, so that doesn’t help. All their docs want you to set the code from the main controller, which obviously I don’t have anymore. Do you have any ideas here? I may have to break down and buy another keypad …
Note, I haven’t written any groovy, mostly just c# and java. I may learn and see if I can tweak the DH to make it work for my keypad … unless you have a better idea.
I will need to do more digging as setting up any key codes doesn’t seem to work at all as well as most of the other features. Only the temperate and motion “kind of” work. I took a picture with my phone, but I need to push it over to my laptop. But, I doubt that will make a difference, this is a completely different make/model.
Sadly, this is the “other” keypad, which isn’t supported by my device type handler.
It might at least somewhat work if you manually change it to my device handler, if it implements the ZHA alarm device type (Protocol), but most of the things the Centrallite keypad does are “extensions” to the protocol, and not actually compliant, so I wouldn’t expect it to work well, if it works at all.
Since it pairs, its probably possible to get it to work, but I don’t think there’s a device type for the UEI/TCH keypad at the moment.
That’s what I figured. The reason I was seeing motion or anything at all is because I manually changed it to your DTH. Unfortunately, most features don’t work. In fact, the temperature was working, but today it isn’t. So, looks like I’m back to square one. @zcorneli I may try using your DTH and making one for this keypad. Any hints on where I could get some documentation on this device? Also, while watching the log output, it only sends any notifications when there is motion. Key presses and pressing any of the “home”, “away” or “night” buttons sends no codes to the DTH.
Sadly, companies like this (Centrallite, UEI, TCH) only provide their documentation to dealers / direct customers, and not to end users, so you’ll have to do some reverse engineering, and see what works, and what doesnt.
Probably the best place to start, assuming UEI at least somewhat followed the standards, would be the Zigbee IAS ACE (Intruder Alarm System Ancillary Control Equipment) zone type.
Temperature, and battery are both reported via Zigbee standards for those, so I would expect those to ‘just work’ with most Zigbee DTH’s.
As far as seeing incoming data for the key presses, etc, if it follows the Zigbee IAS standards, you’ll need to force it to join as an IAS zone. For the Centrallite keypads, that’s done by pressing the tamper switch once its paired, and I’d think the UEI would do something similar.
If everything’s working then, and it does follow (roughly) the IAS ACE standard, you should see at least something when you put in a code + home/away/night button. You might want to add a debug logging statement for the message received method, to just dump the contents of the received message.