Hi,

Subscriptions and events work out of the box (events are one form of Subcription). The codegenerated classes do extend the “basic” UaNode implementations which do handle this. The only reason why there is specific handling generated for methods is that we cannot know what a custom method would do, but the others are specified in the UA specification.

You can use setValue methods to set new value for a node, either directry to a node which has a Variable NodeClass or via the generated methods for object types. See e.g. MyNodeManager.simulate method in the samples. If the node is subscribed from a client, then it will receive the new value.

For events see the MyNodeManager.triggerEvent method in the samples, the event fields are the Properties/Components of the event node that is in the address space, see e.g. MyNodeManager.activateAlarm. In case you have a “one-shot” event that is not a node in the address space, create it with NodeManagerUaNode.createEvent methods, see MyNodeManager.sendEvent sample.

– Bjarne

I suppose this is one area of improvement for the future releases (2.3 or later; I would like to have some kind of Dependency Injection style options here, i.e. some kind of custom SDK user given contex to afterCreate or something).

If you create the instance of the MySensorTypeNode via a NodeManagerUaNode.createInstance(….) methods, the afterCreate method should be called normally. It is currently not called for instances defined in the XML (I suppose it could theoretically be done, but it is a bit hard to know if a node is toplevel node of a type and not a subnode, because the aftercreate is called for the top-level first and then it will call it automatically for subnodes, after those calls return, it could theoretically override those). Should probably be documented better..

Assuming you meant how to actually find the TwoStateVariable subnode from the aftercreate method (or elsewhere), see the generated classes more closely. The codegen generates 5 .java files for a type. An interface, which contains get/set/getnode methods for the subnodes. In addition to the interface, 2 classes are generated for each side (client/server): XXXTypeImplBase, XXXTypeImpl, XXXTypeNodeBase, XXXTypeNode. The Base classes implement the interface methods, the Impl/Node classes extend the Base class in order to provide possible additional methods, mainly used to allow implementations of the server side of the Methods defined for a type. Idea is that the Interface and Base files can be generated again easily while the Impl/Node classes contain custom code and wont be generated again normally.

The generated classes itself extend implementations of the UaNode interface that do most of the internal work (i.e. I’m trying to say that those implementations existed long before we did the codegen and that the codegenerated classes sort of provide more convinience methods of accessing the data, everything is possible to create/model using the “basic” implementations of UaNode(s), i.e. if there is no “special overload” for a given ObjectType registered via calling registerModel, the server would use instances of UaObjectNode class when creating instances of the ObjectType, but would need to find the subnodes e.g. via .getComponent(QualifiedName parameter that would be name given for the sub-componet. The codegenerated Base classes do have these “queries” generated in the get/set/getnode methods.

You can use the generated methods to set the value of the sub-node or alternatively get the node and call .setValue for it directly. Also to be clear I mean a Java method .setValue for the object returned in .getXXXNode() so it is not a UA method and therefore not visible in the address space (I would assuming this is what you mean by ‘client’).

Each Ua Node instance has several Attributes, one of them is NodeId which does give it an unique address so it can be found in the Address Space. You can find a node via UaClient/UaServer.getAddressSpace().getNode(NodeId) and also in server side via NodeManagerUaNode.getNode, see MyNodeManager in the samples. Currently you do need to cast the retuned node to correct type, but when you create the node via NodeManagerUaNode.createInstance that take a Class parameter in returns the node directly in correct java type (future 2.3 version will contain additional getNode methods that also take a Class parameter and does the casting automatically if possible)

– Bjarne