Referencing #12, further thought on the subject of uniqueness has led me down the path that a schema should either be "scoped" as a manufacturer wide parameter (all devices supporting the parameter can use this schema) or specific to a manufacturer device model version (only a specific device model running a certain software version can use this schema).
In my mind there are two main reasons for the need for this "scope":

The manufacturer id allows for schemas with the same parameter id to sit in the same namespace as each other. e.g. ETC and HES may have a parameter schema each for a parameter that has the same id.
"labels" within the schema are different per device model version. e.g.

Device 1:

  "get_response": [
    {
      "name": "dmx_loss_behavior",
      "type": "uint8",
      "labels": [
        { "name": "dmx_loss_behavior_instant", "value": 0 },
        { "name": "dmx_loss_behavior_wait2min", "value": 1 },
        { "name": "dmx_loss_behavior_hll", "value": 2 }
      ]
    }
  ],

Device 2:

  "get_response": [
    {
      "name": "dmx_loss_behavior",
      "type": "uint8",
      "labels": [
        { "name": "dmx_loss_behavior_hll", "value": 0 }
        { "name": "dmx_loss_behavior_wait5min", "value": 1 },
        { "name": "dmx_loss_behavior_wait10min", "value": 2 },
        { "name": "dmx_loss_behavior_instant", "value": 3 },
      ]
    }
  ],

These "labels" are important as they remove the need to do the typical get request for parameter descriptions. In theory if we have a schema, it contains labels, and we know that the parameter the schema is for is "informedBy" (#14) another parameter, we can omit that informing parameter from the get requests after receiving supported parameters.

The schema used by Device 1 could be used by a large majority of the devices made by a manufacturer as such its scope could be deemed "manufacturer wide" and the schema would look something like this:

{
  "scope": { 
    "esta_manufacturer_id": 12345
  },
  "name": "DMX_LOSS_BEHAVIOR",
  "pid": 33034,
  "version": 1,
  "get_request_subdevice_range": [ "root", "subdevices" ],
  "get_request": [],
  "get_response": [
    {
      "name": "dmx_loss_behavior",
      "type": "uint8",
      "labels": [
        { "name": "dmx_loss_behavior_instant", "value": 0 },
        { "name": "dmx_loss_behavior_wait2min", "value": 1 },
        { "name": "dmx_loss_behavior_hll", "value": 2 }
      ]
    }
  ],
  "set_request_subdevice_range": [ "root", "subdevices", "broadcast" ],
  "set_request": "get_response",
  "set_response": []
}

The schema for Device 2 though is a specific to that particular device and its version and would look something like this:

{
  "scope": { 
    "esta_manufacturer_id": 12345,
    "device_model_id": 1337,
    "software_version_id": 12345678,
    "root": true
  },
  "name": "DMX_LOSS_BEHAVIOR",
  "pid": 33034,
  "version": 1,
  "get_request_subdevice_range": [ "root", "subdevices" ],
  "get_request": [],
  "get_response": [
    {
      "name": "dmx_loss_behavior",
      "type": "uint8",
      "labels": [
        { "name": "dmx_loss_behavior_instant", "value": 0 },
        { "name": "dmx_loss_behavior_wait2min", "value": 1 },
        { "name": "dmx_loss_behavior_hll", "value": 2 }
      ]
    }
  ],
  "set_request_subdevice_range": [ "root", "subdevices", "broadcast" ],
  "set_request": "get_response",
  "set_response": []
}

I wondered about different levels of specificity, for instance omitting the software_version_id would allow the schema to be valid for all device models made by the manufacturer... That might add a bit too much complexity to it though.

Uniqueness #13

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions