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.
Product Update
.png)
There is usually a small box in the cabinet whose entire job is translation. It was bought per line, configured by whoever commissioned that line, patched separately if it gets patched at all, and it quietly holds a second copy of your data. Nobody loves it. Nobody has a plan to remove it either, because the equipment on the other side of it is never going to learn a new protocol.
That box is what this release removes.
Modbus is the plant floor's lowest common denominator. It dates from 1979 and it is deliberately crude. A device asks for a numbered slot of data and gets a number back. No structure, no descriptions, no way to discover what anything means.
That crudeness is exactly why it refuses to die. Almost every PLC, drive, power meter, panel HMI and controller ever shipped supports Modbus, and a large share of them support only Modbus. It is the one protocol you can assume is present on a site you have never visited. Any serious industrial data strategy has to meet it where it is.
Coreflux could already talk to Modbus equipment. A Route went out to a device, read its registers, and put the values on the MQTT bus. Useful, but it only works in one direction: getting data in.
The new Modbus Server Route reverses that. Coreflux now presents itself as a Modbus device, and the plant's own systems connect to Coreflux instead. SCADA, HMIs, historians and PLCs see the data that lives on your bus as ordinary Modbus values, exactly as if it were coming from a piece of equipment they already know how to talk to.
This matters because a lot of plant equipment can only ever ask. It cannot be asked, and it will never subscribe to anything. Before this Route, connecting it to your data meant putting a translator in the middle. Now it points at Coreflux.
Existing systems see your data with no changes on their side. No drivers to install, no vendor to call, no integration project. From the SCADA's point of view, Coreflux is another Modbus device on the network.
Control flows both ways. An operator changing a setpoint in the HMI writes it back to Coreflux and onto the bus, where the rest of your logic, Dashboards and models can see it and act on it. One governed path, both directions.
One less box in the cabinet. The protocol gateway that used to sit between the broker and the plant network is no longer needed. So neither is the purchase order, the second configuration, the second patch cycle or the second copy of your data.
Definitions live with everything else. What gets exposed is described in Language of Things, in the same place as the rest of your Coreflux setup, versioned and reviewable. Not in a device web interface that one person remembers the password to.
The usual arrangement is a gateway appliance per line or per cell, translating between the plant's Modbus equipment and whatever the IT side is running. Each one is a purchase, a configuration, something to secure and patch, and a second place your data lives. Which means a standing question about which copy is right when the two disagree.
The Modbus Server Route removes that layer. Coreflux holds the data once and presents it in the form the plant already understands.
Brownfield integrators, whose projects are mostly equipment older than the person commissioning it. Metal workshops, plastic injection, food production and water utilities where the HMI is a fixed-function panel and replacing it is not on the table. Anyone who has priced a Modbus gateway per line and then multiplied it out across a site.
Addressing, data types, security considerations and the full set of options are in the technical documentation.
%20(1).png)
%20(2)%20(1).png)