Iris keypad v3 Setup

🛎️ Get Help Devices
1

Hi all -

I just received an Iris keypad v3 from a seller on eBay and I'm wondering how to set it up properly. I see there are a couple of very long threads on this keypad elsewhere so hoping this thing isn't a total P.O.S.

Here's the status so far...

I was able to pair the keypad easily (once I realized it was Zigbee, not Z-wave). After hub detected it as "Device", I selected the Iris V3 Keypad from the device type drop-down list.
[I know there is long thread about this and how there are a couple different firmware for this, but wondering if someone can summarize what the status of that is.]

I configured the keypad lock codes successfully in the Lock Code Manager. Was happy to find out I could use the same name/code pairs I used for smartlocks with the keypad for consistency.

I set the entry and exit delays in the device settings and also set Delay arming Armed-Away and Delay intrusion Armed-Away in HSM. I'm confused on what the difference is between these or if they are the same thing. I could really use a little help on that.

Figured out that the process to arm / disarm on the keypad is as follows:

First, made sure that Use keypad(s) to arm/disarm is turned on for the keypad in HSM settings.

To arm:
Press the ON button on the keypad, the status should change to "armed away"

To disarm:
Enter the four digit code and press the OFF button, the status should change to "disarmed".

In trying to test things, I'm not sure I have things set up correctly. Sometimes the keypad waits awhile then starts a countdown beep sequence, other times not. And sometimes the device events don't show anything happened when I hit the ON/OFF buttons.

Question:
How do you cancel arming the system from the keypad if the keypad is in the exit delay arming phase?

p.s.
I'm going to hold off on adding my siren back into HSM while I figure this keypad out, otherwise I think I'll be tripping it a lot while I'm messing around with getting it set up.

2

Since you are already using HSM, you want to add the keypad into that app under Configure Arm/Disarm.

image
image.png772×293 12.9 KB

This will allow HSM to control the entry/exit delays as well as use the keypad as a chime during those events.

I have both the v2 and the v3 and they both work great. The v3 actually has been working much better. I have the beeping on the lowest volume possible and it's still a bit loud (you can change the volume by holding down the 2 button or the 5 button).

3

Thanks.

I did add the keypad under HSM > Configure Arm/Disarm... does that mean I should not set the entry and exit delays in the device settings and just set Delay arming Armed-Away and Delay intrusion Armed-Away in HSM?

Also, how do you cancel arming once it's in the delay phase, if say for instance, you need to grab something from the house before it arms.

4

No, you should ONLY set them in HSM. HSM will set them on the device to the correct settings. You should not modify any of the device settings directly. In fact, if you have, you might want to remove the keypad and start over to make sure you haven't screwed anything up. HSM will handle arming the keypads at the right time.

Unfortunately, because of the way HSM and the keypad interact, you can't. The only option is to wait until the arming is complete and then disarm it. However, HSM will only detect an intrusion when a sensor CHANGES from inactive to active. So, if a motion sensor is active when HSM finishes it's arming delay, it will not detect that as an intrusion unless it goes inactive first. This is to prevent motion sensors with long timeouts not tripping your alarm every time you exit. In general, when this happens to me, I wait for the arming coutdown to finish and then disarm the system Then exit and rearm. It's just easier than trying to get out before the 30 seconds is over. It might cost you 15 seconds of your day but you won't have false alarms.

5

I did end up removing it from HE, factory resetting it and then adding it back to HE and only "touching" it via HSM and Lock Manager but it is acting very funky on both arming and disarming the system with long pauses before the countdown beeps start, and even after it is supposedly disarmed, HSM still alerts me with motion alerts even though the dashboard says that HSM is disarmed. It's really bizarre. I wonder if any other people have experienced that with this keypad. I guess I'll do a deep dive in some of the older threads on this keypad to see if it's related to the firmware issue some people were having.

6

When you say that arming/disarming is "funky" what exactly do you mean? Are you arming from the keypad or the dashboard?

When you say that HSM will be disarmed but still going into "alert"? Well, that's not possible. It's possible that what you are looking at isn't the true status of HSM. But if HSM is disarmed it can't alert.

When you added the keypad back in, did it automatically assign the Iris v2 Keypad driver to it or a different driver?

7

I am doing it all from the keypad.

I would have thought you were right about saying I wouldn't get an alert if HSM was truly disarmed, but I swear that's what's happening. I will triple-check this but that's what appears to be happening.

When I added it back it, it did the same as the first time... HE just detects as "Device" and then I manually chose the Iris V3 Keypad driver from the drop-down list. So from reading through the other thread on this, I have determined I must have one of the eBay ones with the "old firmware".

One thing I wonder about from the other thread... some posts said to set it manually to the Iris V3 keypad driver and then to hit the "Configure" button... I did not hit the "Configure" button, just the "Save Preferences" button... should I have hit the "Configure" button?

8

If you could post logs, that would be helpful.

You must always hit the configure button if you change the driver.

You then have to add the keypad back into HSM again. Like I showed you above.

9

Just did what you recommended. Here's what's happening now.

I hit ON on the keypad. On button flashes a few times, then after 15 seconds or so of nothing, it does a quick beep sequence and then ON lights up and system goes to armedAway status.

Logs are here:

2019-10-26 04:51:14.226 pm infoIris Keypad was armed away [physical]

app:1012019-10-26 04:50:49.869 pm tracemodeChangeHandler com.hubitat.hub.domain.Event@f3cff0

dev:3962019-10-26 04:50:49.840 pm tracearmAway(30) called, already armAway

dev:3962019-10-26 04:50:49.835 pm debugarmAway(30, armMode:03, armingMode:0A)

app:1012019-10-26 04:50:49.736 pm tracemodeChangeHandler com.hubitat.hub.domain.Event@74786b

dev:3962019-10-26 04:50:49.427 pm tracearmAway(30) called, already armAway

dev:3962019-10-26 04:50:49.423 pm debugarmAway(30, armMode:03, armingMode:0A)

app:162019-10-26 04:50:49.029 pm infoArmed Away

dev:1942019-10-26 04:50:44.776 pm infoHeat Tape Plug energyDuration is 33.83 Days

dev:3962019-10-26 04:50:21.865 pm infoIris Keypad is inactive

dev:3962019-10-26 04:50:20.559 pm debuggetMotionResult: active

dev:3962019-10-26 04:50:20.540 pm debugdescMap: [raw:catchall: 0104 0501 01 03 0040 00 9384 01 00 0000 07 00 , profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:03, options:0040, messageType:00, dni:9384, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:00, data:[]]

app:1012019-10-26 04:50:19.165 pm tracemodeChangeHandler com.hubitat.hub.domain.Event@ccefaa

dev:3962019-10-26 04:50:18.564 pm tracearmAway(30) called, already armAway

dev:3962019-10-26 04:50:18.519 pm debugarmAway(30, armMode:03, armingMode:0A)

dev:3962019-10-26 04:49:52.447 pm tracesendArmResponse- sucess, bin:-1, armMode:00 -> armRequest:03, exitDelay:30, isInitiator:true, lcData:[isValid:true, isInitiator:true, code:0000, name:not required, codeNumber:-1]

dev:3962019-10-26 04:49:52.431 pm debugdescMap: [raw:catchall: 0104 0501 01 03 0040 00 9384 01 00 0000 00 00 0300FF, profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:03, options:0040, messageType:00, dni:9384, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[03, 00, FF]]

dev:3962019-10-26 04:49:51.942 pm infoIris Keypad is active

dev:3962019-10-26 04:49:51.937 pm debuggetMotionResult: active

dev:3962019-10-26 04:49:51.919 pm debugdescMap: [raw:catchall: 0104 0501 01 03 0040 00 9384 01 00 0000 07 00 , profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:03, options:0040, messageType:00, dni:9384, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:07, direction:00, data:[]]

Next, I disarm by entering PIN and hitting Off button on keypad...
OFF button flashed a few times, then ON button turns on. Then after a delay of about 30 seconds, the keypad plays a series of beeps and the OFF button lights up. HSM reports disarmed.

Log entries follow:
app:992019-10-26 05:05:07.874 pm errorEchoApp (v3.2.0.5) | receiveEventData Error: com.hubitat.app.exception.UnknownDeviceTypeException: Device type 'Echo Speaks WS' in namespace 'tonesto7' not found

dev:3962019-10-26 05:04:29.893 pm tracesendArmResponse- sucess, bin:1, armMode:00 -> armRequest:00, exitDelay:0, isInitiator:false, lcData:[isValid:true, isInitiator:false, code:0000, name:not required, codeNumber:-1]

dev:3962019-10-26 05:04:29.761 pm infoIris Keypad was disarmed [digital]

app:1012019-10-26 05:03:39.596 pm tracemodeChangeHandler com.hubitat.hub.domain.Event@1834e8f

app:1012019-10-26 05:03:39.266 pm tracemodeChangeHandler com.hubitat.hub.domain.Event@18412ec

dev:3962019-10-26 05:03:39.157 pm tracesendArmResponse- sucess, bin:1, armMode:00 -> armRequest:00, exitDelay:0, isInitiator:false, lcData:[isValid:true, isInitiator:false, code:0000, name:not required, codeNumber:-1]

app:162019-10-26 05:03:38.691 pm infoDisarmed

dev:3962019-10-26 05:03:37.285 pm infoIris Keypad was disarmed [physical]

dev:3962019-10-26 05:03:06.617 pm infoIris Keypad is inactive

dev:3962019-10-26 05:02:47.058 pm tracesendArmResponse- sucess, bin:-1, armMode:03 -> armRequest:00, exitDelay:0, isInitiator:true, lcData:[isValid:true, isInitiator:true, code:XXXX, name:Mark, codeNumber:1]

dev:3962019-10-26 05:02:47.005 pm debugdescMap: [raw:catchall: 0104 0501 01 03 0040 00 9384 01 00 0000 00 00 000436363237FF, profileId:0104, clusterId:0501, clusterInt:1281, sourceEndpoint:01, destinationEndpoint:03, options:0040, messageType:00, dni:9384, isClusterSpecific:true, isManufacturerSpecific:false, manufacturerId:0000, command:00, direction:00, data:[00, 04, 36, 36, 32, 37, FF]]

So maybe it's working now? Will have to test more.

10

What is your arming delay? 15 seconds?

11

30 seconds for both Delay Armed-Away and Delay intrusion Armed-Away.

12

How do you have HSM set up? You don't have a disarming delay do you? Have you reprogrammed your code into the keypad? It sounds like it is coming up with an improper code.

13

And have you added it back to HSM?

14

I redacted the actual code in the logs, replaced it with XXXX.

15

No....did you program the code back into the device.

16

Okay....so, here's your problem.

You are controlling HSM by controlling the keypad. It also appears that you have a mode change based on HSM disarming. Then it appears that you have HSM set up to react to the mode change. That is why you are getting extra disarm events.

17

No. The codes are managed through LCM and the device page still shows the right lockCodes on the right side info.

18

Pick one thing to control the other, either HSM or Mode, and only control one of the two automatically and you won't have this problem. Either that or you have to adjust your automations that are controlling Mode based on HSM. But basically, the keypad is being disarmed twice because HSM is being disarmed twice. You can see that clearly in the logs. I don't see any evidence that an alarm occurred when the system was disarmed.

19

Are you talking about the "Configure automatic arm/disarm" settings in HSM? I do have it set to Arm-Away when mode becomes Away and Disarm when mode becomes Day, Evening, Night.

So you're saying to get rid of that?

20

I'm sorry, let me try and be more clear....

.....do you see this event?
app:1012019-10-26 04:50:19.165 pm tracemodeChangeHandler com.hubitat.hub.domain.Event@ccefaa

That happened as soon as you armed the system to away. What did that? What is app 101?