In an MQTT network an edge node can be perfectly connected to the broker and still be publishing into the void, because the SCADA system that is supposed to consume its data has gone offline. Sparkplug solves this with the primary host application: a designated consumer whose online-or-offline status the edge nodes watch, so they know not just that they reached the broker but that the system meant to receive their data is actually listening. This guide explains what the primary host application is, how it announces its state on the STATE topic, how edge nodes use that signal, and why losing the primary host - not merely the broker - is what triggers store-and-forward buffering at the edge.
Sparkplug Primary Host Application in one line: A Sparkplug primary host application is the designated consuming SCADA or host system that edge nodes monitor to decide whether they are truly connected end to end. It publishes its online or offline status on a STATE topic keyed to its host ID, and edge nodes watch that topic - if the primary host goes offline, the nodes treat their data path as broken and begin buffering, even though their link to the broker is still up.
MQTT decouples publishers from subscribers through a broker, which is powerful but has a blind spot: a publisher has no inherent way to know whether anyone is receiving what it sends. An edge node can hold a healthy connection to the broker and keep publishing, yet the consuming application may have crashed, lost its connection, or restarted, in which case the node's data is being delivered to no one. For a control system that is an unacceptable ambiguity - a node that thinks all is well while its data goes nowhere.
The primary host application is Sparkplug's answer. It is the specific consuming host - typically the SCADA or IIoT platform ingesting the data - that has been designated as the one whose presence matters. Rather than every edge node trying to track every possible consumer, the architecture nominates one primary host, gives it a known identifier, and lets the edge nodes watch just that one entity. When the primary host is online, nodes know their data has a live destination; when it is offline, they know it does not.
This turns end-to-end connectivity from something a node can only assume into something it can actually verify. The distinction being drawn is between reaching the broker and reaching the consumer. Reaching the broker means the node's link is up. Knowing the primary host is online means the whole path from node to consumer is intact. Sparkplug makes the second condition explicit and observable, so a node's sense of being connected reflects the real state of the data pipeline rather than just its own local link.
The primary host advertises its status on a STATE topic that carries its host identifier, and every edge node that cares subscribes to it. When the primary host application comes online and establishes its session, it publishes an online status on its STATE topic, telling all watching nodes that the consumer is present and ready. This is the host-side counterpart to an edge node's birth - just as a node announces its own arrival, the primary host announces its arrival to the nodes that depend on it.
Crucially, the primary host registers an offline STATE message as its MQTT last will when it connects, so that if it disconnects ungracefully, the broker publishes the offline status on its behalf. This is the same last-will mechanism that edge nodes use for their death messages, applied to the host. Whether the primary host shuts down cleanly and publishes its own offline status, or drops off the network and has the broker publish it, the watching edge nodes reliably learn that the consumer has gone offline. There is no scenario where the host quietly vanishes and leaves the nodes falsely believing it is still there.
This symmetry - the host has a birth and a death just as nodes do - is what makes the Sparkplug session model coherent from both ends. Edge nodes announce themselves to the host through their births and deaths, and the primary host announces itself to the nodes through its STATE topic. Both sides use the broker's last-will feature so that ungraceful disconnects are still announced. The result is a network where every participant that matters has an explicit, broker-backed way of saying whether it is present, rather than leaving anyone to guess from silence.
The practical payoff of watching the primary host is what happens when it goes away. When an edge node sees the primary host's STATE go offline, it concludes that its data no longer has a live destination even if its own broker connection is fine. Rather than continuing to publish into a void where the readings would be lost, a well-designed edge node begins store-and-forward: it buffers its measurements locally, holding the historical data until the primary host returns. This is the key insight - it is the loss of the host, not the loss of the broker, that should trigger buffering, because a node can be perfectly connected to the broker while the consumer is down.
When the primary host comes back and republishes an online STATE, the watching edge nodes recognize that the destination is alive again. At that point they can flush their buffered data forward, delivering the readings that accumulated during the outage so the host's history has no unexplained gap. Combined with the node re-establishing its birth so the host has a fresh, complete model, this lets the system heal cleanly from a host outage: the operator sees a continuous record rather than a hole where the consumer was down.
This is precisely why the primary host concept matters for cloud SCADA over unreliable field links. A cloud platform such as Merobix acting as the primary host application publishes its own STATE, so remote edge nodes on well pads and compressor stations know exactly whether the cloud consumer is reachable. If cloud connectivity drops, the field devices buffer their measurements locally and forward them when the platform returns, so intermittent backhaul does not mean lost history - the gap is filled the moment the primary host is back online. Watching the host rather than just the broker is what makes that buffering trigger correctly, and it is the difference between a resilient field deployment and one that silently drops data whenever the cloud consumer blinks.
The broker is the message router that relays publications between clients; the primary host application is a specific consumer of Sparkplug data, typically the SCADA or IIoT platform. An edge node can be connected to the broker while the primary host is offline, which means its data has nowhere to land. Sparkplug has nodes watch the primary host's STATE precisely so they can tell the difference between reaching the broker and reaching the consumer.
When a node sees the primary host's STATE turn offline, it recognizes its data no longer has a live destination even if its broker link is fine, so a well-designed node begins store-and-forward, buffering its measurements locally. When the primary host republishes an online STATE, the node flushes the buffered data forward and re-establishes its birth. This fills the gap so the host's history stays continuous across the outage.
It publishes its status on a STATE topic keyed to its host identifier, sending an online message when it connects and registering an offline message as its MQTT last will. That last will means the broker publishes the offline status automatically if the host disconnects ungracefully. Between the host's own clean shutdown message and the broker-published last will, watching edge nodes reliably learn whenever the consumer goes offline.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.