Member Discussion

Which EAC Is Best Supported/Compatible With Mercury Controllers?

Hi Folks, the Company I work for is very dynamic with constant changes. Few months ago we defined a global strategy to start migrating old systems to an "open" architecture/software that will allow us to shift gears in the future at any given time minimizing the potential cost of replacing field devices in particular controllers, therefore we decided to use Mercury.

We have selected Milestone and S2 as our primary global solutions for new deployments or upgrades for video management and access control software respectively. So far, so good. Despite of the fact that we knew there were some interoperability limitations between Mercury and S2; we decided to deploy it in low-risk operations; however, I would like to know if someone has already walk this path and if you can share any experience.

it would be helpful is someone knows if there has been any survey/research to analyze interoperability comparison between "major" EAC with Mercury.


Sergio, I figured I can help here. Full disclosure: I ran panel firmware development at Mercury for many years and still provide consulting services to them. Before that, I was on the Honeywell Pro-Watch product team, a Mercury PACS head-end (the PW-6K and 5K panels are Mercury variants).

One thing to consider is what you actual metrics are. For example, the Mercury feature set goes well beyond what a typical site might use. I suspect that each Mercury OEM partner implements maybe 50% of it, but the partners all choose a different 50%. For example, while everyone will implement the core access control functions, not everyone will implement the native intrusion features, asset tracking, fancy trigger/procedure logic, and so forth.

A "feature implementation count / partner" matrix wouldn't be helpful, so all other comparisions are going to be subjective. Also, different partners have different strengths in different verticals and markets, and have implemented the features that best suit them.

That said, S2 is a first-rate organization with good talent. John Moss is a legend and has built [another] excellent company at S2.

I hope this helps. I am more than happy to help your further offline, if you like.

Jonathan, thank you for the feedback. This information helps clarify how things work in reality with Mercury and their business partners. Two questions..... 1) Do you have any particular experience with any specific software (EAC) you consider has solid interoperability with Mercury?, 2) From End-User perspective, who do you partner with if I there are important features you would like to have active from the software that are not supported when using Mercury - Mercury or their partner or Both?


Sorry for the delay...I'm not gettin IPVM relpy notifications for some reason....

1) I probably know the most about Honeywell Pro-Watch, because I was part of the original dev team. I also know a lot about RS2's AccessIt!, Open Options dnaFusion, and Lenel OnGuard.

2) Generally, feature requests are brought up first to the Mercury partner, and a dialogue is started. New features added to Mercury nearly always require work by the Mercury partner to enable, so the discussion generally starts with them.

As years of experiance go by, I find it more important to ask lately is "who has their own team of developers for custom integration work" when evaluating manufacturer products. Maybe not important in your case, but I think something to consider.

Agreed that would be a nice to have.

Johnathan. Could one conclude that if its a Mercury box, then it can be used with any Mercury-using manufacturer? What are the considerations when selecting a Mecury Partner that one should look for when selecting a Mercury based system? Point its, if a company dumps my favorite integrator, what do i have to know to get another manufacturer to who can talk to my controllers? Does the firmware need to be replaced or flashed. If so, does it mean we have to go to each controller?

Again sorry for the delay (not getting IPVM notifications).

You asked what is in reality a very large question. I will answer it as best I can:

The first thing to consider is that your Mercury panels are a component in your whole access control system. Switching from one Mercury OEM to another means that yes, you won't have to rip & replace door hardware, but this of course does not help you with database conversions, badging, and other non-door-controller considerations.

That said, you want to make sure that the Mercury features you are using are supported by the vendor. Higher-level things like elevator control, escort, intrusion support, wireless lockset support, etc., are not necessarily implemented in every Mercury partners' PACS systems. You want to ask about this.

Regarding firmware, that is a function of the PACS system: Some PACS systems will require that firmware be a certain level based on the features in use, so it is good idea to plan for time to do this. Firmware is downloadable, of course, and you generally don't need to physically go to each controller.

For gross hardward interoperability among major EAC brands, see Axis vs HID vs Mercury Access Controllers and specifically this chart:

Hardware is interoperable, but as Jon and others note, it does not mean the software integration is equal. Even though they both use Mercury Security hardware, features in platform A may not be available/supported in platform B.