Hi,

By python you mean this https://github.com/FreeOpcUa/python-opcua or something else?

Anyway, your version of our SDK is kinda old. Could you please try with the latest release 4.6.2, some thing are fixed after the version you have (https://downloads.prosysopc.com/opcua/Prosys_OPC_UA_SDK_for_Java_4_Release_Notes.html).

Given that this functionality completely relies on the server to send the correct data, the most logical explanation would be that either the DataTypeDefinition (if the server uses that new 1.04 Attribute) or the old DataTypeDictionaries data is incorrect. I would need to see those for the structure type in question to know better. Alternatively the encoding might have been done incorrectly, for that typically the only practical way would be to check with wireshark: https://www.prosysopc.com/blog/opc-ua-wireshark/ i.e. what the actual binary was.

Or it is possible that it could be a bug in our SDK, custom structures is one of the more complicated OPC UA features.

In OPC UA 1.04 the structure fields can be multidimensional arrays, since your code just shows array=True, I’m assuming they are onedimensional.

You could try turning logging to DEBUG on the package ‘com.prosysopc.ua.typedictionary’. However, please do the SDK update to 4.6.2 before that, as the logging as also been improved in the later releases.

Also, note that in the encoded form the TypeId within an ExtensionObject is not the DataType NodeId of the type, but the NodeId of an ‘Encodings node’ below that (they are liked with non-hierarchical reference HasEncoding type, so they are typically not visible in trees that show the address space). So if custom Structure types are created, so must the encodings nodes. Then when the old DataTypeDictionaries are in use, the “path continues” sort of from the Encodings nodes to description nodes that then do link to the actual dictionary, which is an XML document as UTF-8 as ByteString in the dictionary node and within the dictionary xml namespaces are used i.e. it gets complicated quite fast).

The TypeDictionary class of the SDK in 4.x along with StructureSpecification etc. is an abstraction (initially it was just for the dictionaries). The TypeDictionary prefers DataTypeDefinition nowadays, but if not all types were successfully resolved via them it will revert to looking also the old DataTypeDictionaries. In practice all the ways you tried to decode is the same operation, but just accessed in a different way (and also what the SDK does internally whenever ExtensionObjects are received over the wire, thus in 4.x manual decoding pretty much cannot work if the automatic didn’t, unless you explicitly disable that automatic logic).

In 4.x, you should be fine with just asking Structure.class instead of DynamicStructure.class, as the API to use both should be pretty much the same.

P.S.
Not related to this, since you only have Strings as the type, but any ‘OptionSet’ Structure subtype would be a problem for us currently (as they use EnumDefition and not StructureDefinition and SDK sort of assumes every Structure type has a StructureDefinition in the DataTypeDefinition).