ESPHome Wi-Fi Disconnects: Fix Reconnect Loops and Offline ESP32 Nodes

When an ESPHome node keeps going offline, the Wi-Fi signal is only one possible cause. A device can have excellent RSSI and still disappear because Home Assistant cannot reach the native API, DHCP is failing, the ESP32 is rebooting from a weak power supply, fast_connect has latched onto the wrong access point, or Wi-Fi power saving is too aggressive for the router.

The fastest way to fix an unreliable ESPHome node is to stop treating every dropout as “bad Wi-Fi” and identify which layer is actually failing:

ESP32 power
   ↓
Wi-Fi association
   ↓
IP / DHCP / DNS
   ↓
ESPHome native API
   ↓
Home Assistant

This guide works through that chain from the bottom up and includes a diagnostic ESPHome configuration you can add temporarily to expose RSSI, IP address, BSSID, uptime and connection state.

First: Is the ESP32 Rebooting or Only Disconnecting?

This is the first thing to determine because the fixes are completely different.

Symptom	More likely cause
Uptime resets to zero	Actual ESP32 reboot/crash/power issue/reboot timeout
Uptime continues but HA shows unavailable	Wi-Fi, IP, API or routing issue
Wi-Fi RSSI sensor disappears with uptime reset	Board rebooting
Device remains pingable but HA unavailable	Native API problem
Device not pingable but uptime later remains high	Wi-Fi/IP reconnection problem
Device reboots on a regular ~15-minute pattern	Check ESPHome Wi-Fi/API reboot timeouts

Add an uptime sensor before changing anything else:

sensor:
  - platform: uptime
    name: "ESP Uptime"
    update_interval: 60s
    entity_category: diagnostic

If uptime repeatedly returns to a small number, you are diagnosing resets, not merely a weak wireless connection.

ESPHome Has Two Different Reboot Timeouts

This catches a lot of people because both default to 15 minutes.

Wi-Fi reboot timeout

wifi:
  reboot_timeout: 15min

If the device cannot establish a Wi-Fi connection for that period, ESPHome reboots it. ESPHome documents this as a recovery mechanism because the low-level network stack can sometimes become stuck and only a full reboot restores it.

Native API reboot timeout

api:
  reboot_timeout: 15min

This is different. The ESP32 can be connected to Wi-Fi perfectly, have an IP address and still reboot if no native API client connects within the timeout.

That means a Home Assistant server outage, VLAN/firewall mistake or API routing problem can produce a regular reboot loop that looks like Wi-Fi instability.

Test the API Timeout Separately

For a device that must continue operating even while Home Assistant is offline, temporarily disable the API reboot timeout:

api:
  reboot_timeout: 0s

If the mysterious 15-minute resets disappear, the problem was not Wi-Fi association. Home Assistant or another API client was failing to connect.

Do the same carefully with the Wi-Fi timeout only while diagnosing:

wifi:
  reboot_timeout: 0s

Do not disable recovery timeouts blindly on every node. A real network-stack lockup can then leave the device offline indefinitely. Use 0s to isolate the cause, then decide what recovery policy makes sense for that device.

Add Wi-Fi Diagnostics to Every Unstable Node

sensor:
  - platform: wifi_signal
    name: "WiFi RSSI"
    id: wifi_rssi
    update_interval: 30s
    entity_category: diagnostic

  - platform: uptime
    name: "ESP Uptime"
    update_interval: 60s
    entity_category: diagnostic

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "ESP IP Address"
    ssid:
      name: "Connected SSID"
    bssid:
      name: "Connected BSSID"
    dns_address:
      name: "DNS Address"
    power_save_mode:
      name: "WiFi Power Save Mode"

binary_sensor:
  - platform: status
    name: "ESPHome Connection"
    entity_category: diagnostic

This immediately tells you much more than the red “Unavailable” badge in Home Assistant.

The status binary sensor represents overall network/API connectivity, while the Wi-Fi information sensors expose which access point and IP configuration the ESP actually obtained.

How to Read RSSI Properly

ESPHome’s wifi_signal sensor reports RSSI in dBm. Values are negative; numbers closer to zero are stronger.

RSSI	Practical interpretation
-30 to -50 dBm	Excellent
-50 to -60 dBm	Very good
-60 to -67 dBm	Usually solid for ESPHome
-67 to -72 dBm	Usable but less margin
-72 to -80 dBm	Weak; dropouts become much more plausible
Below -80 dBm	Expect poor reliability

These are practical engineering ranges rather than an ESPHome guarantee. Two devices at -68 dBm can behave differently depending on interference, antenna orientation and access-point implementation.

Also remember that RSSI only measures signal strength from the connected AP. It does not tell you how congested the channel is or whether packets are being retried heavily.

Strong RSSI Does Not Prove Good Wi-Fi

A node at -50 dBm can still disconnect because of:

2.4 GHz interference.
Router firmware bugs.
Band-steering or mesh roaming behaviour.
Power-save incompatibility.
DHCP renewal failures.
Duplicate/static IP conflicts.
Weak ESP32 power supply during Wi-Fi transmit bursts.
API/firewall problems unrelated to RF.

Use RSSI to identify obvious coverage problems, not as proof that every other part of the network is healthy.

Try power_save_mode: none

ESPHome supports three Wi-Fi power-save levels:

NONE
LIGHT
HIGH

Current ESPHome defaults to LIGHT on ESP32. ESPHome explicitly warns that stronger power saving generally reduces Wi-Fi reliability and can produce more frequent disconnections.

For a mains-powered node that keeps dropping offline, this is one of the first settings to test:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none

If stability improves dramatically, you have found a router/power-save interaction rather than a coverage problem.

For a battery node, disabling power saving can shorten runtime considerably, so treat it as a diagnostic step before deciding on the final configuration.

fast_connect Can Make Roaming Worse

fast_connect skips a full Wi-Fi scan and attempts to connect directly. This can reduce connection time and therefore save energy, but it has a downside.

ESPHome warns that a fast-connect device may connect to the first suitable network/AP it sees even when a better access point is available.

In a house with several mesh nodes or access points using the same SSID, this can create a situation like:

Kitchen ESP32:
AP beside kitchen = -48 dBm
Upstairs AP       = -76 dBm

fast_connect
→ reconnects to upstairs AP
→ node technically works
→ connection becomes unreliable

If a stationary ESPHome node seems to attach to the wrong access point, expose the BSSID diagnostic and disable fast_connect temporarily.

When fast_connect Is Useful

It remains useful for:

Battery devices that wake briefly.
Single-AP networks.
Known fixed networks where scan time matters.

It is not automatically a “make Wi-Fi more reliable” setting.

Static IP Can Fix Slow or Failed DHCP

ESPHome’s own Wi-Fi documentation recommends trying a manual IP when a node connects slowly or has trouble obtaining network connectivity.

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  manual_ip:
    static_ip: 192.168.1.42
    gateway: 192.168.1.1
    subnet: 255.255.255.0
    dns1: 192.168.1.1

This removes DHCP negotiation from the startup path and can make reconnects quicker.

But a Bad Static IP Creates Its Own Problems

Only use a manual IP if you understand your network.

Common mistakes are:

Choosing an address inside the router DHCP pool that later gets assigned to another device.
Wrong gateway address.
Wrong subnet.
Static IP from an old network after changing router.
Wrong DNS server.

An IP conflict can look exactly like random Wi-Fi: the ESP32 associates with the AP, gets excellent RSSI, but packets intermittently go to another device using the same address.

For many home networks, a DHCP reservation configured in the router is cleaner than hard-coding an address in every ESPHome node.

.local / mDNS Problems Are Not Always Wi-Fi Problems

If:

garden-sensor.local

does not resolve, try the device’s actual IP address.

If the IP works but the hostname does not, Wi-Fi is fine. The problem is mDNS/name resolution.

This commonly appears during OTA uploads: ESPHome says the node cannot be found by name even though Home Assistant is still receiving data.

A static IP or router DHCP reservation also gives you a stable upload target without depending on .local resolution.

Fallback AP Can Confuse Troubleshooting

Many standard ESPHome configurations include:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  ap:
    ssid: "Sensor Fallback"
    password: !secret ap_password

captive_portal:

After the configured station connection fails for the AP timeout, ESPHome can start its own fallback hotspot.

If you suddenly see a Wi-Fi network named after the device, that is useful evidence: the ESP is powered and running, but it has failed to join the intended network.

Do not interpret the fallback AP appearing as proof that the ESP32 crashed.

Power Supply Problems Often Look Exactly Like Wi-Fi Dropouts

ESP32 current is bursty. Wi-Fi transmission can expose a marginal USB cable, weak 5 V adapter, poor regulator or long thin power lead.

Typical clues are:

Node works on a laptop USB port but not the installed supply.
Uptime resets rather than continuing.
Dropouts happen when a relay, display or sensor powers up.
Brownout/reset messages appear in serial logs.
Shortening the power cable fixes the problem.

Before moving access points, power the same board from a known-good USB supply for a day. If stability returns, fix power first.

Relay Boards Can Reset the ESP32

A common Home Assistant installation puts an ESP32 and relay board on the same cheap supply.

When the relay energises:

relay coil current rises
→ supply voltage dips
→ ESP32 brownout
→ reboot
→ HA reports unavailable
→ looks like Wi-Fi failure

Watch the uptime sensor while switching loads manually. If uptime resets exactly when the relay changes, the router is innocent.

Multiple Access Points: Watch the BSSID

When several APs share one SSID, the SSID sensor cannot tell you which radio the ESP32 is actually using. The BSSID can.

Expose:

text_sensor:
  - platform: wifi_info
    ssid:
      name: "Connected SSID"
    bssid:
      name: "Connected BSSID"

Then compare the BSSID with your access-point controller/router.

A fixed ESP32 should not repeatedly migrate between distant APs for no good reason. If it does, investigate mesh steering, minimum-RSSI policies or fast_connect.

2.4 GHz Is Required on Most ESP32 Boards

ESP32-C3, C6, S3 and the classic ESP32 use 2.4 GHz Wi-Fi for normal ESPHome operation. C6 supports Wi-Fi 6, but still on 2.4 GHz.

If your router has a combined 2.4/5/6 GHz SSID, that is normally fine, but some band-steering and “smart connect” implementations handle small IoT clients poorly.

As a diagnostic test, create a straightforward 2.4 GHz IoT SSID and move one unstable node onto it. If the problem disappears, investigate router steering/security rather than ESPHome code.

Check Wi-Fi Security Settings

Very new or heavily locked-down router configurations can also cause problems:

WPA3-only networks with older ESP hardware/firmware.
PMF/802.11w settings that are too strict for some clients.
Client isolation blocking Home Assistant from reaching ESPHome.
VLAN firewall rules allowing internet access but blocking local TCP 6053.
Router policies that disconnect low-traffic IoT stations.

A device can therefore connect to Wi-Fi and even reach the internet while remaining unavailable to Home Assistant on another VLAN.

Ping Is a Very Useful Divider

When Home Assistant reports the ESPHome device unavailable, immediately try its IP address:

ping 192.168.1.42

Interpret the result like this:

Ping	Home Assistant	Likely area
Works	Unavailable	API/firewall/integration issue
Fails	Unavailable	Wi-Fi/IP/power/reboot issue
Works intermittently	Flapping	RF/interference/IP conflict/power

This simple test often saves a lot of random YAML changes.

Safe Mode Helps with Real Boot Loops

ESPHome includes a safe-mode recovery system. After repeated failed boots, safe mode can start with almost all normal components disabled while retaining logging, networking and OTA so you can upload repaired firmware.

Current ESPHome defaults to entering safe mode after ten failed boot attempts, and a boot is normally considered good after one minute.

If a newly added display, external component or sensor driver causes immediate crashes, safe mode is more relevant than Wi-Fi tuning.

A minimal explicit configuration is:

safe_mode:
  num_attempts: 10
  reboot_timeout: 5min

OTA already enables safe-mode support in normal ESPHome setups, so this block is usually only needed when changing defaults.

A Good Diagnostic Wi-Fi Configuration

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

  power_save_mode: none

  ap:
    ssid: "ESP Diagnostic Fallback"
    password: !secret ap_password

api:
  encryption:
    key: !secret api_encryption_key
  reboot_timeout: 0s

ota:
  - platform: esphome

captive_portal:

sensor:
  - platform: wifi_signal
    name: "WiFi RSSI"
    update_interval: 30s
    entity_category: diagnostic

  - platform: uptime
    name: "ESP Uptime"
    update_interval: 60s
    entity_category: diagnostic

text_sensor:
  - platform: wifi_info
    ip_address:
      name: "ESP IP"
    ssid:
      name: "ESP SSID"
    bssid:
      name: "ESP BSSID"
    dns_address:
      name: "ESP DNS"
    power_save_mode:
      name: "ESP WiFi Power Save"

binary_sensor:
  - platform: status
    name: "ESPHome Status"
    entity_category: diagnostic

This is deliberately a diagnostic configuration, not a universal final configuration. It disables API-triggered rebooting and Wi-Fi power saving so you can observe the underlying behaviour.

Recommended Troubleshooting Order

Add uptime and Wi-Fi RSSI sensors.
Determine whether the ESP32 is actually rebooting.
Check whether resets occur on a regular 15-minute interval.
Disable API reboot timeout temporarily.
Set power_save_mode: none.
Check RSSI and BSSID.
Disable fast_connect if multiple APs exist.
Ping the device while Home Assistant says unavailable.
Verify DHCP/static IP and look for duplicate addresses.
Test with a known-good power supply and USB cable.
Check VLAN/firewall/router policies.
Only then consider hardware antenna faults or replacing the ESP32.

Quick Fault Table

Symptom	Most useful first check
Unavailable every ~15 min	API and Wi-Fi `reboot_timeout`
RSSI -80 dBm	Improve AP/antenna placement
RSSI -50 dBm but still disconnects	Power save, API, DHCP, router, power supply
Uptime resets with relay switching	Power supply/brownout
Ping works but HA unavailable	Native API/VLAN/firewall
IP works but hostname does not	mDNS/.local resolution
Node connects to distant mesh AP	BSSID and `fast_connect`
Fallback hotspot appears	Station Wi-Fi connection failed
Works after reboot then degrades	Network stack/router/API behaviour
Reboots immediately after new firmware	Crash loop/safe mode, not Wi-Fi

What I Would Change First on a Mains-Powered ESPHome Node

For a fixed mains-powered ESP32 that randomly disappears, the first test configuration I would use is:

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  power_save_mode: none

api:
  reboot_timeout: 0s

Then expose uptime, RSSI, BSSID and IP address and leave it running.

If the node is suddenly stable, re-enable one behaviour at a time. That tells you whether the culprit was Wi-Fi power saving, API connectivity or something else rather than blindly applying ten “ESPHome Wi-Fi fixes” at once.

Related ESPHome Networking Guides

ESP32 Bluetooth Proxy for Home Assistant — ESPHome networking and BLE proxy setup.
Bluetooth Proxy Network Design — placement, Wi-Fi contention and stability.
ESP32 W5500 Ethernet Bluetooth Proxy — removing Wi-Fi from high-traffic proxy nodes.
ESP32-S3 USB Not Detected — recovering nodes that are actually stuck in a firmware boot loop.

Official ESPHome Resources

ESPHome WiFi Component — power saving, manual IP, fast-connect, fallback AP and reboot timeout.
ESPHome Native API — API connection and reboot timeout.
ESPHome WiFi Signal Sensor — RSSI diagnostics.
ESPHome WiFi Info Sensor — IP, SSID, BSSID, DNS and power-save reporting.
ESPHome Safe Mode — boot-loop recovery and OTA repair.