BadFilterNotAllowed

BadFilters

What you actually see

CreateMonitoredItems or ModifyMonitoredItems rejects a specific item with this code while identical items without a filter are accepted.

Why it happens

• DataChangeFilter on an attribute other than ValueDeadband and DataChangeTrigger only make sense for the Value attribute of a Variable. Monitoring DisplayName, Description, AccessLevel or any other attribute is legal, but attaching a DataChangeFilter to it is not. Client code that applies a default filter to every item it creates hits this the first time someone monitors a non-value attribute.
• Wrong filter class for the itemAn EventFilter belongs on an item monitoring the EventNotifier attribute of an event-emitting Object; a DataChangeFilter belongs on a Value item. Swapping them, which is easy in generated code where the filter is a generic ExtensionObject, produces this rather than a decoding error.
• Filter on an event item where the server wants only a select and where clauseEvent items require an EventFilter, not a DataChangeFilter, and some servers reject any other filter on the EventNotifier attribute outright. A generic subscription helper that always adds a deadband will fail on the first alarm subscription.
• AggregateFilter where the server has no aggregate support for subscriptionsAn AggregateFilter on a monitored item asks the server to compute an aggregate over a sliding interval. Support for this is much rarer than support for historical aggregates, and a server without it may refuse the filter as not allowed for the item.
• Filter applied to an item the server treats as non-filterableSome servers refuse filters on items they serve from a cache with no per-item processing, particularly on constrained devices. The item works without a filter and is refused with one, which looks arbitrary until you know the server does no server-side filtering at all.

How to fix it

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

1. Confirm which attribute the item monitorsLog the AttributeId of every item you create. Only Value items should carry a DataChangeFilter. Everything else should be created with no filter at all - a null filter, not an empty DataChangeFilter structure, which some servers also reject.
2. Match filter class to item classValue items take a DataChangeFilter. EventNotifier items take an EventFilter with a select clause and, optionally, a where clause. Do not share one filter-building code path between the two.
3. Create the item without a filter firstEstablish that the item itself is valid by creating it bare, then add the filter with ModifyMonitoredItems. This separates a filter problem from a node or attribute problem in one step and is faster than reading the request encoding.
4. Handle the rejection per item and continueThis is a per-item status, so the rest of the batch succeeds. Catch it, recreate that item without the filter, mark it as unfiltered in your own metadata, and carry on rather than failing the whole subscription.
5. Do the filtering client-side where the server will notOn a server that supports no server-side filtering, apply the deadband in your collector. You lose the bandwidth and load saving, so also reconsider whether the sampling interval can be relaxed instead, which reduces load at the source.

Where it shows up, by tool and stack

What it looks like in the log

CreateMonitoredItems: item ns=2;s=Tank1.Level attribute DisplayName with DataChangeFilter -> BadFilterNotAllowed
EventFilter supplied for Value attribute of ns=4;i=1102; rejected
Item created without filter after BadFilterNotAllowed; deadband applied client-side

Confirm the fix

Recreate the item with the correct filter class or none, confirm the per-item status is Good, and confirm the notification rate matches what the filter should produce - an unenforced deadband shows up as an unchanged notification rate.

Stop it happening again

Build filters in two separate code paths, one for value items and one for event items, assert that any item with an AttributeId other than Value carries no filter, and record per endpoint whether server-side filtering is honoured.

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.