Gledopto esp32 Ultra Mini WLED - Presets forget their custom color schemes

[PennyWafel]

What happened?

I just upgraded from WLED 15.4 on my Gledopto ESP32 Ultra mini to WLED 16.0. Afterwards, all presets with custom color schemes broke. Instead of displaying their custom color scheme, they defaulted back to the standard rainbow effect.

Presets I made with default color schemes were not affected. They function as expected. Only the presets which used custom schemes I created myself broke. They show default rainbow, instead of my own custom colors.

I was able to easily fix this by going through each preset and manually re-assigning the correct custom color schemes. However, I have half a dozen other gledopto's which I will for the time being keep on 15.x for now, because its rather time consuming ;)

To Reproduce Bug

1. have version 15.4 with presets that use custom color schemes (you might need a gledopto ultra mini esp32 if its device specific)
2. update to 16.0
3. see if presets with custom color schemes still have them or have defaulted to standard rainbow

Expected Behavior

Presets should remember their custom color schemes when updating

Install Method

Binary from WLED.me

What version of WLED?

16.0

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

Anything else?

Thanks for the great work you're all doing on this magnificent project.

Code of Conduct

• I agree to follow this project's Code of Conduct

[DedeHai]

this is a breaking change, you need to re-save your presets.

In 0.15.x the custom palettes served double-duty: both custom and audio-reactive palettes shared the same number range, so adding a custom palette shifted the AR palette numbers. This was the same up to 16.0 beta and with now more than 3 custom palettes and out-of-order deletion supported the issue got worse: delete one palette and all of them shifted, breaking all presets.
To solve this I added "placeholders" when deleting one and gave the audio-reactive palettes their own number space, custom palettes now start at 200 instead of 255. In hindsight it might be better to swap their number spaces to avoid this backwards incompatibility or add some auto-migration.

[softhack007]

@coderabbitai is this limitation already covered in #5542 ?

[coderabbitai]

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
gh issue view 5542 --repo wled/WLED --json title,body,labels,comments | jq '{title: .title, body: .body, labels: .labels, comments: .comments}'

Length of output: 272894

---

🏁 Script executed:

#!/bin/bash
gh issue view 5579 --repo wled/WLED --json title,body,labels,comments | jq '{title: .title, body: .body}'

Length of output: 1602

---

@softhack007 — based on my review of the current content of #5542, this specific breaking change is not yet covered there.

The existing #5542 comment only lists customPalettes moved to std::vector<CRGBPalette16> under the non-breaking "Other Notable Changes" section, which refers to the internal data structure refactor. It does not mention:

• The custom palette number space change (custom palettes now start at 200 instead of 255)
• The audio-reactive palettes getting their own separate number range
• The consequence that any preset referencing custom palettes by their old IDs will silently break (showing wrong/default palette) after upgrading — requiring a manual re-save

This would belong under the 💡 Effect / Preset Breaking Changes section of #5542, similar to the effect slot reuse entries. Would you like me to add it to the breaking changes list in #5542?

[softhack007]

@coderabbitai please suggest a concise addition - I prefer to add the text snippet manually.

[coderabbitai]

@softhack007 — here's a concise snippet you can paste into the 💡 Effect / Preset Breaking Changes section of #5542:

---

Custom palette index range changed

Custom palettes now occupy the number range starting at 200 (previously they started at 255, overlapping with audio-reactive palette numbers). Audio-reactive palettes now have their own dedicated number space. As a result, any saved preset that references a custom palette by its old index will silently use the wrong palette after upgrading. Action required: re-save all affected presets after the first boot on the new firmware.

Additionally, placeholder entries are now kept when a custom palette is deleted (instead of shifting all subsequent palette indices), which prevents further preset drift from mid-list deletions going forward.

---

Feel free to trim or adjust the wording to match the style of the rest of the issue.