[Design] Modular Event-Driven Alert and Notification System #99
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Objective
Design a modular, event-driven alert and notification system for RGB Aura that allows external applications, scripts and system services to trigger temporary RGB effects.
The system should integrate with RGB Aura's existing animation engine and OpenRGB infrastructure without interfering with normal operation.
This issue covers the architecture, technical specifications, configuration design and implementation planning. Actual implementation will be divided into separate issues under a dedicated milestone.
1. Background and motivation
RGB Aura currently focuses on controlling RGB devices through predefined configurations and animations.
An event-driven notification system would extend its functionality by allowing external events to temporarily modify RGB output, turning existing RGB hardware into a visual notification system.
Initial use cases include:
The design must remain application-agnostic. RGB Aura should not contain application-specific notification detection logic.
Instead, external integrations should submit standardized events through a documented interface.
2. Proposed architecture
The system should consist of three independent layers.
A. Event sources
External integrations are responsible for detecting events and determining whether an alert should be generated.
Examples include:
Event sources should communicate through a standardized local interface.
Event detection and application-specific filtering must remain outside the core RGB Aura animation engine.
B. Alert Manager
Introduce a dedicated component responsible for receiving, validating, prioritizing and managing alert requests.
Responsibilities should include:
The Alert Manager must remain independent of individual event sources.
C. Animation integration
The existing RGB Aura animation engine should remain responsible for communicating with OpenRGB and controlling devices.
The Alert Manager should request temporary visual overrides through a controlled internal interface.
Independent modules should not compete for direct control of OpenRGB devices.
Normal animations must resume automatically when alerts expire.
3. Design requirements
3.1 Event interface
Evaluate possible communication mechanisms, including:
The preferred solution should be secure, simple to maintain, suitable for a systemd user service and easily accessible from Python and shell scripts.
The initial design should not require a network-accessible API.
Define a standardized event schema that can support:
Document input validation, authorization and any limitations.
3.2 Alert configuration
Design a configuration format that allows users to define reusable notification profiles.
Consider supporting:
Determine which parameters should be configurable globally and which should be defined per alert.
Reuse existing RGB Aura configuration conventions wherever practical.
3.3 Priority and concurrent alerts
Define deterministic rules for handling multiple simultaneous alerts.
Questions to resolve:
The initial implementation should favour predictable behaviour over unnecessary complexity.
3.4 Animation interruption and restoration
Design a mechanism that allows temporary alerts to override normal RGB output without disrupting the existing animation engine.
Requirements:
Special attention should be given to maintaining compatibility with existing RGB Aura device discovery and OpenRGB resilience mechanisms.
3.5 Device and zone targeting
Investigate how notifications should target RGB hardware.
Potential capabilities:
The design should leverage existing RGB Aura device mappings and avoid duplicating device-discovery functionality.
3.6 Reliability and resource management
The notification system should be lightweight and suitable for continuous background operation.
Consider:
The notification system must not compromise normal RGB Aura operation when no alerts are active.
3.7 Security
Define an appropriate trust boundary for external integrations.
Requirements should include:
Evaluate whether external applications should trigger only predefined alert profiles rather than submitting arbitrary animation instructions.
4. Reference integration: EVE Online fleet notifications
Use EVE Online as the initial reference scenario to validate the proposed architecture.
Expected behaviour:
This integration is intended as a proof of concept and should eventually have its own implementation issue.
Its application-specific detection logic must remain outside the RGB Aura core.
5. Proposed implementation phases
The design should produce a set of implementation issues grouped under a dedicated milestone.
Phase 1 — Notification infrastructure
Phase 2 — Configuration and advanced alert management
Phase 3 — Integrations and validation
The precise issue breakdown and implementation order should be established during the design process.
6. Expected deliverables
This design issue should produce:
7. Acceptance criteria
This issue can be closed when:
Out of scope: Implementing the Alert Manager, developing event-source integrations or changing the existing animation engine as part of this design issue.