BadNotSupported

BadProfiles / facets

What you actually see

A service that works with default parameters fails as soon as you set one particular option, filter, encoding or flag.

Why it happens

• An optional parameter the server does not implementDeadband filters, DataChangeTrigger settings, IndexRange on a write, TimestampsToReturn combinations and the more exotic browse result masks are all optional in practice. Servers implement the common paths and reject the rest, which is why the failure tracks the parameter and not the node.
• A data encoding the server does not offerAsking for a JSON or XML encoding of a value from a server that only publishes the binary encoding is not supported, and the same goes for requesting an encoding NodeId that exists in the type but is not implemented on this product.
• A companion-specification feature that is only partially implementedVendors implement the mandatory nodes of a model and leave the optional ones out. A method or an option defined in the companion spec can be present in the address space and still be unsupported by the running implementation.
• A transport or security option the endpoint does not carryRequesting a security policy, a message security mode or a transport profile the endpoint does not offer produces a support failure rather than a security failure. GetEndpoints is the authoritative list of what is on offer.
• The server claims a facet it does not fully implementWhere ServerProfileArray advertises more than the code does, a client that trusts the advertisement asks for something legitimate and gets refused. Only advertising facets that are genuinely implemented is the fix on the server side, and it is exactly what the Compliance Test Tool checks.

How to fix it

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

1. Isolate the option that causes itStrip the request back to its simplest legal form and add one option at a time. The parameter that reintroduces the failure is the unsupported one, and that is the fact you need for both the workaround and the vendor conversation.
2. Read ServerProfileArray and the capability codesCompare what you are asking for against the facets the server claims. If the facet that covers your option is not listed, stop debugging the client; the feature is not there.
3. Take the supported path insteadDrop the deadband and filter downstream, read the whole array instead of an IndexRange, request Both timestamps, or use the binary encoding. Costlier on the wire, but it works today.
4. Call GetEndpoints for security and transport optionsEnumerate the endpoints with security None first and inspect each EndpointDescription for its policy, mode and transport profile URI. Pick from that list rather than from what your client offers.
5. Report it as a conformance gap with evidenceSend the vendor the request parameters, the returned code, and the ServerProfileArray content. A gap between the advertised facet and the behaviour is actionable in a way that a general complaint is not.

Where it shows up, by tool and stack

What it looks like in the log

CreateMonitoredItems: BadNotSupported for requested DataChangeFilter
Requested dataEncoding not supported for this node
Option rejected by server: not part of any implemented facet

Confirm the fix

Re-issue the request without the unsupported option and confirm the operation completes, then document the option as unavailable on this product and version.

Stop it happening again

Probe capability at connect time and adapt rather than assume: read ServerProfileArray, read the endpoint list, and fall back to the simple path automatically when an option is refused.

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.