Better support for variable types

[benmusson]

Currently all SNMP binding variables are parsed as strings, then handed off to the OPC UA server for conversion.
We should be smarter about returning proper OPC UA datatypes.

For instance:
Reading a non-existent entry will return the text "noSuchInstance".

[system24seven]

Also you can't return a table, so for instance 1.3.6.1.2.1.2.2 should return a table of interfaces.
This data would be very useful to show connected devices etc.

[benmusson]

We need to figuring out how to model SNMP tables in an OPC UA namespace.

Here's one possible suggestion:

OPC UA Structures:

SnmpTableColumn:
  - oid: String
  - name: String
  - datatype: Enum

SnmpTableRow:
  - index: UInt32
  - values: Variant[]

SnmpTable:
  - columns: SnmpTableColumn[]
  - rows: SnmpTableRow[]

Desired JSON representation:

{
  "columns": [
    { "oid": "1.3.6.1.2.1.2.2.1.1", "name": "ifIndex", "datatype": "INTEGER" },
    { "oid": "1.3.6.1.2.1.2.2.1.2", "name": "ifDescr", "datatype": "OCTET_STRING" },
    { "oid": "1.3.6.1.2.1.2.2.1.5", "name": "ifSpeed", "datatype": "GAUGE32" },
    { "oid": "1.3.6.1.2.1.2.2.1.8", "name": "ifOperStatus", "datatype": "INTEGER" }
  ],
  "rows": [
    {
      "index": "1",
      "values": [1, "eth0", 1000000000, 1]
    },
    {
      "index": "2",
      "values": [2, "eth1", 1000000000, 2]
    }
  ]
}

We don't currently have any way of reporting the column name, but ideally we'd have that info later.

[system24seven]

Ideally putting it in the Document tag so you can read the whole thing as one tag and turn into a dataset.
Possibly using the same notation that system.util.jsonEncode() would use to encode a native pydataset?

[benmusson]

I'm not an expert, but I don't know how arbitrary table structures can be modeled like that in OPC UA.

Do you have an example of an existing driver that does this?

[benmusson]

I guess we could dynamically create a Struct definition that matches the table's columns?

[system24seven]

I will have to look into it. It isn't straightforward immediately.

[benmusson]

https://reference.opcfoundation.org/Model-Best/v103/docs/

This seems relevant, will be reading over the next week.

[system24seven]

Arrays
I think the second option is the best here, but I am curious what happens when you put an array on the Ignition server.

[benmusson]

The main thing I want resolved before removing the beta moniker is proper datatype support.
Right now, all values read from an SNMP Agent are being returned as strings. Ignition does a good job of converting those strings into other value types when asked, but it's still not right.

To do this right:

1. We need a mapping from SNMP datatypes to OPC UA datatypes.
2. Each agent needs to track the SNMP datatype returned from reading an OID.
3. Reads and writes should use these tracked datatypes to:
   • When reading, the OPC UA Address Space should report the correct DataType.
   • When writing, the new value should be coerced into the correct SNMP datatype.

embr/modules/snmp/gateway/src/main/kotlin/com/mussonindustrial/embr/snmp/utils/SnmpUtils.kt

Lines 49 to 51 in 6e46b3b

	fun DataValue.toVariable(): Variable {
	return OctetString(this.value.value?.toString())
	}

embr/modules/snmp/gateway/src/main/kotlin/com/mussonindustrial/embr/snmp/agents/opc/OidAddressSpace.kt

Lines 89 to 91 in 6e46b3b

	AttributeId.DataType -> OpcUaDataType.String.nodeId