ESPHome Devices take a LONG time to connect to wifi (30-60 Minutes)

Hardware
1

I purchased a bunch of ESPHome Outlets with energy monitoring. I got 5 with a relay built in and 5 without a relay (always on and when they fail power stays on)

I go them from AtHom and the 5 relay devices work exactly as expected and they allow you to connect to them and enter your Wifi credentials. and then 5-10 seconds later they show up in home assistant. The non relay version though seem to have a real struggle connecting to my wifi. It takes them 30-60 minutes before they will show up. I did finally get them all on wifi and added to home assistant. I used ESPHome Builder to then update the YAML to the most recent and changed the update parameter as 10s energy reports seemed a bit much. When I made all my edits and did an “Update All” the 5 non relay version did not come back online for 40 minutes. I emailed the manufacturer and they blamed it on my wifi. Told them that it’s possible but if so why is it ONLY with these 5 devices that are the same model. I was able to add 2 more relay versions of the plug after these 5 were added with no issues and no delay. AtHom wants to blame my wifi router but it’s always these 5 plugs nothing else that has issues when rebooting. They tell me it’s the exact same chip in both versions with the same ‘firmware’ on them so I am kind of stumped…

Any ideas how to check what the problem might be. I don’t reboot them that often and not a huge deal as they are always on because they have no relay but just not how these ESP board should work IMO

2

Also after it does come up here is the Wifi read out stating that there is 100% signal. So its not like its in a bad location with bad wifi

image
image422×528 18.1 KB

3

I have open my router logs and reset the device to see if it shows anything and this is all it shows. It shows it connecting then disconnecting… not sure if that is normal or not…

image
image1407×634 123 KB

4

According to YAML, the model with relay uses esp32-c3 and the model without relay uses esp8285.
So it is not the same chip.

I had several problems in the past with esp8285 and it was my router.

You can create a hotspot on your smartphone with the same credentials as your router and check if the problem persists.

I would try to put the wifi and API credentials directly in the YAML and disable captive_portal.

I would also disable the time, wifi signal sensors, etc., leaving only the power sensors.

5

okay I’ll try that… why disable all that other stuff?

6

As @walberjunior said, they are clearly not the same chip. Athom support has been pretty helpful with me and their WLED controllers, so this response seems out of character.

I also have a mix on ESP8266 and 8285 devices and no problems.

Have you tried flashing a smple configuration like the one below. If this connects to the WiFi quickly then you have another data point to take back to Athom. Also open the device IP in a browser to see the WiFi level.

esphome:
  name: test
  friendly_name: Test

esp8266:
  board: esp8285

logger:

api:

ota:
  platform: esphome

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

web_server:
  port: 80
  
text_sensor:
  - platform: wifi_info
    ip_address:
      name: IP
    ssid:
      name: SSID
    mac_address:
      name: Mac Address  

sensor:
  - platform: wifi_signal
    name: WiFi Level
    #id: $WiFi_level
    update_interval: 30s
7

So I did this and now I cannot connect to my device again, how do I get the device back online to update again.

8

I’m going to take a wild guess if this device is bricked now… it’s completely sealed and no way for me to update it again.

9

Oh wow it finally came back online after 6 hours… No clue why it took that long but looking at the logs

image
image1882×692 54 KB

I am trying to switch it to a static ip to see if that helps at all

10

Okay so setting a static IP address on it fixed the issue. I guess we can blame my wifi but no other devices are having DHCP issues so I am not sure why ONLY these devices are having DHCP issues!

11

Glad to see it fixed. I only use fixed IP on my servers, DHCP on more than 100 other clients. I strongly suspect your router, specifically the DHCP server.

As you get deeper down this rabbit hole you will want to import all of the external package code.

12

Yeah I use DHCP reservations and it does works for 50 other device even 3 new devices I added yesterday. It’s only there 5 same devices that have this issues so weird issue. That’s why I suspect them being the issue. It does look like a DHCP issue though but I don’t know why, need to do some network sniffing. Not a big deal to set a static IP address but it does cause a 30-60 min delay the first time I set them up.

Do you mean just copy their YAML edit it to my likings and keep it all local?

I was wondering about this the other day that I won’t get updates but really it’s a YAML config file it’s not real firmware that would have bug fixes in it.

13

If it works, don’t fix it.

Reserved DHCP addresses is not static IP. Static IP is done in the device itself. Manual IP in the ESPHome configuration YAML file works like a static IP. Fixed would be connecting in a second or less.

This is because the device is still negotiating with the DHCP server for its IP address and/or it could be going into the AP mode.

I don’t like the way that Athom is getting the IP credentials. (They are trying to be all things to all users). It may be going into the AP mode on start because the WiFi credentials aren’t stored or aren’t stored correctly.

If the device is going into the AP mode, you will see it on your phone under the IP address 192.168.4.1 (Default AP mode for ESP). Power up the device then try to connect to 192.168.4.1 to access the AP mode. If I am right the phone will connect to the device and prompt you for your WiFi credentials. (Did you do this initially?)

Turn on the Fast Connect Option. If wifi_fast_connect is set to true, the device skips scanning all available networks and instead attempts to connect to the last successfully connected WiFi network. This means the credentials must have been saved from a previous connection.

Did you ever connect to the Athom AP at 192.168.4.1 to store the WiFi credentials?

I would replace the whole wifi: section.
Change:

wifi:
  # This spawns an AP with the device name and mac address with no password.
  ap: {}
  # Allow rapid re-connection to previously connect WiFi SSID, skipping scan of all SSID
  fast_connect: "${wifi_fast_connect}"
  # Define dns domain / suffix to add to hostname
  domain: "${dns_domain}"

with

wifi:
  ssid: MyHomeNetwork
  password: VerySafePassword

(Reference)

If you must try a static IP, first go into your router and determine what your DHCP range is. Pick an address outside of this range. (Remember what address you selected because you can never reuse that IP again. Personally,I avoid static IPs because of the accounting for what device used what IP).

For example, if your dhcp range is 192.160.1.10 to 192.168.1.254, pick an unused IP address from 192.168.1.2 to .9 (192.168.1.1 is probably used by your router). For this example, let’s use 192.168.1.9

wifi:
  ssid: MyHomeNetwork
  password: VerySafePassword
  
  manual_ip:
    static_ip: 192.168.1.9
    gateway: 192.168.1.1
    subnet: 255.255.255.0

(Reference)

For the purists, Static, Reserved and Manual IP terms are often used interchangeably.

  • Static IP → Hard-coded on the device, does NOT rely on DHCP.
  • Reserved IP → Set in the router’s DHCP, device still uses DHCP.
  • Manual IP in ESPHome → Effectively a static IP but configured in the YAML file.
14

I’m reserving the ip-address in the router nonetheless, otherwise the ip-address may be used for a different device.

15

It still means that the device has to interrogate the DHCP server to obtain an IP address. Manual IP in the configuration file bypasses the DHCP server altogether.

16

Yes, i do both to prevent the router to assign the ip-address to another device when the address is not in use.

17

A manual or static IP address MUST NOT be in the DHCP range. A router will not and cannot assign an IP address outside of the DHCP range. A router will not reassign a reserved IP address to another device no matter how long it is offline.

18

But i can reserve an IP-address in the DHCP range, at least on my router.

19

That is where you are supposed to reserve IP addresses. But if you also make it static in the device you are wasting your time because a static/manual address tells the device to skip the DHCP process altogether.

20

I get what @juergenjw is doing. Most DHCP servers for the home will have the entire rage set for DHCP. Mine is set to 192.168.86.2- 254 so I don’t have any IPs available outside the DHCP range. So the easiest thing to do is just let it connect once and it will show up in the DHCP table and you can reserve it so that IP never gets handed out to any other client. The DHCP reservation is not actually used to assign the IP address to the device it’s just used to make sure no one else gets that IP address. Then set it statically on the device… Yes the best thing to do is to make sure you have space in your DHCP rage to allow for static IPs to be used, but this other way allows the best of both worlds. I know it’s not 100% kosher but it works with no issues and you have a record in your DHCP of what IP address are used by what, so it’s kind of a bonus :slight_smile:

Been doing IT for 30 years and no issues doing this in multi AD environments. But does not mean it cannot have an issue if you have no idea what you are doing.