-
Notifications
You must be signed in to change notification settings - Fork 653
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
Timeout on call http://172.30.32.1:8123/api/core/state #5373
Comments
I am having this exact same issue for the past few weeks. Did you make any progress with troubleshooting? |
Hi, The same issue. After updating HA to the latest version. It causes rebooting HA!! |
Same here ! Did you solve it ? |
For me it was related to esphome background compile errors while interacting with the esphome dashboard. Are any of you running esphome? |
I had to install a previous version of HaOS and to restore the HA without plugins first to make it working again, I'm waiting now before any new update |
Same here, have also ESPhome installed. Tried to restore my old backup and work of some weeks was gone. It worked for some weeks now, but again it starts freezing and some restarts are necesseray per day. What I recognized as well: I have the scheduler components installed, eyerytime I activate my fan scheduler the system freezes..... |
It happens to me since I have installed Frigate NVR. Raspberry Pi 4 with SSD and Coral TPU. |
It's been a few weeks now. It restarts every 15 minutes. I went through all the hardware. HA Generic x86-64 version |
same here ... after upgrading the frontend is not loading anymore Supervisor Log:
|
Same here... Home Assistant starts, is reachable for few seconds and than get timeout on call http... error |
Same here. Unable to find a clue in debug also. |
I've been struggling as well on a RPi4 64 bits 2GB RAM and needed to :
I'm staying now at the moment on: Core 2024.11.2 Make sure you have enough external/remote backups, not only local ones !! I only had backups on GDrive for the last 3 days, (last 20 days locally, + generational backups (weeks, months, ...)) ; might have been problematic if something worse happened |
In my case I was able to search the homeassistant.log logfile and looked for MainThread. The last entry ended with an something starting with an ICS_Calendar that apparently got stuck. Deleting the corresponding entry in homeassistant/.storage/core.config_entries solved it for me. After all it was an HACS integration that somehow got me in problems during the upgrade. No idea how I was able to figure this out.... |
What's weird is that it doesn't seem to be plugin specific, many people are reporting on various plugins/extensions used |
@MichaKersloot Thank you for this. I knew I had bumped the ICS extension at the same time, but it didn't make any sense why that would cause a failure. The issue is already filed here for the ICS extension in case anyone wants to follow along. |
For those wondering, the problem with ics_calendar was definitely in it. I figure I'm not the only one who primarily works with other languages and doesn't know most of the nuances with python. So the following is a summary of the problem, and maybe it'll help someone else with a problematic component. A while ago, a lock was added around downloads to ensure that it wasn't connecting too frequently to a server that didn't like it when several calendars were configured that were hosted on the same server. The most recent change was to switch from using synchronous http calls in the background to using httpx and making the calls fully asynchronous (btw, thanks for the updated HA documentation that explains how I can use httpx clients provided by HA core!). The problem is that, in python, you have to use different classes for locks, and slightly different syntax between sync and async code. Not knowing this, I just left the lock in place, and figured I'd test pulling it out later. So what happens, is that when you have more than one calendar configured, it'll acquire the lock for downloading the first calendar, and when HA calls the update method to download for the second calendar (which happens before the first lock is released), instead of failure to acquire the lock yielding processing so it can be tried later, it deadlocks the main loop for HA, causing HA to hang. This would normally happen pretty early in HA's restart process, but could easily be delayed depending on what other components are installed and configured. I'm not sure why this could happen as it does with only one calendar, but again, what I don't know will cause trouble. :) So a temporary fix is to remove the lock -- it's probably not needed, but I don't know for sure. If it turns out to be needed, I'll add it back in using the correct lock class and syntax. I hope this helps others troubleshoot problems! |
Still running on HAOS 12.4, just updated HA core to 2024.12.4 and running fine for the last 3 days, no issues yet |
Describe the issue you are experiencing
I'm getting sporadic
Connection lost. Reconnecting...
errors.The system recovers after about 45 sec and when checking the supervisor log see this:
What type of installation are you running?
Home Assistant OS
Which operating system are you running on?
Home Assistant Operating System
Steps to reproduce the issue
...
Anything in the Supervisor logs that might be useful for us?
System Health information
System Information
Home Assistant Community Store
Home Assistant Cloud
Home Assistant Supervisor
Dashboards
Recorder
Supervisor diagnostics
config_entry-hassio-a509b91f35186fd4404181d100b1e3b6.json
Additional information
No response
The text was updated successfully, but these errors were encountered: