Integrating Access Control and Camera VMS

Access control determines who may pass a door. A Video Management System (VMS) manages CCTV cameras and recordings. Integration connects their events to attendance, incident reports or your dashboard. Start with official vendor interfaces, retain raw events and monitor when the feed stops. This article explains the technical options and their limits.

Business workflows often need data beyond the vendor's own interface. Attendance should come from door taps. Incidents should join camera events with door events. The tenant portal should know who's inside.

It's like every security device is a guard who only speaks their own language and never reports to the others. The integration work is always the same two jobs: getting events out of the vendor's box, and mapping them into your own domain.

Getting events out

Three routes, in descending order of preference.

Vendor push or SDK bridge. The best case is a vendor that pushes events. Entrypass-class panels can stream an XML transaction message over TCP for every card tap. The integration is a small listener service that accepts the connection, parses each event, and stores it. For camera VMS, the Hikvision/Dahua route is the vendor SDK: Windows DLLs with a callback interface — register for event types, receive structured callbacks.

In both cases, store two records for every event: the raw payload exactly as received, and the normalized row you parsed from it. The raw archive is what saves you when a parse turns out wrong or the vendor introduces an event type you've never seen.

Database-level reads. Many vendor servers write everything into a local database, and a read-only poll of their tables gets you the data when no push interface exists. It's fragile — a vendor schema is not an API, and upgrades change it without notice. So the rules are strict: a read-only account, no writes ever, and the schema treated as versioned per vendor release.

Polling fallback. No push, no database access. Poll current state — door status, online readers, who's inside — on an interval and diff against the previous poll to synthesize events. Lossy and coarse, but a last resort that still beats having no data.

Mapping vendor events to your own domain model

Vendor events speak device dialect. Think of a controller IP, a reader ID, a card number, and a transaction code meaning "valid entry" on one product line and something else on the next. Your systems speak in people, doors, zones, and incidents.

Between the two sits a normalization layer: mapping tables from card to person, reader to door to zone, vendor code to event type. There's a hard rule: an unknown code maps to a generic event with the raw payload attached, never dropped. That's because the unknown events are precisely the ones you'll be asked about later. It's the same discipline as normalizing multi-protocol IoT devices, applied to security hardware.

One recurring trap: panels report local wall-clock time with no timezone offset. The ingest layer must record the correct timezone explicitly to avoid placing events on the wrong date or misordering them across sites.

Resilience against the vendor stack

The vendor side will fail in mundane ways: the Windows service restarts after an update. The license dongle gets unplugged, or the license file goes missing and the server refuses to start. Someone closes the vendor client on the shared PC "to speed it up."

Design for it as you would for any unreliable upstream. The listener reconnects with backoff. Heartbeats and sequence gaps are detected, so silence raises an alarm instead of passing unnoticed. The bridge buffers locally when the uplink is down.

Monitor the feed, not just the process. A vendor service that's running but emitting nothing is the most common failure, and a quiet night and a dead feed can look identical without an independent heartbeat or status check.

Living beside a modern stack

Vendor components dictate their environment: 32-bit Windows DLLs, aging runtimes, sometimes a specific OS version. The answer is quarantine: one small bridge service runs on the Windows machine or VM. Its only job is to translate the vendor interface into a queue or HTTP calls into your real stack, which stays Linux, containerized, and modern.

Vendor DLLs never load into your main backend process. The bridge is boring by design. It's the smallest possible surface pinned to the vendor's world, so everything on the other side of the queue can evolve freely.

Scrutinize the bundled binaries

One last habit before anything ships: open the vendor's SDK folder and look at what's actually in it. LGPL media libraries sitting beside closed binaries, and sometimes no license text at all — which doesn't mean free to use. It means default copyright and undefined redistribution rights for anything you bundle. Get redistribution rights in writing in the supply contract, and read what an unlicensed vendor SDK really means before the SDK lands in your deliverable.

The takeaway

Closed security ecosystems open up the same way every time. A bridge per vendor interface — push listener, SDK shim, or database poller — feeds one normalization layer that speaks your domain language. Keep the raw events, alarm on silence, quarantine the vendor's runtime, and check the licenses of what you redistribute. The vendors' boxes stay closed; your data no longer lives inside them.