JackFrostbyte/rgb-aura
1
2
Fork 0
Code Issues 25 Pull requests Projects Releases 2 Packages Wiki Activity Actions

OpenRGB 1.0 compatibility and resilient device/zone discovery #97

New issue
Closed
opened 2026-09-20 22:25:03 -04:00 by JackFrostbyte · 1 comment
JackFrostbyte commented 2026-09-20 22:25:03 -04:00
Owner
Copy link

OpenRGB 1.0 compatibility and resilient device/zone discovery

Background

RGB Aura currently depends on OpenRGB device and zone names matching the configured mapping exactly.

After upgrading Nobara's OpenRGB package to:

openrgb-1.0-1.20260917git83ea112.fc44.x86_64

RGB Aura began repeatedly failing at startup.

The immediate validation error is:

Mapping validation failed: Zone name mismatch for top_fractal_fans.
Device: ASUS ROG STRIX B650E-E GAMING WIFI
Zone index: 1
Expected zone name: Aura Addressable 1
Detected zone name: Addressable RGB Header 1

OpenRGB 1.0 appears to have renamed at least this motherboard zone:

Aura Addressable 1

to:

Addressable RGB Header 1

Because mapping validation is currently strict, RGB Aura exits with status 2 and systemd repeatedly attempts to restart it.

There is also an older intermittent problem where the NVIDIA GPU is not always detected/available correctly by OpenRGB during startup, causing RGB Aura not to apply the configured effects to the graphics card.

During investigation of the OpenRGB 1.0 upgrade, OpenRGB itself was also observed segfaulting while servicing an SDK client request in:

NetworkServer::SendReply_PluginList()

Therefore RGB Aura should be made more tolerant of OpenRGB version changes and temporary device-discovery failures.

Goals

Improve RGB Aura so that a renamed, temporarily unavailable, or optional RGB device/zone does not unnecessarily prevent the entire lighting controller from operating.

1. Review OpenRGB 1.0 / SDK v6 compatibility

Verify the installed openrgb-python version and RGB Aura's OpenRGB client code against OpenRGB 1.0 / SDK protocol v6.

Check for API or protocol changes affecting:

  • device enumeration
  • zone enumeration
  • plugin enumeration
  • reconnect behavior
  • device IDs/indexes
  • zone names

2. Improve zone mapping resilience

Avoid depending solely on an exact human-readable OpenRGB zone name.

Possible approaches:

  • support multiple accepted aliases for a zone
  • use device + zone index as the primary identifier where reliable
  • allow expected-name aliases such as:
Aura Addressable 1
Addressable RGB Header 1
  • log renamed zones clearly rather than immediately aborting when the physical mapping can still be established safely

The implementation must still protect against controlling the wrong physical RGB header.

3. Improve device discovery resilience

A temporarily missing device should not necessarily terminate RGB Aura.

In particular, investigate the intermittent NVIDIA GPU detection issue.

Desired behavior could include:

  • retry device discovery for a configurable period
  • distinguish required devices from optional devices
  • continue controlling available devices when an optional device is unavailable
  • periodically retry unavailable devices
  • automatically begin controlling a device if it becomes available later
  • clearly log missing/recovered devices

4. Improve OpenRGB connection handling

RGB Aura should handle an OpenRGB SDK server restart or temporary disconnect gracefully where possible.

Consider:

  • reconnect attempts with bounded backoff
  • re-enumeration after reconnect
  • mapping re-validation after OpenRGB restarts
  • avoiding a rapid systemd restart loop for recoverable OpenRGB problems

5. Improve diagnostic logging

On discovery/mapping failures, log enough information to diagnose OpenRGB changes easily:

  • OpenRGB version if available
  • SDK protocol version
  • complete detected device list
  • device names/types
  • zone indexes and names
  • expected mapping
  • unavailable devices
  • aliases used during successful matching

Acceptance criteria

  • RGB Aura works with the current OpenRGB 1.0 package.
  • top_fractal_fans maps correctly despite the OpenRGB zone rename.
  • A missing optional GPU does not prevent motherboard/fan RGB control.
  • Temporary OpenRGB/device discovery failures do not cause an uncontrolled rapid restart loop.
  • RGB Aura can recover from a device becoming available after startup where practical.
  • Mapping safety remains strict enough that RGB Aura cannot silently control an unintended header/device.
  • Tests cover renamed zones, missing optional devices, and reconnect/re-enumeration behavior.
  • Documentation is updated with the OpenRGB compatibility and mapping behavior.
## OpenRGB 1.0 compatibility and resilient device/zone discovery ### Background RGB Aura currently depends on OpenRGB device and zone names matching the configured mapping exactly. After upgrading Nobara's OpenRGB package to: `openrgb-1.0-1.20260917git83ea112.fc44.x86_64` RGB Aura began repeatedly failing at startup. The immediate validation error is: ```text Mapping validation failed: Zone name mismatch for top_fractal_fans. Device: ASUS ROG STRIX B650E-E GAMING WIFI Zone index: 1 Expected zone name: Aura Addressable 1 Detected zone name: Addressable RGB Header 1 ``` OpenRGB 1.0 appears to have renamed at least this motherboard zone: ```text Aura Addressable 1 ``` to: ```text Addressable RGB Header 1 ``` Because mapping validation is currently strict, RGB Aura exits with status 2 and systemd repeatedly attempts to restart it. There is also an older intermittent problem where the NVIDIA GPU is not always detected/available correctly by OpenRGB during startup, causing RGB Aura not to apply the configured effects to the graphics card. During investigation of the OpenRGB 1.0 upgrade, OpenRGB itself was also observed segfaulting while servicing an SDK client request in: ```text NetworkServer::SendReply_PluginList() ``` Therefore RGB Aura should be made more tolerant of OpenRGB version changes and temporary device-discovery failures. ## Goals Improve RGB Aura so that a renamed, temporarily unavailable, or optional RGB device/zone does not unnecessarily prevent the entire lighting controller from operating. ### 1. Review OpenRGB 1.0 / SDK v6 compatibility Verify the installed `openrgb-python` version and RGB Aura's OpenRGB client code against OpenRGB 1.0 / SDK protocol v6. Check for API or protocol changes affecting: * device enumeration * zone enumeration * plugin enumeration * reconnect behavior * device IDs/indexes * zone names ### 2. Improve zone mapping resilience Avoid depending solely on an exact human-readable OpenRGB zone name. Possible approaches: * support multiple accepted aliases for a zone * use device + zone index as the primary identifier where reliable * allow expected-name aliases such as: ```text Aura Addressable 1 Addressable RGB Header 1 ``` * log renamed zones clearly rather than immediately aborting when the physical mapping can still be established safely The implementation must still protect against controlling the wrong physical RGB header. ### 3. Improve device discovery resilience A temporarily missing device should not necessarily terminate RGB Aura. In particular, investigate the intermittent NVIDIA GPU detection issue. Desired behavior could include: * retry device discovery for a configurable period * distinguish required devices from optional devices * continue controlling available devices when an optional device is unavailable * periodically retry unavailable devices * automatically begin controlling a device if it becomes available later * clearly log missing/recovered devices ### 4. Improve OpenRGB connection handling RGB Aura should handle an OpenRGB SDK server restart or temporary disconnect gracefully where possible. Consider: * reconnect attempts with bounded backoff * re-enumeration after reconnect * mapping re-validation after OpenRGB restarts * avoiding a rapid systemd restart loop for recoverable OpenRGB problems ### 5. Improve diagnostic logging On discovery/mapping failures, log enough information to diagnose OpenRGB changes easily: * OpenRGB version if available * SDK protocol version * complete detected device list * device names/types * zone indexes and names * expected mapping * unavailable devices * aliases used during successful matching ### Acceptance criteria * RGB Aura works with the current OpenRGB 1.0 package. * `top_fractal_fans` maps correctly despite the OpenRGB zone rename. * A missing optional GPU does not prevent motherboard/fan RGB control. * Temporary OpenRGB/device discovery failures do not cause an uncontrolled rapid restart loop. * RGB Aura can recover from a device becoming available after startup where practical. * Mapping safety remains strict enough that RGB Aura cannot silently control an unintended header/device. * Tests cover renamed zones, missing optional devices, and reconnect/re-enumeration behavior. * Documentation is updated with the OpenRGB compatibility and mapping behavior.
JackFrostbyte commented 2026-09-21 01:16:42 -04:00
Author
Owner
Copy link

Resolved by PR #98.

OpenRGB 1.0 compatibility and device-discovery resilience have been implemented and hardware-tested.

The fix includes:

  • exact aliases for renamed OpenRGB 1.0 motherboard zones;
  • optional/recoverable RTX 5080 handling;
  • periodic validated refresh for missing optional devices;
  • stable NVIDIA I2C enumeration before OpenRGB startup;
  • avoidance of the unstable OpenRGB plugin-list SDK request;
  • systemd-based OpenRGB/RGB Aura process recovery;
  • strict mapping revalidation after recovery;
  • automatic restoration of the RTX 5080 to OpenRGB Direct mode when required for per-LED control;
  • updated tests and documentation.

A forced OpenRGB process failure recovered successfully through systemd, and the GPU Rainbow → Direct recovery path was independently reproduced and validated on the real hardware.

Closing as completed.

Resolved by PR #98. OpenRGB 1.0 compatibility and device-discovery resilience have been implemented and hardware-tested. The fix includes: * exact aliases for renamed OpenRGB 1.0 motherboard zones; * optional/recoverable RTX 5080 handling; * periodic validated refresh for missing optional devices; * stable NVIDIA I2C enumeration before OpenRGB startup; * avoidance of the unstable OpenRGB plugin-list SDK request; * systemd-based OpenRGB/RGB Aura process recovery; * strict mapping revalidation after recovery; * automatic restoration of the RTX 5080 to OpenRGB `Direct` mode when required for per-LED control; * updated tests and documentation. A forced OpenRGB process failure recovered successfully through systemd, and the GPU `Rainbow` → `Direct` recovery path was independently reproduced and validated on the real hardware. Closing as completed.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
develop
docs/issue-72-animation-pack-architecture
v1.0.1
v1.0
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
JackFrostbyte/rgb-aura#97
No description provided.