[SOLVED] ESPHome DHCP client problems, temporary solution with manual fixed IP

This is very much appreciated. You don’t know how much it helped me! Thanks again!

Hi I think I am missing reading something, I have added to esphome:
platformio_options:
lib_extra_dirs: /config/libs

to the esphome device config file

and created a folder in config called libs but what to I put in this folder to get esphome to point to the git clone? sorry if I am a idiot and do not understand
thank in advance

Pointing ESPHome to the git clone is done by adding the lib_extra_dirs to your yaml file. That will instruct PlatformIO (which builds the code) to also look in the directory that was specified there.

The git clone itself must be in that additional lib dir.
So the path would be /config/libs/AsyncTCP/.

No additional instructions are needed. The lib_extra_dirs directory has presedence over the other library directories, so if you put the fixed AsyncTCP library in that directory, it will override the default one.

ok thanks I have put the clone in /config/libs/AsyncTCP/ its not zipped just the clone files downloaded, I have added
platformio_options:
lib_extra_dirs: /config/libs

to my esp file yaml

run the update but I don’t see any change here the start of the upload, sorry to be a pain

INFO Reading configuration /config/esphome/2_rf.yaml…
INFO Generating C++ source…
INFO Compiling app…
INFO Running: platformio run -d /config/esphome/2_rf
Processing 2_rf (board: esp01_1m; framework: arduino; platform: [email protected])

HARDWARE: ESP8266 80MHz, 80KB RAM, 1MB Flash
PACKAGES:

  • framework-arduinoespressif8266 3.20704.0 (2.7.4)
  • tool-esptool 1.413.0 (4.13)
  • tool-esptoolpy 1.20800.0 (2.8.0)
  • toolchain-xtensa 2.40802.200502 (4.8.2)
    Library Manager: Installing Update
    Library Manager: Already installed, built-in library
    Dependency Graph
    |-- 1.2.3
    | |-- 1.0
    |-- 1.0
    |-- 1.2
    | |-- 1.0
    |-- 1.2.7
    | |-- 1.2.3
    | | |-- 1.0
    | |-- 1.0
    | |-- 1.0
    | |-- 5.13.3
    |-- 5.13.3
    |-- 1.1.1
    | |-- 1.0
    Retrieving maximum program size /data/2_rf/.pioenvs/2_rf/firmware.elf
    Checking size /data/2_rf/.pioenvs/2_rf/firmware.elf
    RAM: [===== ] 47.7% (used 39052 bytes from 81920 bytes)
    Flash: [==== ] 43.1% (used 441636 bytes from 1023984 bytes)
    ========================= [SUCCESS] Took 2.06 seconds =========================

first 1.2.3 is Dependency Graph
ESPAsyncTCP-esphome 1.2.3

Ah, my fix is for the AsyncTCP-esphome library for ESP32.
You are using the ESPAsyncTCP-esphome library for ESP8266.

Do you get “ack timeout” disconnect issues on the ESP8266? In that case, the ESPAsyncTCP might require the same kind of fix. I didn’t look into that.

ok thanks yes its dropping connection thought this may have help many thanks for your help on this

If the connection drops are because of the “ack timeout” errors, then it might be worth to patch the ESPAsyncTCP code in the same way as the AsyncTCP code.
Can you connect the device using a serial to USB connector to your computer, so you can look at the console logging? If the “ack timeout” issue is the culprit here, log then you will see those logged, right before the connection is dropped.

If you can confirm if this is your actual issue, then I can cook up a patch for this library. If the disconnects have another cause, then modifying the code wouldn’t help.

BTW: one thing that I found that might cause extra disconnects, is the log level for the logger component. If you have a high log level, then try lowering it to see if that makes the connection more stable. The time that the CPU is busy with handling the logging sometimes seems to get in the way of the connection handling code. This likely won’t be a definite fix, but I’ve seen improvements when tuning down the logging.

Hello,
I also have an EPS8266.
I have multiple Wi-Fi disconnections.
Several weeks I have been looking for a solution. The best improvement is the deactivation of the logger but the connection is not stable over several hours.
I’m desperate, I spent a lot of time, I can’t do it. :tired_face:
Doing a reset or unplugging / re-plugging is the only solution for the moment.
I am thinking of automating a 220v outlet in order to do a regular reboot.

here about 20h history: image (red it’s ok, grey lost connexion).

Thank you.

Hello… I m facing the same issue mentioned in this thread. I think the solution might be the upgrade of library AsyncTCP-esphome to version 1.2.3. I have no idea how to update it…Currently, on my log, it was still in version 1.1.1 Could you please instruct me all the steps involved to upgrade the library version…

Here are the screenshots I had done so far:

esphome issue 4

esphome issue 2

As dicussued on discord:

  • The key esphome.libraries can be removed. It will not force the library verison.
  • The AsyncTCP subdir must not be named in the lib_extra_dirs, so this should be lib_extra_dirs: /config/libs
  • Make sure that the created libs folder is actually /config/libs and not something like /config/esphome/libs (which would probably be the directory that you would use when running ESPHome as a Home Assistant plugin).

Note that my patched library was included in the ESPHome dev release, but it was rolled back, because somebody got disconnects after compiling in the fix (while the connection was stable with the original version of AsyncTCP). Because of this regression, it’s unlikely that the fix will go into the stable releases.
I created a new pull request with a different solution.

That solution is backward compatible, because it is only a tiny change, that can optionally be compiled in. I am running that fix locally and my device is now even more stable than using the patched AsyncTCP. Therefore I hope this fix will be merged into ESPHome stable. Keep your eyes on the above pull request for more info.

ESPHome v1.18.0 is released

For people that have been playing with the patched version of the AsyncTCP-esphome library: you can upgrade to ESPHome v1.18.0 and delete the lib_extra_dirs hack. The new ESPHome uses my fixed version of the AsyncTCP-esphome code by default.

2 Likes