Constantly asking a device what a value is, over and over, when the answer rarely changes, is a lot of traffic to learn very little. Change-of-value reporting flips that around: a device promises to speak up only when a value actually moves by more than a set amount, and stays silent otherwise, so the network carries information rather than repetition. This guide explains what change-of-value, or COV, reporting is, how the subscription and deadband mechanism works at the device-protocol level, and why it dramatically reduces the bytes a telemetry site sends.
Change-of-value (COV) in one line: Change-of-value reporting is a device-protocol mechanism where a client subscribes to a value and the device notifies it only when that value changes by more than a configured deadband, instead of the client polling repeatedly. Because a stable value produces no traffic and only meaningful changes are transmitted, COV sharply reduces the data a device sends, which is especially valuable on metered cellular telemetry links.
The conventional way to track a value is polling: the client repeatedly asks the device for the current reading, again and again on a fixed cycle, whether or not anything has changed. Polling is simple and predictable, but it is also relentless - every cycle costs a request and a reply regardless of whether the value moved, so a value that sits unchanged for hours still generates a steady stream of traffic that conveys nothing new. On a busy site with many values, that adds up to a lot of bandwidth spent confirming that things are the same as last time.
Change-of-value reporting replaces the repeated question with a standing arrangement. The client subscribes once, telling the device it is interested in a particular value, and the device takes on the responsibility of reporting - it watches the value itself and sends a notification to the subscriber whenever the value changes meaningfully. Between changes it says nothing, because there is nothing to say. The client no longer asks; it waits to be told, and it is told only when there is genuine news. The direction of initiative flips from the client pulling to the device pushing.
This subscription model is built into device protocols used in building and industrial automation, where it is a first-class feature rather than something bolted on. A device exposes the ability to be subscribed to, and a supervisory system establishes subscriptions to the points it cares about. The result is that the network carries events - this value just changed to this - instead of a continuous interrogation, which is a fundamentally more efficient way to keep a supervisory system informed about a set of mostly-stable values.
The subtlety in change-of-value reporting is defining what counts as a change worth reporting, because real analog values are never perfectly still - they jitter and drift by tiny amounts constantly, and reporting every last flicker would defeat the whole purpose. The answer is a deadband: a threshold of movement that a value must exceed before the device considers it a real change. Small fluctuations within the deadband are treated as noise and ignored; only a movement larger than the deadband triggers a notification.
The deadband is what makes the mechanism practical. Set it to a value meaningful for the measurement - a pressure change large enough to matter, a level change worth knowing about - and the device stays quiet through the endless small wiggling of a stable reading, speaking up only when the value genuinely moves. Choosing the deadband is a deliberate trade: a tighter deadband reports finer changes at the cost of more traffic, a wider one saves traffic by only reporting bigger moves. The setting tunes how sensitive the reporting is against how much data it produces.
A well-designed change-of-value scheme usually pairs the deadband with a fallback so silence is never ambiguous. Because a value that has not changed produces no messages, a long silence could mean either that nothing changed or that the device has gone dead, and those are very different situations. A periodic refresh - a heartbeat sent occasionally even when nothing has changed - resolves the ambiguity by confirming the device is alive and the value is still what it last reported. That combination, event-on-change plus an occasional confirmation, gives both efficiency and confidence that no news really is good news.
On a metered cellular link, change-of-value reporting is directly a cost saving, because bytes are money and COV sends far fewer of them. A site whose values are stable most of the time - which describes a great many field measurements - produces almost no routine traffic under COV, sending data only when something actually happens. Compared with polling every point on a fixed cycle around the clock, that can cut a site's telemetry to a small fraction of what continuous polling would generate, which shows up directly as a smaller data bill and more headroom under any usage cap.
It also sharpens the information that reaches the operator. Because a COV notification corresponds to an actual change, the telemetry stream is a stream of events rather than a stream of confirmations, and a real movement in a value tends to arrive promptly as its own notification rather than being discovered on the next scheduled poll. The operator sees what changed, when it changed, without wading through a river of unchanged readings. The signal-to-noise of the whole monitoring picture improves, and meaningful changes are less likely to be blurred by fixed polling intervals.
For a cloud SCADA platform such as Merobix, change-of-value reporting is one of the device-level techniques that make efficient telemetry possible from the field upward. Where a device or gateway supports COV, subscribing to values rather than polling them means each site spends its scarce cellular bandwidth only on genuine changes, so the platform receives lean, event-driven data instead of a costly firehose of repetition. Paired with a periodic confirmation so a quiet point is never mistaken for a dead one, COV lets an operator monitor a large fleet of mostly-stable sites without the data cost that constant polling would impose, keeping both bandwidth and bills under control.
The two are closely related ideas - both send data only when something meaningful changes rather than on a fixed cycle. Report by exception is the general principle of transmitting only exceptions to the expected steady state, while change-of-value reporting is the specific subscription mechanism built into device protocols, where a client subscribes to a value and the device notifies it when the value moves past a deadband. COV is essentially report-by-exception implemented as a protocol-level subscription between a device and its client.
The deadband is the threshold of movement a value must exceed before the device treats it as a real change worth reporting. Its job is to stop the device from reporting the endless tiny jitter and drift of a stable analog reading, which would otherwise flood the network. A tighter deadband reports finer changes but produces more traffic; a wider one saves bandwidth by only reporting larger movements. Choosing it is a deliberate trade between sensitivity and data volume.
Because change-of-value reporting produces no messages while a value is stable, a long silence is ambiguous on its own. The usual solution is to pair COV with a periodic refresh or heartbeat, so the device sends an occasional confirmation even when nothing has changed. That way ongoing silence between those confirmations means the value is genuinely stable, while a missing confirmation reveals that the device has gone dead, resolving the ambiguity.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.