Wrong status of a varibale in READRESPONSE.

[atimin]

Describe the bug

If a variable in the OPC UA server has a not success status, it is copied in READRESPONSE as a number. In other situations, the status code has a string value, for an example 'BadInvalidNodeId'.

To Reproduce

  import websocket
  import json

   msg = {
      'Header': {
        'MessageType':'READ_REQUEST',
        'ClientHandle':'1'
      },
      'Body': { 'Variable' : 'TestVariableWithBadStatus'}
   }

 
  ws = websocket.create_connection('ws://127.0.0.1:8081')
  ws.send(json.dumps(msg)) 
  resp = ws.recv()  
  print(resp)

Results:

{
    "Header": {
        "MessageType": "READ_RESPONSE",
        "ClientHandle": "1"
    },
    "Body": {
        "Value": {
            "Type": "12",
            "Body": "Hello, worldi1111!"
        },
        "Status": "2157641728",
        "SourceTimestamp": "2019-07-27T06:58:53Z",
        "ServerTimestamp": "2019-07-27T11:58:53Z"
    }
}

Expected behavior

The status should be:

   "Status": "BadNoData",

[huebl]

The SPEC specifies that the StatusCode must be returned as a number and not as a string. A string is only allowed in a status object but not in a status variable. Currently we do not support status objects. Should there still be a status string returned then this should be changed.

@FLIPBack - Do you know such places?

[atimin]

Ok. I agree that the status of the value must be an integer. But the names are confusing me again.
Field StatusCode stores the status as a sting. In my opinion, It can't be a code. On the other hand field Status is a number and it is code. Moreover it is hard to distinguish these names.

My offer is to rename Status to OpcUaStatusCode, so its semantic will be clearer. StatusCode is not the best name, but it might cause a lot of changes to rename it.

[atimin]

Should there still be a status string returned then this should be changed.

@FLIPBack - Do you know such places?

Sorry didn't catch, 😞

[huebl]

The implementation (OpcUaWebServer) uses proprietary and OPC UA data types. The description of JSON was not yet included in the SPEC at this time. Therefore, all status codes were transmitted in string format. The new OPC UA specification now also describes the JSON formats. Therefore, the OPC UA data types have already been changed. The own data types were probably not changed yet. That's why there are still differences.

I also think the own data types should be adapted to the OPC UA standard.

[atimin]

@huebl , could you give an example? own data type is not clear to me.

[huebl]

Example OPC UA Data Type: OpcUaVariable (READ_RESPONSE Body)
Example own DataType: Variables (Value Info Response). This data type is not described in OPC UA SPEC.

All requests do not exist in OPC UA. As a result, many own data types are used for the requests / responses. The situation in the OpcUaGateway is different. In most cases (exception login) OPC UA data types are used in this component.

[atimin]

Having a look at the specification, I see that you follow the standard.

I also think the own data types should be adapted to the OPC UA standard.

How do you want to do it?