ESPHome + OpenWRT(ATH10k radio) = ESP8266 ota timed out

walberjunior · November 12, 2021, 11:25pm

Hello,

I would like some help.
I bought some ESP2866 DEV BOARD but I can’t update them through OTA + OpenWRT

I have the following devices:

3 ESP32 boards with ESPHome - OTA OK
8 Sonoff Mini with Tasmota - OTA OK
1 NodeMCU V3 - OTA does not work with OpenWRT
3 D1 Mini - OTA does not work with OpenWRT

The NodeMCU V3 board I’ve owned for a while and I noticed that the OTA wasn’t working. As it was the first and only board with ESP8266 I thought it was defective.

This week I received 3 D1 Mini boards and I can’t update them via OTA either.

I researched the problem and found some suggestions for changing the board configuration:
board: nodemcuv2

board: d1_mini

board: esp01_1m

I tried to add this setting:

board_flash_mode: dout

Nothing worked, however when I create a hotspot on the notebook I can update normally.

Does anyone have any idea of any settings I can change on the router?
TP-Link Archer C7 v5 running OpenWrt 19.07.8

INFO Generating C++ source...
INFO Compiling app...
Processing portao-mini (board: nodemcuv2; framework: arduino; platform: platformio/espressif8266 @ 2.6.3)
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- <ESPAsyncTCP-esphome> 1.2.3
|   |-- <ESP8266WiFi> 1.0
|-- <ESPAsyncWebServer-esphome> 2.0.0
|   |-- <ESPAsyncTCP-esphome> 1.2.3
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ArduinoJson-esphomelib> 5.13.3
|-- <ESP8266WiFi> 1.0
|-- <ArduinoJson-esphomelib> 5.13.3
|-- <ESP8266mDNS> 1.2
|   |-- <ESP8266WiFi> 1.0
|-- <noise-c> 0.1.4
|   |-- <libsodium> 1.10018.1
|-- <DNSServer> 1.1.1
|   |-- <ESP8266WiFi> 1.0
RAM:   [====      ]  40.1% (used 32856 bytes from 81920 bytes)
Flash: [====      ]  42.8% (used 447360 bytes from 1044464 bytes)
========================= [SUCCESS] Took 9.53 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of portao-mini.local
INFO  -> 192.168.0.130
INFO Uploading /data/portao-mini/.pioenvs/portao-mini/firmware.bin (451520 bytes)
INFO Compressed to 309327 bytes
Uploading: [=================                                           ] 28% 
ERROR Error sending data: timed out

  name: quarto
  platform: ESP8266
  board: nodemcuv2
  on_boot:
    priority: -100.0
    then:
      - text_sensor.template.publish:
            id: quarto_version
            state: !lambda |-
              String versao = "1.01";
              return (String(versao)).c_str();
      - component.update: quarto_temp


# Enable logging
logger:

# Enable Home Assistant API
api:

ota:
  password: ""

wifi:
  ssid: ""
  password: ""
  power_save_mode: none

 
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Quarto Fallback Hotspot"
    password: ""

captive_portal:

web_server:
  port: 80
  
text_sensor:
  - platform: template
    name: Uptime Quarto
    id: uptime_human
    icon: mdi:clock-start

  - platform: template
    name: Quarto Versão
    id: quarto_version
    icon: mdi:clock-start
  
  
sensor:
  - platform: uptime
    name: Uptime Quarto
    id: uptime_sensor
    update_interval: 60s
    internal: true
    on_raw_value:
      then:
        - text_sensor.template.publish:
            id: uptime_human
            state: !lambda |-
              int seconds = round(id(uptime_sensor).raw_state);
              int days = seconds / (24 * 3600);
              seconds = seconds % (24 * 3600);
              int hours = seconds / 3600;
              seconds = seconds % 3600;
              int minutes = seconds /  60;
              seconds = seconds % 60;
              return (
                (days ? String(days) + "d " : "") +
                (hours ? String(hours) + "h " : "") +
                (minutes ? String(minutes) + "m " : "") +
                (String(seconds) + "s")
              ).c_str();

  - platform: dht
    pin: 2
    id: quarto_temp
    temperature:
      name: "Quarto Temp"
    humidity:
      name: "Quarto Umidade"
    update_interval: 60s

switch:
  #Comando reinicilizar esp remotamente
  - platform: restart
    id: quarto_restart
    name: Reiniciar
    icon: mdi:restart```

nickrout · November 14, 2021, 4:49am

Keep trying and/or move the device closer to your AP.

Spiro · November 14, 2021, 8:59am

Try setting fast connect and static ip in the wifi settings of the ESP. They tend to drop connection for unknown reason. If you use esphome you eventually get this problem.

walberjunior · November 14, 2021, 1:53pm

@nickrout
It keeps failing even near the router
11:39:44.279 -> e[0;35m[C][wifi:359]: Signal strength: -35 dB e[0;32m▂▄▆█e[0me[0m

@Spiro

I use static ip set on router.
But even setting in ESPHome the update fails


INFO Reading configuration /config/esphome/salatemp.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing salatemp (board: d1_mini; framework: arduino; platform: platformio/espressif8266 @ 2.6.3)
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- <ESPAsyncTCP-esphome> 1.2.3
|   |-- <ESP8266WiFi> 1.0
|-- <ESPAsyncWebServer-esphome> 2.0.0
|   |-- <ESPAsyncTCP-esphome> 1.2.3
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ArduinoJson-esphomelib> 5.13.3
|-- <ESP8266WiFi> 1.0
|-- <ArduinoJson-esphomelib> 5.13.3
|-- <ESP8266mDNS> 1.2
|   |-- <ESP8266WiFi> 1.0
|-- <noise-c> 0.1.4
|   |-- <libsodium> 1.10018.1
|-- <DNSServer> 1.1.1
|   |-- <ESP8266WiFi> 1.0
Compiling /data/salatemp/.pioenvs/salatemp/src/main.cpp.o
Linking /data/salatemp/.pioenvs/salatemp/firmware.elf
Building /data/salatemp/.pioenvs/salatemp/firmware.bin
RAM:   [====      ]  39.4% (used 32296 bytes from 81920 bytes)
Flash: [====      ]  41.5% (used 433492 bytes from 1044464 bytes)
========================= [SUCCESS] Took 19.94 seconds =========================
INFO Successfully compiled program.
INFO Connecting to 192.168.0.206
INFO Uploading /data/salatemp/.pioenvs/salatemp/firmware.bin (437648 bytes)
INFO Compressed to 301636 bytes
Uploading: [================                                            ] 27% 
ERROR Error sending data: timed out

  ssid: ""
  password: " "
  fast_connect: true
  manual_ip:
    static_ip: 192.168.0.206
    gateway: 192.168.0.1
    subnet: 255.255.255.0```

Spiro · November 14, 2021, 2:25pm

The ``` at the end of subnet just a typo?

walberjunior · November 14, 2021, 2:31pm

Yes, Just typo

glyndon · November 14, 2021, 2:48pm

There are several posts on here about this or a similar problem. Random timed entries in the logbook “deviceX is unavailable”, followed a few seconds later by the reappearance of the device, for example.
In more severe cases, it’s what you are seeing, where an OTA stream gets interrupted.

Lots of suggestions involve changes to the ESPHome configuration, but none seem to ever really solve it.
I’ve been wrestling with this but am playing the long-game, trying things and waiting a few days.

So far, the most effective thing I’ve done is to replace OpenWRT with the factory firmware on the WiFi Access Point.
(That’s not a loss of function for me since I use it as “just an AP”, my border router is a standalone device.)

My current working hypothesis is that there is just something not compatible between the ESP’s WiFi stack (not an ESPHome issue, but the layers it runs atop) and the way OpenWRT handles WiFi radios.
Oh, and FWIW, my AP is a TP-Link Archer A7v5 (same hardware as yours, but sold with Amazon-sponsored firmware that lowers the price for the unit in exchange for probably telling them everything we do. I blocked the Archer’s IP from egress at the border which does not affect WiFi clients, just prevents the AP firmware from phoning home to Amazon.

Spiro · November 14, 2021, 2:59pm

Does it make any difference if select N mode or legacy mode on 2.4ghz wireless settings on openwrt?

walberjunior · November 14, 2021, 3:45pm

@glyndon
I move to openwrt to use as track device. But that was before I use home assistant.

what I find strange is that only the dev boards exhibit this behavior. As I don’t have this problem using sonoff mini (esp8265?) with tasmota, I think there is a bug in this setup (esp8266 + openwrt + esphome)

I was thinking about putting the esphome on sonoff, but due to the difficulty of making the flash with the cable if I have the same problem, I gave up

@Spiro

I use it in N Mode, but I tried to change it to legacy and besides not solving the ota problem, the other boards started to show connection problems.

Legacy:
This entity’s are from a esp32 with esphome

N:

Spiro · November 14, 2021, 3:55pm

What I do to make my esphome devices more stable is to put logger level in esphome to INFO. Might be worth a try. Clutching at straws here.

walberjunior · November 14, 2021, 4:29pm

@Spiro

I will try this and also reduce update_interval from 60 to 30 or 10 seconds.

@glyndon talked about disconnection…
In this case I have “micro” disconnections or is the board restarting?

on_boot:
    priority: -100.0
    then:
      - text_sensor.template.publish:
            id: quarto_version
            state: !lambda |-
              String versao = "1.01";
              return (String(versao)).c_str();

glyndon · November 14, 2021, 4:41pm

I’ve watched the a few of the ESP board’s logs using OTA log following, and sometimes it registers reconnecting, but never shows the board restarting. an uptime clock on the board also shows it not restarting, even though it might suffer several dis/re-connects in an hour.

walberjunior · November 14, 2021, 4:52pm

Change the logger level and update_interval, send the fw using the cable.

I opened two tabs, one to update and one to check the log.

INFO Reading configuration /config/esphome/quarto.yaml...
INFO Generating C++ source...
INFO Compiling app...
Processing quarto (board: nodemcuv2; framework: arduino; platform: platformio/espressif8266 @ 2.6.3)
--------------------------------------------------------------------------------
HARDWARE: ESP8266 80MHz, 80KB RAM, 4MB Flash
Dependency Graph
|-- <ESPAsyncTCP-esphome> 1.2.3
|   |-- <ESP8266WiFi> 1.0
|-- <ESPAsyncWebServer-esphome> 2.0.0
|   |-- <ESPAsyncTCP-esphome> 1.2.3
|   |   |-- <ESP8266WiFi> 1.0
|   |-- <Hash> 1.0
|   |-- <ESP8266WiFi> 1.0
|   |-- <ArduinoJson-esphomelib> 5.13.3
|-- <ESP8266WiFi> 1.0
|-- <ArduinoJson-esphomelib> 5.13.3
|-- <ESP8266mDNS> 1.2
|   |-- <ESP8266WiFi> 1.0
|-- <noise-c> 0.1.4
|   |-- <libsodium> 1.10018.1
|-- <DNSServer> 1.1.1
|   |-- <ESP8266WiFi> 1.0
Compiling /data/quarto/.pioenvs/quarto/src/main.cpp.o
Linking /data/quarto/.pioenvs/quarto/firmware.elf
Building /data/quarto/.pioenvs/quarto/firmware.bin
RAM:   [====      ]  39.3% (used 32196 bytes from 81920 bytes)
Flash: [====      ]  40.9% (used 426952 bytes from 1044464 bytes)
========================= [SUCCESS] Took 20.66 seconds =========================
INFO Successfully compiled program.
INFO Resolving IP address of quarto.local
INFO  -> 192.168.0.204
INFO Uploading /data/quarto/.pioenvs/quarto/firmware.bin (431104 bytes)
INFO Compressed to 297813 bytes
Uploading: [============================                                ] 46% 
ERROR Error sending data: timed out

Second tab:

INFO Reading configuration /config/esphome/quarto.yaml...
INFO Starting log output from quarto.local using esphome API
INFO Successfully connected to quarto.local
[13:48:13][I][app:099]: ESPHome version 2021.10.3 compiled on Nov 14 2021, 13:45:44
INFO quarto.local: Ping timed out!
INFO Disconnected from ESPHome API for quarto.local
WARNING Disconnected from API
WARNING Can't connect to ESPHome API for quarto.local: Hello timed out
INFO Trying to reconnect to quarto.local in the background

glyndon · November 14, 2021, 5:58pm

you can probably also (I do) see it manifested as dropped ICMP ping responses.
i.e. at your shell command line: ‘ping your.espdevice’ and watch the once-a-second pings turn up missing every now and then.
No reliable connection should do that.

Spiro · November 14, 2021, 6:04pm

What about on 2.4ghz Openwrt wireless tab edit and click on advanced options on Interface Configuration and untick Disassociate On Low Acknowledgement

walberjunior · November 14, 2021, 7:31pm

@glyndon

Send 20 packets.
ESP32, chromecast, android phone no lost
ESP8266 20 ~ 65% lost
Sonoff 20 ~ 30% lost

@Spiro

I created another wireless network.
First disable Disassociate On Low Acknowledgement no change
then disable WMM Mode no change
then disable Allow legacy 802.11b rates no change

The last two options were trial and error.

glyndon · November 14, 2021, 10:01pm

Two more tidbits for the information pool:

I notice you’re using OpenWRT 19.07. I was on that version and the problems here existed since then, and I’ve since upgraded the AP to 21.02 and 21.02.1 with no change in the ESP problem.
So upgrading OpenWRT may not provide a solution for you.
Since reverting the Archer to [latest] factory firmware 24 hours ago. The time has passed without even one unexplained disconnect. It’s never gone that long before without problem. Thus, I’m becoming convinced that it’s OpenWRT that isn’t compatible with some subtle quirk in the ESP’s 802.11 stack. I’d be happy to eat my words in case there’s another solution and it’s not OpenWRT’s fault - I love OpenWRT, just sad that it doesn’t seem to be able to operate that device’s radio as reliably.

Spiro · November 14, 2021, 10:18pm

I’ve been running 19.7.8 and only intermittently get a problem. Probably more with changes in Esphome that I see problems. Too many variables to say for sure with software and hardware. Got a lot of disconnections with Tasmota but now more stable. Have been running some ESPhome devices for >8 months with no noticeable problems with sensors. Recently get more problems like @walberjunior with OTA but when I hit retry it has always worked. That’s the fun of all this is, in the learning.
Although in the early days the frustration is off putting.

walberjunior · November 14, 2021, 11:28pm

@glyndon

I read something about openwrt and the esp8266 not making the connection and it was a specific model from another brand.

@Spiro

This kind of learning process is good, but it’s better when the solution is found.

I’ll move on for now, as I don’t want to go back to the original firmware and maybe mess up other settings that are working today.

Thanks for everything

orange-assistant · November 15, 2021, 2:10pm

Wonder if this would be worth a thread in the openwrt forum just for a more in depth debugging (network wise). More insights are always better