RDM data or sensors are missing
After RDM discovery has found a fixture, KLSTR.ctrl reads its RDM information one parameter at a time: device info, the list of supported parameters, then everything that depends on them, such as the description of every DMX personality and every sensor. On an RDM line only one request can be answered at a time, and a request that gets no usable answer is dropped without a message. Most missing data comes down to two things: a setting that is off, or requests that got lost on a busy line.
No RDM sensor readings
What you see. In the Monitoring tab, RDM fixtures show No sensors available, or sensor columns with a header but no readings. KLSTR.one fixtures in the same rig do show readings.
Why. Poll sensor values is off by default. KLSTR.ctrl then knows which sensors a fixture has, but never asks for their values.
What to do. Open KLSTR › User Settings (press Cmd , on macOS, Ctrl Shift U on Windows), click RDM and switch on Poll sensor values. The first readings arrive within one Poll sensor freqency (s) interval, 6 seconds by default. See Monitor sensors.
On a big rig, sensor polling adds a lot of RDM traffic. Raise Poll sensor freqency (s) if other RDM requests start to time out.
DMX modes or sensors missing on some fixtures
What you see. After a discovery of a large rig, some fixtures have everything and others, of the same model, have nothing:
- In the Device Configuration window, DMX Personality shows its label but no dropdown, so you can't pick a DMX mode.
- In the Monitoring tab, the fixture is listed under No sensors, although the same model shows sensors elsewhere.
A fixture has either all its mode descriptions or none, and which fixtures are affected changes from one discovery to the next. The fixtures are fine: the problem is in how the data was read.
Why. It happens most on many fixtures with a KLSTR.nano behind one Art-Net node, where each nano relays RDM to its fixture. By default, KLSTR.ctrl reads the fixtures of a line in several passes that can overlap, because a long line is mapped in pieces and each piece starts a new pass. Overlapping requests collide on the one shared line. The replies are lost, or the nano answers that it is busy, and that request is dropped. Mode descriptions are read with one request per mode, so a fixture with many modes is hit first.
What to do.
Switch on Sequential discovery
In User settings › RDM, under PERFORMANCE, switch on Sequential discovery. KLSTR.ctrl then finishes one reading pass before it starts the next, so only one request at a time is on the line and none collide. Discovery takes longer.
Run RDM discovery again
Run RDM discovery on the affected ports: click the discovery icon in the port's box in the Device Topology, or choose KLSTR.nano › RDM › Discover (press CmdShift D on macOS, Ctrl ShiftD on Windows) for every node.
Check the fixtures
Open a fixture that was missing its modes. DMX Personality now shows a dropdown with every mode. Leave Sequential discovery on for this rig.
Wrong DMX modes or sensors for a fixture
What you see. A fixture shows a mode list or sensors that don't match it, for example modes of an older firmware version.
Why. With Use cached PIDS on (the default), KLSTR.ctrl reuses the descriptions it already knows for a fixture model and software version, including a built-in set that can be older than your fixtures.
What to do. Switch off Use cached PIDS in User settings › RDM, under PERFORMANCE, and run RDM discovery on that port again. See Settings: RDM.
Other missing RDM data
| What you see | Likely cause | What to do |
|---|---|---|
| A fixture shows as Unknown, with an orange border and no patch or mode, and the Health Check lists it under rdm › deviceInfo › missing | It was discovered, but never answered the DEVICE_INFO request | Run discovery on its port again. If it stays, check the line and the fixture. See Run a health check |
| A manufacturer-specific parameter is missing in the Device Configuration window | KLSTR.ctrl reads only the standard parameters by default | Switch on Fetch all RDM PIDS in User settings › RDM and run discovery again. Discovery takes longer |
| Many requests time out behind slow nodes or long proxy chains | The answer takes longer than Packet timeout value (ms) (100 ms by default) | Raise Packet timeout value (ms) in User settings › RDM, then restart KLSTR.ctrl |
| Fixtures on a busy line flicker between online and offline | Queued-message requests go unanswered now and then | Raise QMSG offline timout count in User settings › RDM |
| The data is there after discovery, but changes made on the fixture itself don't show | KLSTR.ctrl learns about changes through queued messages | Leave Poll queued messages(QMSG) on, or run discovery again |
Related
Written for KLSTR.ctrl 1.2.0 (a0df909) · Checked 1 Oct 2026
The topology view looks wrong
Why fixtures show up in a group box, in the wrong order or after they were removed from the Device Topology, and how to get a correct picture of the DMX line again.
KLSTR.nano firmware problems
Make sense of KLSTR.nano firmware findings in the Health Check, amber badges, updates that end on done! or failed, and nanos that stop answering after an update.