ESPHome mDNS resolution problem

mondalaci · July 29, 2023, 11:46am

The mDNS name of my ESPHome node is resolved on some OSes (Android and OSX) but not on others (Linux Mint and Windows 10). On the contrary, the hostname of my Home Assistant Yellow, and other local hostnames are resolved by every host.

esphome:
  name: bearcave-monitor

esp32:
  board: az-delivery-devkit-v4
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "xxxx"

ota:
  password: "xxxx"

wifi:
  use_address: 192.168.1.119
  ssid: "monda-back"
  password: "xxxx"

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Bearcave-Monitor"
    password: "xxxx"

mdns:
  disabled: false

output:
  - platform: ledc
    pin: GPIO26
    id: gpio_26

# Example usage in a light
light:
  - platform: monochromatic
    output: gpio_26
    name: "Monitor Light"

i2c:
  scan: true
  id: bus_a

sensor:
  - platform: scd30
    co2:
      name: "Bear Cave SCD30 CO2"
      accuracy_decimals: 1
    temperature:
      name: "Bear Cave SCD30 Temperature"
      accuracy_decimals: 2
    humidity:
      name: "Bear Cave SCD30 Humidity"
      accuracy_decimals: 1
    temperature_offset: 1.5 °C
    address: 0x61
    update_interval: 5s

  - platform: ccs811
    eco2:
      name: "Bear Cave CCS811 eCO2"
    tvoc:
      name: "Bear Cave CCS811 VOC"
    address: 0x5A
    update_interval: 5s

On Linux, avahi-resolve is unable to resolve the ESPHome hostname.

$ avahi-resolve -n bearcave-monitor.local
Failed to resolve host name 'bearcave-monitor.local': Timeout reached

Thanks in advance!

koying · July 29, 2023, 1:21pm

Works both on Windows 10 and Ubuntu.

substitutions:
  device_name: esp-multi-mmwave

###########################################

esphome:
  name: "${device_name}"
  friendly_name: ESP8266 multi mmWave

C:\>ping esp-multi-mmwave.local

Pinging esp-multi-mmwave.local [192.168.3.138] with 32 bytes of data:
Reply from 192.168.3.138: bytes=32 time=7ms TTL=254

❯ avahi-resolve -n esp-multi-mmwave.local
esp-multi-mmwave.local  192.168.3.138

❯ ping esp-multi-mmwave.local
PING esp-multi-mmwave.local (192.168.3.138) 56(84) bytes of data.
64 bytes from esp-multi-mmwave.lan (192.168.3.138): icmp_seq=1 ttl=255 time=3.83 ms

Not using different VLANs, right?

mondalaci · July 29, 2023, 1:49pm

I’m not using different VLANs.

My ESPHome version is 2023.4.0, in case it matters.

orange-assistant · July 29, 2023, 2:01pm

What network gear are you using? And by chance got any snake oil in the mix which might break mDNS?

Not the latest and greatest but you might wanna check if later versions have any changes/improvments regarding mDNS in the change log or just go the quick road to 2023.7 to rule out any bugs in prior versions

paddy0174 · July 29, 2023, 2:07pm

That seems off… With this setting, you’re forcing the device to connect on this IP. This should only be there, if you’re changing your IP address while the device is online.

The next thing, please check your DHCP server for specific settings.

JulianDH · July 29, 2023, 2:10pm

Might want to check whether using static_ip rather than use_address resolves. I only use static_ip and my nodes show up on osx

koying · July 29, 2023, 2:18pm

It already shows up on OP’s OSXes

mondalaci · July 29, 2023, 2:53pm

paddy0174:

mondalaci:
wifi:
  use_address: 192.168.1.119
That seems off… With this setting, you’re forcing the device to connect on this IP. This should only be there, if you’re changing your IP address while the device is online.

The next thing, please check your DHCP server for specific settings.

I’m using use_address because mDNS doesn’t work, so I must use the IP address of the ESPHome node instead of its local domain name.

I could set up static DHCP for the MAC address of this ESPHome node, but I’d much rather fix the mDNS issue.

To my knowledge, use_address doesn’t affect the firmware, and the stock firmware of my Everything Presence One sensor, which is also based on ESPHome, is also affected by this mDNS issue.

paddy0174 · July 29, 2023, 3:01pm

No, you misunderstood. use_address is only, if you are changing something and need to send that to another IP address.

An example: your device has the IP x.x.x.200 and you need to change that for whatever reasons. If you now setup a new IP address (.100) in the firmware, the upload would go to the new IP address (.100). So to upload the firmware to the device (.200), having the new IP address in the firmware (.100), you need to tell ESPHome on what IP address (.200) you want the OTA to connect. That’s what use_address is for.

If you want to set a static IP in the ESP device, you need to use something like this:

wifi:
  ssid: !secret esphome_ssid
  password: !secret esphome_wifi_pw
  
  manual_ip:
    static_ip: 192.168.178.236
    gateway: 192.168.178.1
    subnet: 255.255.255.0
    dns1: 192.168.178.2

EDIT: To clarify, use_addressis only used for the connection while uploading a firmware from ESPHome. It in no way affects the regular IP address, so in your case the IP address the device uses, is set by DHCP, not from your device!

mondalaci · July 29, 2023, 3:49pm

I think I clearly understand the purpose of use_address, and I’m using it as intended. I use it to specify the actual IP address of my ESPHome node for uploading the firmware, given that it’s inaccessible via its mDNS name from my Linux Mint computer.

paddy0174 · July 29, 2023, 4:13pm

No, you don’t understand it. But as you think you’re right, than I and others can assume everything is peachy, your node is working as expected and without errors?! Great, than you can mark this topic as solved.

mondalaci · July 29, 2023, 6:39pm

You’re framing my comment as a way to make myself seem right and others wrong, which is not my intention.

Strictly speaking, based on your description, I may not be using use_address as intended but rather as a workaround. Nevertheless, my issue is still unresolved, and given the above, it’s probably rather unusual.

orange-assistant · July 29, 2023, 7:39pm

Like @koying I can confirm (not from a windows - don’t use that) but from a linux mint client that my esphome nodes IP’s are proper resolved via mDNS.

> ping solar.local

PING solar.local (192.168.0.36) 56(84) bytes of data.
64 bytes from solar.lan (192.168.0.36): icmp_seq=1 ttl=255 time=9.40 ms

So questions from my last post remain:

Some networking/firewalling gear might (partially) break mDNS functions - hence I’m asked about your network setup.

mondalaci · July 29, 2023, 8:18pm

Sorry for missing your question! I use a Sagemcom CS 50001 GPON gateway that my ISP provided. I’ve looked into its settings, and I couldn’t find anything that seemed related. There isn’t any other network gear between my Linux Mint desktop and the ESPHome node.

heisenberg · May 4, 2024, 12:20pm

@mondalaci did you find a solution for this issue? I am having the same issue now with one of my esphome devices, and it is really weird because I can access other esphome devices using their name.local address, but it doesn´t work for one specific devices with the same esphome code.

For instance device sonoff-bedroom works while sonoff-dressing-bedroom.local doesn´t work:

C:\>ping sonoff-bedroom.local

Pinging sonoff-bedroom.local [192.168.1.150] with 32 bytes of data:
Reply from 192.168.1.150: bytes=32 time=19ms TTL=255
Reply from 192.168.1.150: bytes=32 time=19ms TTL=255
Reply from 192.168.1.150: bytes=32 time=6ms TTL=255
Reply from 192.168.1.150: bytes=32 time=3ms TTL=255

Ping statistics for 192.168.1.150:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 3ms, Maximum = 19ms, Average = 11ms

C:\>ping sonoff-dressing-bedroom.local
Ping request could not find host sonoff-dressing-bedroom.local. Please check the name and try again.

EDIT: I just found out restarting my Access Point fixed the issue for that device, so it must be some problem related to the firmware of the Access Point (my Access Point is a router Huawei WiFi AX3 Quad Core in bridge mode)

mondalaci · May 4, 2024, 1:42pm

My issue is unsolved, and it’s not solved by a restart of my wireless gateway either.

yjkwi · May 4, 2024, 2:42pm

I was stuck in similar point. With network mode set to host,

the *.local hostname could NOT be resolved in ESPhome container
the *.local hostname could be resolved in host server of the ESPhome container.

For my case, it seems to be beacause ESPhome container doesnt use mdns to solve hostname, just use /etc/hosts and dns setting of host server.

Actually, when i installed and run avahi-daemon on ESPhome container, the *.local hostaname got resolved.

This is just about my case but hope it could be of kinda help.

koying · May 5, 2024, 9:46am

I have exactly the same symptoms since I upgraded ESPHome to the latest image.
It used to work perfectly fine, up to before the upgrade (I think from 2024.3, but it could be 2024.2, I didn’t pay attention) to 2024.4.2, and now mDNS just wouldn’t work inside the container, while it works on the host.
And yes, I’m in host network mode.

I’m puzzled…

I saw a changelog entry regarding IPV6 in 2024.3 and “Dualstack is added and it could now have up to 5 ip addresses of any type”, but I must admit I just have no clue what “dualstack” is in this context…

EDIT: My workaround:

docker-compose.yaml:

[...]
        environment:
            - "ESPHOME_DASHBOARD_USE_PING=true"
[...]

the_config.yaml

wifi:
    ssid: !secret wifi_ssid
    password: !secret wifi_password
    domain: ".lan"

Hence, the_config.lan is used instead of the_config.local, bypassing mDNS.

Assuming it’s not only us, I guess the problem doesn’t exists at all in HAOS for whatever reason, or there would have been a sh*tstorm already…

yjkwi · May 7, 2024, 9:01am

Thanks for the reposnse.
Actually this is my first installation of Esphome dashboard then i have no idea for previous versions(i am at 2024.4.2).
For my case just having small modification on docker-compose.yaml and preparing a Dockerfile to simply run avahi-daemon on the container is good enough.

docker-compose.yaml:

version: '3'
services:
  esphome:
      container_name: esphome
      build:
          context: .
          dockerfile: Dockerfile
      volumes:
        - ./config:/config
        - /etc/localtime:/etc/localtime:ro
        - /dev/ttyUSB0:/dev/ttyUSB0
        - /var/run/avahi-daemon/socket:/var/run/avahi-daemon/socket
      restart: always
      privileged: true
      network_mode: host
      environment:
        - USERNAME=user_name
        - PASSWORD=user_password

Dockerfile:

FROM ghcr.io/esphome/esphome
RUN apt update \
  && apt install -y avahi-daemon

Not really confident if this is the best way or not but working in my environment.

theblujuice · July 7, 2024, 12:54pm

if you ever come across this. This is how I solved my issue.
pfsense avahi installed, ensure Enable reflection is checked.
My NOT Network is only for my Isolated no internet devices. The mdnsip is 224.0.0.251