MQTT and Sparkplug B

Connection properties#

A subscription is not a history#

This is the most important thing to understand before modelling on MQTT.

A subscription receives what is published from the moment it connects. There is no back-fill, no request for last Tuesday, no way to recover what was published while Infohub was stopped.

Consequences to plan for:

• History starts when you deploy. If Infohub is becoming the record for these values, the first day is the first day.
• Downtime is a gap. If the Infohub instance or its Platform is down for two hours, those two hours are lost permanently.
• Restarts matter. Redeploying the connection reconnects the subscription; anything published during the gap is gone.

Where the values genuinely matter historically, either publish into a historian and read that instead, or accept the gaps and document them so nobody later mistakes a gap for a process event.

Purge Age#

Purge Age controls how long Infohub retains received values before discarding them.

It must comfortably exceed the interval you aggregate to. If you aggregate to hourly, values must survive long enough for the engine to build the hour that contains them — including any delay in the engine getting to that period. A purge age set too tight produces sparse or empty aggregations from a subscription that is demonstrably receiving data, which is a confusing failure to diagnose.

Set it generously. Retaining a few hours of values costs little; losing them costs the period.

Topics and the namespace#

MQTT topics are hierarchical, separated by a delimiter. The Namespace Delimiter property tells Infohub how to interpret the hierarchy so it can present a browsable namespace.

The connector can enumerate topics it has seen. That is a meaningful qualifier: a topic that has not published since Infohub connected does not exist as far as browsing is concerned. A slow-publishing topic may simply not appear yet.

Where you know the topic and it is not listed, entering it directly is legitimate. Verify afterwards that values arrive.

JSON payloads#

Set JSON Payload when publishers send structured JSON rather than a bare value. This is very common in modern deployments, where one message carries a value, a timestamp, a quality, and often several tags at once.

Before configuring, capture an actual message from the broker with a generic MQTT client and look at it. Guessing the payload shape is the main reason MQTT measures return nothing while the subscription is plainly alive.

Two things worth checking in the payload:

Timestamp units. JSON timestamps are frequently Unix epoch values, and whether they are in seconds or milliseconds is not obvious from looking at one number. Getting it wrong places every value a long way from where it belongs.

Time zone. A timestamp with no offset is ambiguous. Confirm what the publisher means by it rather than assuming UTC.

Sparkplug B#

Sparkplug B is a specification layered on MQTT that standardises topic structure, payload encoding, birth and death certificates, and sequence numbering. Where a plant has adopted it, select it as the Protocol rather than treating the traffic as plain MQTT.

Ignore Sequence relaxes Sparkplug's sequence-number checking. Sparkplug uses sequence numbers to detect lost messages, and strict checking is the correct default. Enable this only when a non-conforming publisher produces sequence numbers Infohub cannot reconcile and you have decided to accept the resulting uncertainty — and note that decision somewhere, because it disables a genuine data-integrity check.

Security#

Brokers are frequently exposed more widely than historians, so treat this connection's security properly:

• Enable TLS unless the broker is on an isolated network segment, and even then prefer it.
• Pin the SSL Protocol to a current version rather than accepting whatever is negotiated.
• Use client certificates where the broker supports them, configured through the certificate store and name.
• Subscribe with least privilege. The account should be able to subscribe to the topics Infohub needs and nothing else — and should not be able to publish at all.

That last point matters: a subscriber credential with publish rights is a route from a reporting system into plant control traffic.

Reaching a broker on a plant network#

As with any connection, an MQTT connection is hosted on a Platform. Where the broker lives inside a plant network, host the connection on a Platform running there and let Flow-to-Flow traffic cross the boundary instead of exposing the broker. See Infohub Architecture at a Glance.

Diagnosing#

See also#

• How Infohub Retrieves Data
• Choosing a Data Source
• MQTT and Sparkplug B Consumers
• Connection Property Reference