36 replies to this topic

[Ricksquan]

I'm looking to add an Essex keypad (wiegand) to our garage as an add-on to an existing M1 Gold system. Right now I'm bench testing the keypad by connecting it to one of my live M1KP keypads. I have a user setup in RP with the keypad's site code and pin and have selected authorization to arm and disarm. Where I am now stymied is that entering the code on the Essex keypad when the system is disarmed does arm the system. But once the system is armed, this same code will not disarm via the Essex. In the log, the arming shows but the attempts to disarm do not appear.

I've gone through the old tried and true several times... re-enrolling, powering down and back up, etc. I've also tried numerous combinations of user authorization options. I even thought possibly a code lockout from my early testing so I changed G12 to 99 (disabled) temporarily and have deleted the user and created new. No luck.

I have a suspicion there is something relativelly simple I am overlooking but I can't think of it and I've searched Cocoontech and also Google but I've not seen any similar problems (which really makes me think it may be something simple I'm not seeing).

Any advice would be greatly appreciated. Thanks in advance.

[DELInstallations]

Without having the specific hardware at hand, are you waiting for the delays to expire?

Assuming the users and panel have been sent/received and the calculator gave you the right values for the code, is this another valid code programmed within the system?

Maybe try a user code instead of the code you are trying?

It's getting the wiegand somehow, so it would come to the Essex in this case IMO.

How about throwing a rule in there, I'm wondering if the system is not seeing the data and tying the event to disarm.

[Ricksquan]

Thanks for such a fast response.

The keypad is an Essex KTP-103-SN. The keypad it is wired to is an Elk M1KP via a W035A harness. My assumption is that the calculator did determine the correct code since it recognizes it to arm the system.

Yes, I wait for the exit delay to expire to try to disarm.

I've tried different test user codes, one is an existing code on the system, another is a new code created just for this testing. Both work to arm. Neither work to disarm.

I'd be happy to try putting in a rule. What could I trigger off of? There seems to be no activity that occurs on the Elk side when it is armed and I enter codes on the Essex side. However, the Elk keypad will occasionally beep when the # key is pressed on the Essex keypad which tells me it is receiving data but not acting on it. I thought perhaps there was some setting that I have not addressed on the M1 side which is causing it to accidentally or purposely ignore the attempts to disarm?

[Work2Play]

It's a configuration issue with the user. You absolutely do not need to wait for the exit timers to expire before disarming either; you can arm/disarm/arm/disarm all you want... Ask my wife - I've been doing it a lot lately in testing.

Also, I'm not sure about the KP as I'm using KP2's for my tests, but every time the reader sends a "read", the keypad beeps - regardless if it's a known code or not, it beeps to let you know there was some sort of read that it received.

I would check your user for the options. Just create a blank user and don't touch the options and it should work by default; but check on the Access, Arm, Disarm, and other permissions for that user. I don't have ElkRP in front of me right now, but the options were along those lines. I'd bet just about anything that's where your problem lies.

[DELInstallations]

Also, just a thought and probably not the case, but without looking up the keypad itself, some units send a different trailing digit or bit if something isn't entered to tell it to end or certain keypress sequences may have it send garbage data.

[Ricksquan]

Before I left for work, I tried creating a new user with the default settings. It was able to arm but again not able to disarm. A disappointing test but good to know that, from your experience, those setting should work with an external wiegand keypad.

From here, I'm thinking I'll have to take the testing to the next level to try to narrow it down. I believe I have a spare KP keypad so I may try swapping it out and re-testing. A subsequent test could be to instead add the second KP elsewhere on the bus, then wire it up to the Essex instead and see what happens. Just a matter of finding the time -- it's frustrating being at work when I want to be home testing this!

[Work2Play]

I still think it's going to come down to user configuration - can you post a screenshot of the user config page in ElkRP later when you have a chance? Either that or some global or other type of issue.

DEL could be right, but my experience so far is that Wiegand 26 (what Elk has to use) has absolutely no room for extra codes or characters unlike Wiegand 37 which can have all sorts of extra identifiers. I guess that's worth mentioning too - you are sure the keypad is set for Wiegand 26 right?

Also, there aren't any areas at play are there? There's just one Area for the house and all keypads are assigned to that same area?

[Ricksquan]

As far as it being a configuration issue, I hope you are right. It would make the most logical sense since it is partially functional as far as its ability to arm the system. My keypad swapping test is not logical per se, it would just be me trying to rule out any improbables. I will post a screenshot of the configuration screen for the test user this evening or tomorrow.

Yes, I'm only using area 1.

The documentation for the Essex keypad can be found here... http://www.keyless.c...6BitWiegand.pdf

According to this documentation, DEL is correct that the keypad will send an error message of 26 binary 1s if you hit the # without a code, a code of all zeros, or a code >= 65,535. If I press the # on the Essex without entering a code, the M1KP will beep. I'm tempted to buy a wiegand-usb reader to confirm what the Essex keypad is outputting each time but since the M1KP appears to be happy with the code as far as arming goes and I can't imagine how the Essex would know to send anything different from one sequence of 1-2-3-4-# versus another, I want to pursue several other possibilities first.

[Ricksquan]

I swapped out the keypad but it made no difference. I deleted all test user accounts and started with a fresh new one with the same settings as accounts that currently work when used directly on the keypad. Same result.

I attached a screenshot of the user screen as a reference.

Attached Files

•  Elk Users Screenshot 2012_08_21.jpg   45.58K   9 downloads

[Ricksquan]

Here is a screenshot of the test user account.

Attached Files

•  Elk test user screenshot 2012_08_21.jpg   45.19K   15 downloads

[WayneW]

I seem to recall that the area has to be set to "double keypress" when using a Wiegand reader?

[DELInstallations]

I'm 99% sure access must be checked to get the data and user to act correctly. Not near my panel or an account with multiple readers/KAM's at the moment.

[Ricksquan]

I appreciate everyone's suggestions. I set the area to "double keypress" but unfortunately the results were unchanged. I then tried checking "access" for the test account -- it had the effect of no longer arming the system when the user code was entered on the Essex keypad. I thought that you would choose "access" if you wanted the wiegand device to perform an access-based rule (e.g., open an electronic door lock) rather than simply arm/disarm?

[DELInstallations]

Without digging into it really deep (it's late and I'm on call), how about firing off a rule to change arm state. Don't have RP on this lappy, but believe there's a way to do it reasonably easy

[Ricksquan]

I could remove the arm/disarm settings and simply select access for the keypad user codes. Then use rules to arm/disarm based on access to that keypad. I will test this setup tomorrow as a fall back option. However, I'm not 100% ready to give up on the idea that if the user is setup for arm/disarm, that a valid user code from the external wiegand device shouldn't be able to simply arm/disarm the system as keystrokes on an M1 keypad would -- maybe I'm just being naive. LOL