Elk M1 w/ proximity for large building, do it myself possible?

Never mind. Figured it out. The keyfobs use RFID and need programming for site location and sequential number.
 
So I ordered and got Infinias door controller and the centralized software package.
Honestly, this could not be any simpler!!!! Ordered small batch of keyfobs already programmed for my site and numbered.
30 min of setup and fully operational on the bench controlling a test electric door strike.

AWESOME!!!!! THANK YOU, THANK YOU!!! As usual, you folks have helped tremendously!!!!!!
 
Pay attention to what wiring you run from the door to the controller itself, I'd recommend a composite access cable and then make a junction for power and homerun an 18 or heavier AWG to a nearby power supply in addition to the CAT cable, then centralize your supplies in the comm closets.

What you connect to the additional inputs/outputs would determine what sort of integration to another platform, since I'd recommend standardizing a REX for each door, either via a PIR or microswitch activated via the door hardware (electrified handset, crashbar, etc.) then you would be able to determine what doors unlock on REX or not.

If you run enough cabling back from the controllers to a point where it can be interfaced with the security, you would be able to integrate with a panel like the M1 (provided bus distances aren't exceeded) or similar and drive the security with the unused input/output on the door controller.
 
What advantage is there for having a REX at each door?
I had planned on implementing a doorbell type push button for several doors for our shipping and receiving folks so that can open the door from their desks.

I was also hoping to figure out how to connect to my new Avaya IP Office phone system so that folks could push a button sequence on their phone which then activates a relay to open the main entrance door.
 
DEL may elaborate more, but in many of these systems, there's an alarm that's essentialy always armed - and the activation of the door relay bypasses the sensor for a period of time; at the same time, when leaving something needs to tell the system to ignore the door opening for a short period of time. A motion sensor above the door, a pressure pad, or something in the crash bar bypasses the door contact for a period of time; after which, if the door is still open, it can either just set off the alarm or trigger a "held open" warning. That way if the door is forced open in any way, it triggers the alarm right away.

The other use is for maglocks which need to be deactivated long enough to get out the door; otherwise turning the handle would do nothing.

As for the phone interface, there are a handful of ways - though they typically will require an ATA off your phone system and assigning the door an extension. Many controllers can control several doors so you'd call x888 then *7 for the shop, *8 for the front door, etc; followed by # to activate the door release. I'm totally drawing a blank on the one I installed last, but doorking, doorbell fon, I think Channel Vision, and others -
 
I went digging through that controller and software and it appears it doesn't offer the "normal" access control options I'd be used to however for clarification:

A REX pir or via handleset/crashbar, will typically allow the system to shunt the DSM for a programmable period of time. This would prevent door prop (held too long) or force (opened without credential, IE: key) and would identify trouble points before they became problems, usually it's an end user that causes those events. In the case of most PIR based REX's, they typically would unlock and shunt a door contact at the same time (bypassing a forced door notification) and keep an end-user from crashing into a locked door, so the doors would unlock as they approach from within the protected area, assuming no "push to exit" buttons are being installed. Also, by installing a REX, you'd be able to parallel any variety of NO circuit devices to provide an unlocked action in addition to bypassing any DSM. If done wisely, you'd be able to trigger a generic input anywhere on the system to provide an output anywhere else on the system without the need for more wiring. Infinias doesn't appear to be a 1:1 I/O unit, so mapping appears to be possible.

A door prop or force would either cause an event to fire on the host workstation (only useful if monitored by security) or could be mapped to an output, such as drive an alarm panel for monitored security purposes. In the case of a panel like an Elk, you could map the ACS output to the M1's input to automatically disarm when the first ACS user comes in, then set an auto-arm for a time or if the last out forgets to arm the system. Instead of installing a bunch of door contacts, you would just install DPDT units in the doors and split the circuits between the systems.

We generally use Viking units for our telephone release and interface to client phone systems, however if your system provides a momentary dry contact option, it appears like you'd be able to map certain items across the software and network to your door controllers rather than pulling cabling everywhere.
 
Viking was the brand I was drawing a blank on... I've installed them in a variety of places, including a pretty nifty elevator call button/intercom/prox reader unit; as well as other door-intercoms. Since these were in a VOIP shop I had to use an ATA to create an analog extention off the VOIP PBX, which gave the ability to call an extension and trigger a door opening with the right codes; and even trigger an elevator call by phone in an emergency.
 
Back
Top