Writable table as VirtualParameter

[George Chelidze]

Hi,

As you know PortMapping object's location depends on instances for
WANDevice, WANConnectionDevice and WANIPConnection nodes. So in general
it's:

InternetGatewayDevice.WANDevice.{i}.WANConnectionDevice.{i}.WANIPConnection.{i}.PortMapping

In practice, it can be as simple as
InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.PortMapping,
or with the same success, it can be
InternetGatewayDevice.WANDevice.5.WANConnectionDevice.1.WANIPConnection.3.PortMapping
depending on vendor's implementation. You never know what instances are
used, when do they change (if ever), so you have to query a device.

To be able to manage this table through API, you have to:

A) Find actual instances used. For this, I use the following preset
called WANIPConnectionPortMapping:

let wanIPConnectionPortMapping =
"InternetGatewayDevice.WANDevice.1.WANConnectionDevice.1.WANIPConnection.1.PortMapping";
let portMappings =
declare("InternetGatewayDevice.WANDevice.*.WANConnectionDevice.*.WANIPConnection.*.PortMapping",
{path: Date.now()});
if (portMappings.size) {
  for (let portMapping of portMappings) {
    wanIPConnectionPortMapping = portMapping.path;
    break;
  } 
}
return {writable: false, value: [wanIPConnectionPortMapping, "xsd:string"]};

As a result, I can read VirtualParameters.WANIPConnectionPortMapping,
which contains the actual path (the first one) currently used, and use
it for further API calls.

B) If it's possible to create a VirtualParameter which contains a
writable table, it will be possible to perform whatever operations is
required directly on this parameter (table) without taking care about
instances used, which will simplify the whole process. Another benefit
would be to use this parameter in summary_parameters.yml to display the
table (as far as I understand it's not possible to use any kind of
wildcards/regexp in summary_parameters.yml).

So to summarize, my question is regarding second approach (B): Is it
possible to create a writable virtual parameter which contains a table
(not a primitive like xsd:string, xsd:unsignedInt, etc). If yes, a
simple example would be great. If not, we have a workaround as described
in point A, however it's not clear how to describe this table in
summary_parameters.yml. Any suggestions?

Regards,

George Chelidze