Additional proposal: Mobile Fixture Tester, RDM/Node view and per-port configuration

[Kevin11999]

Hi,

I would like to add a more specific idea for the Fixture Tester, especially for mobile use. I think the web interface could become a very strong phone-based tool for testing a rig on-site.

1. Mobile Fixture Tester layout

On a phone, the Fixture Tester could have a simple mobile layout.

At the top:

Search bar

The search bar should allow the user to search by:

• Fixture name
• Group
• Universe
• Address
• Location
• Manufacturer/type

At the bottom of the mobile page, there could be four main tabs:

Fixture List | Macros | Addresses | Parameters

---

2. Fixture List tab

The Fixture List tab should show the available fixtures in a clear way.

Suggested order:

1. Auto-generated groups first
2. Individual fixtures below that

Groups could be generated from:

• Location
• Universe
• Manufacturer
• Fixture type
• Mode
• MVR data

Example:

LX1
LX2
Front Truss
Back Truss
MAC Ultra
LED PAR

If I search for LX1, I should directly see all fixtures related to LX1.

There should also be a filter option in the search bar, for example:

Search in: Groups / Fixtures / Universes

That way I can quickly decide what I am looking for.

---

3. Macros tab

The Macros tab should show available macros based on the selected fixtures or groups.

For example, if I select a group of fixtures, the macro page should show relevant actions based on the fixture control channels.

Useful macros:

• Lamp On
• Lamp Off
• Reset
• Dimmer Full
• Dimmer Off
• Shutter Open
• Shutter Closed
• Highlight
• Pan/Tilt test
• Color test
• Gobo test

The important thing is that macros should be generated from the fixture data/control channels where possible.

So if a fixture has a control channel with reset or lamp commands, the app should expose those actions clearly.

---

4. Addresses tab

The Addresses tab should be used to test selected fixtures one by one.

Workflow:

1. Select a group or fixtures.
2. Go to Addresses.
3. Press Start.
4. The page shows the current fixture information.
5. Press Next to move to the next fixture.
6. Press Previous to go back.
7. Press Pause to stop automatic stepping.
8. Use a speed slider to make the auto-step faster or slower.

The screen should show useful fixture information:

• Fixture name
• Universe
• DMX address
• Mode
• Manufacturer
• Fixture type
• Location
• MVR information if available

Example:

Fixture: MAC Ultra 01
Universe: 12
Address: 101
Mode: Extended
Location: LX1

This would make it much easier to walk around with a phone and check fixture addressing.

---

5. Parameters tab

The Parameters tab should allow direct control of the selected fixture or selected group.

For example:

Dimmer
[ slider ]

Pan
[ slider ]

Tilt
[ slider ]

Color
[ slider ]

Zoom
[ slider ]

This way I can manually move values up and down and test the fixture directly.

This is very important on mobile, because buttons alone are not enough. For fixture testing, sliders/faders are needed.

---

6. RDM / Node overview

It would also be very useful if the web interface had a clear RDM or network device overview.

Ideally, the app should show:

• Network devices
• DMX nodes
• RDM devices
• Node ports
• Fixtures found through RDM

A useful workflow would be:

1. Open the node/RDM overview.
2. See all network nodes.
3. Click a node.
4. See all ports of that node.
5. Click a port.
6. Edit or test that specific port.

This would make it easier to test the rig from the network side, not only from the fixture side.

---

7. Per-port node configuration

I tested the node/port configuration with Luminex nodes.

The port configuration works in principle, but currently it seems that the port configurator only allows updating all ports at once.

I think it would be much better if each port could be updated individually.

Example:

Node: Luminex Node
Port 1 → Universe 101
Port 2 → Universe 102
Port 3 → Universe 103
Port 4 → Universe 104

If I only want to change Port 2, I should be able to select only Port 2, change the universe, and update only that port.

At the moment, I have to make sure all ports are correct and then update everything together. That is risky, because I may accidentally change ports I do not want to touch.

---

8. Read current port configuration from node

Another issue is that the current configuration does not seem to load back correctly from the node into the port configurator.

Ideally, the app should first read the existing port configuration from the node, then allow editing.

Suggested workflow:

1. Select node.
2. Read current port configuration.
3. Show current port settings.
4. Edit one port or multiple ports.
5. Update only selected ports.

This would make the workflow much safer.

---

9. ELC / other node compatibility issue

I also tested this with ELC nodes.

With ELC, the port configuration does not seem to work correctly. In some cases the node does nothing, or the node appears to crash.

It would be good to investigate whether the current implementation is sending configuration data in a way that is only compatible with some node brands, or whether different node types need different handling.

At minimum, the app should handle unsupported or failing nodes safely and show a clear error instead of causing the node to crash.

---

Suggested development steps

Step 1 — Add mobile Fixture Tester page

Create a responsive mobile view with:

Search bar at the top
Fixture List / Macros / Addresses / Parameters tabs at the bottom

---

Step 2 — Add searchable fixture/group list

Add search and filters for:

• Groups
• Fixtures
• Universes
• Locations
• Fixture types
• Manufacturer
• Mode

---

Step 3 — Add group-based fixture selection

Allow users to select complete groups and use those groups in:

• Address testing
• Macros
• Parameter control
• Takeover

---

Step 4 — Add macro generation from fixture control channels

Use fixture profile/MVR/RDM data where possible to expose macros like:

• Lamp On
• Lamp Off
• Reset
• Highlight
• Shutter Open
• Dimmer Full

---

Step 5 — Add address test mode

Add a mobile-friendly address tester with:

• Start
• Previous
• Next
• Pause
• Auto-step
• Speed slider
• Fixture information display

---

Step 6 — Add parameter sliders

Add sliders for all available parameters of the selected fixture or group.

---

Step 7 — Add RDM/node overview

Show:

• Network nodes
• Node ports
• RDM devices
• Fixtures found through RDM

Allow the user to click a node, then click a port, then test or edit that port.

---

Step 8 — Add per-port node update

Allow updating only one selected port instead of always updating all ports.

This is important for safe show-site changes.

---

Step 9 — Add readback of current node port configuration

Before editing, the app should read the current port configuration from the node and show it correctly in the UI.

---

Step 10 — Improve compatibility and error handling

Test node configuration with multiple brands, for example:

• Luminex
• ELC
• Other Art-Net/sACN nodes

If a node does not support the configuration method, the app should show a clear error and avoid sending commands that may crash or lock up the node.

---

Summary

The goal is to make the Fixture Tester a real mobile rig-testing tool.

The ideal workflow would be:

Open phone → Search group/fixture → Select → Test addresses, run macros, control parameters or edit node port

And for node configuration:

Select node → Select port → Read current config → Edit only that port → Update selected port

This would make DMX Router much more practical during setup, troubleshooting and live show situations.

[fiverecords]

Hi Kevin,

Thanks for the detailed write-up — there's a lot here. Most of the suggestions are around the web UI, which was built mainly for remote access rather than as a primary interface, so polishing it hasn't been the priority. I'll work through your points across the next few releases and try to improve it where it makes sense.

On the port configuration: the current config should be read from the node and populated in the table before any modification — that does look like a bug, I'll look into it in an upcoming release.

On the ELC point: I can't reproduce it on my side. DMXRouter sends standard ArtAddress per the spec, and I've personally tested port config against Luminex, Elation, Netron, Robert Juliat and a generic Chinese brand without issues. If you can grab a Wireshark capture of the traffic when the ELC node misbehaves (a few seconds between DMXRouter and the node is enough), plus the node model and firmware version, that would help pin down whether it's something we're sending or something on the ELC side.

Cheers