Connection break after subscribing to an Event ( SINUMERIC 840D)

[shiva-rockers]

I'm submitting a ...

• (X) bug report
• ( ) feature request
• (X) support request

Current behavior
Program is monitoring variables without any issue, but when i try monitoring Alarm, Program says
connection break, and OPCUA server close the communication PORT, and then i have to restart the
OPCUA server manually to get working again.

Expected behavior
Connection must not be break.

Minimal reproduction of the problem with instructions

When monitoring Variables

- created client -> success
- created session -> success
- created subscription -> success
- subscription to monitor variables -> success

When monitoring Alarms

- created client -> success
- created session -> success
- created subscription -> success
- subscription to monitor Alarms  -> [ Connection break ]  [  server disable the communication port ]

** Code reference **

subscription = new opcua.ClientSubscription(this.session, {
            requestedPublishingInterval: 100,
            requestedLifetimeCount: 1000,
            requestedMaxKeepAliveCount: 12,
            maxNotificationsPerPublish: 10,
            publishingEnabled: true,
            priority: 10
	})
	
let monitorAlarm = this.subscription.monitor({
            nodeId: "ns=2;s=Sinumerik",
            attributeId: opcua.AttributeIds.EventNotifier,
            indexRange: null,
            dataEncoding: null//{ namespaceIndex: 0, name: null }
        }, {
                queueSize: 100000,
                filter: opcua.constructEventFilter([
                    "EventId",
                    "Message"
                ], [opcua.resolveNodeId("ConditionType")]),
                discardOldest: true
       });

Please tell us about your environment:

• ( ) I have installed node-opcua from source ( using git clone)

• (X ) I have installed node-opcua as a package ( using npm install )

• ( ) I am using an application that uses node-opcua

  • ( ) node-red
  • ( ) other : please specify

• Device: Laptop

• OS version: Windows 10

  • (X ) Windows : version : 10
  • ( ) Linux : version : _________
  • ( ) MacOs : version : _________
  • ( ) Raspbian: version : _________
  • ( ) Other : specify :

• Description of the other OPCUA system I am trying to connect to:

  • Name: SINUMERIC
  • Version: 840Dsl/828D
  • Manufacturer/Software vendor: Siemens
  • link : https://www.siemens.com

• node-opcua version: 0.4.5
  node-opcua = 0.4.5

• Node:
  node --version = 8.11.4

---

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[erossignon]

It looks like a crash in the server (SINUMERIC 840Dsl) ( see message " server disable the communication port " ). You may have to contact Siemens customer support

[shiva-rockers]

@erossignon ,
I have contacted with Siemens customer support regarding SINUMERIC 840Dsl issue, and they said to try with UA- Expert tool or the library created in c# and we tried UA-Expert tool and as result we got alarm without any issue and Siemens customer support closed the request.

[simonlmn]

I have observed exactly the same issue and have worked out what causes the issue with the Siemens support:

Alarm/event texts are localized by the server. To influence which locale to use, a client can provide an array of locales as the LocaleIds array in the initial ActivateSessionRequest (e.g. ["en-us"]). If an empty array is provided (as it currently is hard-coded into node-opcua), according to the OPC-UA specification, the server is expected to select any locale it can provide. The same rule applies if the server does not support any of the given locales.

However, the current Siemens OPC-UA Server implementation expects clients to provide it with a non-empty LocaleIds array in the ActivateSessionRequest! If it is empty, the server fails to check this and crashes. A workaround is to send at least one locale, which can be any locale, since the fallback logic on the server does appear to work correctly. So just always sending ["en-us"] makes it work, even if the server does not support this particular locale.

So, long story short, until Siemens fixed this on their side, the only thing we can do is add support for setting the LocaleIds array for the ActiveteSessionsRequest into node-opcua (which probably is a good idea anyway). Currently, it is hard-coded to [] (

node-opcua/packages/node-opcua-client/src/opcua_client.js

Line 492 in d2a1621

localeIds: [],

).

[simonlmn]

I may or may not have the time/budget to provide a PR for implementing that feature.

[shiva-rockers]

Thanks @simonlmn , it helped a lot.
by changing localeIds: [] to localeIds: ['en-us'] i am able to get alarms without crashing the server.