core icon indicating copy to clipboard operation
core copied to clipboard

Dashboards Slow and laggy since 2025.6.0(1)

Open jupppo opened this issue 6 months ago • 16 comments

The problem

Since the update to the 6.0 and also 6.1 my dashboards are very laggy, sometimes displaying a value is also empty. Most of the time I have to wait up to 30sec until graphs are displayed. CPU and Memory Usage seems OK. When I do a fresh restart, it is OK for a while, but after some time it lags again

What version of Home Assistant Core has the issue?

2025.6.1

What was the last working version of Home Assistant Core?

2025.5.X

What type of installation are you running?

Home Assistant OS

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet


Anything in the logs that might be useful for us?


Additional information

No response

jupppo avatar Jun 14 '25 08:06 jupppo

can confirm the issue. every page that has a history graph causes 40% cpu load for me and takes forever to display the graph

nocusham avatar Jun 14 '25 08:06 nocusham

Yes, right. I checked while redering the graphs. CPU peaks above 80% sometimes

jupppo avatar Jun 14 '25 09:06 jupppo

I can confirm same issue... Pages which have multiple mini-graph-card with 24h history do not load...

DejanBukovec avatar Jun 14 '25 12:06 DejanBukovec

Changed the title since it seems to afffect dashboard with graphs only. Thinking about reverting back, cause its really annoying

jupppo avatar Jun 14 '25 13:06 jupppo

For me it seems to occur on dashboards with apexcharts cards.

krithur avatar Jun 14 '25 14:06 krithur

on Apex as well, but mainly on the HA standards

jupppo avatar Jun 14 '25 16:06 jupppo

Same here with 24hr history graphs. Also the Energy Dashboard sometimes doesn't load or at least loads very slowly.

houthacker avatar Jun 14 '25 17:06 houthacker

seems to be that it is not a rendering issue, rather than db query performance

jupppo avatar Jun 14 '25 19:06 jupppo

I have noticed the same issue.

Warren2006 avatar Jun 14 '25 22:06 Warren2006

I am really not getting any further with that. Most of my dashboards are practically unusable. I added Ram and CPU Power to the virtual machine running HA. CPU Load and Memory load is lower, but it has no effect on the loading times of the dashboard. The only hint I get so far is this warning in the logs: Logger: homeassistant.components.recorder.util Quelle: components/recorder/util.py:292 Integration: Recorder (Dokumentation, Probleme) Erstmals aufgetreten: 15:13:56 (1 Vorkommnis) Zuletzt protokolliert: 15:13:56

The system could not validate that the sqlite3 database at //config/home-assistant_v2.db was shutdown cleanly

jupppo avatar Jun 15 '25 13:06 jupppo

+1 Mainly history card doesn't load recent values when opening. Those load after a while (next sensor update?!) I also use the history Explorer card. That one load normally

erkr avatar Jun 15 '25 13:06 erkr

It is not related to database... I use MySQL and is same thing... Adding CPU do not help because looks like only one core is used... Same thing I saw when Im restore backup that only one core has been used... But this is maybe related to "unsupported" version of installation(VM+Supervised installation)...

DejanBukovec avatar Jun 15 '25 14:06 DejanBukovec

I use the full Hass OS on a VM. Why do you think its unsupported?

jupppo avatar Jun 15 '25 15:06 jupppo

I suffer from the same issue, running HAOS on Pi. So no VM involved

erkr avatar Jun 15 '25 15:06 erkr

Small illustration. Here a history card with 4 temp sensors just after opening: image

And the same card about 30 seconds later: image

Edit: I noticed this only seem to happen for history cards populated via a filter in auto entities. That worked till core 2025.5. Since 2025.6 this only works when I hard code the entities. Via auto entities that long delay occurs Raised an issue in auto entities as well: https://github.com/thomasloven/lovelace-auto-entities/issues/553

erkr avatar Jun 15 '25 18:06 erkr

I have the same issue with refresh dashboard pages. After update to 2025.6.1 all pages have long time to show up. Some times is longer 5x than before update.

gednet avatar Jun 15 '25 21:06 gednet

I have noticed the same issue.

g-kiss avatar Jun 16 '25 07:06 g-kiss

I have the same problem - all graphs and calculated values are terribly slow.

jaroslavresler avatar Jun 16 '25 18:06 jaroslavresler

It is really frustrating. I went through the change logs, but I couldnt really pinpoint what could be the root cause of the issue. Without that its hard to contact the respective dev. Perhaps anyone else has an idea, what could cause the issue.

jupppo avatar Jun 16 '25 19:06 jupppo

The service get_statistics was added. Maybe there are related changes in the recorder

erkr avatar Jun 16 '25 21:06 erkr

I'm having this same issue with my config-template-card/picture elements dashboard. Works perfectly on 2025.5.3, but gets bogged down in 2025.6.0 and 2025.6.1.

atrain2009 avatar Jun 16 '25 22:06 atrain2009

Hey @Hypfer we think your change 142602 is causing quite some issues for many users. Could you look into that?

https://github.com/home-assistant/core/pull/142602

Thanks

jupppo avatar Jun 17 '25 09:06 jupppo

Respectfully, I don't see how random people with zero credibility believing something is supposed to be my problem. This is not corporate. Hence, corporate style communication is unsuited for this space.

That said, feel free to take a look at the commit and come up with a hypothesis of how the actual code change could lead to the observed behavior.

"Something changed in the recorder" is good enough of a heuristic to go checking, however, it is not good enough of a proof to ping some random other person in the way that just happened.

Edit: Now on a computer, I could fully parse the previous comments that are

It is really frustrating. I went through the change logs, but I couldnt really pinpoint what could be the root cause of the issue. Without that its hard to contact the respective dev.

And

The service get_statistics was added. Maybe there are related changes in the recorder

So there is no evidence and you admit that there is none, but then suddenly, an idea how to make it someone else's problem appears and suddenly it's

we think your change 142602 is causing quite some issues for many users.

Maybe.. not do that? Especially when there is like a paper trail three comments further up?

Hypfer avatar Jun 17 '25 10:06 Hypfer

Well Hüpfer, its really not nice to get rude and unfriendly. We went through the changes and this is the only thing we saw, which could be related. If you had spend less time in a humble answer like, "No, thats not from my change", or a as experience dev give us even hint, that is something the community could benefit from.

You spent a lot of time quoting and firing at me. I think we could use that time more wisely

jupppo avatar Jun 17 '25 10:06 jupppo

It might have nothing to do with the service @Hypfer created: when calling it directly from the developers tab, the result is almost instant. What I do see however is that the request for the statistics is queued for ~11.5 seconds (Firefox developer tools), and the console show a lot of messages like Received event for unknown subscription 181. Unsubscribing..

Maybe someone from the HA frontend team can help with this?

houthacker avatar Jun 17 '25 14:06 houthacker

@houthacker it is just speculating, but I can imagine changes where made to facilitate the new service. The new service works, but changes probably caused unforeseen delays for i.e. the history card. Funny is that the custom history explorer card is not effected!

erkr avatar Jun 17 '25 14:06 erkr

AFAICT the changes in the PR are 100% related to the new service and no existing code is changed. So only if something calls the new service it could have an effect.

slovdahl avatar Jun 17 '25 14:06 slovdahl

The problem is even bigger than I thought. As rigthly speculated here I can confirm that it affects all my statistical elements. Even those where I do not display a chart:

Image

If I click on those entities, after they loaded after ca. 30s, I get permanently the following:

Image

One thing is strange, although it says entity not available, the values show up in the long term statistics (after 30s loading)

Image

One more thing puzzles me, obviously not all users seem to be affected. Anyone an idea how to proceed from here?

jupppo avatar Jun 18 '25 05:06 jupppo

Honestly, the extent to which 2025.6.x breaks my HA instance versus how little it seems to be impacting others is quite puzzling indeed. I don't use graphs or statistics like many others in this thread seem to, but something in the update brings all of my dashboards to a grinding halt, with long load times and cards that never even appear, and I don't even know where to begin to troubleshoot. I have picture elements cards embedded in a config template card (which gets reevaluated each time one of several entities update), and a simple-swipe-card that contains custom button cards that appear when certain conditions are met. The config template card loads eventually, but the simple-swipe-card containing my custom buttons is completely missing from my dashboard (with no error messages indicating an issue). Everything works fine after rolling back to 2025.5.3. Happy to create another GitHub issue if my issue is unrelated to this, but I thought maybe the root cause was the source of all of our issues.

atrain2009 avatar Jun 18 '25 14:06 atrain2009

I've noticed this with 2025.6.x as well. Whenever I pull up any dashboard with graphs there is some serious lag before the screen populates. I have one particular page with 3 standard sensor cards showing 24 hours of history and every once in a while it will trigger a database lock and my CPU goes up and my whole instance becomes unresponsive until I restart the container. Like others have stated, I'm not sure if they are related but I figured I'd add my own observations. Going back to 2025.5.3 fixes the issue so it does seem specific to this version.

2025-06-18 08:54:40.400 ERROR (PyrateLimiter's Leaker) [root] Uncaught thread exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/threading.py", line 1041, in _bootstrap_inner
    self.run()
    ~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/pyrate_limiter/abstracts/bucket.py", line 195, in run
    asyncio.run(self._leak(self.sync_buckets))
    ~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/asyncio/runners.py", line 195, in run
    return runner.run(main)
           ~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^^^^^
  File "/usr/local/lib/python3.13/asyncio/base_events.py", line 719, in run_until_complete
    return future.result()
           ~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/site-packages/pyrate_limiter/abstracts/bucket.py", line 177, in _leak
    leak = bucket.leak(now)
  File "/usr/local/lib/python3.13/site-packages/pyrate_limiter/buckets/sqlite_bucket.py", line 118, in leak
    count = self.conn.execute(query).fetchone()[0]
            ~~~~~~~~~~~~~~~~~^^^^^^^
sqlite3.OperationalError: database is locked

EDIT: I found that the database locking issue seems related to a combination of using a conditional card with custom expander card on the masonry layout and not with this particular issue on historical data. Converting the page to sections seemed to resolve my issue, strangely enough.

yuejon avatar Jun 18 '25 14:06 yuejon