search

Aircoookie / WLED

Control WS2812B and many more types of digital RGB LEDs with an ESP8266 or ESP32 over WiFi!
https://kno.wled.ge
MIT License
14.2k stars 3.03k forks source link

Swap webserver to PsychicHttp #3724

Open netmindz opened 5 months ago

netmindz commented 5 months ago

While WLED uses a patched version of the ESPAysncWebserver, there are so many issues with performance and stability that relate to the webserver

If this library lives up to it's claims of delivering much better performance, reduces chance of crashing and has similar API, then it's worth investigating

ArduinoMongoose could be another alternative, but it's API is quite different to the existing library

https://github.com/hoeken/PsychicHttp

blazoncek commented 5 months ago

Difficult as WLED still supports ESP8266 and this seems to only support ESP32. Also lack of PROGMEM support may be an issue as everything from WLED UI is stored in PROGMEM ATM.

netmindz commented 5 months ago

I think 8266 support should really be ended. It was never intended to be used as a general purpose MCU, so while it's amazing what you can do "by accident" to hold back development just to maintain support for a platform that was never meant to exist seems wrong.

I don't know enough about PROGMEM to comment on why this is used current and what the impact of the lack of support for it would mean

netmindz commented 5 months ago

I've started having a quick hack about to try and judge how hard the migration would be https://github.com/Aircoookie/WLED/pull/3726

willmmiles commented 5 months ago

I think 8266 support should really be ended. It was never intended to be used as a general purpose MCU, so while it's amazing what you can do "by accident" to hold back development just to maintain support for a platform that was never meant to exist seems wrong.

To me, telling people to throw out their existing hardware and buy new boards because some software developer can't be bothered to do the legwork also seems wrong. ;)

I'm a couple issues away, but doing something about the web server is on my hit list - ESPAysncWebserver, while clever, seems to have no capability to limit its resource consumption and responds to failure by, well, crashing. I had been planning on sketching a queuing mechanism to put some bounds on it, but replacing the server code outright might be just as effective.

FWIW, the PsychicHttp dev has gone on record as being willing to accept ESP8266 patches. PsychicHttp is built on some HTTP server code from the ESP-IDF; it looks like there's some version of it available for ESP8266, in some kind of zombie support state. I'll do some investigation on how easy that code is to get at; I'm still finding my way tracking through the various platform support layers and development repos.

I don't know enough about PROGMEM to comment on why this is used current and what the impact of the lack of support for it would mean

The web pages, js files, etc. used in WLED are embedded as arrays in the firmware binary. Some micros (such as the ESP8266) require different CPU instructions to read constants or data from out of the firmware (aka "PROGMEM", since it's where the program code lies) than from regular data RAM. The trick is usually recognizing a special type (_FlashStringHelper* IIRC) and invoking special memcpy_P calls or the like to copy the data in to the output buffers instead of regular memcpy. Adding support for this to something like PsychicHttp would likely be very straightforward.

TL;DR: @netmindz: if you want to sketch a WLED branch with PsychicHttp, I'd be happy to take a shot at getting it to work with ESP8266s.

netmindz commented 5 months ago

It's not a lazy choice, it's a practical issue of lack of support as it was never intended to be used in the way.

As for throwing stuff away, you can now get esp32 boards for a couple of dollars and they would only need to do that if they wanted to upgrade to new software. In almost all software development minimum hardware specs go up over time

Maintaining two different implementations for different platforms comes at quite a significant development cost.

It's possible that replacing the hot garbage that is the current webserver might give new life to the 8266 if you are able to help get this library to add support, but if you can't, then having a functioning webserver is more important to my eyes than supporting obsolete hardware indefinitely

blazoncek commented 5 months ago

I don't know enough about PROGMEM to comment on why this is used current and what the impact of the lack of support for it would mean

All WLED HTML files are converted into PROGMEM strings and served from there.

For ESP8266 I would not throw it out of the window just yet, though it struggles after 0.14. :D But I would not rule that out either.