wifi_no_sleep = true for ESP32C3 still needed in T 14.5.0 ?

[GEAG]

In file tasmota/tasmota_support/support_wifi.ino there is still the following line enabled only for ESP32C3 targets:

wifi_no_sleep = true; // Temporary patch for IDF4.4, wifi sleeping may cause wifi drops

Since T has been ported to Arduino Core3/IDF5 for all versions >= T 14.0.0, I wonder if this still has relevance or if it is obsolete by now?

Our own tests and measurements have shown, that the energy consumption may be significantly reduced (up to -48%), if this line is eliminated from the code.

[therobveiller]

I’m very surprised you have no response to this, and I didn’t know about this issue and “work around” until your post.
Having recently bought a batch of C3 devices, I noted how incredibly hot they ran with Tasmota compared to my other ESP modules. For a test I pointed my IR heat camera at the C3 board running the version where wifi sleep is disabled (current “bug fix” of wifi_no_sleep = true) and the voltage regulator and ESP32C3 run in the 47-50 Celsius range. Using the same custom software build I use, on the same device of course, with no other changes whatsoever between builds except the code you are referring to commented out so that wifi sleep config follows the normal code options, the chips run at around 25-27 Celsius – a massive difference, and far more conducive to the longevity of the devices.
I have a dynamic sleep value of 50 set in both tests, but obviously that is ignored for C3 in a default build with wifi_no_sleep = true (as I read it).
I have not had any issues at all with wifi not reconnecting or dropping with this code commented out, just like you. And this is with a relatively poor RSSI of 42% on the device as it’s a long way away from the access point.

[Jason2866]

PR #23117

[GEAG]

During testing with T 14.6.0 on a ESP32C3, we have noticed, that Tasmota sometimes blocks completely. The event loop is not serviced anymore.

Since the watchdog seems to have been deactivated according to the Changelog for ESP32 devices during migration to T 14.0.0.2, the device can sometimes only manually be recovered with either (a) a power-cycle or (b) a reboot of the Wifi router, to which the device is connected to.

In some cases, we have noticed, that the device de-blocks itself and reconnects to the Wifi router after about 30 to 40 minutes. Our observation seems to indicate, that such event-loop blocks occur much more frequent, if the Wifi signal and its RSSI is week.

When deactivate sleeping with "SetOption127 ON" we have never noticed a "permanent" event-loop block (for many hours until a manual intervention) during an observation period of a single digit number of days.

We have two ESP32C2 devices with T 14.6.0 running permanently in a distance of about 30 cm from each-other and connected to the same Wifi router about 8 m away with a weak signal through walls. The device (B2) with the worse RSSI is configured with "SetOption127 ON" (no sleep). The one with the better RSSI (B1) with "SetOption127 OFF" and standard sleep 50. The RSSI monitoring is realized through MQTT with Grafana. For B1 we see 2 outages of about 30-40 minutes each in the Graph.

B2 does not show outages where as for B1, we observe several outages (main-loop blocks).

The following would be appreciated:

1. If someone could find & fix the problem of the main-loop blocks, probably somewhere in the Wifi driver.
2. If the watchdog for ESP32 devices, including ESP32C3, could be reactivated, to at least issue a restart of the device after a shorter time of less than a minute of a blocked event-loop.
3. Similar experiences from other ESP32 based devices could maybe help to identify and fix the underlying reason.
4. Any hints for detecting the real cause.

[Jason2866]

Probably the used WiFi AP is mandantory in this scenario too. Your description is missing this info. If SO127 1 fixes the problem just do this. Honestly there is a very very low chance to find the culprit since the wifi stack is closed source.

[Staars]

Besides you can turn on the watchdog for testing here and see, if this is a better compromise for you.

Tasmota/tasmota/my_user_config.h

Line 1166 in 723684b

//#define USE_ESP32_WDT // Enable Watchdog for ESP32, trigger a restart if loop has not responded for 5s, and if `yield();` was not called