Nothing rendered in Browser

[jamesonuk]

I have set this up on 1 D1 mini (https://smile.amazon.co.uk/AZDelivery-Development-ESP8266EX-Compatible-Micropython/dp/B08BTYHJM1/) as per https://antanaitis.lt/2022/09/07/wi-fi-on-your-lay-z-spa-make-it-easy-to-remote-control/

This seems to flash fine, I can connect and set the WiFi credentials but then things start to go awry

Straight after flashing and updating the WiFi details I can normally get to the home page and sometimes open up some of the child pages but at some point very quickly after that it just stops rendering

I have just gone in now (I flashed it this morning) and if I connect a serial monitor I see

HTTP > request: /
HTTP > file sent: /index.html (11023 bytes)
HTTP > request: /WebSocket.js
HTTP > file sent: /WebSocket.js (973 bytes)
HTTP > request: /main.css
HTTP > file sent: /main.css (988 bytes)
HTTP > request: /function.js
HTTP > file sent: /function.js (943 bytes)

so it looks like files are requests are getting through and files are being served..

I am seeing ERR_CONTENT_LENGTH_MISMATCH errors in the console for main.css and function.js but I am not certain this actually prevents them downloading?

Any thoughts on what this might be? I have tried in Chrome and Firefox and both show the same issue

[visualapproach]

I encountered that too while developing v4. From the error message, I guess it's when the ESP doesn't deliver the whole file, or maybe taking too long. If it's something that's changed in the browser, the ESP wifi libraries or memory shortage, I don't know. But it works again for me. I've had one occasion but I waited a while and retried and it worked.

[visualapproach]

[taferris]

How is your wifi connection? Take a look at the RSSI value on main page.

I see this type of issue occasionally on my setup. My RSSI is barely above the noise floor and so I have a very poor connection - worse with bad weather. I have been thinking about changing the web socket update from every 2 seconds to every 10 seconds, so that it has plenty of time for retransmits.

[jamesonuk]

As I am just testing it is sat pretty close to the router with an RSSI of -40 so if anything the signal might be too strong

[jamesonuk]

Hi, I ment what firmware version. 3.x or 4? V4 has date 2023-02-05-alpha

3.5.1

[jamesonuk]

Possibly unnrelated or a red herring but I did see a 404 for websoxket.js at one point (note it was looking for all lower case where as file name is in camel case. I had a quick look and couldn't see where this would have come from thiugh

[jamesonuk]

I had been playing around with a few things without much luck but I minified the CSS and function.js files and now it seems to work fine.
I have also renamed websockets.js to lowercase (and changed the references I found) but I think that is completely unrelated

[visualapproach]

This started happening both to v3.5 and v4 so there must be something that changed. Can someone try downgrading some libraries. Starting with
platform = espressif8266@~3.0.0 or even ~2.0.0
Thx

[visualapproach]

Ok good to know. I think there is not enough memory to send large messages. Just a hunch. I don't know if it's dram or sram(iram) but you could try adding a flag in platformio.ini that increases the iram to 48K. See how I did that in development branch. It's a shot in the dark though. Appreciate your help with testing

[jamesonuk]

I don't know enough about the web server implementation here but I do a lot with full size web servers at work and I can't see memory being the issue.

It should be sending the data in chunks but it seems as if the server is sending the response before it is ready and it is saying the file is smaller than it is and then you get the error.

Just looking now and the hwtest page is still problematic with the image showing the problem but the other pages are fine.

Going to do a bit more digging

[eried]

going the other way

platform = espressif8266@~4.1.0

however seems to currently be stable (but I had it all working nicely this morning after minimising the files and then it wen back later...)

This seems to have fixed my issue (with latest december release)

[jamesonuk]

Just a hunch. I don't know if it's dram or sram(iram) but you could try adding a flag in platformio.ini that increases the iram to 48K

added -DPIO_FRAMEWORK_ARDUINO_MMU_CACHE16_IRAM48 and still seeing the same as above. All working except for the images on the hwtest page which still show the ERR_CONTENT_LENGTH_MISMATCH error.

It is obviously related to file size and it is looking more likely that it is a feature of the ESP8266WebServer.
It has been a long time since I had to do any C++ at University and microcontroller stuff is all new to me but I came across a couple of links that might make sense to you....
https://www.esp8266.com/viewtopic.php?f=32&t=10189
https://www.esp8266.com/viewtopic.php?f=32&t=14267

There is also https://github.com/me-no-dev/ESPAsyncWebServer which is built on top of ESPAsyncTCP which you are already using

[visualapproach]

Yes, I've read those links and there are no real answer I think to other ppl with the same problem. The same code worked fine awhile ago so I think something has changed in either the 8266webserver library, or the arduino framework or espressif8266 core. Someone tried downgrading the core with no difference, so probably not that. I'll investigate further when I have time.
Regarding the ESPAsyncWebServer, I ported the code to try it out. It took a whole day but I read good stuff about it. But it ended up making the .bin file and RAM usage 50% bigger* and I still experienced the broken html pages. So I switched back to "native" webserver and for some reason it just works for me. I have the exact same v4 as is published here on github. If I open three simultaneous web pages it reboots the ESP but that is more understandable.
*I had to install other libraries also to make it work.

[eried]

mine continues failing from time to time, no idea why :( I wish this was ported this to esp32

[SchallertDK]

Where is the Compile buttom? I see the Upload buttom but not any compile

[SchallertDK]

Where is the "Compile" button? :)

[visualapproach]

Compile and build is the same thing and page 10-11 in the build instructions shows how to upload to esp. You can also read about it in the platformio docs.

[SchallertDK]

All the "Hardware Watchdog" faults is only appearing when the heating is getting over 31-32 degrees? My setpoint is 38.
I dont know if that can help anything in the troubleshooting? When i heat up fra example 10 degrees and all the way up to this 31-32 degrees, there is no faults, but efter that i have fault sometimes every 10 minutes

[visualapproach]

@SchallertDK that's strange. If it actually has to do with the temperature maybe a bad solder joint is expanding a little giving bad connection. Or maybe it's not related to the actual temperature but the running time, which coincide with heating time to 32 degrees. Like if there is a memory leak accumulating over time. Can't advice anything else for the moment than to try the latest beta version as mentioned at the bottom of this page.

[eried]

🧐 in still trying to find out why mqtt generates issues

There is some spotty connections 😪 but when I operate the layzspa manually it responds ok... Misterious

[visualapproach]

Don't know. Check RSSI graph if the wi-fi is bad on those occasions. Maybe using a static IP will help a little by connecting faster after a drop.

[visualapproach]

I've optimized the code to use less RAM and in my testing that got rid of the error mentioned in OP.

khoih-prog:
RAM: [====== ] 58.8% (used 48164 bytes from 81920 bytes)
Flash: [======= ] 66.5% (used 694928 bytes from 1044464 bytes)

replace khoih with tzapu:
RAM: [====== ] 57.0% (used 46680 bytes from 81920 bytes)
Flash: [====== ] 63.0% (used 657684 bytes from 1044464 bytes)

Saved 1484 bytes RAM, 37244 bytes Flash

removed double definitions of CHARS[]:
RAM: [====== ] 56.9% (used 46572 bytes from 81920 bytes)
Flash: [====== ] 63.0% (used 657688 bytes from 1044464 bytes)

Saved another 108 bytes of RAM

moved strings to Flash:
RAM: [====== ] 56.2% (used 46076 bytes from 81920 bytes)
Flash: [====== ] 63.0% (used 657684 bytes from 1044464 bytes)

Saved another 496 bytes of RAM

Move display text string outside sStates into DSP object:
RAM: [====== ] 56.1% (used 45948 bytes from 81920 bytes)
Flash: [====== ] 62.8% (used 656168 bytes from 1044464 bytes)

Saved another 128 bytes of RAM
Total: 2216 bytes of RAM (~10% more free DRAMmemory) and 38760 bytes of flash memory.

Present code is in dev branch 2023-03-25-1526