Setting static IP for ESPHome devices advised?

What about the scenario of (easier) blocking of internet access for the device? My main use of static ip is setting the gateway to the same ip address.

static_ip: 10.17.25.12
gateway: 10.17.25.12
subnet: 255.255.255.0

Stops that device being able to communicate externally while still being accessible internally.

1 Like

Best would be just to use VLAN for that “scenario” and don’t mess with static IP’s in the Year 2022 :fireworks:

Are you aware that YOU are in total control (:muscle:) of the device if you run esphome? By default their should be actually no connection (in numbers :zero:) to the outside of your network :raised_hands:

True, but I’d suspect most people do not have a router/switch that gives them the ability to utilize VLANs. With the prevalence of ‘mesh networks’ currently, most manufacturers don’t even give you a webGUI to use.

Again, true, however I’d prefer to make sure of that with an extra 3 short lines of code.

A few years ago, I stopped assigning static IP addresses to my ESPhome devices, and other than consuming an additional ten or fifteen of the available 155 IP addresses, life was good. :slight_smile: Everything ESPHome worked just perfectly with DHCP. Not so in the last few months, and I’m still pointing fingers at Asus router firmware and Broadcom’s AX wireless technology. A handful of my ESP8266 devices (D1 Mini clones) have dropped offline, and don’t appear in Home Assistant. What I have observed: several device DNS node names appear on my router as Espressif instead of the assigned DNS node name daylight-sensor or outdoor-lighting.

This seems to suggest something in the Arduino/ESPhome code is no longer properly establishing the assigned DNS name when joining the network?

Which in turn causes mDNS lookups for ESPHome connectivity to fail.

1 Like

I use DHCP reservations in the router but have to use the static_ip assignments in my esp8266 yaml files in order to get consistent connections. I found this while troubleshooting, make sure Bonjour is running on my windows pc and then use this cmd and get a list of devices that are running. I guess the dns-sd.exe command gets loaded with Bonjour service from iTunes.

Execute this from a Windows command prompt. cntrl-c to end it.

dns-sd -B _esphomelib._tcp

Not to confuse different things: DHCP/DNS from your router works Independent from mDNS :warning: In fact you don’t even need a router to have mDNS working :raised_hands:

1 Like

I concur about DHCP/DNS and mDNS services being separate entities.
My ESPHome devices work better with static IPs as I mentioned so there’s no name resolution required. Thery’re mostly battery operated and use the deep sleep component. So, the static IPs provide quicker Wi-Fi startup when they wake up. It gave me some comfort knowing the mDNS component of ESPHome was functioning when I was able to interrogate the _esphomelib._tcp service from my Windows laptop and see my devices responding.

1 Like

I was using a manual_ip configuration in the device “and” a DHCP reservation for that IP in the router. In hindsight that seems wrong, but it was working.
I wonder exactly how much time is saved by not using DHCP when coming out of a deep sleep?
People say that, but is it significant?
The documentation says “dramatically” but that’s not a very quantitative statement.

You just went with static IP’s then because your esphome nodes didn’t send DHCP requests at all when configured with manual IP :bulb:

You could activate DHCP on your esphome nodes, test it and tell us your mileage how long the 4-way handshake takes in your setup :muscle:

1 Like

I am in the process of removing static IP’s from my ESPHome devices & moving to static IP’s in DHCP. Although I’m also considering using both.

I do like the quicker connect with static IP in device YAML. But have found that static IP’s in some devices along with dynamic DHCP for other (non-ESPHome) devices has been causing IP address conflicts. DHCP doesn’t know about the hard-coded device IP’s, if they haven’t checked in for awhile, and esp. if they’ve been offline for a while, which occurs with some of my spare smart plugs.

Which is why you shouldn’t assign static IPs in the DHCP range. Narrow the DHCP range in your router settings and use static IPs outside that range.

Eg. I have set my DHCP range from .150 to .254.
Anything lower than .150 is left available for static IPs

1 Like

Yeah, I’ve already got some range that is outside of DHCP scope. I might have to rethink and rebuild / reassign my network at some point. Besides static / dynamic, I’m also dealing w subsegments allowed / not allowed communication with Internet. Maybe gotta do that differently. It wasn’t this complicated when I first started out, with a LOT fewer wi-fi and Ethernet devices. :slight_smile:

Yeah brother. Tried to deal with all of that before I realised it was too much hassle to keep on top of it.

Removed all the WiFi devices I could and switched to ZigBee instead. At least with that, I only have to deal with the coordinator’s WiFi address.

1 Like