Closed scstraus closed 5 years ago
Since you are on a Pi, try disabling image_processing:
and see if that helps with performance.
I think it may be MQTT as I have a very verbose Smappee Energy meter that likes to update me every second with a very lengthy update which carries very little useful information. I've disabled it for now. I will see if things improve, but already history graphs are working better.
Is there some good way to tell when things are getting overloaded? My CPU and memory usage don't look that bad. Maybe 50% CPU and 60% memory usage, but I suspect it might be I/O where the bottleneck is since I use a lot of graphs.
Hey I have a very smiliar problem see #19752, and I do not use MQTT (what I am aware off) I checked my PI's performance and I can't see any problems with it, my avg load is araound 40-50% and spikes only reach 70%. I reverted to version 0.83.X with the same config I used in 0.84 and with version 0.83 I do not have the errors or the craches anymore.
I also was showing no load issues in terms of CPU or RAM, but I think the database I/O was overwhelmed (Pi's have a slow USB 2.0 bus which is pretty easy to overwhelm). You may want to do a search for "sql" in your log and see if it's complaining about a locked database or something like that. That indicates the database giving up hope ;-).
It doesn't have to be MQTT that overwhelms the database. If you define enough of any kind of sensor, or a few that update a lot you can get this problem, as each update needs a database write to build out the history (and I can't see any way how to reduce the amount of history records being written, but I'd love to know if someone knows how to do that).
I have now check for all the logs I can fins both HA-logs and Host logs and I can't find anything with SQL-errors in the loggs
Have you been in any luck finding the problem, I am thinking to move the database out from the pi and run it on another server just for testing, do you think the will do any diffrance?
I suspect it's the calendar platform causing the problem.
I'm having the same issue as of version 0.84.6 as well. I'm running Home Assistant in Docker, so I was able to easily create a test container and was able to isolate components one by one. What I found was that in my setup, calendar components were causing Home Assistant to hang on restart. If I left it long enough, it would eventually start, but that could take upwards of an hour to happen. Once it loaded, the log would be filled entirely with errors about the components taking too long to load. For example:
Updating todoist calendar took longer than the scheduled update interval 0:01:00
As a test, created a stock instance of Home Assistant with only the Todoist calendar component loaded and found the same problem, though Home Assistant would now boot after only a few minutes of hanging, again with log errors about taking too long to load. I tried the same test with Google calendar component and had the same problem. As soon as I remove the calendars from my config, Home Assistant seems to boot and run normally again.
@scstraus Can you try removing calendars form your config and let us know what your results are?
Alright, I will turn them off on the next restart. Since I turned off MQTT, the creashes have stopped, but I still get lots of the "taking over 10 seconds" type messages. I'm just commenting out this. For the record my restarts are only taking about 4 minutes.. I have suspected the calendar component of problems in the past, I've noticed previously that my cameras wouldn't start when calendar was enabled. Sometimes they still don't start, but if I restart enough times it usually works.
google:
client_id: !secret google_email_client_id client_secret: !secret google_email_secret
So I tried it and I don't see any major change. Still have the "taking over 10 seconds" messages.. I suspect the ones that are left are because my synology is overloaded more than anything else.. I think for me the issue was MQTT with smappee due to it's overzealous refresh rate and large messages.
@scstraus Okay, thanks for letting me know your results. Seems like there might be a number of components are compounding the issue, though I'm having particular trouble with the calendar component. I'll let you know if I figure anything else out that might be helpful to you.
Interesting I tried to disable all my sensors and it makes no different I don't get the update thingy in the logs but the crashes stills happens. Strange thing is that my config now only consist of IKEA, Telldus and Chromecast devices and a vacuum. Anyone can give me a hint on what to try next?
Home Assistant release with the issue:
0.84.6
Last working Home Assistant release (if known): 0.83.2 was last version I was on without this problem
Operating environment (Hass.io/Docker/Windows/etc.):
Hassbian on Pi B3+ Component/platform:
The main hass process is disappearing. Almost all components are reporting long update times before the crash such as weather.dark_sky, media_player.itunes, calendar.google, weather.openweathermap, etc..
Description of problem:
Hass is crashing. I'm not sure why, it seems like it may be happening when I try to access the logbook from iOS (which appears to not be able to finish retrieving any items or takes so long that I try to go elsewhere in the UI), but there is some delay there, it's definitely not immediate.
Problem-relevant
configuration.yaml
entries and (fill out even if it seems unimportant):Traceback (if applicable):
Additional information: