Sparkplug B

The suite implements the Eclipse Sparkplug 3.0 specification on both sides: Artek-MQTT-Pub provides a Sparkplug B edge node and Artek-MQTT-Sub provides a Sparkplug B host application. Both use the Eclipse Tahu library and work over MQTT 5.0 or 3.1.1.

Edge nodes are managed on Artek MQTT → Edge Nodes, host applications on Artek MQTT → Host Applications.

Edge node (Pub)

An edge node publishes its births, data and deaths under spBv1.0/<group_id>/<msg_type>/<edge_node_id>[/<device_id>], for the node itself and for any devices under it.

• Primary-host aware. When you name a primary host, the edge node waits until that host is online before publishing its node birth (NBIRTH), and ignores stale or out-of-order host STATE messages.
• Death certificate as MQTT Will. The node death (NDEATH) is registered as the connection's MQTT Will, so the broker announces it if the gateway drops off the network. It is in place from the very first connection after a gateway start.
• Rebirth on request. The edge node subscribes to node commands (NCMD) before it publishes its birth, and the mandatory Node Control/Rebirth metric is included in every NBIRTH.
• Sequence numbers. seq runs 0 to 255 per edge node and wraps; bdSeq increases on every new connection and is reused on a rebirth, as the specification requires.
• Valid ids only. Group, edge node, device and primary host ids that are empty, have leading or trailing spaces, or contain /, + or # are refused when you save.

Host application (Sub)

A host application consumes Sparkplug data and turns it into tags in the managed tag provider ([MQTT] by default; see Subscribing).

• STATE. The host publishes its online/offline STATE on spBv1.0/STATE/<host_id> as retained JSON {online, timestamp}, and restores it if it goes missing (self-healing). On a graceful stop it publishes a retained offline STATE.
• Rebirth on error. When it sees a sequence gap or another error, the host asks the edge node for a rebirth.
• Stale on death. On a node death (NDEATH) the node's and its devices' metric tags go Bad_Stale. On a device death (DDEATH) only that device's tags go Bad_Stale.
• Commands. The host application is a consumer. The only commands it sends to edge nodes are automatic rebirth requests.
• Valid ids only. Messages with an empty or space-padded id level are refused. If two different edge ids would map to the same tag folder (for example E.1 and E_1, or ids that differ only in letter case), the host refuses both and holds that folder's tags Bad, so neither edge node can take over the other's tags.

Sharing a connection profile

Several edge nodes and host applications can share one connection profile. Each is a separate logical entity on that one broker session, which has one consequence:

When you disable one of them, it still publishes its death (NDEATH, or a retained offline STATE for a host) on the open session, but it does not send an MQTT DISCONNECT packet, because that would also disconnect every other edge node and host application on the same profile.

If you need strict per-entity disconnect behavior, give each edge node or host application its own connection profile. The suite supports that: each connection carries its own Will.

Eclipse Sparkplug TCK results

The results below are factual records of running the Eclipse Sparkplug TCK 3.0.0 (with its HiveMQ CE broker extension) against this suite, cross-checked against Eclipse Tahu's reference edge node and host application.

How to read them:

• "PASS but INCOMPLETE" is the TCK's normal verdict when some conditional assertions do not apply to the device under test (for example a 3.1.1-only assertion against a client that connects with MQTT 5).
• The TCK's console automatically answers its own operator prompts as PASS. Those automatic answers are not counted as evidence here. Where a prompted behavior mattered (the host marking metrics stale), it was verified separately by reading the tags directly.

Test	Profile	Verdict	Notes
SessionEstablishment	Host	PASS but INCOMPLETE, 0 FAIL	Every applicable assertion passes (connect, will/death, birth, subscribe, STATE publish, birth order, STATE resend, all monitors). The only assertion not executed is clean-session-311, the MQTT 3.1.1 variant; the host connected with MQTT 5.
SessionEstablishment	Edge (no device)	62 PASS, 1 FAIL	The one FAIL is message-flow-device-dcmd-subscribe, a limitation the TCK itself acknowledges: it is checked unconditionally even though an edge node with no devices has no device commands to subscribe to. Device assertions are correctly not executed.
SessionEstablishment	Edge (with a device)	87 PASS, 1 FAIL, 1 N/A	The same single FAIL. All device birth and data assertions execute and pass.
SessionTermination	Edge	PASS but INCOMPLETE, 0 FAIL	DDEATH, intentional-disconnect NDEATH and the will message pass. The MQTT DISCONNECT packet assertions are not executed (see below).
PrimaryHost	Edge	PASS but INCOMPLETE, 0 FAIL	phid-wait-timestamp, host-offline-timestamp and host-offline-reconnect pass, confirming that births wait for the primary host and that stale STATE timestamps are handled.
SessionTermination	Host	PASS but INCOMPLETE, 0 FAIL	The host publishes a graceful retained offline STATE when it stops. The per-application MQTT DISCONNECT assertions are not executed (see below).
MessageOrdering	Host	PASS (all executed)	An immediate rebirth request on a sequence gap is accepted as valid recovery. No operator prompts were involved.
EdgeSessionTermination	Host	PASS	The assertions observed over MQTT pass. The six edge-node-termination-host-action-* assertions (mark node and device metrics stale) are operator prompts; they were verified separately by reading the [MQTT] tags, which showed Bad_Stale on NDEATH (node and devices) and on DDEATH (device only).
SendCommand	Host	Not run	The host application only sends automatic rebirth commands, so answering this test's operator prompt as passed would be a false pass.
MultipleBroker	Host	Not run	Requires a second broker; not in the scope of this run.

The two assertions not executed by design

Two groups of assertions are not executed because of how the suite shares connections, not because of a defect:

1. The edge node's intentional-disconnect packet assertions.
2. The host application's per-application MQTT DISCONNECT death-sequence assertions.

In both cases the death message is always published. It is just not followed by an MQTT DISCONNECT packet, because the edge node or host application shares its broker session with others (see Sharing a connection profile). Giving each one its own connection profile provides strict per-entity disconnect behavior.

Certification

The suite implements the Eclipse Sparkplug 3.0 specification and publishes its Eclipse Sparkplug TCK results as factual test evidence. It is not certified under the Eclipse Sparkplug Compatibility Program. Sparkplug® and the Sparkplug logo are registered trademarks of the Eclipse Foundation.