Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Manufacturer specific E1.20 schemas #17

Open
sammysmallman opened this issue Nov 1, 2021 · 2 comments
Open

Manufacturer specific E1.20 schemas #17

sammysmallman opened this issue Nov 1, 2021 · 2 comments

Comments

@sammysmallman
Copy link

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?

@mayanigrosh
Copy link

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.

@sammysmallman
Copy link
Author

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants