Status code · Data access
BadDataEncodingUnsupported
BadEncoding
BadDataEncodingUnsupported means the encoding you asked for is a valid concept but this server will not produce it for that node. Fall back to the server's default encoding, which over opc.tcp is UA Binary, and let your client decode the structure from DataTypeDefinition rather than dictating the wire format.
Defined behaviour: The server does not support the requested data encoding for the node, even though the encoding itself is recognised. (our description of the condition this code reports)
What you actually see
Structured values read fine with the default encoding but fail as soon as the client asks for XML or JSON, on a server that otherwise behaves normally.
Why it happens
- The server implements binary encoding onlyUA Binary is mandatory over opc.tcp; XML and JSON encodings for custom structures are optional. Many embedded and PLC servers ship binary only, so any request for another encoding is unsupported rather than invalid. This is the normal case, not a defect.
- The transport profile does not carry the requested encodingEncoding and transport are related in practice. A client that works against an HTTPS or WebSocket endpoint with JSON and then moves to opc.tcp may keep asking for JSON out of habit. The server on that endpoint has no reason to produce it.
- Client library defaulting to a non-binary encodingSome client configurations set a preferred encoding globally, intending it as a hint. It is not a hint - it is a request, and the server refuses it per node rather than downgrading silently.
- Encoding requested for a node whose type only defines one encodingA vendor DataType may have exactly one HasEncoding reference. Everything else, however standard the name, is unsupported for that type even if the server supports that encoding for other types.
- Aggregating server cannot translate encodingsA gateway exposing an upstream server's structures may pass encodings through rather than re-encode them. Asking the gateway for an encoding the upstream does not produce results in this code from the aggregation layer.
How to fix it
In diagnostic order: work down, do not skip ahead.
- Remove the encoding request and use the server defaultLeave DataEncoding empty on both the ReadValueId and the monitored item create request. The server returns its default, which over opc.tcp is UA Binary. This is the correct portable behaviour for nearly every integration.
- Load the server's type information so binary decodes cleanlyIf you were asking for JSON or XML because binary structures came back opaque, the real fix is to load DataTypeDefinition from the DataType nodes, or the legacy type dictionary where the server only offers that. Requesting a different encoding is treating the symptom.
- Check which encodings the DataType actually declaresBrowse HasEncoding from the DataType node. If there is a single target named Default Binary, that is the only answer the server has, and no configuration change will produce another.
- Separate wire encoding from your downstream JSON needsIf the requirement is JSON for a broker or an analytics sink, encode on the client or publisher side after decoding the binary value. That keeps the client-server hop on the encoding the server supports. Be deliberate about reversible versus non-reversible JSON downstream: non-reversible loses type information and cannot be round-tripped.
- Verify per item rather than per serviceCreateMonitoredItems may succeed at the service level with per-item encoding failures. Log each item's status so an unsupported encoding does not present as a silently missing tag.
Where it shows up, by tool and stack
| Tool / stack | What to do there |
|---|---|
| OPC Publisher | The wire encoding to the server and the message encoding to the broker are separate settings. Reversible, non-reversible, compact and verbose JSON are output options for the published message, not a request to the OPC UA server, and confusing the two produces this code. |
| asyncua (Python) | Leave DataEncoding empty and let asyncua load custom structures. load_data_type_definitions() builds Python classes from the server's DataTypeDefinition so binary values decode into named fields. |
| node-opcua | The extension object handling resolves structures from the server's data type definitions. Requesting an alternative encoding is rarely needed and is refused by most servers for vendor types. |
| UA-.NETStandard (C#) | The complex type system builds runtime types from the server's definitions, so binary is decodable without asking for XML or JSON. Setting ReadValueId.DataEncoding manually generally makes things worse. |
| Eclipse Milo | The client's data type dictionary and definition handling resolves structures for binary encoding. Where a server exposes structures only in binary, Milo decodes them into dynamic structs without any encoding request. |
| Siemens S7-1500 | Structures exposed by the server are available in binary encoding. A client asking for XML or JSON gets nothing useful; decode the binary structure using the server's type information instead. |
What it looks like in the log
Read returned BadDataEncodingUnsupported for Default JSON on ns=3;i=5001
ServiceFault: BadDataEncodingUnsupported - server supports Default Binary only
MonitoredItem creation failed for structured node: encoding not supportedConfirm the fix
Read the node with the default encoding and confirm the returned structure decodes into named fields in your client rather than an opaque byte blob.
Stop it happening again
Fix the encoding preference to server default in client configuration templates, and solve structure decoding by loading type information at connect time. Keep any JSON requirement on the publishing side, where reversible and non-reversible are your choice to make.
Related status codes
Concepts on this page
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.