A security systems integrator needed door and alarm visibility from Avigilon ACM exposed to downstream BACnet and Modbus systems. Chipkin QuickServer provided the protocol bridge, but the real work was clarifying the driver’s passive read-only model and matching the event table to the actual XML events Avigilon was sending.
This case mattered because the initial customer expectation included write-side overrides. The project only moved forward once the team aligned on a read-only monitoring architecture and then translated live Avigilon XML event traffic into a stable downstream handoff.
At a Glance
- Industry: Security systems / building integration
- Customer: Building security systems integrator
- Facility type: Commercial access-control deployment
- Client role: Service programming and commissioning team
- Project scale: Door-event monitoring for dozens of doors with downstream BACnet and Modbus exposure
- Internal reference: FSE14639
- Protocols: From: Avigilon ACM -> To: BACnet and Modbus
- Chipkin product: Chipkin QuickServer
- Project start: February 2023
Architecture: Avigilon ACM -> XML events -> Chipkin QuickServer -> BACnet and Modbus monitoring workflows
Avigilon ACM to BACnet and Modbus Challenge
The upstream system was Avigilon ACM. The downstream side needed alarm and door-status data made available to BACnet and Modbus consumers without replacing the installed access-control platform.
The first challenge was architectural, not syntactic. The customer wanted both read visibility and write-side overrides, but the QuickServer Avigilon ACM driver is passive and read-only. It depends on Avigilon ACM sending XML events to the QuickServer, and it does not support control writes back into the access-control system.
The second challenge was field reality. Even after the XML server came online, the integrator still had to align the event table with the actual payloads present in packet captures. Door names were longer than expected, and real event names such as “Door Opened,” “Door Closed,” and “Door held open” did not line up with the team’s original assumptions.
That is what made the project publishable: this was not a generic BACnet gateway. It was a security integration where event semantics, source naming, and passive-server behavior all had to match the live Avigilon environment before the downstream handoff would be useful.
Why Chipkin for Avigilon ACM Monitoring
This project fit Chipkin because the value was in protocol interpretation as much as protocol conversion. Chipkin helped the integrator establish realistic expectations for a passive event-driven driver, specify the reports needed from Avigilon ACM, and troubleshoot the XML event content rather than assuming the first point list was correct.
Chipkin also supported the project with practical diagnostics. The customer used packet captures and Wireshark to inspect traffic on TCP port 5104, then worked with Chipkin to map the real source names and event names into a usable table.
The Solution: Passive Event Mapping with QuickServer
Chipkin first documented the constraints of the Avigilon ACM driver: passive server behavior, read-only operation, and the need for Avigilon event, door, and camera reports before a usable configuration could be built.
Once the Avigilon side was configured to send XML events, the project moved into iterative event mapping. The team reviewed live payloads, compared the expected door labels with the actual source names, and corrected the event table to use the events that really appeared on the wire.
That included dealing with long door names and matching specific event names instead of relying on generic assumptions. In one diagnostic pass, the customer identified that the router was not reading Avigilon data because the strings were longer than expected and the actual events were “Door Opened” and “Door Closed.”
The decisive move was treating the integration as live event normalization rather than a static one-time import. Once the event table reflected the real Avigilon payloads, the customer could also maintain the mapping later as door labels changed or doors were added.
Access Control Monitoring Results
The project established a usable Avigilon ACM monitoring path for downstream BACnet and Modbus consumers.
Project proof points:
- The architecture was corrected to a read-only monitoring model before the project went live with unsupported write expectations.
- Chipkin worked from real Avigilon reports that covered 82 doors and 377 door-event definitions.
- The team resolved XML event mismatches by aligning to real payload names such as “Door Opened,” “Door Closed,” and “Door held open.”
- The customer requested training on maintaining the event table so future door-label changes and added doors could be handled without restarting the project.
Have a Similar Avigilon-to-BACnet or Modbus Project?
Need to expose Avigilon ACM events to BACnet or Modbus and sort out what the access-control system is actually publishing on the wire? Chipkin can help with QuickServer setup, passive event-driver configuration, and field-side XML event mapping. Tell us about your project.
Frequently Asked Questions
Can QuickServer write override commands back into Avigilon ACM?
No. In this project, a critical early step was confirming that the Avigilon ACM driver is read-only and passive. It can expose events and status changes that Avigilon pushes to the gateway, but it does not support write-side overrides.
Why did the first event mapping fail?
Because the live XML payloads did not exactly match the initial assumptions. Door labels were longer than expected, and the real event names needed to be matched to what Avigilon was actually sending.
What data did the customer need from Avigilon ACM?
The project depended on Avigilon event reports plus door and camera reports so the QuickServer configuration could be built around real system objects and event names.
For another event-focused integration that exposes operational status to building systems, see the SNMP to BACnet/IP Bard HVAC Alarm Monitoring case study.