ESPHome Device Builder stops resolving IP shortly after start up

I’m running the ESPHome Device Builder add-on on my Home Assistant server and was able to build and install a config over Wi-Fi to my ESP32 S3 board. The device shows up in Home Assistant and seems to be working.

However for some reason, while it reports the device as “online” in Device Builder it throws an error (below) when I try to upload a updated device configuration. If I restart the device I am usually able to upload a new configuration. This is not a big deal with one device, but I can see where it’s going to get old fast if this trend continues.

INFO Successfully compiled program.
ERROR Error resolving IP address of ['esphome-web-c9c344.local']. Is it connected to WiFi?
ERROR (If this error persists, please set a static IP address: https://esphome.io/components/wifi.html#manual-ips)
ERROR Timeout resolving IP address: Timeout while resolving IP address for ['esphome-web-c9c344.local']
WARNING Failed to upload to ['esphome-web-c9c344.local']

The device has a DHCP reservation and a local host name defined on my router. I can ping it by hostname from other systems.

I’m running ESPHome 2025.11.2 on Home Assistant OS. Version numbers are currently:

  • Core 2025.11.3
  • Supervisor 2025.11.5
  • Operating System 16.3
  • Frontend 20251105.1
  • ESPHome Device Builder 2025.11.2

The device is an M5 AtomS3 Lite with the NS4618 speaker board module atttached. It’s configuration YAML is:

esphome:
  name: esphome-web-c9c344
  friendly_name: ESPHome Web c9c344
  min_version: 2025.9.0
  name_add_mac_suffix: false

esp32:
  variant: esp32s3
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
- platform: esphome

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

captive_portal:

i2s_audio:
  - id: i2s_audio_bus
    i2s_lrclk_pin: GPIO39
    i2s_bclk_pin: GPIO05

media_player:
  - platform: i2s_audio
    id: media_out
    name: None
    dac_type: external
    i2s_dout_pin: GPIO38
    mode: mono

binary_sensor:
  - platform: gpio
    pin:
      number: GPIO41
      inverted: true
    id: top_button
    name: Button
    on_click:
      - media_player.toggle:
          id: media_out

light:
  - platform: esp32_rmt_led_strip
    id: led
    name: AtomS3 lite Light
    pin: GPIO35
    chipset: ws2812
    num_leds: 1
    rgb_order: grb

button:
  - platform: safe_mode
    id: button_safe_mode
    name: Safe Mode Boot

  - platform: factory_reset
    id: factory_reset_btn
    name: Factory reset

sensor:
  - platform: uptime
    type: seconds
    name: Uptime Sensor

Hi
I see it advises you to go to esphome page about setting a manual IP in your esphome yaml for the device. Have you tried this. I know you have set a static ip on your router.

You are having mDNS issues.
Are you using VLANs or guest WiGi or any WiFi segregation?

I have VLANs in my network that makes mDNS less than reliable. I’ve added the following stanza to all my ESPHome configs to make ESPHome use my network’s domain instead of “.local”:

wifi:
  domain: .mylocaldomain.com

I also have enabled the “Use ping for status” option in ESPHome Device Builder’s configuration.

I have not had any problems since making those changes.

There is another thread with this same issue that has discussion on this bug.

I have not tried a static IP address yet, as I was hoping to manage address assignment for the devices via DHCP.

No, the network is a single VLAN. There are two WiFi SSIDs (one for regular equipment, one for IoT devices) but they both use the same subnet as the wired equipment.

So HA, Matter server, Matter device and commissioning device (Android or iOS) is on th same network and none of them have multiple NICs?

I’m not using Matter to my knowledge, but yes, all of the equipment is on the same network and none of them have more than one NIC.

Sorry, got mixed up with another question, but it still goes here too.
Test if you can resolve the IP from other machines on the network, when it fails in HA.
If it fails on other machines too, then the issue is not with the ESPHome addon, but with your network in general.