Design MQTT topics and message flow for industrial telemetry using the Sparkplug B specification
domain: sparkplug.eclipse.org · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Structure every topic as spBv1.0/<Group ID>/<Message Type>/<Edge Node ID>/[Device ID], e.g. spBv1.0/FactoryA/DDATA/Line3/Machine7
On edge node startup, publish an NBIRTH declaring every metric name with an assigned numeric alias, then a DBIRTH for each attached device
For ongoing updates, publish NDATA or DDATA referencing metrics by their numeric alias instead of the full name, per the sparkplug_b.proto payload schema
Register the edge node's MQTT Will as the NDEATH topic at connect time so the broker publishes it automatically on ungraceful disconnect
Subscribe to spBv1.0/STATE/<host application id> to track whether the primary host application is online before trusting data messages
Publish all Sparkplug message types at QoS 0 as required by the spec
Known gotchas
An alias is only valid after it has been defined in the corresponding BIRTH message — publishing DATA with an undefined alias breaks compliant subscribers
The Group ID + Edge Node ID pair must be unique across the entire Sparkplug network or session state tracking breaks
STATE message handling differs between Sparkplug spec versions 2.2 and 3.0 — confirm which version the host application and edge nodes both implement
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?