[Test build] Testers for new upcoming build (X-mas '24)

[TD-er]

I've just uploaded the latest GH Actions build to the web flasher

So I would like to summon the very appreciated testing crew :)
@fly74 @ghtester @chemmex @alex-kiev @iz8mbw @Wookbert @Dickesplumpel @thomastech

I had planned to also have the complete network/WiFi rewrite in this build, but it is taking quite a bit longer than expected.
This is also because of other reasons which prevent me from working on ESPEasy for hours at a time. Since the rewrite takes quite a lot of time to get 'into it' again each time I work on it, it doesn't make sense to do anything on it when I only have an hour to spare.

Anyway there have been quite a lot of fixes and other changes since the last build, so let's prepare for some X-mas build.

To make clear what the differences are between SPIFFS and LittleFS:

• ESP32-xx LittleFS builds are based on ESP-IDF 5.3 code
• ESP32-xx SPIFFS builds are based on ESP-IDF 5.1 code

As can be seen, both do not differ a lot anymore and on the next build this difference might even be completely gone as I can hopefully then use pioarduino with the custom SDK flags made by Jason2866 and Staars, both from Tasmota.

Just as a reminder for those who want to upgrade from an April build:

There are lots and lots of changes, but the main tricky one is that it might be impossible to OTA update larger builds from the > April release as there was a bug in the Arduino code which did not properly use timeouts when handling HTTP requests.

If this is an issue, to update any "max" builds, I will add intermediate builds for those typically 16M and 8M builds which do not contain any plugin or controller to make them as small as possible.
This way it is more likely you can successfully OTA update such units without the need to hook them up via serial.

So please let me know if this is indeed an issue (and maybe also for "4M builds LittleFS").
N.B. this does only apply to "LittleFS" builds when OTA updating from the April release. (or test builds from around that time)

Found issues so far:

• Solo1 builds bootloop
• Fetching HTTP calls in quick succession is often failing.
• Unable to save rules while connected via Ethernet (see forum )

[iz8mbw]

@TD-er instead to use the latest GH Actions build, may I build by myself a Custom Build using the latest commit available now on Github?

[TD-er]

Sure
It is the same code base and you may find other issues which may not show when using the standard builds.

[iz8mbw]

OK, going to build and test!

[fly74]

Test activated for from all.zip:

.
├── ./ESP32-D0WDQ5_neopixel_ESP32_4M316k_ETH
│   └── ./ESP32-D0WDQ5_neopixel_ESP32_4M316k_ETH/ESP_Easy_mega_20241210_neopixel_ESP32_4M316k_ETH.bin
├── ./ESP32-D0WDQ6_neopixel_ESP32_4M316k
│   └── ./ESP32-D0WDQ6_neopixel_ESP32_4M316k/ESP_Easy_mega_20241210_neopixel_ESP32_4M316k.bin
├── ./ESP32-D0WDQ6_normal_ESP32_4M316k
│   └── ./ESP32-D0WDQ6_normal_ESP32_4M316k/ESP_Easy_mega_20241210_normal_ESP32_4M316k.bin
├── ./ESP8266_climate_ESP8266_4M1M
│   └── ./ESP8266_climate_ESP8266_4M1M/ESP_Easy_mega_20241210_climate_ESP8266_4M1M.bin
├── ./ESP8266_minimal_core_312_1M_OTA_Domoticz_MQTT
│   └── ./ESP8266_minimal_core_312_1M_OTA_Domoticz_MQTT/ESP_Easy_mega_20241210_minimal_core_312_ESP8266_1M_OTA_Domoticz_MQTT.bin
├── ./ESP8266_neopixel_ESP8266_4M1M
│   └── ./ESP8266_neopixel_ESP8266_4M1M/ESP_Easy_mega_20241210_neopixel_ESP8266_4M1M.bin
└── ./ESP8266_normal_ESP8266_4M1M
   └── ./ESP8266_normal_ESP8266_4M1M/ESP_Easy_mega_20241210_normal_ESP8266_4M1M.bin

[iz8mbw]

All OK here on ESP32 boards (connected on WiFi) using Custum Builds "ESP_Easy_mega_20241210_custom_ESP32_4M316k_LittleFS_ETH"!!!
Thanks @TD-er

[Dickesplumpel]

OTA update from ESP_Easy_mega_20230623_normal_ESP32s2_4M316k_CDC to ESP_Easy_mega_20241210_normal_ESP32s2_4M316k_CDC
Fresh Webui install with ESP_Easy_mega_20241210_normal_ESP8266_4M1M on 12F and ESP_Easy_mega_20241210_normal_ESP32_4M316k on ESP32-WROOM_32

No issues so far. In the past I had often trouble setting up wifi settings with putty, now it seems working pretty good.

[fly74]

Test activated for from all.zip:

.
├── ./ESP32-D0WDQ5_neopixel_ESP32_4M316k_ETH
│   └── ./ESP32-D0WDQ5_neopixel_ESP32_4M316k_ETH/ESP_Easy_mega_20241210_neopixel_ESP32_4M316k_ETH.bin
├── ./ESP32-D0WDQ6_neopixel_ESP32_4M316k
│   └── ./ESP32-D0WDQ6_neopixel_ESP32_4M316k/ESP_Easy_mega_20241210_neopixel_ESP32_4M316k.bin
├── ./ESP32-D0WDQ6_normal_ESP32_4M316k
│   └── ./ESP32-D0WDQ6_normal_ESP32_4M316k/ESP_Easy_mega_20241210_normal_ESP32_4M316k.bin
├── ./ESP8266_climate_ESP8266_4M1M
│   └── ./ESP8266_climate_ESP8266_4M1M/ESP_Easy_mega_20241210_climate_ESP8266_4M1M.bin
├── ./ESP8266_minimal_core_312_1M_OTA_Domoticz_MQTT
│   └── ./ESP8266_minimal_core_312_1M_OTA_Domoticz_MQTT/ESP_Easy_mega_20241210_minimal_core_312_ESP8266_1M_OTA_Domoticz_MQTT.bin
├── ./ESP8266_neopixel_ESP8266_4M1M
│   └── ./ESP8266_neopixel_ESP8266_4M1M/ESP_Easy_mega_20241210_neopixel_ESP8266_4M1M.bin
└── ./ESP8266_normal_ESP8266_4M1M
   └── ./ESP8266_normal_ESP8266_4M1M/ESP_Easy_mega_20241210_normal_ESP8266_4M1M.bin

No issues at all.

[Dickesplumpel]

ESP_Easy_mega_20240331_normal_ESP32c3_4M316k_CDC to ESP_Easy_mega_20241012_normal_ESP32c3_4M316k_CDC on ESP32-c3 super mini
I'm missing ESP_Easy_mega_20241210_climate_ESP32solo1_4M316k_LittleFS, ESP_Easy_mega_20241210_climate_ESP32solo1_4M316k_LittleFS_ETH doesn't work on shelly-plus1, bootloop.

[TD-er]

Check!
Not sure if ETH is the issue here.
Do other solo1 builds work?

[Dickesplumpel]

Update from ESP_Easy_mega_20231223_climate_ESP32solo1_4M316k_LittleFS to ESP_Easy_mega_20241210_climate_ESP32solo1_4M316k_LittleFS_ETH gone wrong. A flash with ESP_Easy_mega_20241210_climate_ESP32solo1_4M316k_LittleFS_ETH.factory doesn't work ether. I will try it again tomorrow with normal build.

[TD-er]

Check!
I will later this evening update the ESP-IDF version for the solo1, and will post here when it is ready.

[chemmex]

Ready to test specifically local AP restart after loss of main WiFi connection.

ESP_Easy_mega_20241210_normal_ESP32c3_4M316k_LittleFS_CDC_ETH.factory.bin, doesn't restart so far

[TD-er]

@Dickesplumpel
Here is a build running for the solo1 update: https://github.com/letscontrolit/ESPEasy/actions/runs/12260984392

@chemmex
Correct, as that is part of the WiFi/network rewrite which is not done yet

[chemmex]

Correct, as that is part of the WiFi/network rewrite which is not done yet

Oh, I see, I mistakenly thought you are doing it incrementally
Will wait for that fully armed.

[iz8mbw]

and after the WiFi rewrite there will be a surprise/present made by @TD-er : the Bluetooth Low Energy support in ESPEasy :-)

[Dickesplumpel]

ESP_Easy_mega_20241210_collection_G_ESP8266_4M1M no issues.
Update from ESP_Easy_mega_20231225_climate_ESP32solo1_4M316k_LittleFS to ESP_Easy_mega_20241210_normal_ESP32solo1_4M316k_LittleFS_ETH does not work, stays on 20231225, doing a clean flash with factory.bin later.

[TD-er]

I will have a look at it later. Not sure which one of my Shelly devices is a single core though, so have to check.

I know there have been issues with the recent solo1 platform builds, but I thought those were fixed by Jason2866.
I will ask him about it

[Dickesplumpel]

Fresh clean install with Bin-ESP32SOLO1-normal_ESP32solo1_4M316k_LittleFS_ETH-20241210_PR_5175_12260984392.factory.bin, serial says this block in a loop:

rst:0x8 (TG1WDT_SYS_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:268
ho 0 tail 12 room 4
load:0x40078000,len:13056
load:0x40080400,len:4
load:0x40080404,len:2724
entry 0x40080534

Same with CollectionG.

[TD-er]

Talked with Jason2866 and he pointed out the error I made.
So this build should hopefully fix the solo1 crashing: https://github.com/letscontrolit/ESPEasy/actions/runs/12273878227

[fly74]

Is it only for the solo1 oder a globally change?

[TD-er]

Is it only for the solo1 oder a globally change?

I also updated to the same (newer) ESP-IDF code for other LittleFS builds, so stricktly speaking also other LittleFS builds will differ from the build I put on the web flasher page.
If this is working with the solo1 boards, I will also put that build on the web flasher page.

[Dickesplumpel]

No, ESP_Easy_mega_20240822_normal_ESP32solo1_4M316k_LittleFS_ETH works fine, upgrade to Bin-ESP32SOLO1-normal_ESP32solo1_4M316k_LittleFS_ETH-20241211_PR_5175_12273878227 or fresh install with factory.bin gets same result as earlier described.

[TD-er]

Jason also confirmed this build is failing on his Solo1.
So have to dig further to see why this is failing.

[fly74]

It looks like we have an issue with sending values with http eg.

/usr/bin/curl http://esp/control?cmd=TaskValueSet,7,1,40
curl: (56) Recv failure: Connection reset by peer

often results in this error. Also with IP without DNS name.

[TD-er]

Which build?
LittleFS or SPIFFS?

[fly74]

ESP_Easy_mega_20241210_normal_ESP32_4M316k.bin

[TD-er]

Is it possible to test it on some (other) node using a LittleFS build?
This fix is not included in the SDK used for SPIFFS builds: espressif/arduino-esp32#10640

[fly74]

Back to ESP_Easy_mega_20240822_normal_ESP32_4M316k works fine.

[fly74]

Is it possible to test it on some (other) node using a LittleFS build? This fix is not included in the SDK used for SPIFFS builds: espressif/arduino-esp32#10640

no running ESP with SPIFFS atm, but can you build one for this bin?

[fly74]

Getting the json and the webinterface is also from disconnects affected.

[TD-er]

Is it possible to test it on some (other) node using a LittleFS build? This fix is not included in the SDK used for SPIFFS builds: espressif/arduino-esp32#10640

no running ESP with SPIFFS atm, but can you build one for this bin?

It is available:

Also in the all.zip file on the webflasher page: https://td-er.nl/ESPEasy/latest/

If you want to convert a node, you should first download a tar file via "Backup Files" on the Tools page.
Make sure you actually have the tar file downloaded, as Chrome for example will pop-up a tooltip asking if you would like to keep the file and if you don't agree, it will not be downloaded.

Then you can flash the LittleFS build, which will format the file system and should keep the WiFi credentials so it will show up connected to your network.
Then you can via the "File Browser" button on the tools page upload the tar file and then reboot the node.

[fly74]

The WIFI wasn't still there, but via AP I could restore the tar-file. But same issues with the unstable connection. How can I revert to the non SPIFFS from 240822?

[fly74]

works with flash and AP restore.

[fly74]

same with downloading backups:

wget http://esp/download -P SAVE --user=xxx --password=xxx --content-disposition
--2024-12-11 21:28:15-- http://esp/download
Resolving esp (esp)... 172.xxxxxx
Connecting to esp (esp)|172.xxxxxx|:80... connected.
HTTP request sent, awaiting response... 401 Unauthorized
Authentication selected: Digest realm="Login Required (default user: admin)", qop="auth", nonce="xxxxxxxxx", opaque="xxxxxxxxx"
Connecting to esp (esp)|172.xxxxxx|:80... connected.
HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers.
Retrying.

[TD-er]

And this was working well on the August build?

[fly74]

yes, when I revert it works.

[TD-er]

Can you disable the password to see if it makes a difference?

[fly74]

It is something with the http-server, I don't think it is the password. If I use a browser the password is accepted after some tries and the download starts.

[TD-er]

The thing is that this will be an extra call.
Just to know where we should start looking.

[fly74]

You're right, without password it works.

[fly74]

Can you reproduce it ?

[TD-er]

OK, so there is something with multiple replies in a quick succession and that's exactly what I've also seen when fetching JS or CSS from the ESP in separate calls.
With the password set, it is probably easier to reproduce, so I will have a look at it.

[fly74]

It also affects the MQTT traffic with loss of values.