I have a doubt regarding the existence or not of an initial notification of the current value from an OPC UA server when a MonitoredDataItem is created.
From the specifications, §184.108.40.206 Monitoring mode:
When a MonitoredItem is enabled (i.e. when the MonitoringMode is changed from DISABLED to SAMPLING or REPORTING) or it is created in the enabled state, the Server shall report the first sample as soon as possible and the time of this sample becomes the starting point for the next sampling interval.
What does it mean exactly with 'shall report the first sample as soon as possible'. Does it mean that the current value of this node in the address space is notified as sample as soon as possible (next publish), or it means that as soon as a new value for this node is sampled, it will be the notified as first notification for this MonitoredDataItem.
I would appreciate a clarification in this issue. Usually when you subscribe a node you want to know also the current value of it and if you don't receive an initial notification upon creation of the MonitoredDataItem you hae to perform always a ReadValue operation for each node.
This is a good question.
The spec does provide some flexibility here, as you can see. Ultimately, the general expectation is that the Server will provide the "initial" value in either the first or second Publish response. This is widely expected by the OPC community as a whole.
Now, having said that, obviously there may be some constraints in how you obtain your values, perhaps they're coming from a distant source that takes a significant amount of time to reach. In this case, it's perfectly acceptable to abide by the expectation above by simply providing null/empty values and a StatusCode of BadWaitingForInitialData. Once your real data-values are received you can simply push those to the Client.
I hope this helps.
Thanks for your reply.
The problem is that until now my client was subscribing to the nodes of different servers, and just by doing so I was always getting initial(current) values for all these nodes. I always thought this was the standard defined.
Now I am connecting to a new server with my usual client and I am not getting any value when I subscribe to the nodes. I need to wait until a change in the value of each of the node happens. It means that if a node with current value '5' has no change until next month I won't be notified for this node until next month. I would expect to receive this '5' but the person that implemented this server asked me to show him where was it written that he had to notify always upon MonitoredItem creation in the server. Now I see the OPC UA specification it is vague here (pity) and I better always subscribe and call Read to be sure and avoid problems.
It seems the developer shares the confusion of some people I met many, many years ago when DA was relatively new. The question was always "what is the initial value?" is it (a) the value that you currently have in-memory, even if it is null? (b) the first value that you receive from a device?
The flexibility in the spec exists because of the decoupling of the sampling engine from the publishing engine. This does not mean that the server can wait a month before sending an initial value. In this case, the sampling interval will have elapsed more than once which means the server now has a confirmed state of a node, and it has an obligation to report it even if it is bad quality.
In what you have described, I would assert the server is non-complaint with its current behavior regarding the initial value.
Email me directly and we can setup a private meeting with the server vendor to fix this, if needed.
I had the same question, and actually I'm still one of those server developers confused by what the initial value should be, or more in general what are the Status Codes that should be returned. How can I learn about these things?
For example if I create a node but I don't provide any data for my implementation to be able to read a value from the device, the framework I'm using by default returns BadNodeIdUnknown in the demo (that is not true since I have a node, so a node id exists) or even worse it returns Good (that may fool a client thinking the default value they received comes from the device). So I saw people that mentioned to use BadWaitingForInitialData, and that might be what I'm looking for, but what I would like is a clear reference where I can learn for each Status Code when it is expected to be used, so that I can give my clients information about encountered problems in a standard way.
Each service definition has a list of status codes that can be returned at the service level and operation level:
Each method definition has a list of status codes that can be returned when it is called:
Additional codes used with data subscriptions are here: