A Python OPC UA client reads a structured variable but returns an opaque ExtensionObject instead of decoded fields. The reported value identifies the encoded type as ENC_DATATYPE_OPC_coiling_machine_production_list in namespace 1, uses encoding 1, and carries a 2311-byte body. Treat this as a data-type-definition loading problem until the client proves that it can resolve and decode the server-defined structure.
Interpret the returned ExtensionObject
| Observed field | Evidence-grounded meaning |
|---|---|
TypeId |
ns=1;s=ENC_DATATYPE_OPC_coiling_machine_production_list identifies the server-specific encoded data type. |
Encoding |
The returned object reports encoding value 1. |
| Body | The client has a 2311-byte encoded payload but has not exposed its structured members. |
The output does not establish that the bytes are corrupt. It establishes only that the attempted client path did not convert them into a decipherable Python structure.
Load definitions before the production read
The synchronous test calls client.load_type_definitions() between two reads. That is the correct sequencing experiment: connect, obtain the node, load definitions, then read the value used by the application. The first read is useful only as a baseline.
- Connect to the OPC UA endpoint.
- Resolve
ns=1;s=VARIABLE_OPC_first_coiling_machine_production_list. - Call the library's data-type-definition loading function.
- Read the node again and inspect whether the value now exposes structured fields instead of a byte body.
Use the asyncio-specific loader
For opcua-asyncio, use load_data_type_definitions. Calling or expecting the synchronous library's load_type_definitions behavior does not test the documented correction supplied for the asyncio path.
connect
get node: ns=1;s=VARIABLE_OPC_first_coiling_machine_production_list
call: load_data_type_definitions
read node value
inspect decoded resultThe evidence does not provide the exact coroutine syntax or library version, so verify the call signature against the installed package rather than guessing an identifier or invocation form.
Verify the decoding result
Success means the post-load read exposes the members of the custom production-list structure. If it still reports the same TypeId, encoding, and opaque byte body, capture the installed client package and version, any exception from definition loading, and whether the server exposes the custom type definition. The available evidence does not identify a confirmed server fault, affected version, or alternate byte-decoding procedure.
FAQ
Why does Python return a 2311-byte OPC UA ExtensionObject?
The client received an encoded custom structure with type ID ns=1;s=ENC_DATATYPE_OPC_coiling_machine_production_list, but the attempted read did not expose its members. The evidence does not show that the 2311-byte body is corrupt.
Which function should opcua-asyncio use to load custom data types?
Call load_data_type_definitions after connecting and before the production read. Then read the node again and check whether structured fields replace the opaque body.
Does client.load_type_definitions guarantee ExtensionObject decoding?
No guarantee is established by the evidence. If the second read remains opaque, verify whether definition loading raised an exception and whether the server exposes a definition for the returned custom TypeId.
