Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Firmware constantly freezing #3912

Open
1 task done
SergioLuxx opened this issue Apr 17, 2024 · 2 comments
Open
1 task done

Firmware constantly freezing #3912

SergioLuxx opened this issue Apr 17, 2024 · 2 comments

Comments

@SergioLuxx
Copy link

SergioLuxx commented Apr 17, 2024

What happened?

All versions after 0.13.3 hang the board tightly until the power is completely lost.
I use python code that sends commands to the lamp via websockets about changing the mode and its parameters, which are selected randomly. Sending occurs at a random time from the list, every [0.2, 0.3, 0.4, 0.5, 1.0] seconds.
I am seriously upset because I am forced to sit on the stable working 0.13.3, which handles such a load absolutely correctly. Every time you release a new version, I install it to check, with the hope that everything will finally work, but no! My lamp starts to freeze constantly after 5 - 10 seconds of running the code to change modes. The LEDs either turn off completely and the board no longer responds to anything, there is not even ping, because it is disconnected from wifi, or random LEDs light up and continue to light, still showing no signs of life. After de-energizing, the lamp works again for 5 - 10 seconds and freezes again.
And constant websocket requests (0.5) seconds json.loads(ws.recv())["state"]["on"] to check the current state of the lamp do not work at all. Again, unlike version 0.13.3. On all versions after - empty lines or False are returned. when the lamp actually works.
Please fix this already.
Controller used - ESP32
https://youtube.com/shorts/7GvTXqnoz9k?feature=share python waits for the lamp to appear on the network, after which it starts sending commands - an instant freeze occurs.
https://youtube.com/shorts/BL8JGxSuO_I?feature=share complete freeze after a short time of operation.
https://youtube.com/shorts/8ri8UbO42uM?feature=share automatic reboot, after a short time of operation, after which it completely freezes.
https://youtube.com/shorts/1mHL42oSASI?feature=share works absolutely correctly on version 0.13.3. On this firmware the lamp can work without interruption.

To Reproduce Bug

Randomly select the palette number and its characteristics, send these changes via websockets to the lamp with a random delay of [0.2, 0.3, 0.4, 0.5, 1.0] seconds.
Request the lamp for its current state via an active websocket connection every 0.5 seconds.

Expected Behavior

Correct operation with quick mode changes, as in version 0.13.3. Transmitting correct readings upon request json.loads(ws.recv())["state"]["on"], as in version 0.13.3.

Install Method

Binary from WLED.me

What version of WLED?

0.14.3

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
@SergioLuxx SergioLuxx added the bug label Apr 17, 2024
@SergioLuxx SergioLuxx changed the title Постоянное зависание прошивки Firmware constantly freezing Apr 17, 2024
@softhack007
Copy link
Collaborator

softhack007 commented May 1, 2024

Hi, why would you want to change effects ~5 times per second? Are your eyes even fast enough to recognise the running effect? If you want something like a strobe, we have dedicated effects for this. Also palette blending is now a feature in WLED, so it's not necessary to send 5 palettes per second to WLED.

@blazoncek
Copy link
Collaborator

That's not a bug but technical limitation of a microcontroller which cannot process as many requests in such a short amount of time given all the other tasks it has to perform.
I agree that this could be mitigated but that the task for a library WLED uses, not WLED itself.

Please provide a debug output and possible crash dump using exception decoder.

If you are unsatisfied then, please, stick with 0.13 which has a bit less to do unfortunately.

@blazoncek blazoncek removed the bug label May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants