Glossary · Subscriptions

DataChangeFilter

A DataChangeFilter is the filter attached to a data MonitoredItem. It has three fields: Trigger (Status, StatusValue, StatusValueTimestamp), DeadbandType (None, Absolute, Percent) and DeadbandValue. Together they decide which samples become notifications. Anything the filter rejects never enters the queue and is never delivered or counted as overflow.

Where it sits in the pipeline

Sample, then filter, then queue, then publish. That order explains the tuning strategy: a deadband reduces pressure on the queue, but a bigger queue cannot recover what a deadband removed. Filter first to cut noise at the source, then size the queue for what genuinely survives, then choose a publishing interval for the consumer. Reversing that order produces either data loss or wasted bandwidth.

The three filter kinds share one slot

The Filter field of a MonitoredItem takes a DataChangeFilter for value items, an EventFilter for event and alarm items, or an AggregateFilter for server-side aggregation over each sampling window. They are mutually exclusive per item. Sending a filter type a server does not implement returns BadMonitoredItemFilterUnsupported, and a structurally wrong one returns BadFilterNotAllowed or a filter-specific code.

Support is uneven on embedded servers

Many PLC and device servers accept a DataChangeFilter object and implement only DeadbandType None. Some report that honestly with BadMonitoredItemFilterUnsupported in the per-item result; others return Good and ignore the deadband entirely. Verify empirically - configure the filter, then compare the notification rate against the unfiltered rate on the same tag.

Example

A filter for a noisy analogue tag, and the per-item result to check

MonitoredItem  ns=3;s="Line3"."Extruder"."MeltPressure"
  SamplingInterval 100
  Filter: DataChangeFilter {
    Trigger      = StatusValue      # status or value changes
    DeadbandType = Absolute         # Percent needs EURange on the node
    DeadbandValue = 0.5             # in the value's engineering units
  }
  QueueSize 10   DiscardOldest true

Check results[i].StatusCode, results[i].FilterResult, results[i].RevisedSamplingInterval
and results[i].RevisedQueueSize - not just the overall response status.
The mistake people make: Applying a deadband to a value that has no meaningful distance - a boolean, a state enumeration, a string or a structure. At best the server rejects it with BadDeadbandFilterInvalid; at worst it accepts and behaves unpredictably. For discrete values, use the trigger and the sampling interval to control traffic instead.

Defined in: Part 4 - Services, MonitoringFilter and DataChangeFilter; Part 8 - Data Access for the deadband semantics.

Last verified 7 September 2026 against OPC UA 1.05.07. OPC UA Connect is an educational resource and is not affiliated with the OPC Foundation.

Free download
OPC UA Server Acceptance Test Pack
A 40-check acceptance test you run against a vendor's server before commissioning sign-off. Weighted scoring, three hard gates, and a one-page verdict for the supplier meeting.
Get the free test pack →
Free, no course, no login