OTA Error sending data: [Errno 104] Connection reset by peer #1721
Comments
|
I had the same issue, turns out I had originally flashed with a
|
|
It looks like the application above won't fit in flash or RAM, but there is no error message. |
|
|
|
I've also been experiencing the symptom of OTA updates stalling with the same error when using just a single remote_receiver module. I'm testing an RF receiver which is a cheap SRX887, which is a superregenerative receiver, meaning that it's always sending pulses through. I find if I tie it's output to ground I can then send OTA updates more reliably (100% reliably if it boots that way, less so if it's only grounded some time after bootup), so my guess is that the interrupt servicing (or polling?) is causing a race / timeout / resource exhaustion condition, particularly during OTA updates. I'm using a Tuya ESP8266 module, the TYWE3S, RF input on GPIO12. Perhaps somewhat related, I noticed that there's an "idle" setting which defines the end of a received code block and a filter param for high-passing, but for RF it might be helpful to have a setting for how long we should see a logic low before actively listening for / decoding a code - since we get noise all the time, but we get a quiet mark/sync block when valid carrier is present (depending on protocol, of course). I haven't looked at the code though, so I might be making some invalid assumptions there. |
Yes, these RF receivers generates interrupts continuously on the data pin. I've a SRX882 receiver connected with similar behavior. All interrupts must be disabled and allocated memory freed before executing an OTA update, but I'm not sure if this is implemented. I've also stack dumps and endless reboots when removing the receiver and add over 100 RF transmit functions. I reached the limit of around 50 RF transmit functions with OTA enabled. Adding more (which is required for my application) results in stack overflow or unpredictable behavior because RAM is full. I can add around 25 RF transmits with OTA disabled. I don't understand why all generated |
Would your use-case support having the transmit functions handled inside HA instead of on-device? I'm using the built-in HA event component to send all received codes into HA, which I then handle using nodered. That way the ESP doesn't need to store any remote codes onboard, and I don't need to reflash every time I change my setups. Downside of course is that it then depends on HA being available to work, but I'm OK with that for the services I'm controlling. Here's what I'm using inside of the remote_receiver definition (shows both an IR and the RF ones, I have the IR one commented out currently while I test RF, but it does work): I've got a similar thing setup for TX, but I haven't tested that, yet - let me know if you'd like the (untested) config though. |
|
Thanks for sharing your idea. I understand what you mean and was not aware that this is possible. Currently I defined all RF codes in the ESPHome yaml, so all codes are located inside the ESP8266. I'll give it a try. |
|
ota source |
|
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. |
|
This is still an issue, it seems that the interrupts from an RF receiver will hog enough time from the cpu that OTA updates stall. At a guess, per @Erriez 's note above, esphome should be disabling interrupts from remote_receiver when it commences an OTA update, if it's not already. |
Operating environment/Installation (Hass.io/Docker/pip/etc.):
pip3
ESP (ESP32/ESP8266, Board/Sonoff):
ESP8266 Wemos D1 Mini / NodeMCU
ESPHome version (latest production, beta, dev branch)
Version: 1.15.3
Affected component:
https://esphome.io/components/ota.html
Description of problem:
OTA update results in failure:
Error sending data: [Errno 104] Connection reset by peerProblem-relevant YAML-configuration entries:
Logs (if applicable):
OTA update over WiFi:
Logs on USB serial:
Additional information and things you've tried:
remote_receiverorremote_transmitterin theyamlfile.remote_receiverandremote_transmitterremoved works (when this already flashed)The text was updated successfully, but these errors were encountered: