Skip to content

Data model

The sandbox exposes two ways to publish data: metrics for named scalar values, and tables for lists of similar rows. Pick the one that matches the shape of the data you collect.

Use metrics for a small, fixed set of named scalar values per device — “CPU temperature”, “uptime”, “firmware version”. Each metric has a stable identifier (UID), a label, a value, a unit, a type, and optional metadata.

var cpu = D.createMetric({
uid: 'cpu',
name: 'CPU Temperature',
value: 62,
unit: 'C',
valueType: D.valueType.NUMBER,
});
var fw = D.createMetric({
uid: 'fw',
name: 'Firmware',
value: '4.1.2-rc3',
unit: '',
valueType: D.valueType.STRING,
metadata: { url: 'https://vendor.example/release-notes/4.1.2-rc3' },
});
D.success([cpu, fw]);
  • The uid is the stable identifier the portal uses to align history across runs. Keep it short and stable.
  • D.valueType.NUMBER values produce charts; D.valueType.STRING values produce a text field.
  • metadata.url (optional) lets the portal render the metric as a link to an external resource.

Use tables when the device returns a list of similar rows — interfaces, VLANs, processes, neighbours. Declare the columns up front, then add rows.

var ifaces = D.createTable('Interfaces', [
{ label: 'Interface' },
{ label: 'In', unit: 'bps' },
{ label: 'Out', unit: 'bps' },
{ label: 'Up', valueType: D.valueType.STRING },
]);
ifaces.insertRecord('eth0', ['eth0', 1200000, 850000, 'yes']);
ifaces.insertRecord('eth1', ['eth1', 0, 0, 'no']);
D.success(ifaces);
  • The first argument to insertRecord is the row UID. Like variable UIDs, it should be stable across runs.
  • Table cells can mix numbers and strings; use the column valueType to steer the portal renderer.
You haveUse
A fixed handful of named valuesMetrics
A single scalar valueMetric
A list of similar objects with the same fieldsTable

You can mix metrics and a table in one D.success call when a device needs both — for example, device-level metrics plus a per-interface table:

D.success([fw, cpu], ifaces);