Solace Sparkplug B: Compliance, the Eclipse List and State Across a Mesh

Solace Sparkplug support is real but unofficial. Solace states on its IoT page that it supports “open standards like MQTT (including MQTT 5.0) and Sparkplug B”, and a Solace community post from August 2023 reported broker 10.5 passing the Eclipse Sparkplug compliance test. But Solace is not on the Eclipse Sparkplug compatible list as of October 2026, its MQTT documentation does not mention Sparkplug, and retained messages, which Sparkplug depends on, are a Controlled Availability feature. This page explains what Sparkplug asks of a broker, what the 2023 result does and does not prove, and how birth, death and state behave when edge nodes and host applications sit on different brokers of a mesh.

It belongs to Solace in manufacturing in the Solace cluster.

What Sparkplug B adds to MQTT

MQTT moves bytes on topics and says nothing about what they mean. Sparkplug, an Eclipse Foundation specification introduced by Cirrus Link in 2016, adds three things on top: a fixed topic form (spBv1.0/group_id/message_type/edge_node_id/device_id), a Protobuf payload with typed metrics, and session state, meaning birth and death certificates so a host always knows whether its data is live. Our UNS guide covers why plants use it, and the MQTT guide covers Will messages and retained messages, the two MQTT features Sparkplug builds on.

Sparkplug 3.0 is an international standard. Version 3.0 was released on 21 October 2022, and on 7 November 2023 the Eclipse Foundation announced it had been published as ISO/IEC 20237:2023 through the JTC 1 Publicly Available Specification process. Eclipse keeps stewardship. A version 4 is in development but not published.

What “Sparkplug compliant” means for a broker

Section 10 of the Sparkplug 3.0 specification defines two broker levels. A Sparkplug Compliant MQTT Server needs only a subset of MQTT. A Sparkplug Aware MQTT Server adds birth-certificate storage. Here is how Solace’s documented MQTT behaviour, from Using MQTT, lines up:

Sparkplug 3.0 requirement	Level	Solace documented behaviour, October 2026
Publish and subscribe at QoS 0	Compliant	Supported
Publish and subscribe at QoS 1	Compliant	Supported (QoS 2 is converted to QoS 1, which Sparkplug does not need)
All aspects of Will messages, including retain and QoS 1	Compliant	Supported, but Will messages are not sent when a session ends because of a broker restart, HA failover or Message VPN shutdown
All aspects of the retain flag	Compliant	Retained messages are a Controlled Availability feature, implemented through retain caches
Store latest NBIRTH and DBIRTH and serve them on $sparkplug/certificates/...	Aware	Not documented by Solace; we found no evidence of it

The two qualifications in the middle column are the ones that matter. Sparkplug uses a retained message for host STATE and Will messages for both host and edge-node death. Both are supported in principle, both carry a documented condition.

The 2023 community test versus the Eclipse list

Precision matters here, because “Solace is Sparkplug compliant” and “Solace is not Sparkplug compliant” both circulate, and neither is quite right.

	The 2023 community run	The Eclipse compatible list
What it is	A Solace Community post by user RonInglesby, 29 August 2023	Eclipse’s published list of products whose test results were submitted and accepted
Version tested	Broker 10.5	Not applicable: Solace is not listed
Result	Reported passing the Sparkplug compliance test for a broker	Listed brokers include Cirrus Link Chariot, HiveMQ Community and Professional editions (plus the Sparkplug Aware extension), NanoMQ and Integration Objects’ SIOTH brokers
Conditions	The VM’s memory had to be raised to 8,192 MB to make the MQTT retain changes, plus a max-memory setting	Each listing names the version tested
Follow-up	In December 2023, asked about submitting to Eclipse, the poster replied “we are considering posting the results there”	No Solace entry as of October 2026

How to read it. The run shows that a correctly configured Solace broker could pass the Sparkplug broker test in 2023. It does not show that the current long-term release (10.26.0, as of October 2026) passes, that the default configuration passes, or that Solace supports it as a product commitment. Solace is also not a member of the Sparkplug Working Group. Our wording: compatible as an MQTT transport, self-tested, not Eclipse-listed. If Sparkplug is central to your plant, run the Eclipse Sparkplug TCK against your exact version and configuration, or put an Eclipse-listed broker at the site (see Solace vs HiveMQ).

State, birth and death across a mesh

Sparkplug was written assuming the edge node and the Primary Host Application talk to the same MQTT server, or that the host is connected to every server in the infrastructure. A mesh can break that assumption.

How it works on one broker. The Primary Host connects with a Will of STATE online=false, subscribes to its own spBv1.0/STATE/host_id topic, then publishes online=true at QoS 1 with the retain flag set. An edge node configured with that Primary Host waits until it sees the host online, then publishes NBIRTH and DBIRTH (never retained) and carries its NDEATH as its MQTT Will, at QoS 1, not retained, with a bdSeq number that ties the death to the matching birth. Data follows as NDATA and DDATA, each carrying a seq number from 0 to 255 so the host can spot a gap and ask for a rebirth. Cirrus Link’s MQTT Transmission, for example, stores data locally while the Primary Host is offline and publishes it when STATE returns to online.

What changes across a mesh.

1. Retained STATE must be visible at the edge node’s broker. If the host publishes STATE to the central broker and the edge node subscribes at the plant broker, the edge node only behaves correctly if the retained STATE is readable there. Whether retained messages held in a retain cache are available across a dynamic-routing link is not documented; test it.
2. Will messages fire at the broker the client was connected to. If the plant broker restarts or fails over, Solace does not send Will messages, so the host never receives NDEATH and may show stale values as live until the edge node reconnects and sends a new NBIRTH. See high availability and disaster recovery for the failover model.
3. The multi-server rule assumes the host is everywhere. The specification says an edge node should move to the next server where the host’s STATE shows online=true. On a mesh where the host connects to one broker only, that logic needs care.

The pattern we would start from: keep Sparkplug inside the site, with edge nodes and their host application (for example a SCADA MQTT host) on the same plant broker, and send modelled, ISA-95-shaped data up the mesh. The Ignition and HighByte page shows that pattern.

Where it gets hard

• No listing means no shared evidence. With an Eclipse-listed broker, the test result is public and tied to a version. With Solace, the evidence is one 2023 forum post. Budget time to run the TCK.
• Retained messages are Controlled Availability. Get the support status for your version in writing.
• Failover without death certificates. Decide how the host detects stale data after a broker failover, and test it by failing the broker during a shift change on a test system.
• Not Sparkplug Aware. Tools that read $sparkplug/certificates topics to rebuild state will not find them.
• Two namespaces. Sparkplug topics identify edge nodes, not lines. The unified namespace page covers mapping them into an enterprise tree.

The protocol-level detail on Solace’s MQTT implementation is on Solace MQTT. If your plants already run Sparkplug and you are deciding where Solace fits above them, that layering decision is part of our IT/OT integration work.