Skip to content

DMXRouter 1.5.4

Choose a tag to compare

View all tags
@fiverecords fiverecords released this 15 Mar 14:44
· 49 commits to main since this release
V1.5.4
80f3703
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

RDM — Fixture ID (E1.37-5: DEVICE_UNIT_NUMBER)

Support for PID 0x0656 DEVICE_UNIT_NUMBER from ANSI E1.37-5. This PID — commonly known as Fixture ID — is designed to give each fixture a unique numeric identifier independent of its DMX address, making it possible to track individual units across different shows, venues, and address schemes.

  • Fixture ID column in the device tree. A new "FID" column appears between DMX and Personality, showing the fixture ID of each discovered device. Robert Juliat and other manufacturers implementing this PID consider it "as important as the DMX address" — the tree reflects this by placing them side by side.
  • Fixture ID in the Info tab. Displayed below Sub-Devices, immediately visible without needing "Fetch Advanced".
  • Fixture ID in the Config tab. A spin box (0–65534) with a Set button lets you assign a fixture ID from DMXRouter, just like setting a DMX address. The value is sent via SET DEVICE_UNIT_NUMBER and confirmed with a re-read.
  • Fetched automatically as part of "Fetch Advanced" alongside all other E1.37 PIDs.
  • RDM Emulator support. Emulated devices respond to GET and SET DEVICE_UNIT_NUMBER. The value is persisted to disk, captured when snapshotting a real device, and advertised in SUPPORTED_PARAMETERS.

RDM — Automatic Status Message Drain (E1.20 §5.3.3)

E1.20 specifies that when a device has queued messages, it sets messageCount > 0 in the response header of any RDM transaction. The controller should then drain those messages by sending GET QUEUED_MESSAGE. DMXRouter now does this automatically.

  • Auto-drain on every RDM response. When any successful RDM response arrives with messageCount > 0, DMXRouter begins draining the device's output queue by sending GET QUEUED_MESSAGE in a loop (50ms spacing) until messageCount reaches 0. This happens transparently in the background — no user action required.
  • Status messages are accumulated per device. Drained STATUS_MESSAGES responses are decoded and stored in the device's data structure, persisting as long as the device remains discovered. Other queued PID responses (non-status) are logged for diagnostics.
  • Concurrency protection. Only one drain loop runs per device at a time. A depth limit of 20 messages per burst prevents runaway loops from misbehaving responders.

This is particularly important for fixtures that use status messages to report selftest results, sensor alerts, or configuration changes made via their own web interface — the controller now picks these up automatically instead of requiring the operator to manually poll.

RDM — Status Message Indicators in the Device Tree

Status messages are now visible at a glance in the device tree, without needing to open the Status tab:

  • The Status column now reflects accumulated status messages. After probe completion (✔), the indicator changes if the device has reported status messages:
    • ⚠ red — one or more errors (STATUS_ERROR / STATUS_ERROR_CLEARED)
    • ⚠ orange — warnings present, no errors (STATUS_WARNING / STATUS_WARNING_CLEARED)
    • ℹ green — advisories only (STATUS_ADVISORY / STATUS_ADVISORY_CLEARED)
    • ✔ green — probe complete, no status messages
  • Tooltip on the Status column summarises the message counts (e.g. "2 errors, 1 warning — select device and open Status tab for details").

This means that when a fixture sends a status message after a selftest, a sensor alert, or a configuration change, the operator sees it immediately in the tree — exactly what professional workflows need.

RDM — Status Tab Improvements

  • Status tab auto-populates when selecting a device. Previously the table was always empty until you clicked "Fetch Status". Now, if the device has accumulated status messages (from auto-drain or previous manual fetches), they appear immediately when you select the device.
  • Manual "Fetch Status" and "GET Queued" also feed the device accumulator. Messages fetched manually are stored alongside auto-drained messages, so the tree indicator updates in real time.
  • "Clear Status" clears both the table and the device accumulator. After sending SET CLEAR_STATUS_ID to the device, the accumulated messages are removed from memory, the tree indicator reverts to ✔, and the table is emptied.
  • Live update during auto-drain. If a device is currently selected and status messages arrive via auto-drain, the Status tab updates immediately with an "(auto-drained)" label in the message count.

RDM — Probe Progress Bar Cleanup

  • The probe progress bar and its status label now hide entirely when discovery finishes, instead of remaining visible as a centered "Idle" / "N devices — ready" label occupying a full-width row. Device count is already shown in the header — the progress bar only appears while probing is actively in progress.

RDM Templates — Lamp Hours Warning

  • Lamp hours limit per model. A new "Lamp Limit" column in the Templates table lets you set a warning threshold in hours (e.g. 2000h for a specific fixture model). The value is stored in the template and persisted to disk.
  • Warning in the device tree. When a discovered device's lamp hours exceed its model's template limit, the device name turns orange and a tooltip shows "Lamp hours: 2150 (limit: 2000h)".
  • Warning in the Info tab. The Lamp Hours row turns red and shows "2150 ⚠ exceeds 2000h limit" when the threshold is exceeded.
  • Set the limit to 0 (shown as "—") to disable the warning for a model.

RDM Templates — Firmware Mismatch Warning

  • Templates now capture the device's firmware version (SOFTWARE_VERSION_LABEL) at save time.
  • Warning on manual apply: when applying a template to a device running a different firmware than the one the template was saved from, a warning dialog explains that personalities, channels, or behavior may have changed, and asks for confirmation before proceeding.
  • Warning on auto-apply: during automatic template application on discovery, firmware mismatches are logged in the RDM transaction log so the operator can review them after probing completes.
  • Visual indicator in the Templates table: the Model column shows an orange text when a discovered device of the same model has a different firmware than the template. Hover the Model cell to see both versions.

UI Polish

  • Improved table layouts across the application. Columns that contain variable-length text (device name, model, label, description) now stretch to use available space, while fixed-width columns (status indicators, timestamps, IDs) no longer waste space. This applies to the RDM device tree, Node Config tree, Fixture DB, PID Browser, Slots, personality tables (RDM, LLRP, RDMNet), and the Show Cue table.
  • RDM device tree Status column now shows ✔ (checkmark) on all platforms instead of 💾 (floppy disk emoji) which had no obvious meaning.
  • RDM and Node Config splitter proportions adjusted so the device tree gets enough room for all columns by default.
  • Show Cue Curve/Loop dropdowns no longer clip on macOS — columns and combo boxes widened to accommodate the dropdown arrow.
  • Interfaces tab font sizes reduced to match the rest of the application. Previously the tab appeared noticeably larger than other tabs, especially on macOS.

macOS — VLAN IP Assignment Fix

  • "Set IP" now works for VLAN interfaces on macOS. Previously, assigning an IP to a VLAN adapter failed with "SERVICE_NOT_FOUND" because the BSD device name (vlan0) was only looked up in hardware ports, where VLANs don't appear. A third lookup path via networksetup -listVLANs now resolves the correct network service name. Physical interfaces (en0) continue to work as before via the hardware ports path.

Platform Availability

Windows

Download and run DMXRouter-Setup.exe. All dependencies included.

VLAN management requires Windows Pro/Enterprise with Hyper-V enabled.

Linux

Download the binary for your architecture:

  • DMXRouter-v1.5.4-linux-x86_64.zip — standard PCs and servers
  • DMXRouter-v1.5.4-linux-arm64.zip — Raspberry Pi 4/5, Orange Pi, ARM64 boards

Qt6 runtime required:

# Ubuntu / Debian / Raspberry Pi OS
sudo apt install libqt6core6 libqt6gui6 libqt6widgets6 libqt6network6

# Fedora
sudo dnf install qt6-qtbase

# Arch
sudo pacman -S qt6-base

Then: chmod +x DMXRouter && ./DMXRouter

VLAN management requires NetworkManager (sudo apt install network-manager if not present). No need to run as root — the app prompts for your password when needed. VLANs persist across reboots.

macOS

Download the .app bundle (Qt6 frameworks bundled). Requires macOS 13.0 (Ventura) or later. On first launch, allow it in System Settings → Privacy & Security.

No need to run with sudo — the app prompts for your password when needed. VLANs appear in System Settings → Network and persist across reboots.

Assets 6
Loading