hyperion.ng
hyperion.ng copied to clipboard
UI Optimization - Creating new LED-Instances
Feature request
As a user, I would like to be guided through the set-up of a new LED-instance that way that I am presented valid configuration options rather that I define them myself.
What problem does this feature solve?
Presenting valid configuration elements to a user will mitigate the risk of misconfiguration and not working setups. In addition, the user is presented with platform specific elements rather than default values deemed for another platform. e.g. serial ports are named differently between Linux and Windows based platforms.
What does the proposed API look like?
N/A
How should this be implemented in your opinion?
Envisioned sequence of activities:
- User selects to create new LED-instance (Clicks "Big +")
- Select LED-device type (e.g. WLED, Philips Hue, APA102,...)
- Select LED-device Sub-type/model (e.g. Philips Hue vs. Entertain, Cololight Pro vs. Stripe)
- Configure Security Details (e.g. Tokens, Client-IDs, etc.)
- Get Device Properties (e.g #Hardware-LEDs, available device ports [COM1,COM6])
- Allow to test/identify the device, (if provided by device)
- Capture/Refine #Hardware-LEDs, if not automatically resolved
- Configure Color Order (BGR, RGB,...)
- Allow to configure device specifics, e.g. a. Baud Rate b. ... c. Latch Time d. Rewrite Time
- Define the layout considering that #LEDs must not exceed ‘HardwareLEDs”, options a. Simple Layout, map device to predefined areas (like for Hue, Yeelight) b. Layout Wizard, as per today c. Layout Wizard, free drawing
- Propose an instance name for the setup (e.g. Type.Subtype.#), allow to overwrite naming
- Save instance incl. layout under given name
- Start instance
To find devices, get device properties or identify them, existing JS-functions interacting with the hyperion backend can be leveraged.