[Test build] Testers for new upcoming build (March '24)
TD-er opened this issue · 25 comments
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
Just as a reminder:
- ESP32-xx LittleFS builds are based on ESP-IDF 5.x code
- ESP32-xx SPIFFS builds are based on ESP-IDF 4.4
I did recently found some very strange issues when using the C++ union which I do use to 'translate' specific bit structs.
It does appear to be mostly an issue on ESP8266.
And most of those union uses were added quite recently as an effort to reduce build size.
At least ESP8266 WiFi (re)connect issues seem to be related to this and there have been some other odd reported issues where MQTT reconnects and with ADS1x15.
In all these cases such a union was used.
The WiFi reconnect issues seem to be related to access points which only allow a limited subset of 802.11b/g/n and block the other(s).
Or on setups where 802.11g is really needed to get a stable connection as the signal is too bad for a stable 'n' connection.
What may happen with the ADS1x15 is hard to predict as there truly are really bad fakes out there which are hard to identify.
I still don't know why this use of union may lead to frequent disconnects, but if you had this, it may be a good idea to double check the controller settings and save again using the linked build.
Starting to test ESP8266.
ESP can connect to one router using 802.11n, and to the other using g. After reboot, though, it can connect using 802.11n to any of two routers (both are ax capable and have b/g enabled) , so can't really find the pattern, it is quite dynamic and probably depends on current noise level.
And maybe also on how busy the AP is at some point.
Some APs may not always respond immediately to a single scan / connect attempt and when one attempt failed, ESPEasy will immediately retry using the other mode.
./ESP8266_normal_ESP8266_4M1M/ESP_Easy_mega_20240311_normal_ESP8266_4M1M.bin
./ESP8266_climate_ESP8266_4M1M/ESP_Easy_mega_20240311_climate_ESP8266_4M1M.bin
./ESP32-D0WDQ6_normal_ESP32_4M316k/ESP_Easy_mega_20240311_normal_ESP32_4M316k.bin
./ESP32-D0WDQ6_neopixel_ESP32_4M316k/ESP_Easy_mega_20240311_neopixel_ESP32_4M316k.bin
./ESP32-D0WDQ6_normal_ESP32_4M316k_LittleFS/ESP_Easy_mega_20240311_normal_ESP32_4M316k_LittleFS.bin
in testing. Waiting for issues....
./ESP8266_normal_ESP8266_4M1M/ESP_Easy_mega_20240311_normal_ESP8266_4M1M.bin ./ESP8266_climate_ESP8266_4M1M/ESP_Easy_mega_20240311_climate_ESP8266_4M1M.bin ./ESP32-D0WDQ6_normal_ESP32_4M316k/ESP_Easy_mega_20240311_normal_ESP32_4M316k.bin ./ESP32-D0WDQ6_neopixel_ESP32_4M316k/ESP_Easy_mega_20240311_neopixel_ESP32_4M316k.bin ./ESP32-D0WDQ6_normal_ESP32_4M316k_LittleFS/ESP_Easy_mega_20240311_normal_ESP32_4M316k_LittleFS.binin testing. Waiting for issues....
No issues.
In the mean time, I did find some issues myself and looking into it...
- M5Stack ATOM S3 (8M flash, no PSRAM) enters bootloop after flashing. Might be related to SPI Ethernet
- Lolin S3 pro (16M flash, 8M PSRAM) reports available PSRAM as a bit less than 6 MB (6080912 bytes)
- HW-CDC (serial port via USB on ESP32-C3/C6/S3) shows missing bytes, probably due to recent check in Arduino code to see if device is connected.
ESP_Easy_mega_20240312_normal_ESP8266_4M1M no issues so far, wifi or wifi reconnect after deepsleep seems more stable.
ESP_Easy_mega_20240312_normal_ESP32c3_4M316k_CDC no issues so far. Both upgrades no fresh flash.
Tried to test all my ESP32 boards with normal LittleFS builds. There was definitely something odd with 20240311 version available from the web flasher as most boards except ESP32 stuck in the console prior to starting the AP, ESP32-S2 with PSRAM even went to a bootloop. So had to reflash them with latest GA build.
20240312 is fine so far on all ESP32 boards, all memory configurations are displayed correctly.
Happy to see that AP mode is restarted when configured network switches off, but this disappears after reboot, it never restarts if at least one main or maintenance network is configured.
By the way, is there a reason to spend boot time for scanning with empty WiFi config?
By the way, is there a reason to spend boot time for scanning with empty WiFi config?
Yep, this way you can immediately show the APs when entering setup.
Otherwise you will loose connection if connected to the AP of the ESP if the ESP then needs to perform a WiFi scan.
ESP_Easy_mega_20240312_climate_ESP32s2_4M316k_CDC no issues and wifi more stable than previous builds.
ESP_Easy_mega_20240314_climate_ESP32s2_4M316k_CDC best version I run in last two years on my S2 so far. 👍
I am still working on the issue with the ESP32-S3 HWCDC (Console via native USB) as you can loose data.
There is a fix, but the people from Arduino must first accept it as they don't seem to be able to reproduce it.
Hello @TD-er, hello all.
All OK here with severals ESP32 boards (4MB and 16MB) using both Custom build and MAX build.
No issues found so far on:
ESP_Easy_mega_20240317_climate_ESP32s2_4M316k_CDC
ESP_Easy_mega_20240317_normal_ESP8266_4M1M
ESP_Easy_mega_20240317_normal_ESP32c3_4M316k_CDC
ESP_Easy_mega_20240317_collection_G_ESP8266_4M1M
ESP_Easy_mega_20240317_normal_ESP32_4M316k (maybe others too) and ads1115 values in device tab only shown when Force Slow I2C speed is enabled (Clock Speed = Slow device Clock Speed = 100MHz in Hardware tab). If disabled only a line is shown.
Is this a build with LittleFS in the name?
Did that ADS1115 work at 400 kHz before, on an older build? As there are quite a lot of that type of sensors that are not what they are claimed to be...
Clock speed was 100MHz before and now only Force Slow I2C speed was disabled in device ads1115 before. An MCP23017, a PCA9685 and a DS3231 are also on the bus and to avoid trouble I set speed to 100MHz. No LittleFS.
Flashed it back to 20231225 and then again to 20240317 and the issue is gone - so maybe something is gone wrong during update - no clue.
I just updated the web flasher to the latest test build:
https://td-er.nl/ESPEasy/latest/
Still known issue:
- ESP32-S3/C3/C6 can still show missing bytes in the console when connected to the HWCDC USB serial port
A few things have been fixed, among which a rather tricky issue where some settings of some plugins might not get saved properly (no specific example yet except for the CUL reader)
In testing:
./ESP8266_neopixel_ESP8266_4M1M/ESP_Easy_mega_20240325_neopixel_ESP8266_4M1M.bin
./ESP8266_normal_ESP8266_4M1M/ESP_Easy_mega_20240325_normal_ESP8266_4M1M.bin
./ESP8266_climate_ESP8266_4M1M/ESP_Easy_mega_20240325_climate_ESP8266_4M1M.bin
./ESP32-D0WDQ6_normal_ESP32_4M316k/ESP_Easy_mega_20240325_normal_ESP32_4M316k.bin
./ESP32-D0WDQ6_neopixel_ESP32_4M316k/ESP_Easy_mega_20240325_neopixel_ESP32_4M316k.bin
./ESP32-D0WDQ6_normal_ESP32_4M316k_LittleFS/ESP_Easy_mega_20240325_normal_ESP32_4M316k_LittleFS.bin
Uploaded a new build to the webflasher which should deal with MQTT disconnects and crashes when using formula.
All OK here with:
"ESP_Easy_mega_20240331_custom_ESP32_4M316k_LittleFS Mar 31 2024"
"ESP_Easy_mega_20240331_max_ESP32_16M8M_LittleFS Mar 31 2024"
Happy Easter.
No issues so far with
ESP_Easy_mega_20240330_climate_ESP32s2_4M316k_CDC
ESP_Easy_mega_20240330_normal_ESP32c3_4M316k_CDC
ESP_Easy_mega_20240330_normal_ESP8266_4M1M
Only issue now is that the build process failed... again... :(
I manually uploaded the last test build I made before making the official build.
So it is based on exactly the same source code, but may have a different Git tag in the sysinfo page.
Anyway thanks for testing y'all and happy easter.