Constantly asking a device for values it has not changed wastes bandwidth, and over a remote link that waste is expensive. OPC UA solves this with subscriptions: instead of the client repeatedly reading, the server watches the points the client cares about and pushes updates only when something changes. This guide explains how subscriptions and monitored items work, what the sampling interval, publishing interval, and deadband each control, and why this push model suits a bandwidth-limited remote site far better than nonstop polling.
OPC UA Subscription and Monitored Item in one line: An OPC UA subscription is a standing arrangement in which the server sends the client data changes on a set of points rather than the client polling for them. Each point the client wants to watch is registered as a monitored item, with a sampling interval that says how often the server checks the value and a deadband that says how much it must change before it counts. The subscription's publishing interval then batches accumulated changes and delivers them together, so only meaningful updates cross the network.
A subscription is a container the client creates on the server to receive change notifications. Inside it, the client adds monitored items, one per node it wants to watch - a wellhead pressure, a tank level, a pump status. Each monitored item tells the server to keep an eye on a particular node's value and to queue up notifications when it changes. The subscription itself is the delivery channel that carries those queued notifications back to the client on a schedule.
Three settings govern the behavior. The sampling interval is how frequently the server samples the underlying value of a monitored item - for instance, every second - to decide whether it has changed. The deadband, discussed below, filters out changes too small to care about. The publishing interval is how often the subscription actually sends whatever notifications have accumulated; a server might sample a value every second but publish batched changes every five seconds, bundling several updates into one message. Separating sampling from publishing lets the server watch closely while still transmitting efficiently.
If nothing has changed by the time a publishing interval elapses, the server does not waste a message on unchanged data - though OPC UA includes keep-alive messages so the client knows the subscription is still healthy during quiet periods. This is the heart of the model: the network carries change notifications and periodic health signals, not a continuous stream of identical readings. A value that sits steady for an hour generates almost no traffic, while a value that moves is reported promptly, all governed by the intervals the client requested when it set the monitored items up.
Analog values jitter. A pressure transmitter reading a nominally steady process will still wobble by tiny amounts from measurement noise, and if every wobble counted as a change, a subscription would fire constantly and defeat its own purpose. A deadband is the threshold that solves this: it tells the server how much a value must move from its last reported reading before the change is worth sending. Movement smaller than the deadband is treated as no change and produces no notification.
OPC UA supports an absolute deadband, expressed in the engineering units of the value - report only if the pressure moves by at least two kPa, for example - and a percent deadband expressed relative to the value's configured range. Choosing a deadband is a trade-off. Set it too tight and noise floods the link with meaningless updates; set it too loose and you miss real, gradual drift. A sensible deadband is large enough to swallow instrument noise but small enough to catch changes an operator would actually want to see.
The deadband works together with the sampling interval to shape the traffic. The sampling interval limits how often a change can possibly be detected, and the deadband limits how large a change has to be to matter. A monitored item might sample every second but, thanks to its deadband, only generate a notification a few times an hour when the process genuinely moves. This combination is what lets a client watch a value attentively without paying for constant transmission of a number that is barely moving.
Modbus has no native change-driven delivery. A Modbus master reads registers on a fixed cycle, retrieving the same values over and over whether or not they moved, because the protocol offers no way for the device to say I only changed this one point. On a fast local wire that is fine, but on a metered cellular link at a remote pad it means paying continuously to re-fetch data that has not changed - the bandwidth cost scales with the polling rate, not with how much the process is actually doing.
An OPC UA subscription inverts that economics. The server does the watching locally, where bandwidth is free, and only sends notifications when a monitored item changes past its deadband. A field where most values are steady most of the time produces a trickle of traffic that spikes only when something happens, which is exactly the pattern a bandwidth-limited or metered connection wants. The client also stops spending effort composing and timing read requests; it declares what it cares about once and then simply receives updates.
For a cloud SCADA such as Merobix monitoring remote sites over cellular or satellite, subscriptions are the efficient way to consume OPC UA data. Merobix registers monitored items for the wellhead pressures, tank levels, and equipment statuses it needs, sets sensible sampling intervals and deadbands so instrument noise does not saturate the link, and receives batched change notifications on the publishing interval. A steady field generates minimal traffic while a developing problem is reported promptly, which is precisely the behavior a remote, connectivity-constrained operation needs - responsiveness where it matters without paying to re-send values that never moved.
The sampling interval is how often the server checks a monitored item's value to see whether it has changed. The publishing interval is how often the subscription actually sends the accumulated change notifications to the client. A server can sample frequently but publish less often, batching several detected changes into one delivery to reduce message overhead.
A deadband sets how much a value must move from its last reported reading before the change is reported. Movement smaller than the deadband is ignored, which filters out instrument noise so a steady but slightly jittery signal does not generate constant notifications. It can be absolute, in engineering units, or a percentage of the value's range.
Polling re-fetches the same values on a fixed cycle regardless of whether they changed, so the bandwidth cost scales with the polling rate. A subscription only sends notifications when a monitored item actually changes past its deadband, so a mostly steady field generates little traffic and spikes only when something happens. That change-driven pattern fits metered or bandwidth-limited connections far better.
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.