Release Notes

​

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

​

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.
• 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 and -restoreRules.
• 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 and 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.
• 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.
• 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 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.
• 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.
• 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 and Sparkplug Host Route 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.

​

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.
• 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.
• 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.

​

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.
• 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.
• Modbus Server route — Serve Modbus data over TCP, with experimental support for Serial (RTU) connections. See the Modbus TCP Server Route guide.
• 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 and Modbus Server persistence.
• 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 (client) and 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.
• 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.
• 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.
• 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

• 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.

​

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

• 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