Pneumercator ES825 to BACnet Fuel Monitoring Case Study

Chipkin QuickServer exposed Pneumercator ES825 fuel monitoring data to BACnet and helped a facilities team validate contact-closure and tank status points on site.

A facilities integration team needed fuel tank monitoring, leak containment, and transfer-system data exposed to a BACnet building automation network. Chipkin QuickServer bridged specialized Modbus RTU devices into BACnet and helped the field team verify live points during on-site testing.

This project stood out because it was not a single-device gateway exercise. The installation combined a Pneumercator ES825-200F fuel tank monitor, an FTI interface, and a leak containment system, with several point types that had to be interpreted correctly before they would be useful on the BACnet side.

At a Glance

  • Industry: Fuel monitoring / building automation
  • Customer: Facilities controls and monitoring integrator
  • Facility type: Commercial fuel monitoring installation
  • Client role: Project management and field commissioning team
  • Project scale: Multiple fuel monitoring devices with contact-closure and status points exposed to BACnet
  • Protocols: From: Modbus RTU → To: BACnet/IP
  • Chipkin product: Chipkin QuickServer
  • Project start: April 2023

Pneumercator ES825 to Chipkin QuickServer to BACnet architecture diagram.

Pneumercator ES825 and fuel monitoring devices → Modbus RTUChipkin QuickServerBACnet/IP → BMS

Pneumercator ES825 to BACnet Challenge

The upstream/server side was a set of fuel monitoring devices communicating over Modbus RTU, centered on the Pneumercator ES825-200F. The downstream/client side was a BACnet building automation environment that needed reliable access to tank status, leak containment information, and contact-closure states.

The complexity came from the device behavior, not the concept of protocol conversion itself. The Pneumercator contact-closure registers used bit-level status encoding, and the actual meaning of those bits depended on how the field device had been programmed. That meant the project needed more than a register list. It needed field validation to confirm that the served BACnet values matched the real installed behavior.

For fuel monitoring projects, that distinction matters. A point that is technically mapped but semantically wrong is not useful to the BAS team. The integration had to preserve meaning as well as connectivity.

Why Chipkin

This was a strong fit for Chipkin because the project required protocol conversion plus device-specific interpretation. Chipkin QuickServer provided the BACnet handoff, and Chipkin support added value by helping the customer verify the Modbus registers directly and align the gateway behavior with the installed equipment.

That kind of field-backed validation is especially important on specialized fuel monitoring devices where bit-level alarms, relay states, and status words do not always behave like generic Modbus examples.

The Solution

Chipkin configured Chipkin QuickServer to read the Pneumercator ES825-200F, the FTI system, and the leak containment system over Modbus RTU and serve the selected values into the BACnet environment.

The decisive step was direct register verification during troubleshooting. By scanning the live Modbus device and reviewing the contact-closure registers, the team confirmed how the 4-bit status layout behaved in the installed system. That let Chipkin finalize a configuration that matched the real device state instead of relying on assumptions alone.

The result was a more trustworthy BACnet presentation for the facilities team, with the fuel monitoring points validated against the field hardware rather than just accepted from a spreadsheet.

Fuel Monitoring Results

The project delivered a working Modbus RTU to BACnet/IP integration for specialized fuel monitoring equipment.

Project proof points:

  • The Pneumercator ES825-200F was successfully exposed to the BACnet system through QuickServer.
  • Contact-closure states and monitored values were validated against live Modbus register behavior.
  • Multiple fuel-system devices were brought into one BACnet monitoring workflow.
  • The field team confirmed the final working points after on-site spot checks.

The customer’s final validation was explicit:

“They tested the points that we were working on and then went back and spot tested ones that had been previously tested with positive results. Looks good.”

— Project manager, facilities integration team

Have a Similar Fuel Monitoring Integration?

Need to expose specialized Modbus RTU fuel monitoring devices to a BACnet/IP BAS? Chipkin can help with QuickServer configuration, live register validation, and point-mapping support for field-ready deployment. Tell us about your project.