ESPHome 2026.7.x breaks connectivity & OTA updates on devices missing mDNS / dynamic IPs

ESPHome
1

image

Hi everyone,

I’m reaching out to highlight an issue introduced in recent ESPHome release (2026.7.x) regarding device status checking and OTA updates, and to see if anyone has a workaround or if this can be addressed upstream.

The Issue

After updating ESPHome to 2026.7.x, several of my stable ESP32 and ESP8266 devices (including a custom fridge controller and a GPS module) suddenly appeared as Offline in the ESPHome Dashboard, and entities became Unavailable in Home Assistant.

Upon investigating the build logs and logs during OTA attempts, I noticed ESPHome now strictly relies on resolving .local mDNS / API endpoints rather than the previous fallback/ping mechanisms.

When attempting an OTA update to push fixes or updated network configs, the dashboard halts with:

Update queued. It will install when the device comes back online.

This creates a catch-22 / deadlock:

  1. ESPHome thinks the device is offline (due to mDNS resolution failure or cached old IP/route errors like [Errno 113] Connect call failed).
  2. Because it marks the device as offline, it refuses to even attempt pushing the OTA update over the known IP address.
  3. The device is actually running its local code fine (e.g., my fridge thermostat is executing logic normally), but network communication with Home Assistant / ESPHome API is completely blocked.

Environment & Diagnostics

  • ESPHome Version: 2026.7.3
  • Network Infrastructure: pfSense router (DHCP server), Teltonika RUTX11 Access Point (2.4GHz dedicated IoT SSID, Client Isolation disabled).
  • Observed Error in Logs:PlaintextINFO Starting log output from 192.168.2.105 using esphome API WARNING Can't connect to ESPHome API for gps @ 192.168.2.105: [Errno 113] Connect call failed ('192.168.2.105', 6053) (SocketAPIError)
  • Power cycling the ESP nodes does not resolve the mDNS discovery state once ESPHome has cached an unroutable IP/host state.

Questions / Feature Request

  1. Is there a way to force an OTA flash over a specified IP address directly from the ESPHome Dashboard UI, bypassing the Update queued... restriction when a device is falsely flagged as offline?
  2. Has anyone else experienced mDNS / API discovery dropouts specifically after upgrading to the 2026.7 series on multi-sub-network or router setups (like pfSense + dedicated APs)?

Any advice or insights on how to force the dashboard to clear its internal mDNS/IP cache without needing a physical serial cable connection would be greatly appreciated!

Thanks!

2

image
image1047×372 10.7 KB

Have you tried setting the esphome app in configuration to ping if mDNS isn’t doing the job?

3

no, but I entered it now and restarted ESPHome Device Builder and checked status… after awhile
image

4

image
image1331×419 9.27 KB

the settings are gone when I recheck the Config

5

Thank you for trying.

6

I was also wondering when I read the release notes on OTA queuing (neat idea, but how it would achieve that, if in the circumstances you are in without a serial intervention)

Are you compiling your code from a separate device than the one you are running ESPHome on?

Where is your target device plugged into? Where is your updating device on the network? Can the two see each other across the network? On what addresses and ports? Do you move and upload your compiled firmware files manually? Have you tried that to confirm your target device is not bricked?

I do updates routinely, having (because I chose to and have seen how flaky mDNS can be in certain configurations) fixed matching static IP Addresses in the ESPHome WiFi configuration and network devices like my router so that mDNS isn’t relied on.

Has something else already stolen that x.x.2.105 IP Address? Are you looking for it on another VLAN segment, firewalled from you? Is your network swallowing mDNS packets as they hop around between the router and access point devices? Is the DHCP IP address allocator on the same segment as your SSID it is attempting to connect to? Can you change it either way so they are the same device, on the router (full entire cold start between), and then on the access point (full restart again), just for troubleshooting purposes? Should you be seeing if the access point has low level system log entries you may find extremely interesting? Your router system log? WireShark? You need to traverse layers in your network stack vertically as well as horizontally.

Have you configured custom ports for each portion to speak over and forgotten some missing link?

You could have a play and have the two co-incode, sort of gamble like you do when mDNS works (feel the love here), or just pick a free IP Address, and start again, your yaml source backed up and intact, the two ends, arms open, skipping across the network, unerringly on the same path of collision, to loving converse, an ESPHome party… :wink:

What of your other ESPHome devices? Are they all consistently behaving the same way? Some or all? Does backing ESPHome out to an earlier version consistently restore the OTA functionality?

The full cold restart option: Is turning everything off, stone cold, voltage drained, and turning it all back on again, structurally for the process of elimination to be able to be followed, checking at each step, so the router comes up first, the access point connects to it, the HomeAssistant server next, the OTA server (if different) next, and the ESPHome devices last? Any other devices conveniently left switched off to prevent distraction.

Have you uncovered another bug, hidden in the idf or a corrupted compiler cache? The formatted detailed compile and run logs are missing, so I’m just guessing, based on experience, your problem is network linked rather than ESPHome or HomeAssistant based.

Chip away at it, isolating what is working, and the other broken bits should tinkle out. Keep us posted, [logs and yaml formatted </> for readability please]

7

Yes, use the ESPHome Command line tool:
esphome upload yourdevice.yaml --device 192.168.1.50

It’s been years since I used the CLI, so don’t ask me how.

8

Have you tried “use_address”

9

The IP Addresses of the following could prove insightful for basics:

The ESPHome device itself
The HomeAssistant server
The ESPHome device being compiled on
The router
The access point
Any virtual underlying platform

10

Status: SOLVED

Hi everyone,

I’m updating this thread to mark it as SOLVED and share the actual root cause of why my ESP8266 and ESP32 nodes failed to connect when migrating from an older router (RUT950) to a new Teltonika RUTX11.

Root Cause

It turned out to be a simple human error: the Wi-Fi password configured for the IoT SSID on the new RUTX11 router was incorrect.

Because WPA2/WPA3 authentication rejections do not explicitly output a clear “Wrong Password” error in standard device or router logs (instead timing out the 4-way handshake), it initially mimicked a DHCP timeout or a firmware negotiation issue. The client count would briefly jump to 2 and immediately drop back to 0 as the connection failed during the key exchange.

Solution

  1. Corrected the Wi-Fi password in the RUTX11 wireless configuration to match what the ESP devices expect.
  2. Once the correct password was applied and the Wi-Fi interface restarted, all ESP8266 and ESP32 devices immediately completed the 4-way handshake and received their DHCP leases instantly.

If you are experiencing similar issues where microcontrollers associate briefly but fail to grab an IP address after a router swap, definitely double-check your SSID credentials first!

11

Thanks for the time to clearly outline why the devices didn’t connect. A simple oversight causing so much grief.
The alternate CLI options may not have worked either, the essential network connections not available.
Glad you got it going, eventually,
Just confirming if the queued OTA updates happened automagically once the network connections were established?