Client is connected but no more changes are retrived from monitored items after some hours about node-opcua HOT 13 OPEN

What does happen when the subscription reaches the max keepalive?

The subscription sends an empty PublishResponse with no data change notification into it,
The client then sends a new PublishRequest, so the server always has some PublishRequest in stock to send back data change notifications.

The consequence is that there is always communication between the client and the server, the subscription remains active, and the channel doesn't time out.

Having a small maxKeepalive is beneficial, it ensure that the session will not timeout.

As a rule of thumb, make sure that publishingInterval*maxKeepAlive < session timeout.

With carefully chosen subscription parameters, the client and server communication should always be up and running, and your subscription will never die.

https://reference.opcfoundation.org/Core/Part4/v104/docs/5.13.1

Was wondering what are the benefits of using the monitoItems in place of doing single monitors, is that more efficent or what?

Yes, grouping monitored items is more efficient as there are fewer client<->server round trips.

I was just wondering how I could recover from a state where the subscription is not working and needs to be refreshed someway.

Subscriptions could timeout and be discarded on the server side if the client and server cannot communicate for an extended period of time

The Subscription is discarded on the server side if the client hasn't been able to communicate with the server within publishingInterval * maxLifeTimecount.

You need to ensure that maxLifeTimecount is big enough but not too big either.
(if your client crahses or doesn't properly terminate the subscription after use, then the subscription would still be recording data on the server side for nothing for as long as publishingInterval * maxLifeTimecount , consuming precious server resources.

After a network outage, an OPCUA client reconnects automatically with the server and will automatically reconstruct any subscription that has a timeout). This requires that the client and servers are OPC UA complaints and implement the reconnection mechanism adequately.

We fixed one recently in 2.117 to fix subscription repair with some servers that do not fully implement the recommended services.

It is possible that we have still case that are not handle properly. This would requires a deeper investigation between the client and server, done under professional service. Please reach out to me in private to see how we can investigate this.

from node-opcua.

maybe the lifetimecount or the max keepalivecount!

https://reference.opcfoundation.org/Core/Part4/v104/docs/5.13.1

i assume 500ms publishing interval is fast for yor count values

from node-opcua.

you can test by just adding the server time as a item it should produce frequent notifications! if that does not help its something else 🤔

from node-opcua.

Hi @AndreasHeine, thanks for your fast response.

maybe the lifetimecount or the max keepalivecount! reference.opcfoundation.org/Core/Part4/v104/docs/5.13.1 i assume 500ms publishing interval is fast for yor count values

Could you explain what you mean more specifically? What values should I set for requestedLifetimeCount and requestedMaxKeepAliveCount? I have events listeners on client for keepalive and keepalive_failure, shouldn't them be triggered in case of keepalive errors? Should I also use an higher sampling interval so? I checked PLC server setting and minumum sampling interval is set to 100ms so that should not be a problem I think.

Any other suggestions about how I could detect and recover from this?

from node-opcua.

sampling just means checking for changes! a notification is only generated if a item change. if there is no change after a while the keepalive counter inc's if the counter is full the subscription dies on clientside. the lifetimecount works the other way around if there is no publishrequest within a publishinterval but notifications the liftemecount inc's. if exeded the server can delete the subscription. so one defines when the server can delete the sub and the other is for the client

from node-opcua.

Ok what if I want to create a subscription that never dies so?

from node-opcua.

add ServerTime to the subscription sampleinterval 5s or so

from node-opcua.

What about listening for terminated event and recreate the subscription if needed? Also what about the warning posted above? It's not clear what I should fix on code

from node-opcua.

if the subscription is terminated there is a small timewindow in which you might miss a event...

-try higher values for the counts
-add all eventlisteners for the subscription just to see what happens if you dont recv changes anymore

from node-opcua.

-try higher values for the counts

Number.MAX_SAFE_INTEGER ?

from node-opcua.

What about listening for terminated event and recreate the subscription if needed? Also what about the warning posted above? It's not clear what I should fix on code

The subscription should never die and should help you to keep the OPC UA connection alive.

Do not try to interfere and recreate a subscription if the terminate event is raised, it might not work as you expect.

    requestedPublishingInterval: 500,
    requestedLifetimeCount: 1000,
    requestedMaxKeepAliveCount: 12,

The parameters you are using impose that the server will send a keepalive publish response every 500*12 ms = 6 seconds, if none of the variables that you are monitoring is changing.

Regarging

04:52:16.776Z :client_session_impl :709 [NODE-OPCUA-W21] Pending transactions: CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest CreateMonitoredItemsRequest
04:52:16.776Z :client_session_impl :710 [NODE-OPCUA-W22] Warning : your opcua client is sending multiple requests simultaneously to the server CreateMonitoredItemsRequest
... please fix your application code

You may be calling subscription.monitor without waiting for the previous call to be completed.

Use this instead:

const monitoredItem = await this.subscription.monitor(
			{
				nodeId: nodeId,
				attributeId: AttributeIds.Value
			},
			{
				samplingInterval: 500,
				discardOldest: true,
				queueSize: 1
			},
			TimestampsToReturn.Both,
			MonitoringMode.Reporting);

Alternatively, if you need to monitor multiple item in one go, use a monitored item group.
( as explain in node-opcua by example

from node-opcua.

The parameters you are using impose that the server will send a keepalive publish response every 500*12 ms = 6 seconds, if none of the variables that you are monitoring is changing.

What does it happen when the subscription reaches the max keepalive? Is it terminated? If so should I recreate it manually or is that automatically handled by node-opcua? I was just wondering how I could recover from a state where the subscription is not working and needs to be refreshed someway

You may be calling subscription.monitor without waiting for the previous call to be completed.

@erossignon Thanks for that, makes sense, didn't thought that could cause problems...

Alternatively, if you need to monitor multiple item in one go, use a monitored item group.

Was wondering what are the benefits of using the monitoItems in place of doing single monitors, is that more efficent or what?

from node-opcua.

After a network outage, an OPCUA client reconnects automatically with the server and will automatically reconstruct any subscription that has a timeout). This requires that the client and servers are OPC UA complaints and implement the reconnection mechanism adequately.

Thanks for the detailed answer @erossignon . I gave a look at everything you said above and I will try to edit my code according to that. What's still not 100% clear to me is if the subscription is automatically restored/repaired from OPCUA client always or not, I mean you said that it will do in case og network outage but what if for some reason it fails because the server simply stops sending notifications for some reason? Is there a way on code side to detect this? I could otherwise thinking about creating an interval that once it doesn't detect any data change for N seconds simply destroy the subscription and recreates it.

Another quesiton, It could happen for some reason that I have items to monitor that don't exist in server, in case I switch to monitorItems instead of monitor in order to monitor multiple items together does that throws if even one of the items in the group doesn't exists or does it simply skip the monitor of the non existing one?

from node-opcua.