We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.
RDM PID Definitions
From wiki.openlighting.org
Contents
Parameter Definitions and OLA
OLA reads the structure of RDM parameter messages at runtime. This allows the users to update PID definitions without upgrading the binaries and also means we can add knowledge of new manufacturer PIDs to the RDM controller software very quickly.
The canonical PID definitions are stored on the http://rdm.openlighting.org site. The site can generate ASCII protocol buffers which are checked into the OLA codebase and distributed with the tarball. One day we may support automatic updating of the PID files.
You can see the latest pid protobufs at pids.proto and manufacturer_pids.proto. In the tarball the files are in data/rdm/ and they are usually installed into /usr/local/share/ola/pids/.
Adding New Parameters
Parameters are added to the rdm.openlighting.org site by specifying the message structure, as well as properties like the parameter name and ID in a Python file. To get started, clone the rdm.openlighting.org code from http://code.google.com/p/open-lighting/source/checkout?repo=rdm-app. The definitions are found in data/pid_data.py. Once you have edited this file push the change to a public git repo and email the open-lighting list asking for a pull request. Simon will sanity check the new parameters and push them to the rdm.openlighting.org site.
Structure
The parameter definitions file is just a Python data structure. At the top level there are two variables MANUFACTURER_PIDS and ESTA_PIDS.
MANUFACTURER_PIDS = [
{'id': <int>, # the manufacturer ID, written in hex
'name': <string>, # the manufacturer name
'pids': [<parameter_definition>],
},
...
]
ESTA_PIDS = [
<parameter_definition>
]
Each Parameter Definition takes the form:
{
'get_request': {'items': [<item>]},
'get_response': {'items': [<item>]},
'get_sub_device_range': <int>,
'name': <string>,
'set_request': {'items': [<item>]},
'set_response': {'items': [<item>]},
'set_sub_device_range': <int>,
'link': <string>, # the URL for more information
'notes': <string>,
'value': <int>, # the PID
}
- {get,set}_request
- The structure of the GET / SET request. This specifies a list of items which are the fields in the parameter message. See the section below for more details.
- {get,set}_response
- The structure of the GET / SET response, same structure as the _request fields.
- {get,set}_sub_device_range
- A value between 0 and 3 which places restrictions on the value of the SubDevice field in the RDM message.
- name
- The name of the PID, should be in CAPS like the names in E1.20
- line
- A URL pointing to where this information was obtained, set to the empty string is there isn't one
- notes
- A text description of what this parameter does. This should be explain to the user how to use the parameter.
- value
- The parameter ID (PID).
The allowed values for the sub_device_ranges are:
- 0
- ROOT_DEVICE, implies the subdevice field is 0x0000
- 1
- ROOT_OR_ALL_SUBDEVICE, the subdevice field is 0x0000 to 0x0200 or 0xffff
- 2
- ROOT_OR_SUBDEVICE, the subdevice field is 0x0000 to 0x0200
- 3
- ONLY_SUBDEVICES, the sub device field is 0x0001 to 0x0200
If a {get,set}_request field isn't present, this means the parameter doesn't support the GET / SET operation. In that case the corresponding _response field should also not be present. Note that this differs from a _request field which is present, but contains no items. The latter means that the parameter data length is 0.
Items
Items represent the data fields within each message. An item can also be a group of items, which is how repeated fields are supported. There are only two required attributes for an item:
{
'name': <string>,
'type': <string>',
}
Item names should be all lower case, with spaces replaced by _ . In OLA, item names are run through CustomCapitalizeLabel() before being displayed to the user. This replaces '_' with ' ' and capitalizes words. For more details see the code in StringUtils.cpp.
The valid item types are:
- bool
- uint8
- uint16
- uint32
- int8
- int16
- int32
- string
- group, a group of items, see below for more details.
- ipv4, a 32 bit IP address
- uid, a 48 bit UID.
All multi-byte items are big endian.
Optional Fields
These are only defined for certain types.
labels multiplier range min_size max_size
Item Groups
Examples
These examples show how Parameters from E1.20 are described using the PID Definitions Syntax.
DEVICE_INFO
A simple example is DEVICE_INFO. This is only defined for GET commands, and returns a message with various mixed-type fields:
{'get_request': {'items': []},
'get_response': {'items': [
{'name': 'protocol_major', 'type': 'uint8'},
{'name': 'protocol_minor', 'type': 'uint8'},
{'name': 'device_model', 'type': 'uint16'},
{'name': 'product_category', 'type': 'uint16'},
{'name': 'software_version','type': 'uint32'},
{'name': 'dmx_footprint', 'type': 'uint16'},
{'name': 'current_personality', 'type': 'uint8'},
{'name': 'personality_count','type': 'uint8'},
{'name': 'dmx_start_address', 'type': 'uint16'},
{'name': 'sub_device_count','type': 'uint16'},
{'name': 'sensor_count', 'type': 'uint8'}]},
'get_sub_device_range': 2,
'name': 'DEVICE_INFO',
'value': 96},
DEVICE_LABEL
DEVICE_LABEL is defined for GET and SET. This example shows how to limit the length of a string.
{'get_request': {'items': []},
'get_response': {'items': [
{'name': 'label', 'max_size': 32, 'type': 'string'}
]},
'get_sub_device_range': 2,
'name': 'DEVICE_LABEL',
'set_request': {'items': [
{'name': 'label','max_size': 32, 'type': 'string'}
]},
'set_response': {'items': []},
'set_sub_device_range': 1,
'value': 130},
}
SLOT_INFO
This example shows how repeated fields work:
{'get_request': {'items': []},
'get_response': {'items': [
{'name': 'slots', 'type': 'group', 'items': [
{'name': 'slot_offset', 'type': 'uint16'},
{'name': 'slot_type', 'type': 'uint8'},
{'name': 'slot_label_id', 'type': 'uint16'}
]},
]},
'get_sub_device_range': 2,
'name': 'SLOT_INFO',
'value': 288},
