Setting ESPHome to use Ping instead of mDNS worked like a charm! But are there any downsides to this? Or can I just leave it at using Ping and be happy? 
I’ve been running it like that for a month or so with no issues. But I really don’t use it very often since all of my devices are already programmed.
I just stumbled on something that might help some people as well.
There is a tag for wifi domain, but default it is set to .local.
**domain** ( *Optional* , string): Set the domain of the node hostname used for uploading. For example, if it’s set to .local, all uploads will be sent to .local. Defaults to .local.
# Example configuration entry
wifi:
ssid: MyHomeNetwork
password: VerySafePassword
domain: .local
I changed this to the domain my router has and suddenly the little green dots finally work!
This is across subnet too - the only downside is that the button to open the web-interface still goes to .local… but I’ll take it! Strike that - I refreshed ESPHome Dashboard, and the button for the web interface is now pointing to the correct domain too!
Everything seems to be working correctly now - just with adding the domain key to the WIFI setup. I am now very happy with this fixed!
Cheers!
DeadEnd
4 Likes
Setting domain: “” was exactly what I needed to make ESPHome work for me on Windows Docker.
My router with caching name server is set to include names of DHCP devices. So I could open the CLI and ping test_node1. But ESPHome was trying to contact test_node1.local and failed. As soon as I set the domain to null, everything started working.
I’m having the same issue on HA running on a pi. I tried configuring through add on configuration in UI, but it made no difference. Any idea on how to configure it to ping instead of mDNS. My sensor is working perfectly apart from this, the ESP home sees it online for a few seconds when I restart it and then status changes to offline but everything keeps functioning other than that.
Who cares, as long as it is working?
But it is dealt with just above here https://esphome.io/guides/faq.html?highlight=ping#can-configuration-files-be-recovered-from-the-device
Add the environment variable ESPHOME_DASHBOARD_USE_PING=true as @finity noted above. Also documented here Frequently Asked Questions — ESPHome.
To add the variable with HA addons: ssh into your HA then open the addons.json file.
Look for "description": "ESPHome add-on for intelligently managing all your ESP8266/ESP32 devices", then append:
"environment": {
"ESPHOME_DASHBOARD_USE_PING": "true"
},
Documentation on Add-on config: Add-On Configuration | Home Assistant Developer Docs
No; in the addon use the configuration tab and tick the status_use_ping option.
That would certainly make things easier but I can’t seem to find that option. Running version 1.20.1 and use browsers in private/incognito mode. No luck in the mobile app neither.
Click on the “Show unused optional configuration options”
I haven’t tried the addon myself. I’m running esphome in a Docker container. But wouldn’t “unused optional configuration options” be the same as “non-functional”? I.e. not implemented?
No, the ones you haven’t used are hidden so that they do not clutter up the interface.
I mean, you may know better, but as you don’t use the addon, it seems unlikely.
Ah, thanks for the input. I’ve just gone over from HA Core to HA Supervised, and have almost all addons as separate Docker containers so far. Thinking of moving the HA related containers over to the HA addons instead, if only for maintaining compatibility. 
Related??
mdns didn’t work
Just curious… My ESPHome devices are on a wifi network that uses VLAN 20 (or is it a subnet?), while my HA is on a separate network. They communicate well despite this because my firewall and routing settings seem to be well-configured. I wonder why it is that the ESPHome dashboard in HA shows the ESP devices offline, but if I reboot one of them (or unplug/plug 5V power) it will come back online just long enough for me to flash it over wifi …and then after some time has passed the device is once again offline and its IP address cannot resolve if I try to flash it. No biggie, I can always just reboot when I am ready to flash. But I’m wondering why this is so.
Have you enabled the use_ping option as described above?
People need to learn about mDNS. I don’t know much about it, but for example a quick google shows me this quote
mDNS’s uses of multicast packets is designed to work within a single IP subnet . That is, mDNS traffic does not cross from one IP subnet to another. As a result, mDNS can be used among a set of devices that are all attached to a single IP subnet, but cannot be used among devices attached to different IP subnets.
And yes you can get repeaters to transfer mDNS across subnets.
I know even less about VLANs but no doubt google can help that too.
Thanks for the reply. I turned it on for a bit and didn’t see any difference; all the ESP nodes still communicated well with HA but were offline in the dashboard. But I toggled it back off because I didn’t see any benefit in leaving it on.
Even if use_ping had resulted in the nodes becoming Online in the dashboard, I’d still be in the dark as to why. I’m not so concerned with making them Online as I am curious as to why this phenomenon occurs. I just find it interesting that they become Online briefly upon bootup, but they eventually go Offline.
I think I’ve fix this issue for me. If you use Adguard or some other non-conventional DNS server, this might be similar to your situation too.
Summary:
Having something like avahi-browse -ar do discovery and spit out a list of found devices and their hostname+IP address, is completely separate from a tool like ping or curl or whatever that completes mostly standard DNS resolution to figure out the IP address to conga-drums.local. Either if the container isn’t setup to look up mDNS first before calling a DNS server (which neither HA or the ESPHome containers do) or your DNS server doesn’t know about any .local hostnames, regardless of if stuff in that container can find out about devices via avahi-browse -ar, none of the other components part of that service will be able to resolve the IP address and talk with them.
My fix was to spin dnsmasq back up on a different port than 53 with only offering up resolution for .local domains, and then add that to the “Upstream DNS servers” list in Adguard (for specific domains). Once that was done all of my containers could resolve conga-drums.local.
I’ve got a lengthier post going into more details at the tail end of this HA bug.
I’m going to paste this around to a few other related threads, because I burnt a whole day trying to figure this out. Hope this helps some of you.