How to use domain names .local with ESPhome and ESP32

ESPHome
1

The problem: When you create sensor or web server with esphome, it is usually published on local network as sensorname.local (where sensorname is name of sensor). That can be identified easily by another ESPhome device which is based on ESP8266. However, ESPhome devices based on ESP32 chip cannot find sensorname.local, because they have problem to identify .local domain. The reason is unclear, it seems to me that there is older library using mDNS resolution mechanism than that in ESP8266.

The workaround is to find IP address of sensorname.local by own mDNS lookup and then use that IP adress instead of sensorname.local. If IP address change (because we often use dynamic IP allocation in our routers), then it will be correctly identified by mDNS lookup script. Here is example, that connects from ESP32-based ESPhome sensor to another ESPhome sensor and reads value:

  1. You have to include library (put full path of library there):
esphome:
  name: blinds-brain
  platform: ESP32
  board: firebeetle32
  includes: /full-path-to/ESPmDNS.h
  platformio_options:
    upload_speed: 921600

http_request:
  useragent: esphome/device
  timeout: 10s
  1. Use following example lambda script to connect to sensorname.local and retrieve value (in this case the sensor name is blinds-cs1, which could be addressed as blinds-cs1.local by ESP8266, but not by ESP32):
  - platform: template
    name: "Received color1"
    id: received_color1
    accuracy_decimals: 0
    update_interval: 2s
    lambda: |-
      HTTPClient http2;
      IPAddress serverIp = MDNS.queryHost("blinds-cs1");   
      while (serverIp.toString() == "0.0.0.0") {
        delay(250);
        serverIp = MDNS.queryHost("blinds-cs1");
        }
      http2.begin("http://"+serverIp.toString()+"/sensor/color_nr");
      http2.GET();
      DynamicJsonBuffer doc(5000);
      JsonObject& root = doc.parseObject(http2.getStream());
      int color = atoi(root["value"].as<char*>());
      return color;
1 Like
2

Making HTTP request from ESP8266 board is very simple and straight-forward process.

You can look at the WebClient example that is installed with the ESP8266 library.

Then - after you craft the URL you’re querying and you know the format of the answer you get - you just test for it to decide what to do with your LEDs.

Please let know if there is a need for more clarifications or code sample.

3

You should really be using static IP addresses for your IoT devices. Smarter and saves a lot of headaches. I keep a spreadsheet of all my devices… it’s pretty big!

4

I usually use static IP’s as well. But now I have challenge to prepare set of sensors that need to cooperate together and they will go to other WLAN. So if I don’t know what is the router there, gateway IP, list of available IP’s, then domain names is the only choice.

1 Like
5

Hello Gonzales, your answer does not seem to be related to my post. Yes, HTTP requests from ESP8266 are easy, but I was solving mDNS name resolution on ESP32, which is not working well. Also, retrieving and serializing json response from server is not that easy either, because JSON v6 library used in Arduino SDK is not compatible with JSON v5 library used in esphome.

6

Another alternative is to define your own (local) domain in your router as well as esphome config…

what I did:

  • added a domain name in my router f.e. assistant.url
    image
    image829×471 8.61 KB
  • added a lease for a device on it’s IP f.e. 192.168.100.100 and gave it a name f.e. home
    image

Added domain to esphome config:

  domain: assistant.url

After that, all your devices should be able to resolve home.assistant.url as the reserved IP

(home.assistant.url should equal your qualified https dns name :innocent:)

7

Any progress on this?

I opened an issue yesterday for what seems to be the same problem:

8

There is lots of talk about network switch or access point issues being the cause of the ESP32 mDNS issues, or changing ESPHome config to static IP address to work around the issue.

However I have noticed on my network that GoogleCast devices, my HP wifi printer, ESP8266 (Lifx bulbs?) and ESP8285 (Athom Smartplug V2) based devices have no problem maintaining an mDNS registration with my HP Aruba access point (HP calls this the AirGroup cache) :

(below is AirGroup cache entry for an example SmartPlug using ESP8285 chip)

_esphomelib._tcp.local                             PTR         IN     4500
athom-smart-plug-v2-3ff451._esphomelib._tcp.local  SRV/NBSTAT  IN     4500
athom-smart-plug-v2-3ff451._esphomelib._tcp.local  TXT         IN     4500
athom-smart-plug-v2-3ff451.local                   A           IN     120

the A-record has the recommended time-to-live of 120 seconds. It seems that the ESP8266 and ESP8285 are able to regularly re-advertise to maintain the mDNS registration.
The other records have a TTL of 4500 seconds (or 1.25 hours).

This set of 4 records gets updated timestamps on a regular basis, and remains in the cache for days and days (while-ever the device is powered on)

However, I have noticed devices with the ESP32 ESPHome codebase seem to do the initial advertisment, but they dont maintain the mDNS advertisement and so the cache entry gets stale and is purged from the AP cache. From the moment the records are purged, I can obviously no longer resolve the xxxx.local hostname to its IP address.

Maybe this is a bug in the mDNS library as implemented specifically on the ESP32 chip?

9

This is very specific to your product. mDNS is build to don’t need/have a central server (unlike DNS). Devices using mDNS communicate with each other directly. Most problems regarding network are typically firewall functions blocking mDNS traffic (this ubi thingies are prone to that if you follow discord).

If you can maybe just try to disable this “AirGroup” function completely and see if things work.
Anyways there is still DNS in your network which should resolve fine always :bulb:

10

I think I may not have been clear.

All switches and access points need to have multicast support turned on in some manner for this to work. sometimes it will be a simple permit of IGMP snooping on a simple switch, other times it could be multicast to unicast conversion on an access point.

== Turning that feature off will guarantee that mDNS wont work. ==

The point of the Aruba AirGroup cache is to show visibility of what the AP has seen with multicast traffic on the network.

My main comment was this :
ESP8285 devices maintain all required ESPHome related mDNS entries (aka the generic _esphomelib._tcp.local entry which ALL ESPHome devices advertise, as well as the device specific names) and refresh those advertisements regularly.

my ESP32 devices do the initial advertisement, and this is shown in the cache report. But after the initial TTL expires, the network cannot see any further advertisements or responses and the records are purged from the cache. At this point it is no longer possible to resolve xxxx.local using mDNS, and ESPHome plugin to HASS will show device as offline.

This seems to indicate that the ESP32 device software (or at least the mDNS library) is not operating the same way as the ESP8266 or ESP8285

11

Interesting. All my esphome nodes (esp82xx and esp32) are always reachable via .local (mDNS). I don’t own that fancy network gear but essential use only old hardware with openwrt.

Can you reproduce this behavior on a little test setup which doesn’t include Aruba hardware? You might be able to narrow down the problematic parts…