After successfully installing over 30 8266 boards I am suddenly getting a “cannot connect” message when making initial internet connection after flashing. Internet SSID shows up as a connection option, password is the same, existing boards communicating without issue (including latest update to YAML deleting the platform). Problem repeats with multiple boards. Reboot of modem, Rasp, etc. all do not correct. Log simply restates “cannot connect” message. Greatly appreciate any trouble shooting suggestions or if similar issue experienced by others.
Show your yaml and it might help
esphome:
name: tempsensors32
friendly_name: tempsensors32
esp8266:
board: esp01_1m
Enable logging
logger:
Enable Home Assistant API
api:
encryption:
key: “Yhl4xJXrS3Cl1YTxzSjJrxLCXTu9lPoQGKOPblach0Q=”
ota:
- platform: esphome
password: “38aab1ec400f99be5bcdc84f8015109a”
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: “Tempsensors32 Fallback Hotspot”
password: “3ANgbhbfbNUi”
captive_portal:
File loads ok. When I go to connect to wi-fi SSID shows up, enter password, but connection times out with “not connected” message. Previously exact same process worked without problem, board showed up on modem and I was able to reserve IP. Now Board does not connect and does not appear on modem.
Can you edit the post above with pre-formatted text tags surrounding your yaml please.
They are added using the <> button on the posting toolbar.
Also if you are flashing via USB please capture your logs and post them - using the correct tags again.
Considering this rather high number of boards, which I assume are already in your network and I assume that there are not only these boards present: do you still have free IP addresses in your network or in the address space handled by the DHCP server?
See also How can I make esphome more reliable? - #4 by donburch888?
YASML file followed by log.
esphome:
name: tempsensors32
friendly_name: tempsensors32
esp8266:
board: esp01_1m
# Enable logging
logger:
# Enable Home Assistant API
api:
encryption:
key: "Yhl4xJXrS3Cl1YTxzSjJrxLCXTu9lPoQGKOPblach0Q="
ota:
- platform: esphome
password: "38aab1ec400f99be5bcdc84f8015109a"
wifi:
ssid: !secret wifi_ssid
password: !secret wifi_password
# Enable fallback hotspot (captive portal) in case wifi connection fails
ap:
ssid: "Tempsensors32 Fallback Hotspot"
password: "3ANgbhbfbNUi"
captive_portal:
```
[12:00:10]sd l | d | l c| e ; c c gg dog b p l{lslp g l #o | c oo l d` no l` o{ 'cl lp o { c ' | # og d` 'nl` n{ ےgc `{ gc ` l x d` g l e o s o| l rl c e |s l g n l` s d l [I][logger:034]: Log initialized
[12:00:10][C][safe_mode:079]: There have been 2 suspected unsuccessful boot attempts
[12:00:10][I][app:029]: Running through setup()...
[12:00:10][C][wifi:048]: Setting up WiFi...
[12:00:10][C][wifi:061]: Starting WiFi...
[12:00:10][C][wifi:062]: Local MAC: C8:C9:A3:38:FA:40
[12:00:10][C][wifi:263]: Setting up AP...
[12:00:10][C][wifi:265]: AP SSID: 'esphome-web-38fa40'
[12:00:10][C][wifi:266]: AP Password: ''
[12:00:10][C][wifi:275]: IP Address: 192.168.4.1
[12:00:10][D][wifi:482]: Starting scan...
[12:00:10][C][web_server:100]: Setting up web server...
[12:00:10][C][api:026]: Setting up Home Assistant API server...
[12:00:10][D][wifi:482]: Starting scan...
[12:00:10][I][app:062]: setup() finished successfully!
[12:00:10][W][component:157]: Component api set Warning flag: unspecified
[12:00:10][I][app:100]: ESPHome version 2024.11.1 compiled on Nov 25 2024, 08:40:56
[12:00:10][I][app:102]: Project esphome.web version 24.11.1
[12:00:10][C][logger:185]: Logger:
[12:00:10][C][logger:186]: Level: DEBUG
[12:00:10][C][logger:188]: Log Baud Rate: 115200
[12:00:10][C][logger:189]: Hardware UART: UART0
[12:00:10][C][captive_portal:089]: Captive Portal:
[12:00:10][C][wifi:600]: WiFi:
[12:00:10][C][wifi:428]: Local MAC: C8:C9:A3:38:FA:40
[12:00:10][C][wifi:433]: SSID: ''[redacted]
[12:00:10][C][wifi:439]: BSSID: FF:FF:FF:FF:FF:FF[redacted]
[12:00:10][C][wifi:441]: Hostname: 'esphome-web-38fa40'
[12:00:10][C][wifi:443]: Signal strength: 31 dB ▂▄▆█
[12:00:10][C][wifi:447]: Channel: 1
[12:00:10][C][wifi:448]: Subnet: 0.0.0.0
[12:00:10][C][wifi:449]: Gateway: 0.0.0.0
[12:00:10][C][wifi:450]: DNS1: 0.0.0.0
[12:00:10][C][wifi:451]: DNS2: 0.0.0.0
[12:00:10][C][web_server:153]: Web Server:
[12:00:10][C][web_server:154]: Address: esphome-web.local:80
[12:00:10][C][mdns:116]: mDNS:
[12:00:10][C][mdns:117]: Hostname: esphome-web-38fa40
[12:00:10][C][esphome.ota:073]: Over-The-Air updates:
[12:00:10][C][esphome.ota:074]: Address: esphome-web.local:8266
[12:00:10][C][esphome.ota:075]: Version: 2
[12:00:10][C][safe_mode:018]: Safe Mode:
[12:00:11][C][safe_mode:019]: Boot considered successful after 60 seconds
[12:00:11][C][safe_mode:021]: Invoke after 10 boot attempts
[12:00:11][C][safe_mode:022]: Remain in safe mode for 300 seconds
[12:00:11][W][safe_mode:028]: Last reset occurred too quickly; safe mode will be invoked in 8 restarts
[12:00:11][C][api:140]: API Server:
[12:00:11][C][api:141]: Address: esphome-web.local:6053
[12:00:11][C][api:145]: Using noise encryption: NO
[12:00:11][C][improv_serial:032]: Improv Serial:
[12:00:12][W][component:237]: Component mdns took a long time for an operation (52 ms).
[12:00:12][W][component:238]: Components should block for at most 30 ms.
[12:00:13][W][component:237]: Component mdns took a long time for an operation (51 ms).
[12:00:13][W][component:238]: Components should block for at most 30 ms.
[12:00:13][W][component:237]: Component mdns took a long time for an operation (101 ms).
[12:00:13][W][component:238]: Components should block for at most 30 ms.
[12:01:10][I][safe_mode:041]: Boot seems successful; resetting boot loop counter
That says the problem is your AP/router/gateway, more specifically your DHCP server/allocator. It did not provide a valid address (unless you also redacted that and didn’t indicate it).
I would look at the logging in the router and consider getting a better one. I have used several brands and many of them work well enough most of the time. Yours seems to be having an issue for some reason.
When I first saw the post, I saw 30,8266… I need new glasses.
At any rate, 30 is not a lot. I have over 100 WiFi clients and most of them are ESP’s.
This is a bit confusing. Are you saying that you tried the same configuration yaml file on multiple boards or that “all do not connect” means all 30 of your existing boards?
Your logfile doesn’t show that an IP address was provided by DHCP. You should have seen something like this:
[14:04:40][C][wifi:600]: WiFi:
[14:04:40][C][wifi:428]: Local MAC: 84:F3:EB:FB:00:A5
[14:04:40][C][wifi:433]: SSID: [redacted]
[14:04:40][C][wifi:436]: IP Address: 192.168.1.126
[14:04:40][C][wifi:439]: BSSID: [redacted]
[14:04:40][C][wifi:441]: Hostname: 'ht16k33_display'
[14:04:40][C][wifi:443]: Signal strength: -49 dB ▂▄▆█
[14:04:40][C][wifi:447]: Channel: 2
[14:04:40][C][wifi:448]: Subnet: 255.255.255.0
[14:04:40][C][wifi:449]: Gateway: 192.168.1.1
[14:04:40][C][wifi:450]: DNS1: 1.1.1.1
[14:04:40][C][wifi:451]: DNS2: 9.9.9.9
Some things to consider.
You can not have two devices with the same
name:
An IP reserved in the router must be in the DHCP pool range. I would start by checking the router settings since the DHCP server is not providing an IP.
What also looks strange is that the Hostname in the log should be the same as the name: in your configuration file.
Your log says: Hostname: 'esphome-web-38fa40'
Your yaml says: name: tempsensors32
I am not sure what would cause this variation. I am again thinking back to the DHCP settings in your router.
If you solve this, or have other data points, please let us know your progress or solutions.
BY THE WAY.
A static IP will probably connect just fine, but I avoid static IPs. (With over 100 WiFi clients, manually managing that many static IP addresses would be a nightmare).
However, as a test, try a static IP. If the device connects with a static IP, then we’re back to looking at the DHCP server. If it works, you could leave it this way, but your next board or other WiFi device might have the same problem.
Last thought: Is there a reason you need the IP address reserved?
The log report automatically redact the SSID and BSSID
You can disable the redaction in your configuration file:
logger:
level: DEBUG
redact: false
Redacting them on a log file report seems silly to me. Your router already broadcasts your SSID, and the BSSID is the MAC address of your router or access point. Any hacker who is going to this much trouble to get into your network will be in a van parked in front of your house with “FBI Surveillance Unit” painted on the side. Trust me, you aren’t that important.
2 Likes
Thanks for all the suggestions. I am still experiencing the problem. The number of devices currently working with HA is actually about 40, most are 8266 nodemcuv2. Each board has a distinct name, sorry for the confusion. On my router the boards are designated in this format: esphome-web-XXXXXX. When initially provisioning the board I get that identification which then allows me to eventually locate it on my router and then reserve the IP.
After experiencing consistent dropped connections I opted for reserved IP’s which corrected the problem. I know that reserved IPs have some of their own issues but in my case they have worked well. The comment about reserved IPs being a bookkeeping headache is very true. In trying to debug the problem I have tried to make as few changes as possible from the previously successful installations. That is why I mentioned no changes to the YAML, I should have clarified that the name is changed as required. I experimented with boards from different suppliers but the failure occurs with all.
The issue is that I cannot make the initial connection to Wi-Fi as part of the flash process. The flash file downloads to the board and the “provisioned” notification shows up. I also see the esphome-web-XXXXXX designation. It is when I try to connect the board wirelessly to my LAN that the connection fails. I enter my SSID from the drop down menu and the password but the connection times out. This all occurs with the initial flash YAML file. Because I cannot connect with Wi-Fi I am unable to download the specific YAML file I am using for the board’s application (Temp Sensor). There is no issue with Wi-Fi signal strength, I am setting up these board within a few feet of the router and Wi-Fi connections to other ESP boards in the area are excellent.
Based on your observations I am going to concentrate on the router interface issues. I will experiment with some alternatives to see if I find a solution. Any further suggestions are most welcome and appreciated.
Are you SURE it really corrected the problem? Intermittent problems are notoriously difficult to resolve, since it is very hard to be sure you really solved the problem or it was just a coincidence.
The only reason I use static IP addresses is if I want a device to have a constant IP address forever. Many routers do a great job of providing reasonably consistent addresses, some do a horrible job and then things get really confusing.
You still haven’t stated what you are using for a router. I am currently using Unifi products, but have had good results with a few different Asus routers previously and the Microsoft MN-700 before that. They all did a fine job of managing IP addresses, so it has been possible to do this well for over two decades.
You are confusing reserved with static. Reserved IP is DHCP and the addresses come from the DHCP server pool. I do not need to manage DHCP reservations, but static IP is hard-coded in the device source code and if I need the IP address I either have a notebook list of static IP addresses or find the source code.
I have over 100 IP clients on my home network. The only ones that have a static IP are my servers. Everything else is on DHCP. Some of the clients have a reserved address on the router.
As I said in post#9,
Have you tried a static IP?
Have you tried removing half of your WiFi devices? (Turn them off, unplug them or remove batteries).
I don’t recall if you said, but what is the DHCP IP range? If there not enough available addresses in the pool then a new client will get a response from the DHCP server indicating that no addresses are available. As a result, the client won’t be able to join the network until an IP address becomes available.
This is the ONE log provided that CLEARLY shows the issue. Your DHCP allocator is NOT providing an IP address. Pretty much everything else in this thread has been “noise”. This is why you MUST provide ACCURATE logs to get any real help.
Now, I suppose it is possible that there is some unusual issue in the framework code (there was a time before the esp32, where the Wi-Fi framework code for the esp8266 had a serious regression, so it certainly is possible).
Knowing which router you are using might be helpful, since some people are familiar with ones that are “problematic” and ones that are known to be good and how to check their logs to see what they are showing.
Point very well taken. Will address questions as I continue to investigate. Engaging oldest son, VP of IT, to see what insights he can provide over the weekend. Will report on results. Greatly appreciate patience and support.