ESP32 keeps dropping Wi-Fi after 20–30 minutes in deployed location — reconnect loop doesn't always recover

To expand on the reason codes: the numeric values come from two sources. Codes 1–45 are 802.11 standard deauthentication/disassociation reason codes defined in the IEEE 802.11 spec. Codes 200+ are ESP-IDF additions — WIFI_REASON_BEACON_TIMEOUT (200) and WIFI_REASON_NO_AP_FOUND (201) being the most common non-standard ones you'll see in practice. They're all defined in esp_wifi_types.h in the ESP-IDF headers if you want the full list.

One thing worth knowing about calling esp_wifi_connect() inside the event handler: the handler runs in the context of the Wi-Fi task, so the call is fine in simple cases, but if you have complex reconnection logic (exponential backoff, MQTT reconnection sequencing, NVS reads) it's cleaner to use a FreeRTOS event group and handle reconnection from your main task or a dedicated network management task. Something like:

/* in event handler */
case WIFI_EVENT_STA_DISCONNECTED:
    xEventGroupClearBits(s_wifi_event_group, WIFI_CONNECTED_BIT);
    xEventGroupSetBits(s_wifi_event_group, WIFI_DISCONNECTED_BIT);
    break;

/* in your main/network task */
EventBits_t bits = xEventGroupWaitBits(s_wifi_event_group,
                                        WIFI_DISCONNECTED_BIT,
                                        pdTRUE, pdFALSE,
                                        portMAX_DELAY);
if (bits & WIFI_DISCONNECTED_BIT) {
    vTaskDelay(pdMS_TO_TICKS(backoff_ms));
    esp_wifi_connect();
}

This separates the event detection from the reconnect logic and makes the backoff timing straightforward. The ESP-IDF wifi_station example in examples/wifi/getting_started/station/ uses the event group pattern if you want a reference.

Also: esp_wifi_set_ps(WIFI_PS_NONE) should definitely be your first test. In ESP-IDF 5.x it can be set before esp_wifi_start() if you call it after esp_wifi_init() and esp_wifi_set_mode().

One more angle if the power save fix doesn't resolve it: the AP itself.

Some consumer routers have a client idle timeout — they deauthenticate stations that haven't exchanged data for a period (anything from 5 minutes to 30 minutes depending on firmware). In the lab on your home AP this might not kick in because you're doing other network activity that keeps the AP's client table warm. In the shed it's the only device on that AP, sending only every 5 minutes. If the AP's idle timer is shorter than your reporting interval, it'll disconnect you between transmissions.

You can distinguish this from power save issues by looking at the reason code: AP-side deauth for idle timeout usually shows up as reason 2 (WIFI_REASON_AUTH_EXPIRE) or reason 4 (WIFI_REASON_AUTH_LEAVE), not 200 (beacon timeout).

Quick test to confirm: swap the router for a mobile hotspot temporarily. Phone hotspots generally don't have aggressive idle timeouts, so if the device stays connected for hours on the hotspot but not the router, you're hitting the AP's keepalive behaviour rather than a power save or signal problem. From there you can look at the router's settings (if it exposes them) or bump your MQTT keepalive interval below the AP's idle threshold to keep the association alive.

At -65 to -70 dBm you're not in great shape for a sensitive AP, but you're generally above the point where beacons get dropped reliably — so signal being the primary cause is less likely than power save or AP behaviour at that RSSI. Still worth running esp_wifi_sta_get_ap_info() to poll RSSI periodically and log it, just to confirm it's not worse than expected at certain times of day.

The deep sleep and power management article has a useful breakdown of the five ESP32 power modes and their modem behaviour, which is worth reading alongside this to understand the WIFI_PS_NONE vs WIFI_PS_MIN_MODEM vs WIFI_PS_MAX_MODEM trade-offs.