Aircoookie
Dynamic UI for LED settings
The BusManager supplies the list of LED Types
Once a type has been selected then config requirements are returned for this type.
This needs to cater for this like which pins are needed, colour order etc
For each required value the following are required
- Label - e.g Data Pin
- Type - pin / numeric / option
- Type info - min/max for numeric, key-value for options
- config key - where to save this value
Note: This enhancement may be part of (or prequel to) Settings rewrite which "is supposed to read all information from cfg.json file". As cfg.json does not contain any field descriptions (apart from key names) or limits or "lists" this may need to be delegated to the firmware in the form of current xml.cpp constructs (injected JavaScript) or similar.
To allow educated UI the following must also be provided for particular LED type:
- has RGB
- has White
- has CCT
- bit depth and buffer use (for memory calculations)
- name and number of "pin" fields with their min/max values or possible "lists" of key-value pairs
- uses GPIO or not
- what type of interface/driver does it need (RMT, I2S, UDP, I2C, LEDC, etc) (limit selection when HW is exhausted)
- etc/tbd
If it is to be done by UI then UI needs to be informed of HW limitations and capabilities. Difficult. If it is to be performed by firmware then there should be a HTTP endpoint within firmware to provide those calculations. UI would need to "consult" firmware (most likely using XHR) on each change and not do that too quickly to not overwhelm the CPU. I do not know which is better. The second would be more accurate IMO except if the first would get every detail.
If the goal is that we can change/add what output options are added without needing to add LED type specific code to the UI, then it has to be on the backend that these details are calculated.
That might be taking that requirement too strongly/literally however?
The request payload and response should be very small so really shouldn't be an issue. If we do see issues than that's really an indication of bigger issues with the webserver that needs attention
The request payload and response should be very small so really shouldn't be an issue. If we do see issues than that's really an indication of bigger issues with the webserver that needs attention
You are welcome to join @willmmiles 's efforts in making AWS better. 😄
Back to topic, I am starting to see issues with compile-time selections of possible bus types and their capabilities.
But changing that may require rethinking entire bus logic I am not willing to take. Your PR may be a step in the right direction but will stil require profoud changes in BusManager to be fully run-time configurable.