Reboot instead of restricting LED-type change with multiple buses

[DedeHai]

When adding more than one bus in LED settings, editing the type is only possible for the last bus.
This is to ensure proper hardware initialisation.
However, this is confusing to users and should be handled differently. Instead of restricting it in the settings, a variable should be added to the LED settings page that keeps track of the problematic changes i.e. the bus type and if necessary, display a warning and issue a reboot.
@willmmiles do you know which settings or combinations are critical in this regard?

[willmmiles]

Honestly I don't know why the restriction was originally implemented, beyond noting that I'm aware that construction order can matter so it isn't possible in the general case to modify bus settings in place without (at the very least) destroying them all and reconstructing. And reallocating bus resources can in turn be problematic if the system RAM is fragmented as it can be tough to make large allocations, leading to failed Bus objects and probable crashes as those "unhappy" states are less well tested. A good example is the trouble with long strips on ESP8266 -- it can work OK after a reboot, but gets dicey if the settings are changed mid-run as the new LED buffer might fragment available RAM such that segment/pixel buffers are harder to allocate.

Similarly, driver cleanup is probably just less well tested. I don't know of any specific issues offhand, but then the UI change was a response to problems that came from before I started working on the project. There might be some tracks in the issue board or forums.

[DedeHai]

@blazoncek can you explain on why this restriction was needed?

[blazoncek]

To correctly account available buses.

A workaround would be to add drag & drop bus reordering funcionality of buses in settings. That would allow user to re-arrange buses without needing to delete them.

Unfortunately that was beyond my HTML/JS expertise.

[DedeHai]

To correctly account available buses.

I dont quite follow. which function are you referring to that causes trouble if the bus settings are changed? I think adding DnD reordering is overkill. I think either reconstructing all buses (if that is not done already) or even a reboot are better options than restricting the UI.

[blazoncek]

DnD is not an overkill and since it is UI based only I deem it shouldn't be too difficult to implement.
I have a rough idea but lack experience in JS/HTML for that.

I dont quite follow.

I.e. for C3, Add/select one-pin digital, add/create an analog output, then add/create one-pin digital. All is well. Then change the analog to one-pin digital. What now? You have 3 digital that cannot be accommodated using C3. But which one to remove? Same thing goes with GPIO (easier to resolve though).

However, I'm not willing to exert effort to modify the code, so it is up to you if you wish to change it.

[DedeHai]

I see, so its about the UI not respecting limits and not about bus manager functions. I will check if there is a solution other than restricting all but the last.
regarding DnD: I did ask claude.ai about that last week but for segment reordering. what it came up with did basically work but was still wonky after a few iterations so I abandoned it. Used about 2k of flash too.

[blazoncek]

Segment reordering is tied to memory structure within ESP. IDK if it can be done, but if you can reorder vector elements then it is a piece of cake.

[DedeHai]

ah sorry, I wrote that in a hurry and mixed it up. Not segment but preset reordering.

[blazoncek]

Preset reordering is a bit tougher but could be done using DnD and sorting by ID rather than name.
It would require re-saving preset with different ID and then removing previous ID. A risky operation if preset corruption is still present.

[blazoncek]

DnD-output.mov

[DedeHai]

#5014 properly fixes this.