I’m not as familiar with Mercury as some other EAC controllers on the market but it feels like the portfolio is has some gaps. I was looking for an "Edge-based" IP / PoE-powered controller and am used to having 4 inputs, a couple of relays, maybe even built-in strike output w/ power so I don’t have to tie up the other outputs/relays, built-in tamper technology of some variety (optical, switch etc), etc. I don’t really see an equivalent in Mercury-land. EP1502 has most of the stuff but is not PoE powered and not really really what I think of as as an “edge-based” controller. EP1501 is PoE powered but short on inputs (maybe other things too). Boards like the MR51e have most of the I/O I’m looking for but they don’t really have onboard “brain power” and appear to rely on a separate intelligent controller (EP1501, EP1502, EPxxx) to store credentials and such, essentially just making it a fancy expansion board to another board somewhere else. Are there options I’ve overlooked?
Mercury Missing A “Full Featured” IP PoE Powered Edge Controller?
What are you using the 4 inputs for other than door status and REX inputs? Also, is this for a single door/single reader, or a single door/two reader application?
Depends on the door behavior we're implementing. Most are Single Door/Single reader. Variety of uses for higher count of inputs/outputs again depending on scenario. Inputs: LBM's, intercom ties or other types of door releases, reader tampers, box tampers, etc. Some of which could be serialed together but if I have the inputs I'd rather have them dedicated to the different functions and then handle the behaviors/monitoring/alerting with software config. Gives more insight, more flexibility, easier troubleshooting. More Outputs: Sounding devices, integrations w/ ADA functions, etc.
I don't think you're missing anything, but the 1501 is probably what you're looking for. In addition to the on-board inputs and outputs to support a typical single door, this controller can connect any of the SIO units to it, either via network (MR51e), or via 485 to the MR52, 16IN, or 16OUT. Should have a lot of flexibility for you if you need more inputs or outputs, or to control another door.
Hope that helps,
Greg
May be. Just feels like I should be able to do this with one "board" and not have to start chaining things together so to speak. Starting to realize I was spoiled with some of the other hardware I've used.
The 1501s also have power output to power door locks and readers via POE. Which access control system are you using the Mercury hardware with?
If they couldn't do that I wouldn't even begin to consider it a PoE-powered Edge-based solution but maybe that's just me. But that doesn't address my need or at least desire for more I/O. What I haven't done yet, but will soon, is run the numbers to see if there is enough power budget there do all the usual things that you mentioned plus enough to drive a small expansion board: MR50, etc. If not and we're talking separate power or even separate network run for some of the PoE powered expansion boards (MR51e) then that's not really a direction I find appealing.
What I do find intriguing is the thought that was potentially hinted at above that many? most? people, or rather door "profiles" they are implementing, are just using two inputs and not getting into some of the other uses I mentioned.
Concerning your software question, there are a few platforms we're working with. Since it's largely a software agnostic question I didn't mention any of them.
What network controllers are you current using? We have found Mecury to be extremely flexible for system designs and take overs of other systems. Plus customers aren't locked in to one vender which they really like.
I don't disagree and even my title is a bit of a misnomer as I know Merc controllers are very full featured. My issue is primarily with I/O qty on a single PoE powered intelligent board. The MR51e comes really close but I want it to have on board "intelligence" that comes in the EP line.
My interest in the Merc's is that they are pretty much the most "agnostic" to have a variety of platform support. Of course that's nothing "agnostic" like the camera market but it's about as good as it gets with PACS today. I'd still call it proprietary but just proprietary that many people support, typically via their own firmware flash.
I compare this to some other units I see like this sampling:
-Axis A1001 I like the idea, features, and form factor. I hope it eventually sees broader adoption but do worry about it "getting there". Tough market to get into best I can tell.
-3xLogic has a controller that is tiny (almost too tiny) but packed with I/O. Looks very neat.
HID Edge EH400 - Never saw many of these.
Check out the Isonas IPBridge as well as their RC-04 IP/POE reader controller. The IPBridge is a 2 or 3 door POE controller and you can run POE+ to it without needing a POE+ splitter (it is native POE+) and control a couple of doors off of one POE drop. You can also daisy-chain the network cable connection between them (they have both an IN and an OUT network port on them as well as IN and OUT for hardwired standard power if you like).
Never seen another controller come in a 3-door model as well ... makes me chuckle every time I even type the phrase "3 door controller", but there it is. The drawback to the IPBridge is that the wiring strip is not a removable terminal block style, so the wiring can get a bit messy if you're not too careful and replacing one requires all of the wires to be removed from their screw terminals instead of just popping off a molex style connector(s). This was a bad design decision from an installer's/tech's point of view. The controller itself is quite small for as much as it does, so all of the wiring for 2 or 3 doors connects to a relatively small device.
Installed a bunch of them in a live hospital retrofit; removed all of the old AMAG controller boards and installed IPbridges and kept all of the HID readers, locks, PIR's, DSS's in place. In this case, we only powered the IPBridges with POE and used the existing power supplies for lock's, etc. because of existing tie-ins to the fire alarm system.
Now that Isonas is running mainly on a hosted platform instead of the previously free on-premise software, this might not be for everyone. For smaller systems, the hosted platform is great and ver cost-effective ... the new on-premise software they have is no longer free, but more enterprise in nature and comes with an msrp of 3,999.00 for unlimited sites/doors.
There is no perfect system; just depends on best fit for the end user from a first cost + cost to own standpoint (obvious, I know).
Isonas does have a new SDK available, so I figure in the future there will be more PACS options that support the hardware.
I've reached out to Mercury for comment here.
Also, it terms of a multi-door PoE controller, one of the limiting factors is that pass-thru power budget is limited, and while one or two doors readers/locks may not be a problem, things might get tight for more. This is a factor we mention in PoE Powered Access Control Tutorial.
I'll update with Mercury's response here.
Hi, thanks for the post. You raise an interesting point albeit something that hasn't come up as much as you might think. Since we see that sales trends of our products across 20+ OEMs, I can tell you that while a growing percentage of overall sales, PoE is still only a fraction of the controller ecosystem. We've had PoE controllers for 10 years and the industry adoption has taken time. With that said, we are up-revving our entire controller line in 2018 starting with the downstream boards (Series 3) released January 1 followed by the "intelligent" controllers in July. There will be some new variants available in the future.
As of today, the only PoE options are the EP1501 & MR51e. By mid-2018, we will also have the MR62e which drops the wiegand reader inputs (supports 4 OSDP readers) and adds additional inputs / outputs. While this controller is not categorized as "intelligent", it will have future capabilities including a downloadable database for network outage situations, etc.
Below is the number of inputs and outputs for each of these products.
|
Product |
Num Inputs |
Num Outputs |
Num Readers |
|
EP1501 |
2 |
2 |
2 |
|
MR51e |
4 |
2 |
2 |
|
MR62e |
6 |
4 |
2 |
The EP1501 was really designed to control a single door and that is why there are reduced number of inputs and outputs. Based on industry feedback, the form factor needed to allow for field upgrades of older controllers which limited the physical real estate for additional components. The aim was to make this device fit in a 3-gang electrical box.
The MR51e and our upcoming MR62e do offer more I/O capabilities but they rely on intelligence up at a controller (some customers have installed those controllers in the Cloud!). These boards also have the same form factor and fit in a 3-gang electrical box.
Additional I/O can be added to the EP1501 through downstream boards in the cases where that's necessary.
As always, we need to balance cost of the product with what's desired by the customers. We have some new flavors in the works which will continue to push the controller market forward with not only native Mercury capability, but "app store" type functionality to integrate many more building systems than the industry talks to today.
We encourage industry feedback and would love to have an open dialog about what the integrator and end-user community wants to see in the future.
Good response Matt. Can you clarify the number of card readers available for the MR61e. I see where you mentioned that four OSDP readers are supported but the table shows two readers. Are these Wiegand readers or is Wiegand not supported by the MR61e?
OSDP is inherently daisy-chainable, so you can have several readers on the same loop.
Sorry, I noticed my error after I hit POST and I don't see a way of making corrections. The MR-62e will support 4 OSDP readers / 2 doors (in & out readers). We are dropping support of wiegand readers with this specific product for two reasons: 1) We can use the real estate on the board for additional inputs / outputs. 2) We are in the security business and wiegand is inherently insecure. Time for all of the industry to make the shift to cyber-secure devices and technology!
Ask questions and get answers to your physical security questions from IPVM team members and fellow subscribers.