In our OPC UA server we have tag with the array of ExtensionObject. UAExpert client displays each array element as 3 number fileds (Min, Max and Status).
But our client based on 4.8.0 Prosys Java SDK throws an exception with the following information:

StatusCode: Bad_DecodingError (0x80070000) "Decoding halted because of invalid data in the stream."
Detailed Message: Unknown encoding: urn:localhost:opcua:demo-server:1004

To decode we use the following code:

DataValue dataValue = ......;
uaClient.getTypeDictionary().decode(dataValue.getValue().getValue()[0]);

Any thoughts how to fix this?

That is the way to go. The initial connection must be done successfully manually, after that the SDK can take care of the rest. So basically have e.g. a List of UaClients that have not yet succeeded in a .connect and then periodically do .connect for them and once successful remove from the List. Or have separate thread per client to do the same.

It is possible we some day create something in the SDK that would make this easier.

I am about to do an implementation where on a failed connect we wait a while before trying to connect again.
Need to do it threaded as our app connects to several servers creating a client for each and twe want app to work for the servers that are up.
Is that the way to go or is there something I missed in OPC UA Java SDK that we can use instead?

This is a bug in Simulation Server. It has been implemented to use 1000 Values per Nodes as an upper limit, but it seems to be ignoring lower limits provided by Clients.

Also one correction to my first post: Even if I set the numValuesPerNode to 0, I get chunks of 1000 values in the Response. (I thought I had seen one case where it was only one Request/Response, but I'm no more able to get all values at once)

Simulation Server Version is: 2026.1.0-16

I've a question regarding the parameter numValuesPerNode for the historyReadRaw method:

JavaDoc is:
numValuesPerNode - the maximum number of events to return for a single node. If the value is 0, all values between startTime and endTime are returned.

I did some tests using Wireshark to see the HistoryReadRequest/Response calls. I'm requesting history values for one hour from the SimulationServer for one of the Simulation Nodes. So there should be 3600 parameters.

When I set the numValuesPerNode to 0, there is one Request/Response where the response contains as expected the 3600 values.

When I set the numValuesPerNode to 1000, there are four Request/Response where the first 3 response cotains as expected each 1000 values und the 4th the remaining 600.

But then I set the numValuesPerNode to 100, and I would have expected 36 Request/Repsonses, but there are still 4 like when the numValuesPerNode is set to 1000.

So it looks like this:

ReadRawModifiedDetails: ReadRawModifiedDetails
IsReadModified: False
StartTime: Mar 19, 2026 15:00:00.000000000 Mitteleuropäische Zeit
EndTime: Mar 19, 2026 16:00:00.000000000 Mitteleuropäische Zeit
NumValuesPerNode: 100
ReturnBounds: False

HistoryData: ExtensionObject
TypeId: NodeId
EncodingMask: 0x01, has binary body
HistoryData: HistoryData
DataValues: Array of DataValue
ArraySize: 1000
[0]: DataValue
[1]: DataValue
....
[999]: DataValue

So my question, is the numValuesPerNode more or less a suggestion to the server, and the server decides how many nodes it will return?

Thank you

I think the idea is anyways, that with returnBounds=false, you will only get all samples without any interpolation at the bounds. But, you can ask for consecutive time ranges and still get all samples - even the ones that fall on the bounds, but only once.

So now it seems that we are doing the "right thing", but returning the sample at the endTime instead of startTime.

Whereas, for returnBounds=true, the last sample seems to be too much, indeed.

We will need to check this out and see where the flaw is... Thanks for reporting.

I'm just trying to read the history of the 'Counter' simulation value from the Simulation Server and recognized that when I call historyReadRaw with e.g. startDate 03/19/26 14:00:00.0000000 GMT and endData 03/19/26 14:05:00.0000000 GMT and returnBounds=false that I'm getting values from 14:00:01 to 14:05:00.

But as returnBounds was false, I expected values from 14:00:01 to 14:04:59

------------------------------------------------------------------------------------------
historyReadRaw(): startDate: 03/19/26 14:00:00.0000000 GMT
historyReadRaw(): endDate : 03/19/26 14:05:00.0000000 GMT

historyReadAll: nodeId: ns=3;i=1001, indexRange: null, timestampsToReturn: Both, historyReadDetails: ReadRawModifiedDetails [IsReadModified="false", StartTime="03/19/26 14:00:00.0000000 GMT", EndTime="03/19/26 14:05:00.0000000 GMT", NumValuesPerNode="0", ReturnBounds="false"]

historyReadAll: Got StatusCode: GOOD (0x00000000) "The operation succeeded."
historyReadAll: Read complete, returning 300 values

historyReadRaw(): dataValue: DataValue(value=22, statusCode=GOOD (0x00000000) "The operation succeeded.", sourceTimestamp=03/19/26 14:00:01.0000000 GMT, sourcePicoseconds=0, serverTimestamp=03/19/26 14:00:01.0000000 GMT, serverPicoseconds=0)
...
historyReadRaw(): dataValue: DataValue(value=11, statusCode=GOOD (0x00000000) "The operation succeeded.", sourceTimestamp=03/19/26 14:05:00.0000000 GMT, sourcePicoseconds=0, serverTimestamp=03/19/26 14:05:00.0000000 GMT, serverPicoseconds=0)

------------------------------------------------------------------------------------------

I tried the same with returnBounds = true, then I get 302 values from 14:00:00 to 14:05:01 - but I expected the last at 14:05:00

Is this normal or is it one entry too much?

Thank you!

Anyway, now on the nuances and a longer version on the answer.

Based on the SDK method signature used, you create a self-signed certificate. The reality for those is that they are mostly made to practically never expire. Of course this is not ideal, but changing the certificate brings troubles since it needs to be trusted by all apps (again), so in practice most just make them last years. There might be scenarios where the certs are updated, but then just the applications are restarted as it doesn't happen often (lets say, once per a year or two). There the renew flag does allow creating the new certificate, which is probably better than requiring using e.g. openssl to create one or loading an expired one.

OPC UA tries to fix this issue nowadays by introducing a concept called GlobalDiscoveryServer(GDS), that takes care of managing the certificates and trust lists of apps of a "factory floor". There isn't yet a lot support for it out there, things take time; we are also still building support it as well and it probably still takes .. some time, sorry. There are also some unanswered questions, thus more exploration is needed. Though, for self-signed certs, the same issues would happen with each renew, so I can open that a bit.

Since clients need to trust the new certs, ideally I think a server would have endpoints for both the old and new cert at the same time until all parties trust the new cert. If the server just swaps the cert, even if old connections would be kept active, they will eventually need to do a secure channel renew or there is a connection break. At that point depending on the client implementation it is broken until restarted.

Since the assumptions of certs being forever-lasting has been true for like more than 15 years at this point (or that apps just are restarted if the certs are updated), it is unclear can any client application out there deal with this on-the-fly. Also while in some rare cases a server has more than once cert, they have been for different security policies. Now there would be more than one for the same policy. Our own UaClient component for example cannot handle this scenario yet, it will select the first endpoint that is suitable, this happens only on the initial connection, it is never automatically checked again. It might be possible to make it work by nudging it to right direction by calling some methods and/or possibly ensuring certain orderings of endpoints returned by the server (this might be hard at the moment), but the point is that it is not automatic yet.

With GDS and/or CA-signed certs the above only happens if the CA cert itself needs to be renewed. With GDS managing app trust lists, it could resolve this by first updating the new CA to the lists well in advance before it starts to use it for signing. And the CA-signing resolves trust issues since new certs are signed by the CA which then gives already the trust (so dual endpoints would be needed only for certs made with different CA certs, for non-GDS-managed software). Though of course for this world to become reality all apps must then support GDS (or support dual endpoints and better cert selection). Some of this could be done today without GDS, though managing revocation lists is not possible, unless they are transmitted outside of OPC UA means to all apps.

There are some nuances on how a client selects even the endpoint. Of course it might make most sense to choose an already trusted cert that has the most time left until expiry. However, the validation process itself typically drives UI/dialogs to ask the user that is cert trusted if it is not yet. Thus on the other hand it would make sense to choose the latest cert so that it is becomes trusted. However if an UI is running unattended, it might break the app until attended, then it might have made sense to select the older, already trusted (but then there should be another mechanisms for asking trusts from the user; or just only rely on e.g. disk-based configuration).

Once we have GDS support in place, I think then we should support updating it on-the-fly (unless the exploration results that it would never work).

The SDK components are not yet designed for changing certificates. There are a lot more nuances to the matter though, but I'll try to give a larger answer later.

In short, you must restart the UaServer. You might still run into issues regarding the clients, they might also need to be restarted.

Certificate and identity creation - ApplicationIdentity.loadOrCreateCertificate(appDescription, getOrganization(), getPassword(), privatePath, true, hostname);
Setting the identity - UaServer.setApplicationIdentity(identity);

Since there will be clients connected, I am trying to find a way to update the certificate/identity during runtime without a server restart. Is it possible to update the server certificate at runtime in a running UaServer instance? If yes, how? Does setApplicationIdentity() alone update what clients see, or do we need to reinitialize endpoints?

When double values are encoded and decoded, it becomes impossible for Clients to distinguish between null and zero because both use the same encoded form. This also applies when they are used in Structure fields such as Low and High fields of Range. In fact, double is a non-nullable DataType in OPC UA and therefore it is technically not possible to set such values to null. The UI of Simulation Server is simply being misleading as it shows the value without any encoding and decoding and in "Java world" it is possible for the values of these fields to be null.

The OPC UA specification states the following for Range:

If a limit is not known a NaN shall be used. (https://reference.opcfoundatio.....docs/5.6.2)

I've verified that NaN can be used in Simulation Server as the value of the Low and High fields of Range. Thus, you should use that instead of null. Simply type NaN to the text field where you would enter Low and High values and it should be accepted and handled properly by the Server and the Client.