Flash Demo
.png)
This guide is based on Nahuel Godoy's Flash Demo presentation at Coreflux Cracked, January 26, 2025. Nahuel is a full-stack developer at Coreflux working on both the broker and UI.
Connect Modbus, OPC UA, databases, video streams, and more through a single interface. Visual mode or code mode, your choice.
You're standing on a factory floor looking at three devices. One speaks Modbus. One speaks OPC UA. One is plain MQTT because someone installed it three years ago and nobody remembers why.
Your job: make them all talk to the same broker.
In the traditional approach, this means three different integration paths, three different configuration headaches, and three different things that can break independently. Multiply this by every device in your facility and you understand why integration engineers develop that particular thousand-yard stare.
LoT Routes offers a different approach.
Nahuel Godoy, full-stack developer at Coreflux, puts it simply: "Routes are a piece of code that programs the broker to connect to a device, service, or something you might need, get data from it, and show it directly into the broker. You can think of it as a universal adapter."
That's the core concept. A Route is a programmable connection between your broker and... basically anything. The broker becomes the universal translator, handling protocol differences so you don't have to.
One broker. Any protocol. Any device. Any service.
Here's where Routes get interesting for different types of users.
Some engineers think in code. They want to see the LoT syntax, tweak parameters directly, and have complete control over every configuration detail. Routes support that through the LoT code editor.
Other engineers prefer visual interfaces. They want to click through fields, see options laid out clearly, and configure without memorizing syntax. Routes support that too through Visual Mode.
Same configuration. Same power. Different workflow.
The Route Management panel in Coreflux's new UI gives you both modes side by side. Switch between them as needed. Start visually and fine-tune in code. Or write everything in code and use visual mode to verify your configuration. Your choice.
When you open a Route in the management panel, you'll see several configuration sections:
Basic Information
Name, description, and data type. Required fields are clearly marked.
Configuration
The core settings for your Route type. For a Modbus device, this includes connection parameters. For an OPC UA server, authentication and endpoint details. Each Route type has its own configuration requirements.
Events
On-demand operations that execute the Route. Think of events as manual triggers or scheduled actions that pull data when you need it rather than continuously.
Mappings
Continuous polling operations. Mappings regularly grab data from your device at defined intervals. This is your "always watching" configuration for data that needs constant monitoring.
Tags
Data points that represent a register or variable in a device. Within a Mapping, Tags let you reference specific registers or variables from your connected device, making it easier to organize what data you're pulling and where it's going.
You can add and delete fields as needed. The interface adapts to what your specific Route type requires.
Starting from scratch is overrated.
The Route template library contains pre-built configurations for common device and service types:
Each template provides the minimal LoT code needed to get that Route type working. Select a template, click create, and you have a functional starting point. Customize the fields for your specific setup and you're connected.
No need to remember syntax for every protocol. The templates handle the boilerplate.
Once your Routes are running, you need to know what's happening.
Connection Status
Every Route shows its status visually:
Route Logs
Each Route maintains its own log with filtering options:
The logs capture events happening within that specific Route, making troubleshooting straightforward. When something goes wrong, you know exactly where to look.
Here's the practical workflow Nahuel demonstrated:
Step 1: Open the Coreflux UI connected to your broker
Step 2: Navigate to the LoT editor
Step 3: Write or paste your Route definition in LoT code:
DEFINE ROUTE ModbusDevice WITH TYPE MODBUS_TCP
ADD MODBUS_CONFIG
WITH CONNECTION_TYPE "TCP"
WITH IP "127.0.0.1"
WITH PORT 5020
WITH SLAVE_ID 1
ADD MAPPING PollingData
WITH SOURCE_TOPIC "modbus/simulator"
WITH EVERY 1 SECOND
ADD TAG Temp_0
WITH ADDRESS "0"
WITH ADDRESS_TYPE "HOLDING_REGISTER"
WITH DATA_TYPE "INT16"
Step 4: Execute to install the Route
Step 5: Open Route Management to verify and configure
Alternatively, start from the template library, select your device type, create the Route, then customize through Visual Mode or Code Mode.
Nahuel also delivered on a promise from the previous Flash Demo.
The MQTT Explorer and publisher were previously separate tabs. Users wanted them combined. Now they are.
The new MQTT Explorer includes:
It's a quality-of-life improvement that makes working with your MQTT data significantly smoother.
Routes are available in the Coreflux broker. Download and experiment:
Download Coreflux: coreflux.org/downloads
Start with the template library. Pick a device type you have available. Create the Route. Watch your data flow into the broker.
The "universal adapter" concept becomes real when you see three different protocols unified under one interface.
The Flash Demo series continues. Follow Coreflux on LinkedIn and YouTube for upcoming demos covering new features, integrations, and the continued evolution of the UI.
Routes are just one piece of what makes LoT powerful. There's more to explore.
This guide is based on Nahuel Godoy's Flash Demo presentation at Coreflux Cracked, January 26, 2025. Nahuel is a full-stack developer at Coreflux working on both the broker and UI.
.png)
.png)