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 sits between your broker and your plant network, it was bought per line, it was configured by whoever commissioned that line, it gets 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.
Modbus comes in two forms that matter here. Modbus TCP runs over Ethernet, which is how most equipment installed in the last two decades is connected. Modbus RTU is the older serial form, running over RS-485 wiring. This Connector is Modbus TCP.
Coreflux could already talk to Modbus equipment. A Connector went out to a device, read its registers, wrote to them where needed, and put the values on the MQTT bus. Useful, but Coreflux was always the one opening the connection. That leaves out every system that can only ask.
The new Modbus Server Connector reverses the direction of initiation. Coreflux now presents itself as a Modbus TCP device, and the plant's own systems connect to Coreflux instead. SCADA, HMIs, historians and PLCs see the values you expose as ordinary Modbus registers, exactly as if they were coming from a piece of equipment they already know how to talk to.
Point your SCADA or HMI at a Coreflux IP. It looks like any other Modbus device. No new protocol, no extra box, just a Connector that answers when they call.
| Before (Client Connector) | Now (Server Connector) | |
| Who starts the conversation | Coreflux calls each device | Plant systems call one Coreflux IP |
| How data flows | Inbound-led, Coreflux polls each device and can write to its registers | Outbound-led, Coreflux answers when plant systems ask and accepts writes to the registers you expose |
| What it unlocks | Getting legacy equipment onto the bus | Letting that equipment use the values you expose, without a gateway box |
The distinction is direction of initiation, not one way versus two way. Both Connectors can read and write. What changes is who opens the connection.
That matters because a lot of plant equipment can only ever ask. It cannot be asked, and it will never subscribe to anything. Before this Connector, 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.
This is Modbus TCP, so the equipment connecting to Coreflux needs to be on an Ethernet network. It replaces a Modbus TCP gateway, the box translating between your broker and your plant systems.
It does not replace a serial converter. If you have RTU equipment on RS-485 wiring, whatever currently gets that onto Ethernet stays where it is. Coreflux sits on the Ethernet side of it, and the Connector still removes the other gateway, the one on the broker side. One box out instead of two, which is worth having.
The usual arrangement is a gateway appliance per line or per cell, translating between the plant's Modbus TCP 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 Connector 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 on the plant network and replacing it is not on the table. Anyone who has priced a Modbus TCP 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.
.png)
%20(2)%20(1).png)