The EasyFetch discussion got a bit off-topic due to the discussions about WiFi improvements made by TD-er. So this is a new discussion about testing the experimental WiFi changes.
Using OTA, I installed mega_20250315_climate_ESP32_4M316k_LittleFS_ETH on a ESP32. It seems to be working fine. I am using it with EasyFetch and no issues have appeared. Ethernet is NOT used on this device.
Please let me know if any special tests are wanted.
- Thomas
WiFi Improvements, March 2025 Code Test Results
Moderators: grovkillen, Stuntteam, TD-er
Re: WiFi Improvements, March 2025 Code Test Results
One of the things I specifically looked into is to make sure it will always reconnect, no matter how bad your WiFi is.
However, every now and then I still see that a disconnect even is not processed immediately.
It can sometimes take 20 - 120 sec before the ESP notices it is no longer connected.
So that is still something to look into as trying to attempt reading incoming data, where the ESP disconnects between receiving the data and getting disconnected may result in some crash as the pointer to the received data may no longer be valid.
So what I did is to force disconnects from a Mikrotik access point and sometimes also just reboot the AP to which the ESP is connected.
Another issue which is still not solved is that the TX power may not always use the actual set TX power.
Again using a Mikrotik access point clearly shows the RSSI chart of any connected clients, showing the TX power may not always return to the same level when the ESP switches TX power to the same level as before.
So it may seem to get stuck to 20 dBm and suddenly start dynamically alter TX power, but never return to the same RSSI values on the access point as before.
Not yet tested extensively:
- Static IP
- Hidden SSID (there is a difference for hidden SSID on channels <= channel 11 and above)
- Start with unreachable access point, to see if will eventually start AP mode and then after a minute stop AP mode to start connecting to the configured AP.
However, every now and then I still see that a disconnect even is not processed immediately.
It can sometimes take 20 - 120 sec before the ESP notices it is no longer connected.
So that is still something to look into as trying to attempt reading incoming data, where the ESP disconnects between receiving the data and getting disconnected may result in some crash as the pointer to the received data may no longer be valid.
So what I did is to force disconnects from a Mikrotik access point and sometimes also just reboot the AP to which the ESP is connected.
Another issue which is still not solved is that the TX power may not always use the actual set TX power.
Again using a Mikrotik access point clearly shows the RSSI chart of any connected clients, showing the TX power may not always return to the same level when the ESP switches TX power to the same level as before.
So it may seem to get stuck to 20 dBm and suddenly start dynamically alter TX power, but never return to the same RSSI values on the access point as before.
Not yet tested extensively:
- Static IP
- Hidden SSID (there is a difference for hidden SSID on channels <= channel 11 and above)
- Start with unreachable access point, to see if will eventually start AP mode and then after a minute stop AP mode to start connecting to the configured AP.
Re: WiFi Improvements, March 2025 Code Test Results
I can test static IP.
- Thomas
- Thomas
Re: WiFi Improvements, March 2025 Code Test Results
Static IP working fine for me. But I haven't done anything special other than set the IP and reboot.
- Thomas
- Thomas
Who is online
Users browsing this forum: No registered users and 25 guests