rdm-schema icon indicating copy to clipboard operation
rdm-schema copied to clipboard

Manufacturer specific E1.20 schemas

Open sammysmallman opened this issue 4 years ago • 2 comments

There is a plausible scenario where a manufacturer may want to write a manufacturer specific version of an E1.20 parameter, for example:

{
  "scope": { 
    "esta_manufacturer_id": 12345,
    "device_model_id": 1337,
    "software_version_id": 12345678,
    "root": true
  }
  "name": "DMX_PERSONALITY",
  "pid": 224,
  "version": 1,
  "get_request_subdevice_range": [ "root", "subdevices" ],
  "get_request": [],
  "get_response": [
    {
      "name": "personality",
      "type": "uint8",
      "ranges": [
        { "minimum": 1, "maximum": 3 }
      ],
      "labels": [
        { "name": "1_ch", "value": 1 },
        { "name": "direct", "value": 2 },
        { "name": "direct_plus_strobe", "value": 3 }
      ]
    },
    { "name": "personality_count", "type": "uint8" }
  ],
  "set_request_subdevice_range": [ "root", "subdevices", "broadcast" ],
  "set_request": [
    { "$ref": "#/get_response/0" }
  ],
  "set_response": []
}

I've used the scope property referred to in #13, but do we think this should be a thing?

sammysmallman avatar Nov 01 '21 10:11 sammysmallman

We discussed this in today's E1.37-5 meeting and came to the conclusion that doing something like this is counter to the intent of the Parameter Metadata Language. The Parameter Metadata Language is intended as a complement to RDM--not a replacement. Encoding this information here is no longer just describing the PID, but is actually implementing it outside the realm of the RDM conversation. Beyond that, E1.37-5 specifically prohibits transmitting PIDs with the ESTA Manufacturer ID, because those definitions exist and can only be altered as part of the ratified RDM documents.

mayanigrosh avatar May 19 '22 17:05 mayanigrosh

I don't disagree with your comment but... Is a manufacturer specific parameter definition providing labels like in the example above not implementing it outside the realm of the normal RDM conversation? If we are to take that route should labels not be omitted and a description parameter much the same as DMX_PERSONALITY_DESCRIPTION be used along side the parameter to provide its labels?

sammysmallman avatar May 19 '22 21:05 sammysmallman