mDNS issues with ESPHome (perhaps?)

Just checking to see if others are having the same issues I have started having recently.

The underlying issue is that most of the ESPHome nodes are showing as offline in the ESPHome Building window but are still updating the various values in the other displays.

However when I try to update any of them, they compile correctly but then, when they come to the OTA update part, they report either "error resolving IP address" (which means they cannot translate the host name to an IP address) or "no path to host" (the name has been translated but HA cannot connect to the node).

I've tried to restart the ESPHome nodes and they show up for a few moments and then 'disappear' from the ESPHome Builder display. Similarly when I restart the router then they show up as connected but then 'disappear' from that systems display - by this I mean they don't show as connected but 'ping' and 'traceroute' show them all, and the WiFi device shows them as active and transferring packets.

All this makes me think the mDNS systems in the ESPHome nodes is not working correctly.

All the nodes are either ESP32S3 or ESP32C3 MCU's. Also I don't think this is an issue with the signal strength - most are showing in the -45dBm to -65dBm range at the WiFi node and one that is giving trouble is right next to it with -28dBm.

Are others having similar issues?

Any information that I can provide that might help track this down?

Susan

Are you using VLANs? It does sound like an mDNS issue, and having ESPHome and your devices on separate VLANs would cause that. How do you have ESPHome installed— ESPHome as an app inside HAOS, or are you running a separate ESPHome docker container?

Typical options would be:

  1. Flatten your network by eliminating VLANs. A flat network is what is recommended by the documentation.
  2. If you don’t want to flatten your entire network, at least ensure the devices and ESPHome are on the same subnet.
  3. Use ping instead of mDNS for the dashboard to determine online/offline status (but this won’t affect connectivity during OTA updates). Relevant docs here.
  4. Use a static IP in your YAML config for each device. This won’t affect the dashboard’s online/offline reporting but will address oTA flashing issues
  5. Set up firewall and routing rules to ensure the ESPHome container can talk to your device and that mDNS is routed between the subnets
  6. Add HA to each network/VLAN, as described here.
1 Like

I confirm the issue

Ah yes - I should have said....

All nodes on my local network are on the same subnet - no VLANs involved at all.

HA itself runs on a Raspberry Pi 5 which is also on the same subnet so no firewalls etc are present (except in the router to the Internet). ESPHome runs inside HA.

I generally use DHCP so having host names is quite important. Therefore I'm reluctant t have to create static addresses for all of the ESPHome nodes (but I guess if that is the only solution then I'll have to go that way).

I'm seeing the same behaviour here, was fine with 2026.5.0, broke with 2026.5.1.

My ESPHome camera node is an ESP32 S3 and I can ping it just fine from my Mac:

Inventor7777@Mac-Studio - 17:59 ~ % ping sr-esp-cam.local
PING sr-esp-cam.local (192.168.50.159): 56 data bytes
64 bytes from 192.168.50.159: icmp_seq=0 ttl=64 time=54.308 ms
64 bytes from 192.168.50.159: icmp_seq=1 ttl=64 time=20.530 ms
64 bytes from 192.168.50.159: icmp_seq=2 ttl=64 time=9.977 ms
64 bytes from 192.168.50.159: icmp_seq=3 ttl=64 time=8.228 ms

My HA server also sees it okay:

root@HAOS-M710q - 18:01 /root # ping sr-esp-cam.local
PING sr-esp-cam.local (2600:8807:3d00:15:9270:69ff:fe14:d380): 56 data bytes
64 bytes from 2600:8807:3d00:15:9270:69ff:fe14:d380: seq=0 ttl=255 time=66.839 ms
64 bytes from 2600:8807:3d00:15:9270:69ff:fe14:d380: seq=1 ttl=255 time=82.837 ms
64 bytes from 2600:8807:3d00:15:9270:69ff:fe14:d380: seq=2 ttl=255 time=22.628 ms

ESPHome Device Builder resolves it:

INFO ESPHome 2026.5.1
INFO Loaded validated config cache for sr-esp-cam.yaml, skipping validation.
INFO Starting log output from sr-esp-cam.local using esphome API
INFO Successfully resolved sr-esp-cam.local in 0.129s
INFO Successfully connected to sr-esp-cam @ 2600:8807:3d00:15:9270:69ff:fe14:d380 in 0.014s
INFO Successful handshake with sr-esp-cam @ 2600:8807:3d00:15:9270:69ff:fe14:d380 in 0.111s
[18:04:43.668][I][app:151]: ESPHome version 2026.5.1 compiled on 2026-05-26 00:01:55 -0500
[18:04:43.668][I][app:158]: ESP32 Chip: ESP32-S3 rev0.2, 2 core(s)

Firmware version: Firmware: 2026.5.1 (2026-05-26 00:01:55 -0500)

I might have come across something : I took one of the nodes that was giving trouble at put it on my desk so I could look at its logging (via USB - WiFi wouldn't work) and I saw:

[10:38:14][D][wifi:1437]: Found networks:
[10:38:14][I][wifi:1408]: - 'Iota' [redacted]▂▄▆█ Ch:13 -63dB P:0
[10:38:14][D][wifi:1828]: Retry phase: INITIAL_CONNECT → SCAN_CONNECTING
[10:38:14][I][wifi:1076]: Connecting to [redacted] [redacted] (priority 0, attempt 1/2 in phase SCAN_CONNECTING)...
[10:38:15][I][wifi:1546]: Connected
[10:38:15][D][wifi:1563]: Disabling AP
[10:38:15][C][wifi:1216]:   IP Address: 10.1.1.134
[10:38:15][C][wifi:1227]:   SSID: [redacted]
[10:38:15][C][wifi:1227]:  BSSID: [redacted]
[10:38:15][C][wifi:1227]:  Hostname: 'bathroom-humidity'
[10:38:15][C][wifi:1227]:  Signal strength: -63 dB ▂▄▆█
[10:38:15][C][wifi:1227]:  Channel: 13
[10:38:15][C][wifi:1227]:  Subnet: 255.255.255.0
[10:38:15][C][wifi:1227]:  Gateway: 10.1.1.1
[10:38:15][C][wifi:1227]:  DNS1: 10.1.1.25
[10:38:15][C][wifi:1227]:  DNS2: 0.0.0.0
[10:38:15][W][component:422]: wifi cleared Warning flag
[10:39:11][I][safe_mode:091]: Boot seems successful; resetting boot loop counter
[10:39:13][D][preferences:152]: Writing 1 items: 0 cached, 1 written, 0 failed
[10:43:15][D][wifi:2415]: Roam scan (-62 dBm, attempt 1/3)
[10:48:15][D][wifi:2415]: Roam scan (-63 dBm, attempt 2/3)
[10:53:11][E][api:127]: No clients; rebooting
[10:53:11][I][app:247]: Forcing a reboot
[10:53:11]ESP-ROM:esp32c3-api1-20210207
[10:53:11]Build:Feb  7 2021
[10:53:11]rst:0xc (RTC_SW_CPU_RST),boot:0xd (SPI_FAST_FLASH_BOOT)
[10:53:11]Saved PC:0x40385232
[10:53:11]SPIWP:0xee
[10:53:11]mode:DIO, clock div:1
[10:53:11]load:0x3fcd5830,len:0x15ac
[10:53:11]load:0x403cbf10,len:0xba4

Note the line at 10:53:11 saying "No clients; rebooting"
That occurred almost exactly 15 minutes after the previous reboot (which occurred for the same reason 15 minutes after that reboot).

So it would appear to me that the node is OK but for some reason ESPHome in HA is not accessing it (even through the 'ESPHome Builder' display is showing it as 'ONLINE').

@inventor7777 - As I said in my original post, I'm having trouble with most of my ESPHome nodes but this implies not all. The nodes that are not failing do respond to pings etc..

I've tried looking at the various characteristics of my nodes to see if there is a pattern to the ones that are working and those that are not but there is no definite pattern. Most of the nodes are on ESPHome 2026.4.5 but there is a mix of those that work and don't. I do have 2 nodes with one on 2026.5.0 and the other 2026.5.1 that are working so I' going to see if I can update the node that is now on my desk to see if that changes anything.

I've also looked at for the platform (esp-idf vs arduino) and the maker of the MCU (Seeed mostly and Espressif themselves for one) but again the results are all over the place.

The only pattern I've seen is that the issue seemed to start on the 25th of May at between 10AM and 12 Noon (which is when I would have updated something) in that that is the date/time of the last data recorded for the failing nodes.

I have my DHCP fixed addresses, but I don't use those in HA, and instead let discovery work to resolve its IP.

I'm not clear when HA decides when to look up the IP -- every boot or just once during discovery. If I run jq . config/.storage/core.config_entries | less and look at my devices it shows both the IP and the mDNS name -- so might be interesting to see what that show and matches the device's actual IP.

      {
        "created_at": "2024-10-23T18:29:11.446336+00:00",
        "data": {
          "device_name": "gas-meter",
          "host": "192.168.0.197",
          "noise_psk": "hrMgPQo1ImGmSoFJhnfVr4fwAOZPr5ujmdq7ffnjjmI=",
          "password": "",
          "port": 6053
        },
        "disabled_by": null,
        "discovery_keys": {
          "dhcp": [
            {
              "domain": "dhcp",
              "key": "64e8337e06dc",
              "version": 1
            }
          ],
          "zeroconf": [
            {
              "domain": "zeroconf",
              "key": [
                "_esphomelib._tcp.local.",
                "gas-meter._esphomelib._tcp.local."
              ],
              "version": 1
            }
          ]
        },

Anything in this thread that might help?

@busman - I was not aware you could run that command but the following are two of my entries:

      {
        "created_at": "1970-01-01T00:00:00+00:00",
        "data": {
          "device_name": "gasmetermonitor",
          "host": "10.1.1.202",
          "noise_psk": "y98VCvOJS8aHdc5ZGUUvf+M+voxw/bIMHYgH7Q2PZiU=",
          "password": "",
          "port": 6053
        },
        "disabled_by": null,
        "discovery_keys": {
          "dhcp": [
            {
              "domain": "dhcp",
              "key": "64e83383cb40",
              "version": 1
            }
          ],
          "zeroconf": [
            {
              "domain": "zeroconf",
              "key": [
                "_esphomelib._tcp.local.",
                "gasmetermonitor._esphomelib._tcp.local."
              ],
              "version": 1
            }
          ]
        },
        "domain": "esphome",
        "entry_id": "xxxxxxxxxx",
        "minor_version": 1,
        "modified_at": "2026-05-25T01:31:03.812307+00:00",
        "options": {
          "allow_service_calls": false
        },
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "zeroconf",
        "subentries": [],
        "title": "GasMeterMonitor",
        "unique_id": "xxxxxxxxxxx",
        "version": 1
      },
      {
        "created_at": "1970-01-01T00:00:00+00:00",
        "data": {
          "device_name": "watermonitor",
          "host": "10.1.1.191",
          "noise_psk": "J4VHQFkXxuReKFpJ14ktlS6Yf2+zLOlDhHZwR52KHU0=",
          "password": "",
          "port": 6053
        },
        "disabled_by": null,
        "discovery_keys": {
          "dhcp": [
            {
              "domain": "dhcp",
              "key": "64e8338415d4",
              "version": 1
            }
          ],
          "zeroconf": [
            {
              "domain": "zeroconf",
              "key": [
                "_esphomelib._tcp.local.",
                "watermonitor._esphomelib._tcp.local."
              ],
              "version": 1
            }
          ]
        },
        "domain": "esphome",
        "entry_id": "xxxxxxx",
        "minor_version": 1,
        "modified_at": "2026-05-25T01:31:07.781394+00:00",
        "options": {
          "allow_service_calls": false
        },
        "pref_disable_new_entities": false,
        "pref_disable_polling": false,
        "source": "zeroconf",
        "subentries": [],
        "title": "WaterMonitor",
        "unique_id": "xxxxxxxx",
        "version": 1
      },

The 'gasmetermonitor' entry works perfectly while the 'watermonitor' one reboots every 15 minutes with the device and all of its measurements showing as 'unavailable'.

I'm actually starting to wonder if there is something 'wrong' with my network. For example:

susan@Susans-iMac build % ping gasmetermonitor.local
ping: cannot resolve gasmetermonitor.local: Unknown host
susan@Susans-iMac build % ping 10.1.1.202           
PING 10.1.1.202 (10.1.1.202): 56 data bytes
64 bytes from 10.1.1.202: icmp_seq=0 ttl=64 time=308.608 ms
64 bytes from 10.1.1.202: icmp_seq=1 ttl=64 time=123.690 ms
^C
--- 10.1.1.202 ping statistics ---
2 packets transmitted, 2 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 123.690/216.149/308.608/92.459 ms
susan@Susans-iMac build % ping watermonitor.local
PING watermonitor.local (10.1.1.191): 56 data bytes
64 bytes from 10.1.1.191: icmp_seq=0 ttl=64 time=41.803 ms
Request timeout for icmp_seq 1
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
^C

So I can ping the gas monitor by IP but not name, but the water monitor name did resolve (this time - it often doesn't!) and the ping did go though once but then timed out. Strange (to me at least).

(BTW both of these nodes are within 1 metre of each other)

Looks like you are on a Mac. I assume you have dns-sd command. On my Mac I can query the mDNS like this and fetch the IP. See if that give any clues. (See below)

Probably need the ESPHome logs for the water monitor to see what it's doing.

The reboot every 15 minutes makes sense if the API isn't connecting.

I assume you tried "Reload" for the device in the ESPHome integration and/or remvoing it and adding it back in.

This is on my mac for my gas meter:

$ dns-sd -B _esphomelib._tcp. | grep gas
22:01:14.739  Add        3  14 local.               _esphomelib._tcp.    gas-meter
^C

$ dns-sd -G v4 gas-meter.local
DATE: ---Tue 26 May 2026---
22:01:26.469  ...STARTING...
Timestamp     A/R  Flags         IF  Hostname                               Address                                      TTL
22:01:26.710  Add  2             14  gas-meter.local.                       192.168.0.197                                120

$ ping gas-meter.local
PING gas-meter.local (192.168.0.197): 56 data bytes
64 bytes from 192.168.0.197: icmp_seq=0 ttl=64 time=12.102 ms
64 bytes from 192.168.0.197: icmp_seq=1 ttl=64 time=123.623 ms
^C

And back to this:

The lookup is either hitting the cache or it's asking the device for its IP (from my understanding) and then it can't ping it. So, either the device is not responding to pings or the lookup is wrong.

This still works when my "gas-meter" is unplugged because it's cached:

$ dns-sd -q gas-meter.local
DATE: ---Wed 27 May 2026---
 8:15:58.326  ...STARTING...
Timestamp     A/R  Flags         IF  Name                          Type   Class  Rdata
 8:15:58.644  Add  2             14  gas-meter.local.              Addr   IN     192.168.0.197
^C

But if I then flush the cache it no longer shows up:

$ sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

$ dns-sd -q gas-meter.local
DATE: ---Wed 27 May 2026---
 8:17:39.683  ...STARTING...
^C

And then plugging back in it will almost immediately resolve again.

$ dns-sd -q gas-meter.local
DATE: ---Wed 27 May 2026---
 8:20:15.997  ...STARTING...
Timestamp     A/R  Flags         IF  Name                          Type   Class  Rdata
 8:20:16.000  Add  40000002      14  gas-meter.local.              Addr   IN     192.168.0.197
^C

In other words, I'd check if the ESPHome device is doing what is expected.

BTW, I stopped HA, modified the IP address (to make it incorrect) in core.config_entries and started it back up and it connected to the ESPHome device. The logs don't show it resolving, but it must do the lookup when connecting instead of using the IP in core.config_entries.

I assume you haven't changed the "name" or specified an IP address in the device's config, right?

Time for 'red faces' on my part.

For a separate project I fired up a new Raspberry Pi Zero w with a brand new installation of Trixie (32-bit, no desktop etc.). I then found the same situation - the new node was connected to the WiFi AP and I could ping and ssh to it by the IP address but not the host name.

I have a Unifi Nano HD AP and so did some searching about that. The most common 'fault resolution' for that device seemed to be the old "turn it off and turn it on again" (apologies to the IT Crowd).

I did that and all of the ESPHome nodes came to life again (except one that I've had a long standing item on my 'to do' list to sort out).

My apologies for the 'noise' in this forum, and my thinks to those how have come to my assistance.

Susan (who has re-learned an old lesson)

2 Likes

That'll do it! Does UniFi have a scheduled reboot option? You could probably set it to reboot at late night weekly or monthly to prevent those sort of issues in the future :laughing: