MQTT Edge Platform
A local, event-driven message boundary for devices, automation, and selected enterprise delivery.
MQTT is most useful at the edge when it is treated as an operational contract, not as an ungoverned stream of JSON. A durable design gives every topic a producer, meaning, freshness expectation, access boundary, and named consumer-while keeping device operation local.
Use MQTT to decouple local producers and consumers
MQTT is a lightweight publish/subscribe protocol. Publishers send a message to a named topic; brokers distribute it to matching subscribers. At the edge, that pattern lets instruments, gateways, cameras, applications, and automation modules exchange selected state without every producer knowing which dashboard, rule, historian, or enterprise system will consume it.
An MQTT edge platform adds the operational responsibilities around the protocol: local broker lifecycle, client authentication, TLS, topic design, retained-state policy, message persistence, event conversion, health monitoring, and a controlled path to other systems. It does not make the broker a source of truth for every high-rate raw signal or a substitute for fieldbus and safety authority.
Banalytics can run an embedded broker within the local Agent and connect to external brokers through MQTT v3 and v5 connectors. The Agent can also turn received topic messages into local events, evaluate rules, execute configured actions, and publish selected outcomes. This makes MQTT a practical integration boundary around a physical system rather than merely a transport library.
Keep acquisition, state, event, and enterprise delivery distinct
| Layer | Role | Typical message responsibility |
|---|---|---|
| Field source | Produces a measurement or state through its native interface. | Gateway telemetry, controller state, meter reading, sensor value, camera-derived observation. |
| Local MQTT broker | Distributes messages within the site or edge node. | Authenticated publish/subscribe, retained current state where justified, persistence according to the deployment. |
| Edge interpretation | Validates and contextualises incoming data. | Freshness check, schema validation, unit and source identity, event creation, rule evaluation. |
| Operational response | Applies a bounded local workflow. | Notification, dashboard update, local record, controlled action, or escalation. |
| External consumer | Receives an intentionally selected integration outcome. | Event summary, aggregate, command acknowledgement, or evidence reference rather than all raw inputs. |
This separation prevents a common failure mode: using the same topic as raw telemetry, current state, alarm, command, acknowledgement, and audit record. Each role needs different retention, QoS, access, and interpretation rules.
Run a broker locally, connect deliberately, and translate messages into workflow
The MQTT Server component turns an Agent into an embedded broker for local IoT, industrial, and automation workloads. The documented configuration includes TLS, password authentication, mutual TLS, WebSocket access, persistence, and runtime statistics. Local operation removes an avoidable dependency on an external broker for site-internal message exchange.
Use an MQTT v3 or v5 connector when the relevant broker is elsewhere. The MQTT Topic Listener subscribes to one topic filter and emits an MQTTTopicMessageEvent for each received message, including topic, payload, QoS, retained flag, and payload type metadata. Banalytics Event Manager can then evaluate that event and invoke a preconfigured response.
For outbound delivery, an MQTT publish action can create a defined hand-off to another local service, a gateway, or a governed external consumer. This means the local data path can remain useful through upstream disruption while the platform records, retries, or reconnects according to the actual delivery contract.
Make every topic self-explanatory to the people who must operate it
Topic names should describe ownership and meaning, not implementation accident. A practical structure separates site, asset, source, and message role. For example:
site/krk-01/pump-17/state
site/krk-01/pump-17/telemetry
site/krk-01/pump-17/event/overtemperature
site/krk-01/pump-17/command/request
site/krk-01/pump-17/command/ackKeep the payload contract equally explicit. It should identify source time, source identity, schema or version, value and units, quality or freshness, and correlation information where a response is expected. A timestamp created when a gateway reconnects is not interchangeable with the time a sensor made the measurement.
| Message type | Recommended treatment | Common mistake |
|---|---|---|
| Current state | Use a stable topic and retain only when new subscribers need the last known state. | Retaining transient alarms or commands and replaying them as if they were current. |
| Telemetry | Carry source time, units, and quality; define sampling and acceptable loss. | Assuming arrival time proves data freshness. |
| Event | Include condition, source, severity, time, context, and event identifier. | Publishing only a Boolean with no evidence or routing context. |
| Command | Use an explicit request and acknowledgement path with authorisation, timeout, and safe failure behaviour. | Treating broker delivery as proof that a physical action occurred. |
Choose guarantees deliberately
MQTT QoS describes transport delivery semantics between clients and broker; it does not prove that a downstream service parsed a payload correctly or that a requested device command completed. Retained messages are a last-known-value convenience, not a history database. Persistent sessions and broker persistence improve recovery behaviour but introduce storage, lifecycle, and data-governance responsibilities.
- Scope credentials by role. A sensor should not be able to publish commands; a dashboard should not need write access to device-control topics.
- Use transport protection. Select TLS and, where appropriate, mutual TLS as part of the local or external broker configuration.
- Use narrow subscriptions. Broad wildcard filters can turn busy brokers into an uncontrolled event source. The MQTT Topic Listener documentation specifically recommends narrow production filters.
- Set bounded back-pressure behaviour. Define maximum message size, rate, queueing, expiry, reconnect, and disk-budget behaviour before production load arrives.
- Observe broker and node health. Authentication failures, client churn, storage pressure, reconnects, retained-state age, and processing lag are all actionable operating signals.
System Monitor reports host CPU, memory, disk, thread, media, WebRTC, and user-activity state. Use it alongside broker and connector metrics so overload or a full disk is not mistaken for a quiet field system.
Commands require a closed-loop design
A command topic is a request, not authority over a physical system. A safe operational pattern includes sender identity, command identifier, target asset, intended state, validity window, an acknowledgement from the responsible local controller or gateway, and a timeout or fault outcome. The consumer must validate source, authorisation, state, and interlocks before acting.
Banalytics can coordinate configured rules and actions around a command workflow, but certified safety controls, PLC logic, safety relays, DCS, and SIS retain their designed authority. An MQTT message must never be the only safeguard between an untrusted producer and a high-consequence physical action.
Prove the contract before connecting every device
- Choose one asset class and document topic owners, consumers, payload schema, retention, and failure rules.
- Test normal operation, disconnects, broker restart, malformed payloads, duplicate delivery, stale retained values, and unauthorised access.
- Expose selected topic messages through the listener-to-event path and verify that events carry source context.
- Measure producer rate, subscriber lag, broker storage, and edge-host resources at realistic peak load.
- Replicate only the tested pattern, with versioned topic contracts and an owner for changes.
An MQTT edge platform is successful when devices and services can evolve independently while operators still know what every message means, who may produce it, and what happens when it is late, duplicated, or absent.