An operations team needed carbon monoxide data from multiple field sensors delivered both to a BACnet/IP building system and to a custom HTTP application. Chipkin QuickServer helped bridge the Modbus RTU data into both workflows while resolving float-conversion and payload-structure issues that would have blocked the deployment.
This case stands out because the gateway had to satisfy two downstream consumers at once. The project was not finished when the serial sensors started talking. It was finished only when the same data could be trusted inside the building system and republished in a format the custom web application could use.
At a Glance
- Industry: High-value operations / environmental monitoring
- Customer: Operations and facilities engineering team
- Facility type: Mission-critical indoor monitoring environment
- Client role: Engineering and application-development stakeholders
- Project scale: 4 CO sensors across 2 serial trunks with BACnet/IP and HTTP delivery
- Protocols: From: Modbus RTU -> To: BACnet/IP and HTTP/REST
- Chipkin product: Chipkin QuickServer FS-QS-2010-F
- Project start: November 2022
- Internal reference: FSE15435
Architecture: CO sensors -> Modbus RTU -> Chipkin QuickServer -> BACnet/IP BMS and HTTP application
Modbus RTU to BACnet/IP and HTTP Challenge
The upstream/server side was a set of carbon monoxide sensors communicating over Modbus RTU on two serial trunks. The downstream/client side was split: one consumer needed BACnet/IP for facility visibility, and another needed an HTTP or REST-oriented data path for a custom application.
That dual-delivery requirement made the project more interesting than a standard Modbus-to-BACnet job. The team had to confirm the serial communication first, then make sure the data type conversion was correct, and finally package the values in a structure the HTTP workflow could consume without ambiguity.
The result is a useful public pattern: one gateway, two downstream uses, and a monitoring outcome that supports both operational visibility and application-layer access.
Why Chipkin
This was a strong fit for Chipkin because the project crossed serial field integration, BACnet delivery, and application-facing HTTP publishing. Chipkin QuickServer provided the bridge, while Chipkin support helped the team correct the word order for the sensor values and organize the HTTP-side data model into something practical.
That combination matters when a gateway is expected to feed both a traditional building system and a custom software workflow.
The Solution
Chipkin configured the QuickServer to read four CO sensors over Modbus RTU across two serial trunks and expose the resulting values over BACnet/IP. To make the data useful end to end, the project also corrected the floating-point interpretation using the required word-order handling for the sensor registers.
For the HTTP side, the sensor readings were consolidated into one data-array structure with predictable offsets so the customer’s application could access the values reliably. That avoided a more fragmented payload model and gave the development team a cleaner path into the gateway data.
The decisive value was not only that the gateway could read Modbus. It was that the same verified sensor values became usable in two downstream systems with one maintained integration point.
For another project where Chipkin turned source-side field data into a cleaner downstream building workflow, see the Modbus RTU to BACnet/IP Remote Chiller Integration case study.
CO Monitoring Results
The project delivered a working Modbus RTU to BACnet/IP and HTTP integration path for CO monitoring.
Project proof points:
- 4 CO sensors were integrated across 2 serial trunks.
- The float word-order issue was corrected so the live sensor values were interpreted properly.
- One consolidated HTTP data structure supported the custom application workflow.
- The final monitored system was confirmed operational after the dual-output path was validated.
The customer’s confirmation was concise and clear:
“Everything seems to be functioning as it should.”
— Technical contact, operations monitoring team
Have a Similar Dual-Output Monitoring Project?
Need one gateway to expose Modbus RTU data both to a BACnet/IP system and to an application-facing HTTP workflow? Chipkin can help with QuickServer configuration, data conversion, and practical multi-consumer gateway design. Tell us about your project.
Frequently Asked Questions
Can QuickServer expose Modbus RTU data to both BACnet/IP and HTTP?
Yes. That was the core delivered architecture in this case: one QuickServer read the CO sensors over Modbus RTU and then served the data both to a BACnet/IP system and to an HTTP-oriented application workflow.
Can Chipkin correct float word-order issues during commissioning?
Yes. This project included the work needed to fix the floating-point interpretation so the live CO values were usable instead of misleading.
Is one gateway enough when a BMS and a custom app both need the same data?
It can be, when the gateway is designed for both consumers from the start. In this deployment, the HTTP payload model was also cleaned up so the application team had a predictable way to read the data.