We've launched our new site at www.openlighting.org. This wiki will remain and be updated with more technical information.
RDM Responder Testing
From wiki.openlighting.org
As part of the Open Lighting Project we've developed a suite of tests for RDM responders. This enables manufacturers to check how well a RDM device conforms to the E1.20 specification. The tests cases are written in Python, and use the Open Lighting Architecture to communicate with devices.
Have a question? Ask on the RDM Test Group.
Supported Devices
The following RDM Controller devices are supported:
- RDM-TRI - the doesn't support the Discovery tests yet.
- DMXter4 RDM / MiniDMXter
- Robe Universal Interface (latest firmware required)
- DMX USB Pro (2.4 firmware required)
Downloading & Installing the Test Software
The tests are built on top of the Open Lighting Architecture which runs on Mac OS, Linux and FreeBSD. If you're a Windows user, the easiest way to get started is to use the Raspberry Pi (instructions). It's a $35 embedded linux computer and you can run all the tests through a web browser without ever having to log in.
For Mac, Linux & FreeBSD users, follow the OLA Installation Instructions. If you're installing from source you need to add --enable-rdm-tests when running ./configure . If you use Debian or Ubuntu packages make sure you install the ola-rdm-tests package. The tests are quite stable at this point, so unless you have a reason to use the Git version I'd stick to using the monthly releases.
Running the Tests
The tests can be run from either the command line or a web browser. If you're new to using the command line we suggest you use the Web UI. It can do everything the command line tests can do.
Useful Links:
Interpreting the Output
See the Guide to Interpreting Test Output.
Test Coverage
As of 7th July 2012 the following PIDs in E1.20 aren't tested:
- STATUS_MESSAGES
- STATUS_ID_DESCRIPTION
- SUB_DEVICE_STATUS_REPORT_THRESHOLD
- RESET_DEVICE
Test Categories
Tests are grouped according to the sections in the RDM Categories/Parameter ID Defines table in the E1.20 document. There are some extra categories for specific behavior like error conditions and sub device handling.
Test States
There are four possible result states for a test:
- Passed
- The responder replied with the expected result
- Failed
- The responder failed to reply, or replied with an un-expected result
- Not Run
- This test wasn't run because the responder doesn't support the required functionality or a previous test failed.
- Broken
- An internal error occurred, this indicates a programming error or an error with the test rig.
Log Messages
- Warnings
- Warnings indicate behavior that doesn't match the standard, but is unlikely to cause usability issues. Warnings are printed in the summary section of the test output.
- Advisory Messages
- Advisory messages indicate issues that are not covered by the standard but are likely to cause problems i.e a sensor temperature out side of the stated scale range.