BadMonitoredItemFilterUnsupported

BadFilters

What you actually see

The same filter that works against one server is rejected by another, usually a PLC or an embedded gateway, while the item itself is created successfully without the filter.

Why it happens

• Percent deadband not implementedAbsolute deadband is nearly universal; percent deadband requires the server to read EURange and compute a proportion, and constrained servers frequently skip it. The item is fine, the value is fine, the server simply does not do that arithmetic.
• AggregateFilter on a monitored itemAn AggregateFilter asks the server to compute an aggregate such as an average over a processing interval and report the result as the item's value. This is much rarer than historical aggregate support. A server with a full HistoryRead aggregate implementation may still not support aggregates on subscriptions.
• Content filter operators the server does not implementWhere clauses in event filters can use operators beyond simple comparison, including OfType, InList, Between, Like and the relationship operators. Servers implement a subset. The filter is well formed and the operands resolve, but the operator is not available.
• No server-side filtering at allSome small servers serve monitored items straight from a cache with no per-item filter evaluation. They accept DeadbandType None and refuse everything else. Once you know that, the design question is how to reduce load without filtering - usually a longer sampling interval.
• Filter unsupported for this specific item even though supported generallyA server can support deadband on its own variables and not on values it aggregates from a downstream server or a legacy tunnelled source. The same filter then works on some nodes and not others within one address space, which looks inconsistent until you know where the values come from.

How to fix it

In diagnostic order: work down, do not skip ahead.

1. Establish what the server supports once, in a probeAt commissioning, create test items with absolute deadband, percent deadband and a simple where clause, and record which are accepted. Store the result per endpoint. This turns a recurring mystery into a configuration fact and takes a few minutes.
2. Fall back in a defined orderTry Percent, fall back to Absolute computed from EURange or from your own engineering knowledge, fall back to DeadbandType None with a StatusValue DataChangeTrigger. Log which level you landed on per item so the fallback is visible rather than silent.
3. Reduce load with the sampling interval insteadWhere no server-side filtering is available, the only lever at the server is how often it samples. Set a per-item sampling interval that reflects how fast the signal really changes; -1 makes the item inherit the subscription's publishing interval, which is often enough.
4. Filter in the collector and say soApply the deadband client-side and record in your metadata that the tag is client-filtered. This matters for data lineage: a client-side deadband means the server still sampled and transmitted everything, so it does not relieve server or network load.
5. Simplify event where clauses to severity and condition classComparisons on Severity and ConditionClassId are the most widely supported. Replace an OfType-based filter with a severity threshold and do the finer classification in your consumer where the server will not.
6. Check ServerProfileArray for the facets the server claimsThe ServerProfileArray property on the Server object lists the profile and facet URIs the server advertises, including data access and event-related facets. It is a claim rather than proof, but a server that does not advertise a relevant facet is unlikely to implement the filter you want.

Where it shows up, by tool and stack

What it looks like in the log

CreateMonitoredItems: DeadbandType Percent unsupported by server, item created unfiltered
AggregateFilter on monitored item ns=2;s=Line1.Rate returned BadMonitoredItemFilterUnsupported
Falling back to absolute deadband 0.5 for ns=3;s=Oven.Temp

Confirm the fix

Confirm the fallback item is created Good, then confirm the notification rate matches the filtering you believe is in place, and record in your endpoint profile which filter types this server accepted.

Stop it happening again

Probe filter support per endpoint at commissioning and store the result, implement an explicit fallback ladder with logging, and mark client-filtered tags in your metadata so nobody later assumes the reduction happened at the server.

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.