Various usability problems in the LEDs settings page - Type not changeable, GPIO, Length and mA/LED settings sometimes lost upon save

[Fonzi03]

What happened?

After saving, only ports 1-3 applied properly. Ports 4-8 (in my instance) changed from the following settings:
mA/LED: 55mA (default setting)
Data GPIO:

changed to:
mA/LED: Custom
Data GPIO: 0

To Reproduce Bug

WT32-ETH01
(installed ethernet version)

flash a new board, apply wifi settings.
navigate to settings --> Usermods
Under Digitalmic:
Change Pin I2S WS to unused from default
Change Pin I2S SCK to unused from default
Save
navigate to settings --> LED Preferences
Add 8 strings ( I used sk6812 )
Each string set to Length: 1

GPIO in order of ports 1-8 :
2, 4, 12, 14, 15, 17, 5, 33

Save

Go back to LED Preferences and the mA/LED, Length (sometimes only some ports are affect not all, never 1-3), and Data GPIO ports are not as they were set previously.

Removing the strings and re-adding them saving again seems to have a similar issue where mA/LED clears but GPIO assignments stay.

Change the incorrect mA/LED from custom back to the default 55mA
Save

Now settings remain

Start changing the length of strings
1: 145
Save

2: 283
Save

3: 55
Save
Crash

Rebooting board does nothing.
The only recovery option at this point is to re-flash

This is repeatable. (except sometimes the GPIO stays and sometimes does not, every time it loses the GPIO it only loses them after port 3)

I first started with putting the appropriate pixels and strings in order then save but to test for reporting the bug I did them individually and only 1 pixel each.

This renders the software/ board unusable for me as I cannot get it set to the strings that I need it consistently locks up the board.

This does not occur in 14.4 (however applying the above settings, then selecting the Ethernet type in 14.4 it goes into the same bricked state)

Expected Behavior

I can set all pixel settings without issues.

Install Method

Binary from WLED.me

What version of WLED?

0.15.0-b7

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

No response

Code of Conduct

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

[k7bbr]

I compiled 0.15.0-b7 for Ethernet and tried it on a WT32 board. Same result. When changing to other protocols like SK6812 or TM1814 the WT32 module won't save. Did try a Factory reset after setting pixel type as SK6812 and Ethernet connection was completely gone. Had to re-install 0.14.4 binary back to the device and things worked. When I updated back to 0.15.0-b7 networking was totally gone again. The WT32 device has no Ethernet or WLED-AP access point. Connected pixels are illuminated, but networking is gone. Flash again to 0.14.4 Ethernet and wifi work again. Can get Ethernet to work on initial installation of 0.15.0-b7, but once the attempt to change pixel type has been made, can't ever get Ethernet back even after flashing down to 0.14.4 and back up. Another note: Is it supposed to be the behavior of the LED Preferences page now that you can only change the pixel type of the last item in the list of LED outputs? The only one that can be changed in a list of more than 1 output is the last one. If you want to change all the outputs or some of them, you have to remove outputs and then add them back in.

…

On Wed, Nov 13, 2024 at 11:47 PM Fonzi03 ***@***.***> wrote: What happened? After saving, only ports 1-3 applied properly. Ports 4-8 (in my instance) changed from the following settings: mA/LED: 55mA (default setting) Data GPIO: changed to: mA/LED: Custom Data GPIO: 0 To Reproduce Bug WT32-ETH01 (installed ethernet version) flash a new board, apply wifi settings. navigate to settings --> Usermods Under Digitalmic: Change Pin I2S WS to unused from default Change Pin I2S SCK to unused from default Save navigate to settings --> LED Preferences Add 8 strings ( I used sk6812 ) Each string set to Length: 1 GPIO in order of ports 1-8 : 2, 4, 12, 14, 15, 17, 5, 33 Save Go back to LED Preferences and the mA/LED, Length (sometimes only some ports are affect not all, never 1-3), and Data GPIO ports are not as they were set previously. Removing the strings and re-adding them saving again seems to have a similar issue where mA/LED clears but GPIO assignments stay. Change the incorrect mA/LED from custom back to the default 55mA Save Now settings remain Start changing the length of strings 1: 145 Save 2: 283 Save 3: 55 Save Crash Rebooting board does nothing. The only recovery option at this point is to re-flash This is repeatable. (except sometimes the GPIO stays and sometimes does not, every time it loses the GPIO it only loses them after port 3) I first started with putting the appropriate pixels and strings in order then save but to test for reporting the bug I did them individually and only 1 pixel each. This renders the software/ board unusable for me as I cannot get it set to the strings that I need it consistently locks up the board. This does not occur in 14.4 (however applying the above settings, then selecting the Ethernet type in 14.4 it goes into the same bricked state) Expected Behavior I can set all pixel settings without issues. Install Method Binary from WLED.me What version of WLED? 0.15.0-b7 Which microcontroller/board are you seeing the problem on? ESP32 Relevant log/trace output *No response* Anything else? *No response* Code of Conduct - I agree to follow this project's Code of Conduct — Reply to this email directly, view it on GitHub <#4280>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AGGPSXEQY3D4IRUEUV7JYGT2ARBRTAVCNFSM6AAAAABRYFA5IGVHI2DSMVQWIX3LMV43ASLTON2WKOZSGY2TONZYG44DQNI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[softhack007]

As this affects usability of the LEDs settings page, it would be good to understand what's going on before 0.15.0-RC1 #4287

[softhack007]

Another note: Is it supposed to be the behavior of the LED Preferences page now that you can only change the pixel type of the last item in the list of LED outputs?

I can confirm this part of the problem description - only the last output type can be modified, all others are grayed out.
wled_cfg1.json

[softhack007]

GPIO in order of ports 1-8 : 2, 4, 12, 14, 15, 17, 5, 33
Save
Start changing the length of strings
1: 145 Save
2: 283 Save
3: 55 Save Crash

I could not reproduce the crash any more - most likely it was fixed with #4312, #4327, or #4321

[softhack007]

Can get Ethernet to work on initial installation of 0.15.0-b7

• This needs to verified by someone wo has the WT32-ETH board - might be related to a pin conflict, because many pins broken out on the WT32-ETH are actually not usable.

[softhack007]

GPIO in order of ports 1-8 : 2, 4, 12, 14, 15, 17, 5, 33
Save

Go back to LED Preferences and the mA/LED, Length (sometimes only some ports are affected but not all, never 1-3), and Data GPIO ports are not as they were set previously.

I can reproduce the behaviour with this simple cfg.json
wled_cfg2.json

• enter LEDs settings
• add two additional outputs, save
• re-enter LEDs settings
• --> last output ABL is reset to 0

Before Save:

When re-opening the page:

Note: I did not test if adding 3, 4, or 5 outputs also leaves the last 2,3, or 4 ABL values as custom/0, but this is very likely.

[softhack007]

To other maintainers:
I think the problems that are still reproducible are annoying but not blocking.

We could list them as "know problems" in the 0.15.0-RC1 release notes and take the time to find a fix later.

[willmmiles]

Thanks for making a clear reproducing case. Smells to me like a bug in the settings JSON response - if you can, can you quickly check that the response looks sane?

[softhack007]

Thanks for making a clear reproducing case. Smells to me like a bug in the settings JSON response - if you can, can you quickly check that the response looks sane?

I can try that tomorrow - actually i need to use MSEdge dev tools, right? Or is there a place where DEBUG_PRINTF still works, to dump out the response string?

[willmmiles]

I usually use my browser's dev panel, yes. For non-websocket requests like this, you can curl or wget at the command line too.

[softhack007]

Smells to me like a bug in the settings JSON response - if you can, can you quickly check that the response looks sane?

I've checked the "settingsScript" part s.js?p=2 looks meaningful and not truncated.

[willmmiles]

Yup. Looks like the problem is with the POST - the form data is empty for the 'LA3' and 'LA4' fields, we just get 'LAsel3' and 'LAsel4', so the value read back is 0. I think something is going wrong with the initialization of some of the hidden fields.