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

Partial web interface #231

Open
dherkes opened this issue Dec 14, 2021 · 14 comments
Open

Partial web interface #231

dherkes opened this issue Dec 14, 2021 · 14 comments

Comments

@dherkes
Copy link

dherkes commented Dec 14, 2021

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.
webserver

@tobi01001
Copy link
Contributor

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).
image

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:

<!-- request js from internet CDN -->
<script src="https://code.jquery.com/jquery-3.1.1.min.js" integrity="sha256-hVVnYaiADRTO2PzUGmuLJr8BLUSjGIZsDYGmIJLv2b8=" crossorigin="anonymous"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery-minicolors/2.2.4/jquery.minicolors.min.js" integrity="sha256-XAFQ9dZ6hy8p/GRhU8h/8pMvM1etymiJLZW1CiHV3bQ=" crossorigin="anonymous"></script>
<!-- <script src="https://cdnjs.cloudflare.com/ajax/libs/reconnecting-websocket/1.0.0/reconnecting-websocket.min.js" integrity="sha256-A4JwlcDvqO4JXpvEtvWY1RH8JAEMu5W21wP8GUXLUNs=" crossorigin="anonymous"></script> -->
<script src="https://cdnjs.cloudflare.com/ajax/libs/FileSaver.js/2.0.2/FileSaver.min.js" integrity="sha512-k8F8QynmFNURwbUJC8drKA+fo3YfNvjqKzStdydD6au+MzvxBoRnxH8E31RJXwDY9DrnEiPhh9wBoDSIxhkyHQ==" crossorigin="anonymous"></script>
<!-- request js from the ESP8266 web server -->
<!-- <script src="js/jquery-3.1.1.min.js"></script> -->
<!-- <script src="js/bootstrap.min.js"></script> -->
<!-- <script src="js/minicolors.min.js"></script> -->
<!-- <script src="js/r-websocket.min.js"></script> -->
<!-- <script src="js/FileSaver.min.js"></script> -->

<!-- request CSS from internet CDN -->
<link rel="stylesheet" href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css" integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u" crossorigin="anonymous">
<link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/jquery-minicolors/2.2.4/jquery.minicolors.min.css" integrity="sha256-4wnSkPYU5B4yngAlx/rEb8LdfMah4teUth4AfhGEuaY=" crossorigin="anonymous" />
<!-- request CSS from the ESP8266 web server -->
<!-- <link rel="stylesheet" href="css/bootstrap.min.css"> -->
<!-- <link rel="stylesheet" href="css/minicolors.min.css"> -->

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

Hope this helps...

@dherkes
Copy link
Author

dherkes commented Dec 14, 2021

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
Copy link
Owner

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

@tobi01001
Copy link
Contributor

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
Copy link
Owner

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

@dherkes
Copy link
Author

dherkes commented Dec 17, 2021

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

@jasoncoon
Copy link
Owner

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
Copy link
Owner

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
Copy link
Author

dherkes commented Dec 20, 2021

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
Copy link
Collaborator

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
Copy link
Owner

@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
Copy link
Contributor

tobi01001 commented Dec 20, 2021

Did you try this?

#209 (comment)

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
Copy link
Contributor

tobi01001 commented Dec 20, 2021

@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.

tobi01001 added a commit to tobi01001/esp8266-fastled-webserver that referenced this issue Dec 20, 2021
At least the correct content type for the file being served static.
henrygab added a commit that referenced this issue Dec 21, 2021
Fixes Partial web interface  #231 when loaded from file system
@henrygab
Copy link
Collaborator

@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).

tobi01001 added a commit to tobi01001/esp8266-fastled-webserver that referenced this issue Jan 31, 2022
Script function to load css/js from the ESP when offline.
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

4 participants