> ## Documentation Index > Fetch the complete documentation index at: https://docs.coreflux.org/llms.txt > Use this file to discover all available pages before exploring further. # Release Notes > New features, improvements, and fixes in each release of the Coreflux MQTT broker and HUB.
**Breaking Changes** in this release: **HUB is not in the broker image** — `coreflux/coreflux-mqtt-broker` is broker-only. The HUB is `coreflux/coreflux-hub`, always in its own container. **HUB URL is `http://localhost:3000`** — broker ports `8080` (HTTP) and `8443` (HTTPS) are no longer HUB endpoints. Bookmarks and reverse proxies that pointed at those ports will not reach the HUB. **Action:** use [Docker Compose](/latest/quick-start/installation) (the default `full` profile starts broker + HUB on one network) or run the HUB image beside the broker. Open `http://localhost:3000`. When both services share the Compose network, click **New Connection** and set **Host** to `broker` (**Protocol** `mqtt://`, **Port** `1883`, or **Protocol** `ws://`, **Port** `5000`, **Path** `mqtt`) — not `localhost`. See [Installation](/latest/quick-start/installation) and [Updating Your Coreflux](/latest/updating-coreflux). ### 2.14.3 - Default rules and Visu panel publishing #### Bug fixes * **Default rules load with an active project; Visu panels can be published** — When a project is already active at startup or after `-loadProject`, the broker's seeded permission rules now apply correctly so internal clients retain `$SYS` access and panels publish to `$Visu/...` topics again after project activation. ### 2.14.2 - Sparkplug B route, MQTT & LoT performance improvements Sparkplug B Support, MQTT client lifecycle action triggers, better OT master/client visibility in broker logs, a banded Rules precedence model, project lifecycle improvements, and faster publish, LoT, and route dispatch. #### Improvements * **Rules priorities are now banded** — The rule priority number line is split into bands: `0`–`99` is reserved for the broker's immutable system rules, `100`–`999 999` is your band, and the permissive catch-alls `AllowPublishTopic` / `AllowSubscribeTopic` now sit at `1 000 000`. Only the strongest matching band decides an operation, where a DENY beats an ALLOW (deny-wins) and nothing matching means denied (default-deny). Moving the catch-alls to the weakest band **fixes a topic-visibility bypass**: they previously shipped tied with everything else, so a specific access rule could not reliably override the allow-all fallback — which left Visu panel view topics effectively public. `-addRule` now rejects priorities outside `100`–`1 000 000`. **Action:** custom rules written in the old `1`–`99` range are clamped to `100` on load and logged individually. Clamping keeps them in force, but several rules can land on `100` together, where ties resolve deny-wins — re-space them across the user band, putting the more specific rule at the lower number. See [RBAC with LoT Rules](/latest/lot-language/rules/rbac#rule-precedence). * **`AllowConnect` seed and `FOR Connect` rules** — Fresh brokers now ship a third permissive catch-all, `AllowConnect`, at priority `1 000 000` (the same weakest band as `AllowPublishTopic` / `AllowSubscribeTopic`). Write `FOR Connect` rules in the user band to decide who may connect after authentication; they outrank the seed. Brokers with no Connect rule at all still leave CONNECT ungated. `-restoreRules` puts all three seeds back to their shipped ALLOW definitions. See [RBAC](/latest/lot-language/rules/rbac#connection-admission) and [`-restoreRules`](/latest/mqtt-broker/commands#restoring-seeded-rules). * **Project manifests, entity ownership, and ad-hoc entities** — Each stored project publishes a retained content manifest on `$SYS/Coreflux/Projects/{name}/manifest` (SHA-256 of exact file bytes, plus entities declared in `.lotnb` cells). `-projectManifest` returns the same JSON on demand. Running entities are attributed on `$SYS/Coreflux/Entities/ownership` and in the `-listEntities` / `-loadProject` `origin` field. **Loading or unloading a project no longer deletes ad-hoc entities** added with `-addAction` and similar commands while no project was active. **Action:** if you relied on Activate to wipe the whole runtime, remove those entities explicitly before loading a project. See [Project Commands](/latest/mqtt-broker/commands#project-commands) and [Project Topics](/latest/mqtt-broker/sys-topics#project-topics). * **Loaded projects stay active after a restart** — After `-loadProject` (or `--project`), the last loaded project is remembered and re-activated on the next start unless you pass `--project`. `-unloadProject` returns to standalone mode on the next restart. See [Startup Options](/latest/mqtt-broker/startup-options#loading-a-project-at-startup). * **`ON START` runs on deploy; action publishes are no longer blocked by user ACL** — Deploying an `ON START` action on a live broker executes the body immediately (cold start still runs once after the MQTT broker is ready). Action `PUBLISH` / `KEEP` still put messages on MQTT for any subscriber; they are no longer denied by user publish rules, so bootstrap topics from actions are not silently dropped. Clients still need subscribe permission to receive those messages. See [Initialization Triggers](/latest/lot-language/actions/events#initialization-triggers). * **OT string sizing — `LENGTH` is the preferred keyword** — Across OT routes that support configurable string sizing, `WITH LENGTH` is now the documented primary keyword; `STRING_SIZE` remains accepted as a parser alias. See the shared [String sizing by Route](/latest/lot-language/routes/industrial/overview#string-sizing-by-route) reference on the industrial routes overview. * **Modbus Server STRING defaults and cap** — Unsized `STRING` tags no longer reserve a single register (which silently truncated barcodes and caused Illegal Data Address on FC16 writes). The server now defaults to **40 bytes (20 registers)** and warns when size is omitted. Route validation rejects `LENGTH` values above **246 bytes (123 registers)**, the FC16 write cap. See the [Modbus TCP Server Route guide](/latest/lot-language/routes/industrial/modbus-tcp-server). * **Modbus Server and OPC UA Server activity logging** — Modbus Server routes log accepted and rejected master writes (plus rejected reads), with bank-aware function-code labels and `LENGTH` guidance when an undeclared holding-register range is the cause; connection open/close counts are logged from the existing watchdog (**the master's source IP is not available**). OPC UA Server routes log client session create/close events and accepted external writes on tags and STRUCT fields. * **MQTT client lifecycle action triggers** — New `ON CONNECT DO`, `ON DISCONNECT DO`, and `ON SUBSCRIBE ["pattern"] DO` triggers run LoT automation when clients connect, disconnect, or subscribe. Action bodies expose session context via `CLIENTID`, `USER`, `ENDPOINT`, `CLEANSESSION`, `DISCONNECTREASON`, `SUBSCRIBETOPIC`, and `SUBSCRIBEQOS`. The broker only evaluates lifecycle hooks when at least one action defines them. See [Action Triggers](/latest/lot-language/actions/events#client-lifecycle-triggers). * **Improved command response handling** — Broker command responses are now consistently structured as JSON. Each command may include a `requestId` field, allowing you to easily correlate requests and responses. * **Sparkplug B routes (beta)** — Decode Sparkplug B protobuf into readable JSON, publish Coreflux topics as an edge node, or run Coreflux as the Primary Host Application with namespace state, commands, and automatic rebirth requests. See the [Sparkplug B Route](/latest/lot-language/routes/system/sparkplug-b) and [Sparkplug Host Route](/latest/lot-language/routes/system/sparkplug-host) guides. #### Performance * **MQTT between clients** — More messages complete per second, the slowest publishes finish sooner (about 10% lower p99 latency). Messages that update route topics stay in the order they arrived. * **LoT rules and actions** — Permission checks, topic triggers, timers, and dashboard invokes no longer slow down as more distinct topics exist on the broker. LoT-heavy traffic that was about **10× slower at 30,000 topics** — and about **70× slower at 100,000** — now stays as fast as it was on a nearly empty broker. `USER HAS` and `USER IN GROUP` checks stay fast as the user list grows. * **Route mappings** — Adding mappings no longer makes every publish more expensive, including on topics that no mapping uses. Exact-topic mappings (the common case) keep up with tens of thousands of messages per second at **sub-millisecond** latency with **no loss** — the same flood previously took around **25 seconds** and dropped some messages. Wildcard mappings (`+` / `#`) now deliver fully as well. When a route cannot keep up, memory stays bounded: the broker waits, then drops the **newest** arriving message rather than older ones already in flight. Set `ADD ROUTE_CONFIG` on a route (`OVERLOAD_POLICY`, `OVERLOAD_TIMEOUT`, `OVERLOAD_CAPACITY`) when that route needs a different wait-or-drop contract. See [Route Overload Configuration](/latest/lot-language/routes/route-config). #### Bug fixes * **Rules with `IF` and no `ELSE` now compile** — `IF USER IS "dashboard" THEN DENY` (no `ELSE`) previously failed compilation on first evaluation and was treated as a deny for every matching publish or subscribe. The missing branch is now the opposite of the `THEN` decision. See [Rules Syntax](/latest/lot-language/rules/syntax#combining-conditions). * **Python scripts no longer lose their code on restart** — Scripts that contained blank lines were truncated down to the `# Script Name:` header after a reboot, so `CALL PYTHON` failed even though the script still appeared in listings. Complete scripts now persist across restarts. See [Python Integration](/latest/lot-language/actions/python-integration#writing-python-scripts). * **Built-in rules survive project add/load/unload** — Adding or switching a project no longer wipes the broker's default permission rules, so internal clients keep `$SYS` access. See [RBAC](/latest/lot-language/rules/rbac#seed-catch-alls). ### 2.2.0 - Kafka, OPC UA Server & Modbus Server routes * **Kafka route** — Connect Coreflux directly to Kafka as a producer or consumer, with support for security protocols and configurable batching and compression. See the [Kafka Route guide](/latest/lot-language/routes/streaming/kafka). * **OPC UA Server route** — Expose Coreflux data to OPC UA clients with a secure-by-default setup, including support for array and struct nodes. See the [OPC UA Server Route guide](/latest/lot-language/routes/industrial/opcua-server). * **Modbus Server route** — Serve Modbus data over TCP, with experimental support for Serial (RTU) connections. See the [Modbus TCP Server Route guide](/latest/lot-language/routes/industrial/modbus-tcp-server). * **OT route persistence** — Server routes (OPC UA Server, Modbus Server) persist their state and recover automatically after a restart, so data isn't lost on reconnect. See [OPC UA Server persistence](/latest/lot-language/routes/industrial/opcua-server#data-persistence--recovery) and [Modbus Server persistence](/latest/lot-language/routes/industrial/modbus-tcp-server#data-persistence--recovery). * **OPC UA client certificate authentication** — Authenticate OPC UA client connections using PKI certificates for more secure deployments. * **Modbus one-based addressing** — Set `WITH ONE_BASED_ADDRESSES true` on Modbus client and server routes so tag addresses match device manuals that label registers starting at 1. See [Modbus addressing](/latest/lot-language/routes/industrial/modbus-tcp-client#modbus-addressing) (client) and [Address notation](/latest/lot-language/routes/industrial/modbus-tcp-server#address-notation) (server). * **Publish payload as bytes** — Forward or retain binary MQTT payloads bit-for-bit with `PAYLOAD AS BYTES` on `PUBLISH TOPIC` and `KEEP TOPIC`. See [ACTION Operations](/latest/lot-language/actions/operations#binary-passthrough--payload-as-bytes). * **EtherNet/IP route** — Joined attribute reads (`ENABLE_JOIN_ATTRIBUTE`), bit extraction (`BIT_ADDRESS`), ARRAY/STRUCT decoding from assembly buffers, bidirectional `WRITABLE` tags, and legacy Hub Asset field mapping for migrations. See the [EtherNet/IP Route guide](/latest/lot-language/routes/industrial/ethernetip). * **Allen-Bradley route** — Symbolic tag-name access (`Program:MainProgram.Tag` format), `AB`/`ALLENBRADLEY` route aliases, `PATH` vs `SLOT` routing, family-specific STRING/TIME encoding, and cross-link to EtherNet/IP for explicit CIP paths. See the [Allen-Bradley Route guide](/latest/lot-language/routes/industrial/allen-bradley). * **Bug fixes** — Fixed BACnet alarm retention, EtherNet/IP connection parameters and legacy-style compatibility, a Modbus TCP word-order issue, an OPC UA client connection issue, and a licensing load-order. ### 2.1.0 - BACnet route (building automation) and Protobuf models * **BACnet route** — Connect Coreflux to building automation systems (HVAC, lighting, metering) and bridge them to MQTT * Read live values and write setpoints to BACnet controllers * Get instant updates on change, without constant polling * Receive alarms and event notifications directly in MQTT See the [BACnet Route guide](/v2.1/lot-language/routes/industrial/bacnet) to get started. * **Protobuf LoT models (beta)** — Decode and encode binary protobuf on MQTT from LoT: `WITH FORMAT PROTOBUF` (or `BOTH`), `PROTO_TAG` to match vendor `.proto` field numbers, `ADD MODEL` for nested messages on publish, `GET PROTO` / `GET PROTOBUF` to read top-level fields, and `PUBLISH MODEL` to emit real protobuf bytes (not JSON-in-bytes). `WITH FORMAT BOTH` keeps JSON on the main topic and binary on a `/protobuf` sidecar topic. See [Protobuf Models](/latest/lot-language/models/protobuf) for more details. ### 2.0.3 - OT tags & route stability * **OT tag JSON publish** — Message payload now includes the `unit` field * **Modbus and EthernetIP routes** — Stability improvements ### 2.0.2 - ON CHANGE trigger and bug fixes * **`ON CHANGE` trigger for LoT actions** — Run actions only when the message payload on a topic is different from the last message on that same topic. Use it for high-frequency telemetry, historians, and forwarding when you do not need to process duplicate values; `ON TOPIC` still runs on every matching publish. * **Bug fixes** — Stability and correctness improvements across the broker, LoT, and HUB ### 2.0.0 - AI Agent route in the broker * **AI Agent route** — Create custom agents usable within LoT for AI-driven steps and logic * **Cloud and local LLMs** — Support for both on AI features ### 1.10.0 - Protobuf & REST API route Support for environment variables and secrets on LoT * **Protobuf** support * **REST API route** with OAuth and JWT support * **Default project on boot** — Load a default project to a Coreflux broker when the broker starts **Breaking Changes** in this release: **HUB is not in the broker image** — `coreflux/coreflux-mqtt-broker` is broker-only. The HUB is `coreflux/coreflux-hub`, always in its own container. **HUB URL is `http://localhost:3000`** — broker ports `8080` (HTTP) and `8443` (HTTPS) are no longer HUB endpoints. Bookmarks and reverse proxies that pointed at those ports will not reach the HUB. **Action:** use [Docker Compose](/latest/quick-start/installation) (the default `full` profile starts broker + HUB on one network) or run the HUB image beside the broker. Open `http://localhost:3000`. When both services share the Compose network, click **New Connection** and set **Host** to `broker` (**Protocol** `mqtt://`, **Port** `1883`, or **Protocol** `ws://`, **Port** `5000`, **Path** `mqtt`) — not `localhost`. See [Installation](/latest/quick-start/installation) and [Updating Your Coreflux](/latest/updating-coreflux). ### 2.3.4 - Login, Deploy, and Data Viewer fixes #### Bug fixes * **Non-admin users no longer get bounced back to the login screen** — Signing in as a user without full system access could loop back to login instead of opening the HUB in Limited Mode. The HUB now recognizes a denied `$SYS` subscription for what it is and opens Limited Mode as designed. * **Deploy project shows accurate status** — Deploying a project via [Connections Manager](/hub/connections) no longer surfaces the broker's success response as a false warning, and the project header no longer gets stuck on **Updating** after the deploy completes. * **LoT Editor keeps dropped files on the project** — Images and other files dropped into a project (from the Finder, Explorer, or a mixed-OS drag) now stay attached instead of being lost. * **Data Viewer confirms whether a publish actually landed** — Sending a message no longer shows **Published** when the broker silently rejected it for lacking a publish ACL; Data Viewer now waits for the topic echo before confirming. ### 2.3.0 - LoT Editor, Connections Manager, LoT Flow wiring #### LoT Editor * **Visual Studio Code-style editor** — An intuitive notebookeditor with a familiar interface inside the HUB. * **Unified Projects view** — One Projects list covering every project stored on the broker and every draft held in the HUB. The live project is marked, local-only drafts stay distinct, and each row carries its own sync state: clean, unsaved edits, changed on the broker, or diverged. * **Push only what changed** — Push stores the working copy and deploys just the drift, instead of redeploying a whole project. * **Broker Runtime inspector** — A table of what is actually running on the broker, with read-only source for each entity, and a jump from any running entity to the notebook that declares it. * **Documents alongside notebooks** — Open and store Markdown, text, PDF, and images in a project, import files from disk, and reference them in LoT notebook cells. * **Copy entities between notebooks** — Copy or drag a declared or deployed entity into another notebook. * **Version history** Git based version control for project files. * **Activate and Deactivate projects** from the project tree. #### Connections Manager * **More than one broker** — The HUB keeps a named list of broker connections with favorites, replacing the single remembered URL. Each is shown as a card on the login screen. * **Change Broker** — Switch the whole HUB to another saved connection from the account menu, without logging out and reconfiguring. * **Per-connection TLS** — Store a CA certificate and a client certificate against an individual connection. * **Credentials kept off the connection record** — Passwords and client keys live in a separate store; the desktop app encrypts it using the operating system's secure storage, and the browser app never writes them to disk. * **Live reachability on the login list** — Saved connections are probed so you can see which brokers answer before you pick one. #### LoT Flow * **Cleaner connections between nodes** — `KEEP`-topic edges and "matches" edges no longer clutter the canvas, and `MODEL` nodes are drawn as terminals, so the remaining edges show real data flow. * **Topics grouped by role** — Command and telemetry topics are grouped by the role they play, with disambiguated group labels, prefix hubs backed by a topic-set panel, and wildcard subscriptions expanded to the topics they match. * **Topic pulse toggle** — Turn live topic activity animation on or off. * **Export the canvas as an image** — Download the current flow as a PNG. ### 2.2.0 - UNS viewer & LoT Flow * **LoT Flow** — A new interactive view of your LoT data flows, showing entity, topic, and Python nodes alongside live topic values, action traces, and route status. * **UNS viewer** — Browse your Unified Namespace as a tree, with search, live payload previews, and a graph layout. * **Data Viewer overhaul** — A refreshed explorer with a detailed topic view, timeline, faster topic indexing, and better subscription management. * **In-app release notes** — A "What's New" dialog in the HUB so you can see what's changed without leaving the app. * **Refreshed HUB styling** — Updated visual design and dock layout. * **AI chat improvements** — A setup wizard, an artifact panel, and a generally expanded chat experience. * **Expanded dashboard panels** — More display components, gauge options, and model-binding support for building richer dashboards. * **Bug fixes** — Fixed the LoT compiler and dashboard rendering for `ON KEY PRESS`, `ON THRESHOLD BREACH`, conditional handlers, `WITH THEME`, numeric decimals and suffixes, threshold zones on gauges/charts, and callable actions. Fixed `INVOKE ACTION`, `BIND TO MODEL`, the accordion "Add Section," and tab titles in dashboards. Fixed real-time charts to show both traces with a legend and to correctly distinguish bar vs. line modes. Fixed select/dropdown interactions, topic-to-widget data binding (previously showing a single point instead of the full array), slider and toggle controls publishing incorrect values, icon visibility, multi-panel layouts, and events not being recognized on mount. Fixed the AI agent to properly detect uninstalled routes, and corrected its confirmation prompts. General mobile layout improvements. ### 2.0.0 - UI/UX overhaul, standalone installer, AI Agent Coreflux HUB Data Viewer showing MQTT topic tree with live data values and real-time charts * **UI/UX improvements** * **Standalone installer** — Windows and Linux * **AI Agent** * **Insights mode** — Ask questions about running data, using project information as context * **Agent mode** — Build LoT, routes, and dashboards with an AI copilot * **Editor Area Apps** — Data viewer, Logs Viewer, Secrets & Variables management, etc. in the VSCode editor area for better usability. * **Connection Manager** — Multiple broker connections can be stored for easy switching * **LoT Entities table view** — View deployed LoT entities running on the broker in a dedicated table view * **LoT Projects support** — Create, edit, and deploy LoT projects Screen recording of creating and deploying LoT in the Coreflux VS Code extension * **Improved VS Code extension (beta)** * License usage * Live MQTT data (topic tree) * **Data Viewer** — View and replay historical and live data for MQTT topics, with viewers for raw, JSON, PDF, GeoJSON (map), audio, and more * **Execution trace** — View and replay historical and live data from LoT execution, including success and error states, published topics, and internal variables * Manage secrets and environment variables