Iris Keypad Anomoly

On my Iris keypad, I accidentally pressed the Partial button without entering any numbers. To my surprise my Living Room lamp shut off, press Partial again the lamp turned on. Since I have the LR lamp plugged into a SmartPower switch, and programmed with a simple smartapp to toggle the switch from pin 0000 from any keypad, I quickly dismissed ghosts, but was still very surprised. Then I tried the ON key, same result. Off did nothing.

I confirmed what was going on using the IDE Live Logging, and there it was
9:34:49 PM: debug Received arm command with keycode/armMode: 0000/1 (Partial Pressed no pin)
9:35:01 PM: debug Received arm command with keycode/armMode: 0000/3 (On pressed no pin)

So before making any suggestions about putting this to use by setting a User pin in SHM Delay for quick arming without a pin, but not quick disarming, I’m wondering if anyone else is seeing the 0000 transmission when pressing the Iris Partial or On key with no prior pin numbers?

Answering my own question, yes this is working as designed according to the following thread, although “keypads with newer firmware need a double push.” Updated IRIS keypad firmware on a ST controller does not occur, so press once or twice on Partial or On, it sends pin code 0000.

@arnb Is this just how it is? or did you find a way around the double press? its just a bit annoying. Then it runs my routine twice before arming.

Never had a double push issue. My original question was about me finding the Iris V2 sent 0000 pin when pressing On or Partial with no pin entry. I subsequently implemented this V2 hardware option in SHM Delay, and that logic is now used with the V3, however the Rboy App Dth generates the 0000 pin because the V3 hardware sends an empty pin in this situation.

“Double Push” If it runs a routine twice it implies two physical hardware sends. What is showing in the logs for the device?

My Iris V2 works with a single push. Firmware: 0x140B5310 ST as of this writing does not update Iris Keypad Firmware AFAIK.

@rboy @maddie Any insight on this question?

I have both the v2 and v3 - v2 performs normally with 1 press. The logs show it sending the commands twice and that the device does switch to armed/stay but the buttons don’t change on the device.

I’m confused.

So the Iris V2

  • on one press of On or Partial key it sends two hardware messages?
  • Which buttons don’t change? What are you expecting?

What occurs on my V2 when I press On (I have exit delay set for away) the Iris logo blinks red, keypad sounds tones. Upon expiration of exit delay seconds, Iris logo shows solid red, On button is lit, however I must wave my hand over the proximity sensors to see this.

What does V3 do?

Thats my fault I didn’t really describe that well.

The v2 works fine. One press and it arms. lights change. all good.

The v3 I press partial and it runs all the commands - arms the system then changes the display keys to OFF. Press partial again and the commands run again, but the second time the display keys stay on partial. Oddly keypad device in Smartthings shows the keypad as armed. Its like the buttons aren’t in sync with the DTH.

What I’ve also found is that if I don’t press partial the second time I cannot disarm the system with the keypad.

Of course I just tried and it armed normally… Its completely random.

SHM Delay function and logic is identical for the V3 and V2. This could possibly be a signal strength issue. What happens if you move the V3 closer to the ST Hub?

Perhaps @RBoy or @maddie can help.

It happened during my initial testing with the hub and keypad on my desk. Usually the lights flash when it loses connectivity. I’m having that issue with my v2 unit. I’ll try to grab a log the next time it happens.

The Iris V2 and Centralite keypads are very sensitive to timing delays, and can and will time out when they don’t get an acknowledgement from a pin/mode entry in some unknown to me time frame. I’ve modified my personal Keypad DTH to issue the acknowledgement, and the Rboy DTH seems to do the same thing, but I still get occasional keypad “light shows” due to network dropouts. I have no idea why they occur, possibly internet or cloud delays?

Perhaps @Rboy can enlighten us on this issue.

There are multiple reasons, sometimes it’s latency or sometimes it’s the ZigBee mesh. If the command doesn’t reach it (timely) the state may not change.

Things to try,

  • turn off hub for 20 minutes and then power it on (forces a ZigBee rebuild).
  • try a zigbee repeater
  • move the device away from the hub so that it connects via a zigbee repeater (this is the best solution I’ve found so far)