MQTT and Sparkplug B Consumers

Connection properties#

Topic and payload formats#

These two properties are where the design work happens, and they are what makes the consumer flexible enough to fit an existing broker convention rather than imposing one.

Both are templates. Rather than publishing a fixed shape, you describe the topic a value should go to and the body it should carry, and Infohub substitutes per measure.

Placeholders let the model's own structure drive the topic — model attributes in particular, so the topic reflects the plant hierarchy:

plant/[ModelAttribute("Area")]/[ModelAttribute("Line")]/<measure>

A [Version] placeholder is also available in custom topic and payload formats, which is new in 7.2.0. It lets subscribers distinguish payload revisions — useful when you need to change the payload shape without breaking existing consumers, because they can key off the version rather than guessing.

Keep the payload as simple as the subscribers need. A JSON body with a value, a timestamp, and a quality is easy for anything to consume. An elaborate nested structure is harder for every subscriber and provides no benefit unless something actually reads the extra fields.

Timestamps in the payload#

Publish timestamps unambiguously. Two decisions:

Units. If publishing epoch values, be explicit about seconds or milliseconds and document it. Subscribers cannot tell from the number, and getting it wrong puts values decades away.

Time zone. Publish UTC, or include an explicit offset. A timestamp with no offset is ambiguous, and every subscriber will resolve the ambiguity differently.

These are the same problems the MQTT data source faces reading other people's payloads. Having experienced it from the consuming side is a good argument for being precise on the publishing side.

Sparkplug B#

Selecting Sparkplug as the Protocol switches to that specification's conventions: a standardised topic structure, encoded payloads, birth and death certificates, and sequence numbering.

Group ID and Node ID establish Infohub's identity in the Sparkplug namespace. These are not free-form labels — they position Infohub within the plant's Sparkplug topology, and they must be agreed with whoever governs it. Two publishers claiming the same group and node identity will confuse every subscriber.

Choose Sparkplug when the plant has adopted it. Its advantages — automatic discovery, state awareness, defined semantics — only exist if subscribers expect it. Publishing Sparkplug into an environment where nothing speaks it adds complexity for no benefit, and plain MQTT with a well-designed topic structure is the better choice there.

Quality of Service#

MQTT's delivery guarantees, from at-most-once to exactly-once. Higher levels cost broker resources and latency.

For reporting data published every interval, the middle ground is usually right: losing a message occasionally is tolerable because the next one supersedes it, and the values remain available in Infohub regardless. For values a downstream control decision depends on, raise it.

Note that QoS governs delivery while connected. It does not replay messages published while a subscriber was absent — that is the subscriber's problem, and it is why a broker is not an archive.

Security#

Brokers are frequently reachable more widely than databases, so treat this properly:

• Enable TLS, and pin the SSL protocol to a current version.
• Use a dedicated credential for Infohub's publishing, not a shared one.
• Grant publish rights only to the topics Infohub uses, and no subscribe rights at all. A publisher credential that can also subscribe, or publish anywhere, is a wider hole than it needs to be.
• Use client certificates where the broker supports them.

Volume#

A broker sees every value you publish. Do the arithmetic: a thousand measures at hourly intervals is 24,000 messages a day, and at minutely intervals it is 1.4 million.

Publish what subscribers need, at the interval they need it. Publishing a minutely measure to a broker whose subscribers report daily is a great deal of traffic for no benefit — and the namespace filter is the tool for narrowing it.

Also remember that restatements republish. A backfill in Infohub produces a burst of messages for historical periods, which subscribers expecting only current values may handle badly. Warn them, or exclude backfilled periods from publication.

Diagnosing#

See also#

• What a Data Consumer Is
• MQTT and Sparkplug B
• Consumer Reference
• Model Attributes