OLE User Manual
 All Pages
RDM Responder

Overview

The OLE software can simulate different types of RDM Device Models. This allows RDM controllers to be tested without having to purchase different types of RDM products.

Each Device Model is identified with a 16-bit Device Model ID. See Section 10.5.1 of the RDM Standard for more information on Device Model IDs.

The device can only operate as one model at a time.

Model ID (hex) Model Id (dec) Description
0x0100 256 LED Driver
0x0101 257 Proxy, which ACK_TIMERs all requests to child devices.
0x0102 258 Moving Light
0x0103 259 Sensor only device (no DMX footprint)
0x0104 260 E1.37-2 Network Device
0x0105 261 Dimmer, with sub-devices & status messages.

Selecting the Device Model ID

The RDM Device Model is controlled by Manufacturer Specific RDM PIDs. They can be changed with any RDM Controller software that supports setting Manufacturer Specific PIDs. These PIDs do not appear in SUPPORTED_PARAMETERS, so in a sense they are 'hidden'.

MODEL_ID_LIST

MODEL_ID_LIST will return a list of Device Model IDs. There is no data in the GET request.

MODEL_ID

MODEL_ID is used to Get or Set the current Device Model ID.

OLA Commands

The PIDs aren't included in the 0.10.0 release of OLA, so you will need to add this file to your PID data directory (normally /usr/local/share/ola/pids or /usr/share/ola/pids) and restart olad.

Once you know the UID of your device. you can use OLA command line tools, to fetch a list of available models:

$ ola_rdm_get --universe 1 --uid 7a70:fffffe00 model_id_list

To change the current model:

$ ola_rdm_set --universe 1 --uid 7a70:fffffe00 model_id 258

LED Model

The LED Model can be used to control SPI LED Pixels. It provides very basic RDM support, with 2 Manufacturer specific PIDs to control the type and number of pixels.

Supported Parameters

PIDGetSet
PRODUCT_DETAIL_ID_LISTY
DEVICE_MODEL_DESCRIPTIONY
MANUFACTURER_LABELY
DEVICE_LABELYY
PIXEL_TYPEYY
PIXEL_COUNTYY

Proxy Model

This model simulates a wireless RDM proxy with 2 downstream RDM devices. All requests to the downstream devices will return an ACK_TIMER. The response messages can be obtained with a GET QUEUED_MESSAGES.

Supported Parameters

PIDGetSet
PROXIED_DEVICESY
PROXIED_DEVICE_COUNTY
PRODUCT_DETAIL_ID_LISTY
DEVICE_MODEL_DESCRIPTIONY
MANUFACTURER_LABELY
DEVICE_LABELYY

Moving Light Model

This model simulates an RDM enabled Moving Light.

Supported Parameters

PIDGetSet
COMMS_STATUSYY
PRODUCT_DETAIL_ID_LISTY
DEVICE_MODEL_DESCRIPTIONY
MANUFACTURER_LABELY
DEVICE_LABELYY
FACTORY_DEFAULTSYY
LANGUAGE_CAPABILITIESY
LANGUAGEYY
BOOT_SOFTWARE_VERSION_IDY
BOOT_SOFTWARE_VERSION_LABELY
DMX_PERSONALITYYY
DMX_PERSONALITY_DESCRIPTIONY
SLOT_INFOY
SLOT_DESCRIPTIONY
DEFAULT_SLOT_VALUEY
DEVICE_HOURSYY
LAMP_HOURSYY
LAMP_STRIKESYY
LAMP_STATEYY
LAMP_ON_MODEYY
DEVICE_POWER_CYCLESYY
DISPLAY_INVERTYY
DISPLAY_LEVELYY
PAN_INVERTYY
TILT_INVERTYY
PAN_TILT_SWAPYY
REAL_TIME_CLOCKYY
RESET_DEVICEY
POWER_STATEYY

Sensor Model

This model has a DMX footprint of 0.

Supported Parameters

PIDGetSet
PRODUCT_DETAIL_ID_LISTY
DEVICE_MODEL_DESCRIPTIONY
MANUFACTURER_LABELY
DEVICE_LABELYY
SENSOR_DEFINITIONY
SENSOR_VALUEYY
RECORD_SENSORSY

Sensors

Sensor Index Name Type, Units Units Notes
0 Temperature Temperature, Centigrade Deci Data is from the onboard temp. sensor if present, or random data if not.
1 Missing Sensor Acceleration, meters / second^2 Deci Always NACKs SENSOR_VALUE with NR_HARDWARE_FAULT
2 Voltage Voltage, Volts Milli Data is random numbers

Network Model

This model implements the PIDs from E1.37-2, IPv4 & DNS Configuration Messages.

Supported Parameters

PIDGetSet
PRODUCT_DETAIL_ID_LISTY
DEVICE_MODEL_DESCRIPTIONY
MANUFACTURER_LABELY
DEVICE_LABELYY
LIST_INTERFACESY
INTERFACE_LABELY
INTERFACE_HARDWARE_ADDRESS_TYPE1Y
IPV4_DHCP_MODEYY
IPV4_ZEROCONF_MODEYY
IPV4_CURRENT_ADDRESSY
IPV4_STATIC_ADDRESSYY
INTERFACE_RENEW_DHCPY
INTERFACE_RELEASE_DHCPY
INTERFACE_APPLY_CONFIGURATIONY
IPV4_DEFAULT_ROUTEYY
DNS_IPV4_NAME_SERVERYY
DNS_HOSTNAMEYY
DNS_DOMAIN_NAMEYY

Interfaces

Interface Index Name DHCP Supported Notes
1 eth0 Yes -
3 tun0 No -
4 wlan0 Yes 1/3rd of DHCP renew requests will fail

Dimmer

This model simulates a Dimmer. The root device has a DMX footprint of 0 and there are 4 sub-devices present.

All PIDs from E1.37-1, Dimmer Message Sets are supported.

Supported Parameters

PIDGetSet
STATUS_MESSAGESY
STATUS_ID_DESCRIPTIONY
PRODUCT_DETAIL_ID_LISTY
DEVICE_MODEL_DESCRIPTIONY
MANUFACTURER_LABELY
DEVICE_LABELYY
DMX_BLOCK_ADDRESSYY
DMX_FAIL_MODEYY
DMX_STARTUP_MODEYY
LOCK_PINYY
LOCK_STATEYY
LOCK_STATE_DESCRIPTIONY
PERFORM_SELFTESTYY
SELF_TEST_DESCRIPTIONY
CAPTURE_PRESETY
PRESET_PLAYBACKYY
PRESET_INFOY
PRESET_STATUSYY
PRESET_MERGEMODEYY
POWER_ON_SELF_TESTYY

Sub-devices

The dimmer has multiple sub-devices, that each take a single slot of DMX data. The sub-devices are not contiguous.

DMX_BLOCK_ADDRESS can be used to set the DMX Start Address of all sub-devices in a single operation.

Dimmer Settings

Each sub-device of the dimmer implements the PIDs from Section 4 of E1.37-1. To make things interesting, not all sub-devices support all the dimmer curves / modulation frequencies.

Presets & Scenes.

The root device provides 3 scenes. The first scene (index 1) is a factory programed scene, which can't be modified. The 2nd and 3rd scenes can be 'updated' with capture preset.

DMX_FAIL_MODE and DMX_STARTUP_MODE can be used to change the on-failure and on-startup scenes.

Status Messages

Sub devices 1 & 3 will periodically queue status messages, which can be collected using the STATUS_MESSAGE PID. Subdevice 3 uses a manufacturer defined status_id, and the string can be retrieved with STATUS_ID_DESCRIPTION. Status messages from the individual sub devices can be suppressed with SUB_DEVICE_STATUS_REPORT_THRESHOLD.

Lock PIN

The root device implements the LOCK_PIN, LOCK_STATE & LOCK_STATE_DESCRIPTION PIDs. Besides the unlock state (default), there are two custom states. The 1st locks only the sub-devices, the 2nd locks both subdevices and the root device.

The default lock pin is 0000.

Self Tests

The root device supports two self tests. The 1st completes in 5s and always passes. The 2nd takes 20s and always fails. When the test completes a status message is queued.