OTA Never Ever Works (*at least* on ESP32-S3) #5678
Labels
Comments
|
What does the device log show when you try to update it? |
|
How should I see it ? It's offline since I tried OTA ... it didn't come back up. The only thing I can see on MQTT is with I get only:
Or do you mean trying to perform OTA when it's plugged in via USB port ? |
|
You didn't say anything about it not coming back up. If the ota update fails, it should continue with the original version. |
|
The complete config YAML is available in the "Example YAML snippet" Section. I do not have a single file, it's a packaged version. Thus to reproduce the easiest is on Debian/Ubuntu (or other GNU/Linux Distribution) and potentially Windows WSL / MacOS with BASH support: Otherwise in the root tolder: And in the I have BOTH
|
luckylinux
changed the title
|
Could it be a low-RAM issue ? The Atom S3 Lite (unlike many ESP32 / ESP32-S3 modules e.g. -WROVER or -WROOM) does NOT have an external PSRAM (0 MB). It has a ESP32-S3FN8 SOC 8 MB Flash and approx. integrated 320 kB RAM. Although according to Wikipedia it should have integrated 520 kiB RAM: I tried to re-upload on the device that didn't come up after the latest OTA update. But it fails to re-upload as well. Probably the only solution is to manually reboot the ESP32 👎. |
|
Otherwise could it be that It doesn't state anything in the docs, but it seems you HAVE to declare that block yourself: |
|
I tried pinging the ESP32 from a Desktop computer sitting in the House to the ESP32 in the Garage through a Power Line adapter: Ubuntu Desktop <--> ~ 10 meters Cat6 Cable <--> Power Line Adapter <--> ~ 10 meters Power Cord <--> Power Line Adapter <--> ~ 2 meters Cat 6 Cable <--> Rock 5B running MQTT/dnsmasq/hostapd <--> Alfa AWUS1900 USB-Wifi Adapter (RTL8814AU) <--> ESP32
No big issues. No packets lost. Latency might be a bit on the higher end but still ... This is WiFi, it will never be as good as ethernet. For comparison: Ubuntu Desktop <--> ~ 10 meters Cat6 Cable <--> Power Line Adapter <--> ~ 10 meters Power Cord <--> Power Line Adapter <--> ~ 2 meters Cat 6 Cable <--> Rock 5B running MQTT/dnsmasq/hostapd
|
|
But note that OTA was also failing when directly connected from within the garage (so EXCLUDING any of this Power Line adapters etc). |
|
I will need to cross-check on these specific devices, but I could replicate the PROBLEM on a Raspberry Pi 2 (armv7l) with the same hostapd+dnsmasq configuration and the same Alfa AWUS1900 USB-Wifi Adapter (RTL8814AU). For those having issues with OTA failing to upload, like at 4% - 10% or so, the FIRST thing to check if your network connectivity, configuration, routing, firewall, etc. That was also what the other GitHub Issues / Home Assistant Forums seemed to suggest. I lost 2+ days trying to sort out why OTA would fail, the watchdog getting triggered, then the device BRICKS without even resetting itself. In some cases cycling USB Power Supply is enough to make it recover. But in some/most cases, you need to USB flash AGAIN. The network connectivity seems fine, although if you ping long enough you can see the latency increasing dramatically. But there is NOT really a network "failure" per se ... Ping: Traceroute: TCP Traceroute: Out of desperation, I tried to flash the firmware from the Raspberry Pi that is running the AP, so it's DIRECTLY in the correct subnet for the esp32 device that it's trying to flash. Upload the firmware on the Raspberry Pi server first, you do NOT want to wait for all the time it takes for it to compile (Raspberry Pi 2 here ...): Root cause was to enable (on the Rock 5B in the Garage or the Raspberry Pi that I have in the House for some warmer-environment testing) in /etc/sysctl.conf (for Debian/Raspberry Pi OS/Ubuntu and similar GNU/Linux Distributions): That's probably causing some serious flooding of the different subnets which are now "merged" into one, without NAT/Masquerading or other stuff to take care of these conflicts. In past versions this was done by iptables, but nowadays it got replaced by nftables, which is very different to configure. That's what I need to figure out right now .... |
|
The difference (while still probably having the issue) can be seen in Running this between MYHOSTNAME Ubuntu Desktop <-----> Raspberry Pi 2 AP (using either the same-subnet IP address 192.168.4.31 or the esp32-subnet IP address 172.27.1.1). Directly to AP using the main LAN address: Involving Routing on the main OPNSense Router (Static Route to the Raspberry Pi AP for the involved 172.27.1.1/16 subnet): Directly to AP using the main LAN address: Involving Routing on the main OPNSense Router (Static Route to the Raspberry Pi AP for the involved 172.27.1.1/16 subnet): Directly to AP using the main LAN address: Involving Routing on the main OPNSense Router (Static Route to the Raspberry Pi AP for the involved 172.27.1.1/16 subnet): So While |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The problem
I tried several times OTA and it Never Ever works (at least for me and on an ESP32-S3 - Atom S3 Lite).
Looking at some threads here it is, most likely, a WiFi AP Configuration issue:
I am running my ESP32 off a Homemade AP off a Rock 5B ARM64 SBC with Alfa AWUS1900 USB-Wifi Adapter (RTL8814AU) with Hostapd + DNSmasq.
The devices have no problem being connected and staying connected. Ping works.
I also tried to Reboot the ESP32 (Normal Mode or Safe Mode) prior to performing the OTA.
Nope. It still won't work.
Host DNS Resolution works correctly (the Hostname resolves to the correct IP address).
I tried version: 1 and version: 2 for the OTA section, both time out.
Web Server OTA is not supported on esp-idf framework so that's out of the window too.
This is what I have in the OTA section:
Same issue on ESPHome 2023.12.1 (IIRC the version number, I recently upgraded, but that did NOT solve the issue).
Anything that can be done to get OTA to work ?
The error message just reports:
Which version of ESPHome has the issue?
2024.3.1
What type of installation are you using?
Docker
Which version of Home Assistant has the issue?
N/A
What platform are you using?
ESP32
Board
Atom S3 Lite
Component causing the issue
ota
Example YAML snippet
Requires Debian/Ubuntu GNU/Linux to work with BASH.
Other GNU/Linux Distributions will also work with very minor adjustments (just change the
apt-getcommand part).Potentially Windows WSL / MacOS with BASH support could also work, not sure.
Anything in the logs that might be useful for us?
Additional information
/etc/hostapd/hostapd.conffile:journalctl -xeu dnsmasq.servicedoesn't really show many disconnections / disconnections / renew of DHCP lease (I was doing several USB reflashing in the evening, possible exception: 23:40:27 when I was asleep)Similar story for hostapd:
journalctl -xeu hostapd.servicegivesLooking at https://metadata.ftp-master.debian.org/changelogs//main/w/wpa/wpa_2.10-21_changelog I don't see anything obvious that I am missing on Debian Bookworm - Stable (12) with hostapd-2.10-12 compared to Debian Testing / Unstable with hostapd-2.10-21.
The text was updated successfully, but these errors were encountered: