Hi,

Yes, assuming I understood correctly.

However, it is best to do this a bit differently. While the DataTypeDefinition etc. can be used, that is OPC UA 1.04 based Attribute. And there are multiple other ways for the enumerations to be defined in older spec versions. SDK abstracts the concept of older DataTypeDictionaries and the newer DataTypeDefinitions with concepts called StructureSpecification and EnumerationSpecification, these should always be used instead (unless visualizing the raw Attribute value of the DataTypeDefinition in a generic client). These can be obtained via EncoderContext, which can be via UaClient.getEncoderContext(), once you have connected to the server (by default we read the types part when we connect).

So, you can find EncoderContext.getEnumerationSpecification(UaNodeId) (convert the NodeId to UaNodeId, e.g. via UaNodeId.fromLocal(id, client.getNamespaceTable), the UaNodeId is SDK-specific idea of a NodeId, but forced to use the UaNamespace(Uri) instead of the index (NodeId vs. ExpandedNodeId is sort of a pain, and ExpandedNodeId could contain either, thus Maps keys work best with UaNodeId).

Then you can use Variant.asEnum(EnumerationSpecification). Alternatively if you know the enum, and have used our Codegen to generate the information model (assuming you have that, or it is core information model type, in which case we have already generated that), you can also use asEnum(Class) (where the class is the enum type.class). The output is still Object, as the value could have been array or multi-dim array (it is converted to equal ValueRank of output i.e. scalar -> scalar, 1dim->1dim, 2d->2d so on).

Once you have the EnumerationSpecification, you can use methods of that to find the mappings, also you can get the Enumeration.Builder of the type via toEnumerationBuilder use setValue(int) and build().

The data within Variant is always the integer format, as that is was is transferred over the wire. Technically Variant constructor accepts Enumeration-instances, but was decided that they are converted immediately to Integer(s) (so that it wont flip between ints and enums depending from where it came from). This is one are that could use some improvements, but not sure when. Basically when we do decode the messages it is kinda hard to know if it was an Enumeration, as they are encoded as Int32 and there is no type-info “nearby” to check (e.g. a Read of Value would also need to always Read DataType, or know it somehow).