Hi,

From the “HelicheckType hc = …” I assume you have run the included Codegen tool of the SDK?

Assuming you would have included the output resource files to classpath, SDK should be able to automatically discover the generated classes. The Codegen outputs a META-INF/services/com.prosysopc.ua.client.ClientCodegenModelProvider file (and it must be as-is in the classpath i.e. so that the path starts from META-INF within the classpath), which is then used internally via java ServiceLoader when the UaClient is created.

In other cases the model must be manually registered before you connect via UaClient.registerModel(XXXClientInformationModel.MODEL) where the XXXClientInformationModel is output by the generator. The XXX is the prefix, if any, from the codegen configuration, e.g. in di_adi_plcopen.xml in the configexamples in codegen folder of the SDK distribution zip, there is:

So it would be DiClientInformationModel. If you do not set any, it is just ClientInformationModel, though I would recommend to set a prefix as the SDK already contains the core namespace without prefix and thus it is important that you do NOT use com.prosysopc.ua.types.opcua.client.ClientInformationModel, but the one you generated.

Sorry, it is a bit hard to say, I would need more details.

Basically what the client side does during .getNode is that it checks the HasTypeDefinition Reference of the node, then it tries to find the best UaNode interface implementation for it. If a (generated, registered) type is a direct match, that is used, otherwise it will look for the supertypes of the type definition until it finds a match (because this must/will also work without Codegen). Since all types derive from the core namespace types which is generated by us and is internal to the SDK, it will eventually use those.

The com.prosysopc.ua.types.opcua.client.BaseObjectTypeImpl is the root type for all Object types (and part of the core namespace). So either the HasTypeDefinition pointed to it directly (and you basically might have the wrong nodeid?) or there is no more specific subtype registered.

Is there any chance that the NodeId was wrong? Note that if you did use the index-based NodeId, it can be different in each server.

And if possible please doublecheck the model registration in the client. Sorry to doubt, but this kind of an error typically would happen if the model is not registered (and thus everything just uses the core namespace types, thus the cast will fail). If you do not have any manual code and rely on the automatic logic for the registartion, could you temporarily add the client.registerModel call just in case to see if it helps?

Can you check using either UaExpert or https://www.prosysopc.com/products/opc-ua-browser/ does the type node exist in the server and is the HasTypeDefinition Reference correct on the node you are trying to getNode()? And compare the node on the 2 servers, are there any differences etc. ?

P.S.
Maybe at some point SDK could tell this automatically (if the given Class is not registered), but basically at the moment just blindly casts the resulted UaNode to the given class type.

Is it possible to send screenshots where the Attributes and References are visible for the “…ace().getNode(node_id_helicheck);” ‘node_id_helicheck’ node, and then possibly the HasTypeDefinition target type as well? If yes, please send them to uajava-support@prosysopc.com and mention this thread. Additionally, if possible, could you send the model nodeset xml file as well?
Basically I would be looking something I could reproduce locally or enough information.

You could try checking client.getRegisteredClasses().getClass or containsClass to doublecheck was the type (HelicheckType.class) registered (or note that it is the implementation classes, so it would be HelicheckTypeImpl.class in practice, but that does implement the interface). The ExpandedNodeId parameter must be given in the Namespace uri-form, not the index one (Codegen outputs use the uri form, because it cannot know the index beforehand, and also the index could be multiple matches if the application connects to multiple servers etc.). You should be able to get the correct via ExpandedNodeId.parseExpandedNodeId(string) and give it the string within the @TypeDefinitionId annotation of the generated class, e.g. for AnalogItemType it would be “nsu=http://opcfoundation.org/UA/;i=2368”, because the generated class has @TypeDefinitionId(“nsu=http://opcfoundation.org/UA/;i=2368”).