Hi,

Thanks for the question. It is intentional and according to the OPC UA Specification.

Spec 1.04 Part 4 section 7.34.2 Table 178 last entry:
“Bad_WaitingForInitialData Waiting for the Server to obtain values from the underlying data source.
After creating a MonitoredItem or after setting the MonitoringMode from DISABLED to
REPORTING or SAMPLING, it may take some time for the Server to actually obtain
values for these items. In such cases the Server can send a Notification with this status
prior to the Notification with the first value or status from the data source.”

i.e. an OPC UA Client can _never_ assume the first notification to be a “real” notification.

Additionally Table 160 in section 7.20.2 for the DataChangeNotification Value field:
“Value DataValue The StatusCode, value and timestamp(s) of the monitored Attribute depending
on the sampling and queuing configuration.
If the StatusCode indicates an error then the value is to be ignored.
If not every detected change has been returned since the Server’s queue
buffer for the MonitoredItem reached its limit and had to purge out data and
the size of the queue is larger than one, the Overflow bit in the DataValue
InfoBits of the statusCode is set.”

Therefore you should always check the status as well (in ALL notifications).

This is somewhat a trade-off between making the items fast and sending that as first notification vs. waiting for the data. The current design in the latests versions avoids some problems if a client makes 100s of monitoreditems at once. We could revisit that at some point (or maybe add some options), however the current impl is something any UA Client should be able to handle.