Trouble with Essex Keypad and Elk M1

[tmbrown97]

I just double checked a working user/fob I have entered - it's just a default-creation I did from the keypad with the fob... It looks just like yours except by default it had the Access Menus 1-5 box also checked.

Without touching any programming or doing anything but hook the reader up and enroll the card, any time I swipe the card it alternates between Armed and Disarmed. No waiting for timers, or anything else. I'm not sure what's different.

Did you ever confirm the part about the keypad itself beeping when it's getting a card swipe? I know my KP2 will beep any time it gets a read whether it's a valid code or not. Can you make sure that it's beeping (getting the read) on the keypad each time you activate it? And lastly, did you double-check that the device is properly set to Weigand26 and not Weigand37? I don't think it'd work if set wrong, but who knows. Weigand37 has room for a lot of optional values as well.

 

[Ricksquan]

The KP does beep each time the # key on the Essex keypad is pressed regardless of whether a valid code was entered. Thank you for confirming what your settings are that work -- this helps begin to rule out the basic settings issues. With that said, I do need to completely rule out the Essex keypad as the problem so I ordered a simple weigand-usb dongle today so that I can confirm exactly what it is putting out each time. This particular model of keypad is meant to be Weigand26 only. But you are right that I don't know for certain that it is putting out Weigand26 -- the product serial number and documentation say so and the M1 seems to like it well enough for arming, but as they say... "seeing is believing".

Out of curiosity, what do you have for your arming options under area settings for the area with your working weigand device?

 

[tmbrown97]

Arming options checked are: Restart Exit Timers and Single Keypress Quick-Arm.

What wiegand dongle did you order? I could probably use one for some testing I'm doing.

 

[Del91574]

Sounds like the Essex is dumping generic weigand data into the M1, possibly a format issue.

 

[Ricksquan]

I did the second of my illogical tests (hey, it makes me feel better to rule out stuff) by adding a new keypad elsewhere on the bus and then attaching the Essex keypad to it. The results were the same. So with obvious hardware and config issues mostly ruled out, I am very curious to see what the Essex is putting out.

This is the device I ordered. I explained to the vendor what I wanted to use it for and they said it should work fine. I guess I can justify the cost ($75 plus s&h) since it could save me that much in time chasing the wrong solutions. Plus, I might add more wiegand-based devices in the future and this could come in handy for testing them as well.

 

[tmbrown97]

I just have a hard time believing that the Essex is changing what it puts out... it doesn't know the arm status does it? All it knows is that you typed in a code and pressed #?

I'll be curious to find out what you learn with this. Also, I'd be half tempted to buy a cheapo ~$16 eBay RFID reader and see if it with a card responds as you'd normally expect.

 

[gatchel]

Is it possible that the essex is configured for a bit pattern instead of wiegand. (I didn't read the instructions)

 

[Ricksquan]

Per the documentation for the essex, it is only designed to output 26-bit Wiegand. The only changeable aspects are the site code and the input voltage (12v or 5v... yes I have the jumper set to 12v). A link to the documentation is in one of the posts higher up. I'm anxiously awaiting the arrival of a wiegand-usb interface so I can confirm once and for all what is coming out of this keypad. Work2Play's idea of picking up a cheap RFID reader is not a bad one -- that would make a logical next step to this debugging process if the Essex output is found to be good.

 

[tmbrown97]

The other thing I would do on your panel for troubleshooting, is enroll users to handle the "error" situations... basically do the Enroll and go press # on the thing - that would hopefully learn that code; then check the "Access" box and program a rule to make an announcement when the Error happens (this would be good to have regardless) and have it announce something when it receives that error.

 

[Ricksquan]

This actually openend up an area of testing I had not thought of. Since this is my first external device and is not a swipe, I have never used user enrolling via the keypad - Ive only used RP. By enrolling the essex users via the Elk keypad as I've done this afternoon, I'm seeing the Elk receiving exactly what I would have expected. For example, creating a new user via the Elk keypad, enrolling and entering 2-3-4-5-# on the Essex keypad results in RP showing that new user with a site code of 101 (what I have the essex keypad set to) and a user code of 2345. I tried this with several user code combinations and it is consistently logging what I'm entering on the essex. Even enrolling with just a # gives a code of 65535 which is the expected error code of all binary 1's. As suggested, I kept this "65535" user as an error user with access only and a rule to put up an error message on the keypad when triggered by access. If I enter # alone on the essex, this error message does show up on the elk keypad. So back to the test... I enter 2-3-4-5-# on the essex and the M1 arms. After it arms (during wait or after wait is over), I enter 2-3-4-5-# and the Elk keypad gives a single tone. It does not disarm, there is no message, no other actions that I can see. On the log, it will show the 2345 user as arming the system but the only other entry is my own code disarming the system directly from the Elk keypad after the test is over.

I'll still run tests with the wiegand-usb device when it arrives but today's tests made me more doubtful that the problem is with the essex output. I've also ordered a cheap wiegand swipe reader w cards as an additional test (or toy to play with, depending on how you look at it).

I emailed Elk tech support a few days ago and they were nice enough to offer some suggestions similar to what you folks have already suggested. My last question to them was if they have any knowledge of any scenario where a user can arm a system but not be permitted to disarm. I have not yet heard back. If there are such scenarios, one could potentially offer some clue or direction of research with my setup.

 

[tmbrown97]

Glad you've gotten a little further with the testing. For a while now I've suspected that the problem lies in your Elk configuration somewhere and not the Essex. I just wish I knew exactly where the problem was! I've tried going through all the ElkRP screens I can think of but haven't seen anything that I can think would cause such issue. I'll keep looking; in the mean time, you'll know for sure when the prox reader comes in and exhibits the same behavior!

 

[tmbrown97]

OK - I just went to the computer with ElkRP on it and went through every possible screen again; I just can't see anything else that would cause such behavior. At this point I suspect something's just wrong or (small chance) there's a rule interfering.

How current are you on all your firmware versions? Have you tried going through them all and getting them current? I did try scanning release notes for something about this, but nothing came up; that said it couldn't hurt.

Do you have any rules around disarming? Perhaps disable all your rules for a minute and test; then reenable when finished.

If that goes nowhere, I'd wait 'till your cheapo prox reader comes in and confirms the same results; at which time I'd start with a blank template on the panel and see - if it works then, slowly restore your settings and keep testing to see if you can tell if/when it breaks again.

And since you're playing with all this, if you decide you need a KAM, let me know - I ordered one a few weeks ago thinking I'd need it then decided in this case to just run my reader off an installed KP2. I never even opened the UPS box it shipped in.

 

[Ricksquan]

My M1G has firmware 5.2.4, the keypads are all 2.1.48, and RP is at 2.0.14. While there are newer M1G firmwares, the release notes don't address anything like what I'm dealing with. It even notes that new units are still shipped with 5.2.4. There are newer XSP and XEP firmwares but nothing that would seem relevant.

I have no rules related to arming or disarming. I'll throw in a all-rules-disabled test next time just for the heck of it.

I don't want to get ahead of myself but I've seen a few posts over the years where the Elk tech folks suggest nuking the setup (on of the higher global settings) and starting over. How rare is this to do? Is this a potential nightmare or is it not too bad if you have RP settings saved.

 

[tmbrown97]

Nothing to it, honestly; You can have a saved configuration that can always be dumped back in. You can also copy your setup as it is now into yet another template so you have multiple versions to work with. You'll see DELInstallations recommend it every so often. I did it about 2 years ago.

 

[Ricksquan]

The wiegand-usb dongle arrived and I hooked the data leads up at the location of the Elk keypad and it read correctly and consistently what was being entered on the essex keypad. So I thought about wiping the M1 clean just in case there were any ghost settings messing me up. But then I thought I'd try something else first...

When I first started this, I had read in a number of places that cat5e was sufficient between readers and the Elk keypad. I did the voltage drop calculations on 12vdc 20mA on 15ft of 24ga and it was okay nevertheless I still doubled up the cat5e wire for the voltage. The data lines are 5vdc at something much less than 20mA so again I thought it was safe and have never given it another thought especially since I was getting a postive arming and now even today getting accurate readings from the wiegand-usb dongle. But just for the heck of it, I doubled up the data lines so that data0 and data1 were both carried over a pair of cat5e. Guess what? That did it!!! The disarming began to function. I'm no electronics wiz so I'm only guessing there's something about the Elk keypad needing a somewhat stronger wiegand signal when it is armed than when it is disarmed? While it would be somewhat interesting to do more tests to know the exact electronics cause, I don't have time and I'm ready to move on with what should have been an afternoon project -- LOL. Afterall, wire is cheap, my time isn't. I would have doubled up the conductors or even started with heavier gauge if it wasn't for the positive postings on using cat5e for readers and me wanting to squeeze out another conductor for controlling the green/red LEDs on the essex. Now I know to just pull an extra cable for the LED control. I'll probably pull 2 cat5e so that I have spares for the future.

I want to thank everyone for all the tips and advice, it was hugely helpful in eliminating numerous potential causes. Cocoontech is awesome!