Grab a chair before proceeding.
You’re about to access the full Coreflux platform. Some people report weakness in their knees upon first contact.
You’ve been warned.
.png)
Product Update
The chiller and the injection press are in the same building. Their data is in two different worlds.
Separate integrators. Separate software. Separate budgets. Often separate people who have never met. That was workable for as long as nobody asked a question that crossed the line between them.
The questions people ask now all cross that line. What does this site actually consume. Where is the energy going. How does heating and cooling load track production load. What is our real cost and carbon per unit produced.
Answering those means the chiller and the press have to live in the same place.
BACnet is the language of building management. It is an open standard, ANSI/ASHRAE 135, and if a building has a management system for heating and cooling, lighting, meters or access control, it very likely speaks BACnet.
Two things about it are worth knowing.
Controllers announce themselves on the network, so equipment can be found without anyone maintaining a list of addresses.
And the alarms come from the controllers themselves. A chiller decides it is too warm and says so, rather than a supervisory system noticing afterwards and inferring it. When you connect to BACnet, you are connecting to equipment that already knows its own state.
The BACnet/IP Connector puts building systems onto the same unified namespace as the production line next door, using the same way of working as every other Coreflux industrial Connector. One mental model, one governed bus, one place your Dashboards and models read from, whether the value came from a press or a rooftop unit.
Building data lands on the bus alongside production data. Room temperatures, meter readings, lighting states and access events become ordinary values your Dashboards, logic and models can use, in the same form as everything from the factory floor.
Equipment reports when something changes. Rather than Coreflux asking every few seconds whether anything is different, controllers can push updates only when a value actually moves. Less traffic on the building network, and faster reaction when it matters.
Setpoints can be adjusted from Coreflux. Automation and operators can move a cooling setpoint or a schedule, and it slots in at the right level of the building system's own control hierarchy rather than fighting whatever the local logic is trying to do.
Alarms are the real ones. When a controller raises an alarm, it arrives on the bus as that alarm, not as something reconstructed from readings. An operator acknowledging it from a Coreflux Dashboard genuinely acknowledges it in the building system, so the two views do not drift apart.
It works on locked-down building networks. Plenty of building equipment sits behind firewalls or on segmented networks and will not answer a general enquiry. Coreflux can connect to it directly instead.
Commissioning and diagnostics are covered. One-off reads and writes can be triggered on demand, which is what you need while getting a site up and running. It is also what an AI agent needs in order to investigate something without a human driving each step.
The Connector is built for what integrators actually meet on site.
One scoping note worth having to hand: this covers BACnet over IP networks, which is the modern and by far the most common deployment. Older serial BACnet wiring, MS/TP, is not covered.
Energy and facilities teams who own both a factory and the envelope around it. Integrators quoting smart-building and industrial work out of the same office with two entirely different toolchains. Enterprises with ESG reporting obligations that currently reconcile building data and production data in a spreadsheet.
Device settings, data points, alarms and the full set of configuration options are in the technical documentation.
%20(1).png)
.png)