MQTT Publishing New in 1.0.0

Everything else in this section is about getting data in. This page is the other direction: mirroring live namespace tags out to an MQTT broker QUBIQ does not host, so a cloud platform, an analytics stack or another SCADA system can subscribe to your plant.

It does not matter where a tag came from. An OPC-UA tag, a Modbus register, an expression tag and a tag QUBIQ computes itself all publish the same way, because a publisher reads the namespace, not a protocol.

Licensing

Broker egress belongs to the MQTT Driver module. Without it you can still create, edit and turn publishers off — but none can be turned on, and the Publishing view says so by name rather than failing generically. → Licensing & modules

Where it lives

Publishing is part of the Namespace panel, not Settings — it is a fence over the tags that panel owns, and it belongs beside them.

To…	Go to
See and manage every publisher	Namespace → MQTT Publishing (the toolbar toggle; it replaces the tree with the publisher list)
See where one tag goes, and how often	Edit the tag → Publishing tab
Publish a tag, a folder or a multi-selection	Right-click in the tree → Publishing

The checkbox is the verb Changed in 1.0.6

Right-click → Publishing lists the brokers themselves with a checkbox beside each, and that is the whole gesture — for a tag, a folder and a multi-selection alike. Ticking one sends the selection there; unticking stops it. The menu stays open, because ticking a second broker is the usual next move.

A folder is not published — its tags are — so a folder or a multi-selection gets a third state, drawn as a dash:

The box shows	Means
Ticked	The whole selection goes to that broker.
Empty	The fence does not reach any of it.
A dash	The fence reaches into the selection — some of it publishes, some does not.

Clicking a dashed box does not guess. "Publish the rest" and "stop the ones that are" are equally plausible readings of the same click, and this menu writes immediately, so it hands the decision to the dialog instead of sending a subtree to an outside broker on one click from somebody who meant the opposite. Two other cases hand off the same way, because each needs a sentence the menu has no room for: a publish the Except fence would swallow, and a stop that would leave the publisher with an empty scope, which the server refuses outright.

Stopping a folder stops the subtree. A publisher scoped to Line1/Pump and Line1/Valve does not literally cover Line1, and stopping Line1 used to find nothing to remove and report no change — leaving both tags publishing with no way to stop them from the folder they live in. A stop now owns everything under the target.

There is no longer a Publish to MQTT… / Stop Publishing… pair of verbs, and the dialog has no Action radio. A tick means this broker sends these tags and an untick means it stops; the difference from what is true today is the change. Nothing is staged until something is changed, so opening the dialog and closing it cannot alter anything, and a broker nobody touched is never part of the save.

One publisher per broker

A publisher is exactly one broker, one format, one fence. Sending the same tags to two brokers is two publishers, not a list inside one — they are independent by construction, with their own client, their own buffer and their own liveness, so a broker that is down or slow degrades only itself.

The publisher list answers four questions per row:

Column	What it shows
Broker	The publisher's name, the connection it sends to, and a dot: green when enabled.
Sends	How much of the plant it reaches, then the format, QoS, and whether values are retained or buffered.
Status	What it is actually doing right now — published, dropped, failed, stopped.
On	The enable switch, plus edit and delete.

Status comes from the running bridge service, not from the database. A saved publisher and a running one are different things, and telling them apart is the entire point of that column. If the bridge is not answering, the column says so — it does not render as "0 published", which would read as a publisher running and idle, a different problem with a different fix.

Creating a publisher

Add publisher asks for the following. Nothing publishes until you turn the publisher on afterwards — a new one is created disabled.

Field	Default	Notes
Name	—	How the publisher is told apart in the list.
Broker	—	Any MQTT connection.
Format	Classic MQTT	Or Sparkplug B — see below.
QoS	1 — at least once	0 at most once · 1 at least once · 2 exactly once.
Group id / Edge node id	—	Sparkplug B only, and required for it.
Topic prefix	qubiq	Prepended to every tag's namespace path. A live preview under the field shows the topic a real tag would land on.
Tags → Publish	All tags	The scope fence.
Tags → Except	(nothing)	Subtracted from the scope.
Retain last value	on	The broker keeps the last message per topic, so a subscriber that connects later learns the current state instead of waiting for the next change.
Publish on change only	on	Report by exception — see below.
…seconds — send anyway if nothing changed	0 (off)	The heartbeat. Only offered while Publish on change only is on. New in 1.0.6
Never miss a value	off	See Delivery.

Every one of those switches is honoured at creation, not only on a later edit. Unticking Retain, the loop guard or Publish on change only while creating a publisher used to be discarded silently, and only a subsequent save stuck. 1.0.6

The two fences

Publish and Except sit side by side and are always visible, because how much of the plant a publisher sends is the riskiest fact about it and it should not be behind a click.

• Publish is the scope. * means the whole plant, stated explicitly. Anything else is a list of namespace paths; a folder covers everything under it, including tags added later — which is what makes "all of Line 1" a rule rather than a snapshot.
• Except is subtracted. Line1 in Publish and Line1/Diagnostics in Except is the shape most real configurations take.

An empty scope publishes nothing

This is deliberate, on both sides of the wire. If an empty list meant "everything", then the riskiest configuration in the product — every tag in the plant leaving for an outside broker — would be the one you get from a dropped field. So "everything" is *, and it is never inferred.

The same rule makes excluding * a legitimate way to pause a publisher without losing its configuration.

There is no per-tag publish flag. A fence does the same job with no per-tag rows, using the same picker for both halves, and it expresses what people actually want: everything except the diagnostics folder. A tag does carry its own reporting cadence — but that decides how often, never whether.

Topics

A tag's topic is the prefix followed by its namespace path — both already use /, so this is a join, not a translation:

prefix:     qubiq
tag path:   Plant1/Line2/Oven1/Temperature
topic:      qubiq/Plant1/Line2/Oven1/Temperature

Repeated separators collapse and the outer ones are trimmed, so a stray / in a prefix cannot produce an empty topic level.

A prefix may not contain + or # — those belong to a topic filter, not a topic name, and the usual way one arrives here is somebody pasting a subscription they tested in an MQTT client. It may not begin with $ either; that namespace belongs to the broker.

Payload — classic MQTT

One topic per tag, carrying a small JSON envelope:

{ "v": 71.4, "q": "Good", "t": "2026-09-07T04:21:08.132Z", "u": "°C" }

Key	Meaning
v	The value.
q	Quality, verbatim from the source.
t	The source timestamp, RFC 3339.
u	Engineering unit. Omitted when the tag has none.

The keys are short on purpose: this is written once per tag change per broker, and on a plant with tens of thousands of tags the difference between value and v is real bytes on the wire and real storage in every retained message. The vocabulary is the one Sparkplug and most SCADA bridges already use, so a subscriber needs no QUBIQ-specific documentation to read it.

Sparkplug B egress

Choosing Sparkplug B makes the publisher an edge node rather than a topic writer, and the group id and edge node id become part of every topic it sends.

Message	When
NBIRTH	On connect, and again on request. Declares the full metric set with aliases and datatypes.
NDATA	Every subsequent value, numbered and carrying aliases only.
NDEATH	Registered with the broker as the Will before the connection exists, so an ungraceful disconnect still announces the node as dead.

Two details matter in practice:

• bdSeq pairs a death with the birth it ends. The NDEATH published as the Will carries the same birth/death sequence the NBIRTH announced, so a stale death left over from a previous session cannot kill the current one.
• A host can demand a rebirth. Node Control/Rebirth on the node's NCMD topic makes the publisher re-announce its whole metric set — which is how a host that missed the birth resynchronises without restarting anything.

Sequence numbers wrap at 256 and aliases are fixed for the life of a session. Get either wrong and a compliant host discards the stream silently, because that is what the specification tells it to do — which is why the session state machine is a separate, exhaustively tested piece rather than something the publisher improvises.

Delivery: live, or buffered

Never miss a value is the one switch that changes what happens to a value while the broker is away, and it is a genuine trade rather than a quality setting.

	Off — live (default)	On — buffered
How it publishes	Asynchronously, up to 256 un-acked messages in flight	One at a time, in order, blocking on each ack
When the broker cannot keep up	The value is dropped; the newest wins	The value waits in a durable buffer
Can it fall behind?	No — it stays live	Yes, and that is what the buffer is for
Right for	Dashboards and HMIs, where the current value is the whole point	A consumer doing arithmetic on every sample — totalisers, billing, batch records

Live mode leans on Retain last value to cover the gap: a subscriber that connects after a drop still gets the current value from the broker's retained message.

Buffered mode is at-least-once, not exactly-once. A redelivery after an ack that was lost in flight republishes a value the broker already has, which for a tag stream is harmless — the same value on the same topic. Nothing here pretends otherwise.

Report by exception

Publish on change only is on by default, and it does real work: the internal stream carries the scan rate, not the change rate, so a polled protocol producing a reading every 200 ms would otherwise send 300 identical messages a minute to your broker.

A reading is sent when it says something new, which is two questions and not one:

1. Has anything changed — the value, of any type, or the quality. Quality is part of the reading, not metadata about it. With Retain on, suppressing a Good→Bad transition at an unmoved value would leave the broker serving a Good-looking number to every late subscriber for as long as the process stood still, so quality is checked first and on its own.
2. Did it move far enough — and only where the tag declares a deadband. A tag already tuned for the historian is already tuned for the broker. A publisher can override that with an absolute deadband in engineering units through the API — absolute, never percent; the percentage form belongs to alarm hysteresis, which is a different concept on a different model.

A behaviour change on upgrade Changed in 1.0.6

Report by exception was on by default before 1.0.6 and did nothing for the ordinary tag. The gate was the tag's deadband alone, and a deadband of 0 — which is the default, and is documented as a threshold for storage — accepted everything; booleans and strings were never suppressed at all. So most installations have been publishing at the scan rate whatever the switch said.

The first run after upgrading drops those publishers from scan rate to change rate, which is the intent and a large reduction. It is also a real change for any subscriber that was using message arrival as a liveness signal. That is what the heartbeat below is for.

The heartbeat New in 1.0.6

Report by exception makes silence ambiguous: a process standing still and a dead gateway are both a topic that stopped updating. …seconds — send anyway if nothing changed restores no news is good news without giving the scan rate back — a tag on a 250 ms poll with a 60-second heartbeat costs the broker one message a minute instead of 240.

Set per	Publisher. 0 is off, and off is the default.
Minimum	10 seconds.
What it sends	The value already held — it is not a re-read, so it costs the plant nothing and cannot invent a reading the device never gave.
Effect on the rest	None. It touches neither the change baselines nor the storm breaker.
Shown	Only while Publish on change only is on. Without it every scan is already a message, so a heartbeat would be noise with no question to answer.

Classic MQTT only. A Sparkplug host already tracks edge-node liveness through NBIRTH / NDEATH and the Will, which is the protocol's own answer to the same question and a better one.

Per-tag: how often this tag is sent New in 1.0.6

Cadence is a property of the signal, not of the broker it happens to go to. A counter, a heartbeat or a batch step has to arrive at its scan rate wherever it is sent — and one tag can be in the scope of several publishers at once. So the opt-out lives on the tag, on its Publishing tab:

Setting	What it does
Follow the broker (default)	Each publisher applies its own Publish on change only setting. The tab names what that currently resolves to, so "inherit" is something you can see rather than work out.
Only when it changes	Sent when the value moves or its quality does, however often the device is polled — even from a publisher that sends every sample.
Every reading	Every reading is sent, even an identical one. Right for a counter, a heartbeat or a batch step, where arriving at all is the signal.

It is saved with the tag and applies to every publisher below it on that tab. This is a cadence setting, not a coverage one: it cannot put a tag on a broker the fences do not reach, and it cannot take one off.

Loop protection

Publishing tags to a broker QUBIQ also reads from is how a feedback loop starts: a value goes out, comes back in as an update, and goes out again. Four layers stand in the way, and the last one is the one that matters.

1. Configuration. A cycle the configuration can prove is rejected before it runs.
2. Origin exclusion. A value is never published back to the connection it came from. This kills self-echo outright, and the direct leg of an A→B→A pair. A value whose origin cannot be determined is dropped, not passed: an unattributable value is exactly the one that might be a loop, and dropping it costs one sample where publishing it risks a storm.
3. Timestamp. A value that is not newer than the last one sent is collapsed. This works for Sparkplug sources; classic MQTT ingest re-stamps values with its own receive time, so a looped classic value always looks newer and this layer cannot fire for it — which is why there is a fourth.
4. The storm breaker. Each tag is capped at 50 messages per second per broker by default. A tag that sustains more than that is a feedback loop, not a process — no physical measurement needs 50 updates a second on a broker.

The breaker is a token bucket, so a genuine process event that jumps and settles spends burst allowance and recovers; only a sustained rate trips it. And tripping is sticky: the tag is quarantined on that broker and stays stopped until somebody releases it. A rolling limiter would publish 50 messages a second forever, which is a slower storm rather than no storm, and would never present an operator with a fact to act on.

A quarantined tag shows in the Publishing view and on the tag's own Publishing tab, with a badge on the toolbar counting them. Releasing one needs Edit connections and is audited.

Permissions

Publishing reuses the connection vocabulary rather than inventing a second one — a publisher is a use of a connection, and anyone who may edit connections can already point one anywhere.

Action	Permission
See publishers, their status and their coverage	View connections
Create a publisher	Create connections
Edit one, turn one on or off, release a quarantine	Edit connections
Delete one	Delete connections

Turning a publisher on is what starts plant data leaving the building, so it is gated on edit rather than view, and it is audited on its own rather than as part of a save. → Audit journal

Troubleshooting

Symptom	Check
Publisher is on, nothing arrives at the broker	Is a tag in the Publish fence also caught by Except? The exception wins. The bulk dialog says so before you save; the fences themselves do not.
Far fewer messages than before the upgrade	Expected — see the upgrade note. Add a heartbeat if a subscriber was using message arrival as a liveness signal.
One tag floods the broker, or one tag has gone quiet	Its own cadence overrides the publisher's. Check How often this tag is sent on the tag's Publishing tab.
"Nothing is published to a broker" and the switch will not turn on	The MQTT Driver module is not licensed. Check that the page says so in the server's own words — a failed request now reports itself as a failed request and says explicitly that it is not a licensing problem. 1.0.6
Stopping a folder reports no change	Fixed in 1.0.6 — a stop now owns the whole subtree. On an earlier build, stop each tag.
Status shows nothing at all	The bridge service is not answering — check it under Administration → Services.
A tag stopped publishing on its own	The storm breaker quarantined it. Find the loop before releasing it, or it will trip again.
Values arrive but a Sparkplug host ignores them	A missed NBIRTH. Send Node Control/Rebirth, and check the group and edge node ids are unique on that broker.
A subscriber that joins late sees nothing until the next change	Retain last value is off.
Topics have an empty level in them	A stray separator in a namespace name — the join collapses repeats, so this is a name to fix rather than a prefix.

See also

• MQTT & Sparkplug B connections — the inbound half
• Tags — deadband, quality and units, all of which travel with a published value
• Store and forward — the same durable-buffer idea, for database writes