BadNotImplemented
BadProfiles / facets
BadNotImplemented means the code path for what you asked simply does not exist in this server build. Treat it as a profile and facet question rather than a defect: read ServerProfileArray and the ServerCapabilities short codes to see what the product genuinely claims, and design to that.
What you actually see
A service or an operation that is defined in the specification and visible in your SDK returns the same refusal on every attempt, on every node, from every client.
Why it happens
- A stub left in place for an optional featureStacks scaffold every service in the specification and implement the ones the target profile requires. The unimplemented ones return this code. It is the most honest failure mode available and should be read as a capability statement.
- A feature disabled at compile timeEmbedded builds strip subscriptions, history, methods, discovery or PubSub to fit flash and RAM budgets. The running server has no way to enable them and no configuration file will change it.
- A companion-specification method that was modelled but not codedVendors sometimes import a companion-specification NodeSet2 so the address space looks complete, then implement only part of the behaviour. The method node exists, is browsable and executable-looking, and returns this when called.
- An early or preview version of the productPreview builds and early firmware ship partial service coverage. The same call against a later firmware succeeds, which makes it look intermittent across a fleet with mixed versions.
- Over-claimed facets hiding the gapIf ServerProfileArray advertises a facet whose conformance units are not implemented, clients written from that advertisement hit this code. The rule the reference stack states plainly is to advertise only what is genuinely implemented, because the Compliance Test Tool will exercise every claimed facet, and over-claiming is a top cause of failed certification.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Establish what the server claimsRead ServerProfileArray and Server/ServerCapabilities, including the short capability codes. Anything you need that is not covered by a claimed facet should be assumed absent until proven otherwise.
- Record the exact build and firmware versionRead the Server object BuildInfo: product name, product URI, software version and build number. Support conversations and fleet comparisons both depend on this, and mixed versions explain most apparent inconsistency.
- Test the same operation against a reference serverRun the operation against a free public server such as opc.tcp://opcua.umati.app:4840 or opc.tcp://milo.digitalpetri.com:62541/milo. Success there proves your client is correct and localises the gap to the target product.
- Design the workaround around the claimed facetsCollect and aggregate outside the server, resolve browse paths instead of querying, or push modelling into an offline NodeSet2. Pick a path that only uses services the claimed facets cover.
- Ask the vendor for the certified profile listRequest the profiles and facets the product is certified for and the version that certification applies to. That is a checkable answer and it tells you what future firmware is committed to.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| open62541 (C) | Feature availability is decided in the build configuration, and the documented service matrix is the reference. A binary built for a constrained device can lack subscriptions or history entirely. |
| UA-.NETStandard (C#) | The reference server is a good yardstick for what a full implementation does. Comparing your target against it on the same operation separates a client bug from a product gap quickly. |
| Eclipse Milo (Java) | The public demo server at opc.tcp://milo.digitalpetri.com:62541/milo is a convenient control case for client-side verification before you conclude the target server is at fault. |
| Prosys | Simulation servers implement broad service coverage, which makes them useful as the reference when you need to prove that a request shape is valid. |
| Siemens S7-1500 | Controller-embedded servers implement a bounded service subset that changes between firmware releases. Confirm the current subset and any option or licence requirement against the vendor documentation for your firmware. |
| opcua-commander | Reading ServerProfileArray and the capability short codes from the tree gives you the claimed facet list in seconds, which is what a conformance conversation with the vendor needs to start from. |
What it looks like in the log
BadNotImplemented returned for AddNodes
Method exists in address space but has no server-side implementation
BuildInfo: ProductName=EmbeddedUAServer SoftwareVersion=1.2 BuildNumber=44Confirm the fix
Prove the same operation succeeds against a reference server with the identical request, then confirm the target server behaves consistently on the workaround path you chose.
Stop it happening again
Capability-probe at connect time and fail loudly at startup rather than at three in the morning, and keep firmware versions consistent across a fleet so the same client configuration behaves the same everywhere.
Stuck on more than one of these? The troubleshooting clinic works through broken configurations end to end, on camera.
Troubleshooting clinic →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.