Iris Keypad stopped working recently

Devices & Integrations
1

Sometime in the last week, my Iris Security keypads have stopped working with Smart Home Monitor. I am not sure if this began with the recent ST outages and instability, or if it was before.

I was and am using the miriad/Centralite-Keypad device handler, ethayer’s lock manager, and arnbme’s SHMDelay and keypad module.

This was all working fine with my two keypads until a few days ago when we discovered the keypads weren’t changing SHM’s armed status when we enter our codes. The keypad still knows the difference between a correct and incorrect code - judging by the tones it gives. But it just doesn’t have any effect on the SHM armed status.

If I enter a correct code and “on” (which is Armed/Away), ST app shows the device in state ExitDelay, and never leaves that state. If I enter the correct code with “Partial” (Armed/Stay), it gives the success tone but no change in state.

I’ve done everything I can think of to try to clear out any bad states, with no luck. This includes:

  • Removing keypads from ST app
  • Removing/uninstalling the apps from ST android app
  • Deleting the device handler and SmartApps from IDE, re-adding
  • Readding keypads
  • Setting up apps again, with new users, codes, and slots.

No change…

Have observed logs while entering a valid code, and there’s no obvious errors, just:

8667fd89-ff2b-4092-93f3-e58ae5141236 12:19:41 AM: debug code: 1245 used: 1245
8667fd89-ff2b-4092-93f3-e58ae5141236 12:19:41 AM: debug 1245
8667fd89-ff2b-4092-93f3-e58ae5141236 12:19:41 AM: debug code: 1245 used: 1245
8667fd89-ff2b-4092-93f3-e58ae5141236 12:19:41 AM: debug 1245
e46a53f7-df78-48ef-894f-649c8cef5fee 12:19:41 AM: trace Method: acknowledgeArmRequest(armMode): [raw 0x501 {09 01 00 03}, send 0x92D8 1 1, delay 100]
e46a53f7-df78-48ef-894f-649c8cef5fee 12:19:41 AM: trace [name:codeEntered, value:1245, data:3, isStateChange:true, displayed:false, linkText:Keypad - Master, descriptionText:Keypad - Master code entered is 1245]
e46a53f7-df78-48ef-894f-649c8cef5fee 12:19:41 AM: trace Method: handleArmRequest(message): [name:codeEntered, value:1245, data:3, isStateChange:true, displayed:false, linkText:Keypad - Master, descriptionText:Keypad - Master code entered is 1245]
e46a53f7-df78-48ef-894f-649c8cef5fee 12:19:41 AM: debug Received arm command with keycode/armMode: 1245/3
e46a53f7-df78-48ef-894f-649c8cef5fee 12:19:41 AM: debug Parsing ‘catchall: 0104 0501 01 01 0140 00 92D8 01 00 0000 00 00 030431323435FF’

I wanted to believe this was tied to the outages, but waiting and retrying over and over again has gotten me nowhere. This was first noticed right in the middle of the ST instability, but we actually hadn’t used the keypads for about a week before, so I can’t pin down a date.

The fact that it just stopped working and isn’t returning to its normal working state makes me think this has more to do with a recent update than it does the outages. Did something change with SHM?

SHM otherwise seems to work fine. I can change armed state via the dashboard, I get intrusions, etc. Just no keypad interaction.

Any ideas?

Thanks

2

Any ideas? We’re dead in the water with our keypads

3

I’ve been in contact with two other users @Fun_user and @Legion, with what appears to be a similar problem at this link

My Xfinity keypad continues to work properly. Perhaps the only code difference is i’m using my forked version of ethayer’s Keypad module. Please go to SHM Delay documentation, then scroll down to “Keypad module replacement”, follow the installation instructions. Try it and let me know if it changes anything.

4

I’ve read that Iris keypads do not do OTA updates, but please go to IDE devices–> keypad --> firmware and check if the “Last Updated” has a recent date.

5

Thanks for the replies. Firmware:

Current Version: 0x10025310
Target Version: 0x10025310
Last Updated: N/A
Last Checked: 2018-01-08 11:58

I’ll check the other suggestion

6

Thank you for checking. Wanted to rule out a firmware change.

7

Your suggestion to follow the instructions led me to the cause: user error.

I am a dope and completely spaced on there needing to be routines set to control the arm-states in lock manager. I had those originally when I set this all up, and I guess I deleted those from ST somewhere along the way, and completely forgot that those are what handles the SHM arm changes. I had it in my head that the app did that directly.

Adding routines back in fixed it.

Thanks for the guidance.

Solution: RTFM.

8

Getting a functioning keypad in SmartThings can be a daunting task. I’m pleased to learn that you were able to resolve this issue.

Many users conflate ST Arm State with SHM’s mode, but they are independent fields, setting one does not set the other. The original Lock Manager Keypad module sets Smarthings Arm State by default, setting Smarthome mode requires the routine names and a mode in the routine. Since most routines also set the Smarthings arm mode again, there is a significant amount of overhead in the original Keypad module. My forked keypad module replacement corrects and eliminates most of the overhead, but absolutely requires valid routines with a valid SHM mode and ST arm state.