Hi,

I could most likely spend at least a day talking about this alone since it gives some troubles, but this is the short version; ask if unclear.

Variant’s binary encoding uses a so called builtin-type id: https://reference.opcfoundation.org/Core/docs/Part6/5.1.2/, OPC UA Binary-wise only these types really exist, everything else is constructed with them in some way.

The DataTypeId is not in the binary stream, only the builtin-type id (this is most likely one of the OPC UA’s optimizations). It is possible to just use this information alone, and as far as I know, UaExpert is basically “just using this”. It might do then something more on top of that via the DataTypeId, but basically that is how it is able to show it (technically this is not the “correct datatype”, but it might be equal to it if the DataTypeId would be a built-in datatype). That is also why it cannot Write to a node if the Value is null (nothing to deduce the type from).

The same thing sort of can be done in our SDK via DataValue.getValue().getValue().getClass() (with a null check added in a real case). However, for a 100% correct handling it should be combined with the DataTypeId (but for some use-case the Class might be enough). For example, Enumerations are binaryencoded as Int32 (https://reference.opcfoundation.org/Core/docs/Part6/5.2.4/). Only via the DataTypeId you can know which enum it was. Also for types that are subtypes of builtin types, the encoding for is always the super-build-in-type. While a Read might not need the info, a Write should know it, since e.g. a DurationString (in UA a subtype of String) DataTypeId’d node would only accept a subset of String (but in encoding it is a String; and also in our SDK it is a java.lang.String always since it is final). For Structures, they are encoded as ExtensionObjects, those have a NodeId, but is an “Encoding Id”, not the DataTypeId.

P.S.
Anyway, the DataTypeId must be in the server properly, thus it is a bug there and should be fixed.