Partial web interface

[dherkes]

When I compile and upload the sketch and Wi-Fi setting (either /dev/ttyUSB, or OTA), the main screen of the web server does not show as much detail as it once did. For example, the sliders are missing, as are the drop-down menus allowing the choices of lighting routines. I have attached a screenshot. In the simple sketch page, the on/off button no longer works, and the changes do not persist after a reboot. I also have to report that when I compile using PlatformIO, the file system is not pushed to the MCU. I must say, PlatformIO is easy to operate!

Thank you for all of your hard wok.

[tobi01001]

Hi,

when using platform.io, there is the option to build and upload the filesystem in the platformio menu (in VS code on the left).

For the other problem: at first, you should maje sure that you upload the current file system (build fs / upload fs). Further, the bootstrap and css stuff for the web app is loaded from the internet and will only work if your MCU has access to internet. If it does not have internet access - and you don't want it to have - , you could change the index.html to load the data from the filesystem: https://github.com/jasoncoon/esp8266-fastled-webserver/blob/6f1b74809071df863c3ef591b0a48805cd621843/esp8266-fastled-webserver/data/index.htm#L428-L440

https://github.com/jasoncoon/esp8266-fastled-webserver/blob/6f1b74809071df863c3ef591b0a48805cd621843/esp8266-fastled-webserver/data/index.htm#L10-L17

But at first you should ensure that both LittleFs Filesystem and sketch have been uploaded correctly.

Hope this helps...

[dherkes]

Hi,

Thanks so much. I run my iOT devices on a private network, due to a nosey neighbor (apparently) I edited index.htm, and now it works like a charm. Any chance you guys will be doing the same magic on esp32-webserver? I appreciate PlatformIO, very much.

[jasoncoon]

Glad to hear it! The goal is to get both ESP8266 & ESP32 working with the same code.

[tobi01001]

I am not that web / js / css expert, but could we possibly change the html files to have the files on the ESP as fallback in case the server cannot be reached? something like this maybe?

[jasoncoon]

Yeah, we could use something like this: https://stackoverflow.com/a/30547720

[dherkes]

So pop an error message, and fallback to the built-in web server HTML and CSS?

[jasoncoon]

I spent some time working on this, and I cannot get the latest changes in master to serve static files with the correct Content-Type header. It always returns application/octet-stream, regardless of file type. This seems to result in the browser not applying the stylesheets to the page. It does not seem to affect the loading of the js files.

I'm not even trying anything fancy with fallback, just have the link elements in index.htm file set to return the local CSS files: https://github.com/jasoncoon/esp8266-fastled-webserver/blob/main/esp8266-fastled-webserver/data/index.htm#L10-L16

I've tried searching around, but not finding much. serveStatic should be setting the Content-Type header to the correct type based on the file extension. I've tried it with the files in their respective directories in LittleFS (js, css, etc), and with all of the files at the root.

@henrygab or anyone else have any ideas? This seemed to work at least before the switch from SPIFFS to LittleFS.

[jasoncoon]

I've confirmed that using the ESP8266 Arduino core version 3.0.2 fixes the Content-Type problem, although it results in flickering in the first pixel. I have not yet tried other versions, newer than 2.7.0, but older than the latest 3.0.2.

Also note that I had to use Arduino to compile and upload using the 3.0.2 core. I could not get it to build using PlatformIO. I got a variety of errors while trying different changes to platformio.ini.

[dherkes]

Agreed, PlatformIO won't compile the files. Too bad, but I'm sure this will get worked out. My “thing” is now flickering on all six of the first pixel strings. Instead of the sliders, I'm getting a text box and pull down menu (no CSS loaded), and I have to reload the page after any changes.

[henrygab]

I've had visitors the past few days, and thus haven't had much time to code.

Two things:

v3 Core

Is the v3 core the one where Espressif moved to using C++17, the std library, and throwing exceptions?

If so, there's a number of subtle changes that come along with that, and thus I would not moving to them without significant investigation, review, and testing.

Ideas on serveStatic()

1. Does it work in default (v2) core, if the files are stored in the root?

2. Is all files both created and fully populated with data, before calling .serveStatic()?

   If not, that's a problem, as the class caches some information when adding static content.

Next steps

Debug! There's a neat extension to enable simple debugging over USB, even on ESP8266.

See https://arduino-esp8266.readthedocs.io/en/latest/gdb.html.

Yes, its' as simple as including a header, and then adding one line in setup(). Dig in, find out why, and then we can fix it.

[jasoncoon]

@dherkes I only get the flickering on the first pixel of each string (reproduced on the one first pixel on F256 and all five first pixels on F1024) when I upload using Arduino and have the latest ESP8266 board installed. If you're using Arduino, go to the boards manager and install version 2.7.4. If you're using PlatformIO, then I'm not sure.

@henrygab no problem! Yes, it looks like the latest version does use C++17. There is an option in the Arduino Tools menu to disable exceptions.

1. Yes, I tried moving all of the files to the root, but the same problem (incorrect Content-Type header) persisted.
2. I'm not sure how the files would not be created and fully populated, they're static and uploaded using PlatformIO.

I'll keep digging.

[tobi01001]

Did you try this?

https://github.com/jasoncoon/esp8266-fastled-webserver/pull/209#issuecomment-938374596

Cannot test right now but could maybe check later today...

EDIT: Nevermind. the Solution is below. No need to switch to the >= V3 core right now...

[tobi01001]

@dherkes I only get the flickering on the first pixel of each string (reproduced on the one first pixel on F256 and all five first pixels on F1024) when I upload using Arduino and have the latest ESP8266 board installed. If you're using Arduino, go to the boards manager and install version 2.7.4. If you're using PlatformIO, then I'm not sure.

@henrygab no problem! Yes, it looks like the latest version does use C++17. There is an option in the Arduino Tools menu to disable exceptions.

1. Yes, I tried moving all of the files to the root, but the same problem (incorrect Content-Type header) persisted.
2. I'm not sure how the files would not be created and fully populated, they're static and uploaded using PlatformIO.

I'll keep digging.

Few things identified, see #240 for proposals for corrections.

The main problem for the contentType and stream response is that someone set MIMETYPE_MINIMAL in platformio.ini (no offense ;-) ). This limits the abilities of the Webserver to detect the content type.

[henrygab]

@henrygab no problem! Yes, it looks like the latest version does use C++17. There is an option in the Arduino Tools menu to disable exceptions.

Yes, I recall that option to disable exceptions existed in earlier versions ... it's fairly important for some libraries that expect new to return null (rather than throw).

IIRC, when IDF was moving to C++17, that option to disable exceptions was removed. That was obviously an obstacle ... even if the exceptions could be disabled via a hack, there was a significant risk that the system code was relying upon the ability to catch exceptions (vs. checking return-value), and thus lose the ability to gracefully fail in legacy code.

Maybe this is no longer an issue? Maybe they enabled C++17 without requiring exception handling in all client code? I honestly don't know... but I figure it's better to raise a warning flag early, even if wrong, rather than have major work start only to later discover compatibility bugs for existing Arduino libraries (or at least the ones used in the project).