Hi arnb,
Thank you very much.
The steps to update the handler is
Here is the repo for the UEI version of this DTH (updated 5/10/2019)
This is a DTH for the Xfinity UEI XHK1 keypad. It is essentially the same as the modified Mitch Pond DTH but wth the battery section modified to account for the increased voltage of the batteries in the UEI.
I want to report that the mandatory updates from the repository for the Centralite device handler and for the smarttapp per ArnB’s instructions worked perfectly. My keypad is functional again! Thanks so much indeed.
I deleted all SmartApps and Device Handlers. I reinstalled all the latest SmartApps and Device Handlers.
My Iris Keypad was found instantly by Smartthings.
The app (v2.2.9) installed easily and a delay profile was made.
I do not seem to have an option for creating a User Profile. Although all the SmartApps are seen on the website, and only SHM Delay is published, I do not have the option to add users and create passcodes.
This was working before Smartthings changed their code.
I have uninstalled and reinstalled several times.
Please help!
Assuming all the modules are installed according to the instructions, please insure in Global Settings, that the “A real or simulated Keypad is used to arm and disarm Smart Home Monitor” flag is set to On/True, that should give you the ability to set keypad User Pins
Replying to a very old message, my apologies :). Are you using Hubitat next to ST for your alarm solution or is there a dedicated ‘app’ for Hubitat? I’m exploring the option to move, because of signal drops and delays influencing the reliability of my Iris Keypad and, consequently, my entire alarm system. However, I don’t quite know where to start. My ST setup is working flawlessly except for the keypad, so it’d be quite the jump.
My system is a hybrid, with two keypads and ActionTiles on ST still acting as the controller, everything else on Hubitat. I also have single keypad on Hubitat where I developed Nyckelharpa, an HSM extension. In the near future, my system will be Hubitat controlled, with a single keypad on ST. HSM is similar the SHM, but includes builtin exit and entry delays. The HE system also has full but not perfect keypad support.
From my experience, it is a timing issue impacting the keypads on ST, the devices demand a fast response message and produce a “light show” when the response is late, or fall off the network. Not much that can be done about timing when things are running in the ST cloud.
Sometimes adding a Zigbee repeater/switch device near the keypad helps.
Thx! I’ve tried a Zigbee repeater near the keypad. Last week I had to remove and add the keypad from ST a few times. I did so holding the keypad next to the ST hub. However, I’m under the impression that I have to add the keypad when it’s on its original location so it ‘learns’ to route the signal through the repeater. Since adding it near the hub I get the feeling the response time is slower, producing the light show you’re describing. Does this make sense, or is the Zigbee network more flexible than I’m assuming?
I’ll take a look at HSM and Nyckelharpa, and the amount of work it’ll take to migrate fully. I like to fiddle, but since the birth of my son there’s much less spare time available :).
That’s my understanding. I also read that over a few days time it resets to the current location.
Try searching out the threads devoted to improving and resetting the ZigBee mesh.
If you remove power from the hub (and take out the batteries on a V2 hub) for at least 20 minutes when you power the hub back up it will rebuild the zigbee mesh.
If you have zigbee smart bulbs be careful. Some are lousy repeaters. I have some smart bulbs. When I rebuild my mesh I will also remove power from the bulbs until after the mesh is rebuilt so they aren’t used as repeaters.
Thank so much!!! This worked and users were able to be set up.
I am now having a problem with the Front Door Contact Sensor triggering Intrusion Detected, even though it is removed in SHM Delay as Real Contact Sensor and Simulated Contact Sensor (ZFront Door) is monitored.
Also, is there a way to make the Keypad beep until either the siren goes off or the alarm is disarmed? (Using Iris V2 Keypad and Dome Siren)
Your quick, informative replies are greatly appreciated and thank you again!
I believe you’re missing the entry delay time probably in the delay profile
I had the entry delay set to 15 seconds. I changed it to 30 seconds, but immediately when the front door sensor was opened I still get an intruder alert. The siren still is on a delay and doesn’t go off immediately, but I need to clear the alert in the SmartThings App.
You should be getting a message from SHM stating the device that caused the intrusion. If the SHM intrusion device is NOT the Simulated Contact Sensor, then it is a problem with the SHM settings, otherwise it’s SHm Delay throwing the intrusion and when global setting is set to produce name of triggering sensor, the name of the sensor is in the SHM Delay message.
SHM requires the intrusion be cleared in order to get the next intrusion. Very old issue, will likely never be fixed.
Thanks again. When the Keypad stopped working, I reset everything, including what triggers SHM intrusion alerts. I must have set it to look at the physical contact and not the simulated contact when the system stopped working, and I never switched it off. No SHM looks at “ZFront Door” and not “Front Door” and everything is working beautifully.
Pleased that you got it working again.
I understand the SOP when something fails on ST, is to rip it out and start over. This is not a wise choice when dealing with complex apps.
Enhancements and Changes
I urge everyone to stay up to date, please update your system,
Warning
*This DTH requires module SHM Delay 2.2.9 or higher
How to Install
There is one (1) module associated with this update.
Centralite Keypad DTH Module, install, Save, and Publish for me
Install via the repository (preferred), from the following repo.
Owner: arnbme (in upper case that is ARNBME)
Name: SHMDelay
Branch: Version2
If you did not update at the prior mandatory release Update module SHM Delay.
How to change github repo for keypad DTH
Post Installation
No settings changes are required
Unable to get new DTH or SHM Delay modules with ST github interface
The source is available for manual update at
I need help with one step of the installation process. When I get to step 10. Delay Profiles I do not have the same settings available to me that is listed in the instructions. For Item 4. (Optional) When a motion sensor triggers an intrusion during an entry or exit delay: select a motion sensor device
When multiple motion sensors must be defined: set global Allow Multiple Motion Sensors to On/True
Defined motion sensors are monitored during Alarm Status: Away
Mine is worded a little different. I have (Optional) Ignore these Motion sensors during exit delay, and when the real contact sensor opens during entry delay. These sensors are monitored in Alarm State: Away (Remove from Smarthome Security Armed (Away) Monitoring). I added my two motion sensors to this and removed the motions sensors from Armed away monitoring. The motion sensors do trigger the alarm when activated, but they show up as a simulated door sensor in SHM. Is this normal or do I have the settings wrong? I would like to distinguish between door and motion sensor alarms.
When SHM Delay encounters an intrusion condition, it opens the simulated contact sensor. So if things are properly setup most all SHM issued messages would show the simulated sensor. However, to ease the process of determining the actual cause of the SHM Delay intrusion, when global associated witth “This app issues an intrusion message with name of triggering real sensor?” is on SHM Delay issue a message with the name of the sensor creating the issue. Look at the Notifications log to find the problem.
The documentation may not be 100% in agreement with the latest versions of the live modules.
When a motion sensor is defined in multiple profiles, the “I have the same motion sensor defined in multiple delay profiles…” must be set on to stop false intrusion alerts.