Device starts sampling and publishing at slower intervals after reconnection in 2.9.0 (preview)

Describe the bug On 2.9.0 (preview), I’m seeing strange behaviour where I ask a sample and publishing interval of 50 ms for multiple properties, and after a reconnection to the server, this gets somehow changed to a slower interval. The initial rate (after publisher start-up) is always correct.

To Reproduce Steps to reproduce the behavior:

1. Add a few property subscriptions with sampling and publishing intervals of 50 ms.
2. Connect to the server, observe data coming through at the requested rate.
3. Let the server reboot or go offline and the publisher pick this up.
4. Put the server back online and the publisher reconnect.
5. Observe (most times) that updates come in at a slower rate than 50 ms.

Expected behavior Updates come in at 50 ms.

Additional context I’m not sure if this is the OPC Publisher that is at fault - it could also be a weird OPC UA server, but if not, hopefully I’ll get an idea as to how this can happen.

Other things I’ve verified:

• Use 0 as publication interval; the server always negotiates 4, so 50 is certainly not too much for it.
• Publisher still reports “50/50” as requested and expected publishing interval when the problem occurs.
• The rate at which MessageTriggerMessageReceived is triggered is also slower, so it happens earlier in the publisher (or is caused by the server).
• The amount it becomes slower is random; usually updates suddenly start getting published after 5 seconds, sometimes 300 ms, sometimes 1 second, and so on.
• If just the publishing interval became wrong, I’d expect multiple values to show up in the data as the sampling interval is still low, but that’s not the case; I still get only one sample per publication, which implies both values got slower somehow.
• There are no other properties in published-nodes.json that have different publishing intervals that may mistakenly get used; they are all 50 ms.
• Restarting the publisher fixes it.
• No noticeable errors or warnings are reported, except DataChange for monitored item 107 subscription '50'/'opc.tcp://THE_SERVER:853/FOO' has unexpected sequenceNumber 1 missing 2, 3, 4, 5, 6, 7, 8, 9, 10, 11 which were already received, probably because the server starts over with 1 after a reboot and the publisher tries to maintain the previous state on reconnection?

Is there some timing logic somewhere that may get confused in the OPC Publisher? I couldn’t find any, but I may have missed it.

I cannot test with a stable version because I’m using the 2.9.0 (preview) with a custom SignalR back end. This custom back end is similar to the new MQTT one and I didn’t touch any of the logic related to data subscriptions; as mentioned the problem also seems to happen before the back end is involved.

[NoTuxNoBux]

I just wanted to cycle back and confirm that it was indeed a server issue; turns out the server in question has a quirk where it can only publish at a single interval, so if multiple independent (yes, that’s right) clients connect (doesn’t matter if it’s an OPC Publisher or not), even for separate properties, and use different publication intervals, only the last one is used - the first one then gets updates at a slower rate without it being renegotiated in OPC UA; the property just updates at at a slower pace.

The sample rate can still vary just fine for these properties, weirdly enough, it’s only about the publishing interval in this server - the workaround/fix for me was thus to set all publication intervals in all clients to the lowest value I need for any one property; the other ones still won’t be included if they don’t change as their sample intervals are higher.

Might be useful to know for others experiencing similar issues.

[NoTuxNoBux]

I’m going to see if I can verify if this is what is happening and come back to this issue once I do.

I’m not 100% sure yet, but it’s becoming more and more likely that the server is at fault here. I can also reproduce this issue with other tooling such as UA Expert; the publishing interval remains the same, but the update rate of the property itself tanks, so it’s not sending any more updates because the property simply wasn’t updated, not because the publishing interval is incorrect.

Since it’s also reproducible with other tools, I think this can be closed as not a bug in OPC Publisher. I will reopen in case new information appears that implicates the publisher again for some reason.

Thanks for the valuable tip and assistance!