-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Crash on http_request.post #2853
Comments
Did some more testing and it appears that esphome will crash every time if the response is not provided within around 4 seconds. The below will consistently crash if the response is provided after 5 seconds. Apparently, the watchdog timer is not being reset during waiting. Basically, this component is hardly usable on ESP32 due to this issue.
|
I'm experiencing the same issue on ESPHome 2022.4.0. |
None that I'm aware of. This component is basically useless in this state. This seems to be a general issue with watchdog on ESP32. There are quite a few other open issues where WDT triggers restarts when too much is going on. |
A similar issue here, In short, ESP32 crashes when the server is unavailable |
Could it be because http_request component is making synchronous requests? If so, then probably 5 second timeout is the maximum value allowed for now? Could be the component re-implemented using asynchronous calls (https://www.arduino.cc/reference/en/libraries/asynchttprequest_generic/)? |
+1 |
1 similar comment
+1 |
Same issue here. Was thinking it was something I'd done all day. ESPHome Version: 2022.10.0
Example snippet from yaml # Make periodic update to google
time:
- platform: sntp
id: sntp_time
on_time:
# Every 5 minutes
- seconds: 0
minutes: /5
then:
- if:
condition:
lambda: 'return id(top_temp).has_state() && id(bottom_temp).has_state();'
then:
- output.turn_on: status_led
- logger.log:
level: INFO
format: "Updating top: %.1f bottom: %.1f"
args: [ 'id(top_temp).state', 'id(bottom_temp).state' ]
- http_request.get:
verify_ssl: false
url: !lambda |-
char buf[256];
sprintf(buf, "https://script.google.com/macros/s/DeplymentID/exec?top=%.1f&bottom=%.1f", id(top_temp).state, id(bottom_temp).state);
return ((std::string) buf).c_str();
on_response:
then:
- wait_until:
condition:
wifi.connected:
timeout: 45s
- logger.log:
format: "Response status: %d"
args:
- status_code
- output.turn_off: status_led |
I get such a non-permanent error when I try to control my relay from the esp 8266 board. At the same time, the request from the PC works. Has anyone found a solution? How do we bring this problem to the developers? |
Seems, like the default
http_request:
timeout: 1s
#include <esp_task_wdt.h>
esp_task_wdt_init(15 /* timeout */, false /* panic */); A better solution would be of course using some async http library, maybe just native ESP-IDF's http client will be a good alternative. |
Hi, I have the same problem. I get watchdog induced restarts when the timeout is larger than 1s. I am trying to send data to google sheet. It works, but I do not get a response from HTTP GET due to timeout. Is there any workaround for this? Perhaps a watchdog definition in on_boot automation? |
Hello, Any news on that ? I also got this issue on ESP32 (event without 1s timeout). I don't have this on ESP8266. This bug make http component inusable on ESP32. Since this bug has been there for a year, I would like this component to be marked as incompatible with ESP32 |
Same issue here. I have been debugging for days because pretty much any http_request fails and crashes the ESP until I finally found this issue. |
Same here. This issue basically makes it almost impossible to use. It works for a few minutes and crashes again. I'm using it to call an API of a device in the same network, response is always very fast (under 1 second). |
Has anyone implemented the second workaround? |
Just tried reducing the Timeout to 4 seconds, still crashing. I tried the C++ fix, by creating a file in the configuration directory named
to my configuration
I'd be interested in getting the C++ solution working if possible. |
4 seconds might be still too big, there are actually 2 timeouts (connect timeout and receive, both of which set to 4 seconds, if I remember correctly, so in worst case full request might take 8 seconds, which is still bigger than 5 seconds. In many cases setting as low as 1 second could work if you don't need to analyze response status. You can't call a function from a header file, you should include header and call |
I tried 1 second timeout and still getting crashes. Was getting connection refused instead of a 200 response if that makes any difference. I also tried https://github.com/epiclabs-uc/esphome-nowatchdog-component, but the ESP still crashes unfortunately. |
I'm also getting crashed but only when using ethernet withLAN8720 on an esp32 but when I use wifi its working without problems. |
i also have crashes when doing an http request to dsmr. Hopefully this can be fixed soon and i can power my p1 meter through poe and get rid of the wifi connection. |
FYI, My devices are using POE Ethernet and it doesn't resolve the issue in my situation. |
it works for me when i use the wifi connection, as soon as i enable POE ethernet i have crashes and i get failures back for the post requests. |
That's interesting! |
I experience exactly the same problem when making HTTP request from one node to another via eth on esp32. I have smart home modules with exposed API and this pretty much prevents any direct communication between them. changing timeouts doesn't help. Can we mark it as a bug? would anyone be able to pick it up? |
I believe I am also having this issue, with the watchdog resetting my device and doing http_request.post every 2.5 minutes, usually within 600 ms, but sometimes seeing up to 3500ms
|
I am seeing a similar issue with my Airgradient using an ESP32. If there is no internet connection, the request fails and ESP crashes. Since the airgradient esphome config also sends a HTTP POST on boot, sometimes it even fails to boot and gets stuck in a bootloop. |
So far this has worked great for my esp32 devices. Any chance you know of a similar workaround for esp8266? |
The problem
The device crashes randomly when performing http_request. It seems that the watchdog triggers the restart.
It only occurs on ESP32 (tried on lolin32_lite, nodemcu-32s and mhetesp32minikit), but not ESP8266 (d1_mini).
Sample yaml reproduces the issue quite often, but not every time. It seems to be more consistent when there are some sensors attached.
Which version of ESPHome has the issue?
2021.12.1
What type of installation are you using?
pip
Which version of Home Assistant has the issue?
No response
What platform are you using?
ESP32
Board
lolin32_lite, nodemcu-32s, mhetesp32minikit
Component causing the issue
http_request
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response
The text was updated successfully, but these errors were encountered: