Fix logic in web flasher

[TD-er]

The latest webflasher code does have lots and lots of fixes regarding keeping the connection active, flash speed, etc.
However there have been some changes which makes other features of the webflasher unusable since the ESP is put into flash mode immediately.

Some logic changes are needed in the webflasher code, which probably also require some changes in ESPEasy.

Related repos which need to be forked:

• https://github.com/Jason2866/esp-web-tools
• https://github.com/Jason2866/WebSerial_ESPTool

Logic changes needed:

Different modes, like "flashing firmware" and "maintainance mode".
The first one needs the ESP to be put into flash mode, the second one should not.

This does sound easy, but it actually isn't, as in Windows the USB device is gone while the device reboots into a different mode.
So the browser needs to reconnect and this reconnect often fails and/or causes a WDT reboot on the ESP.

This means there needs to be some way to detect which mode is active, which differs per ESP-type. And we do have a lot of them lately:

• ESP32-S2 (most problematic one as it is using TinyUSB)
• ESP32-S3
• ESP32-C3
• ESP32-C5
• ESP32-C6
• ESP32-C61
• ESP32-P4

Each of these act differently, so this involves a lot of testing.

Complicating factor is that the webflasher tries to send IMPROV calls, which seem to affect the reliability of connecting to the ESP a lot.
So when connecting to the ESP to flash, these should be suppressed and maybe in ESPEasy there should be some mechanism to act differently to IMPROV commands in some specific use cases. (or ignore them)

Another really complicating factor is that there is no simple way out of "bootloader mode", according to @Jason2866
The behavior differs per ESP-variant and also on some devices whether it was put into "bootloader mode" via the JTAG interface or via the "boot" button.
For some devices the user may need to power cycle the device to get out of "bootloader mode".

Ideas:

Check the output of the ESP device to see if there is a string indicating "waiting for download" (literal string may differ per ESP model) and then sync the internal known state.
If we want to query IMPROV calls, setup WiFi or use the console, we need to (somehow) manage to bring device out of boot mode in firmware mode.

[TD-er]

@chromoxdor Could you have a look at the code of both repo's I linked to see if this would be something for you to look into?
As you know I don't know anything about JS/TS.

[chromoxdor]

Could you have a look at the code of both repo's I linked to see if this would be something for you to look into?
As you know I don't know anything about JS/TS.

To be honest, I never used the webflasher, but I definitely can have a look at it. But it'll take some time since I don't have time until next Wednesday, and also I am doing a lot of restructuring in our flat for our third family member coming in two months, which eats up a lot of time too.

"maintainance mode".

Can you explain what this is.

[TD-er]

"maintainance mode".

Can you explain what this is.

Well it is like connecting to the ESP via the webflasher page and use it to perform some setup tasks like connecting to WiFi and allowing to have a fully functioning console.

[chromoxdor]

Well it is like connecting to the ESP via the webflasher page and use it to perform some setup tasks like connecting to WiFi and allowing to have a fully functioning console.

Wouldn't this be just a normal serial console and a script which "translates" the WiFi credentials you entered into serial commands?

[TD-er]

The current web flasher does have the "IMPROV" protocol which is a protocol used among several other firmware versions to handle this.
This was working very well, however we now have the problem the device is somehow put into flash mode where this is not intended.
If it is in flash mode, there is no ESPEasy running, so nothing can be communicated other than downloading the firmware image.

So the main problem is that we need to check in what mode the connected ESP is and then act on it.

For these actions we need to be in flash mode:

• update firmware
• Low-level access to the file system for backup/fix issues with files

For these actions we need to be in 'normal' mode (thus running the programmed sketch like ESPEasy:

• Console
• WiFi setup (using IMPROV protocol)

You can try it yourself:
https://td-er.nl/ESPEasy/latest/

This is working fine in Mac OS, but not from Windows.

[TD-er]

@Jason2866 did make some improvements in his 'work-in-progress web flasher' (read: the playground for code that later ends up in the webflasher I use for ESPEasy) https://jason2866.github.io/esp32tool/

Using that code the wifi setup and console is working again... most of the time.
N.B. When testing and stuff isn't working, testing in 'incognito mode' is adviced.

I believe most of the things that needs to be changed is in ESPEasy on how to handle the USB-CDC/JTAG-CDC to reduce the number of reconnects of the USB device.

To test the improvements, toggle 'advanced mode' and then after connecting you can toggle 'console'.
In the console window there is also an "IMPROV" button at the top, which can help to setup WiFi.

[Jason2866]

The esp32tool is no WiP. It is productive ready and finished. There will be no work done to move code from esp32tool too the WebInstaller from me. Latest changes are just adding improv for fun there. esp32tool is not ment for end users just flashing a firmware. It is a tool.

[Jason2866]

Let the AI move functions out of install-dialog.ts in a extra file. https://github.com/Jason2866/esp-web-tools/tree/wip_refactor. This version is 99,9% not working. But when comparing with the main branch refactoring should be easier.

Wow, a first test was working. Did never expect since i let the AI change everything i did not like. MAAANY big changes...
So it is for sure a good start for a real programmer to make the code shine