2024.5: Just a little bit smaller

petro · May 4, 2024, 10:40am

Yes, because you have the dreame vacuum custom integraiton, please read the issues with that custom integration. Update it to 1.0.4 before updating HA.

Isengo1989 · May 4, 2024, 10:42am

Can I do this via CLI ?

ha store smth smth?

Maybe you can link to instructions. Maybe I have to stop the core first?

petro · May 4, 2024, 10:43am

iDevice · May 4, 2024, 10:43am

I noticed the same problem, all the speed gains from previous versions are gone, 2024.5.x is very slow to start now.
I looked at the integrations startup times and nothing changed there, so it’s something else, but I don’t know where to investigate.

petro · May 4, 2024, 10:46am

If you’re having issues like this, it’s likely caused by a custom integration doing bad things. My startup times reduced by 4 seconds this release. I went from 14 seconds to 10 seconds. Largely because of fixes in a few specific integrations (MQTT mostly). I still have 2 integrations that are slow to start up.

I suggest looking in your logs for slowdowns, even going as far as running the troubleshooting guide that bdraco posted earlier.

stefan.uytterhoeven · May 4, 2024, 11:00am

Of course, it needs to be dynamic.
So, an automation can change those startup values during the day. Eg:
In the morning very bright and white, during the night, low brightness, maybe yellow color, when just turning on light

petro · May 4, 2024, 11:02am

If you want something like that, use adaptive lighting custom integration or something similiar.

tom_l · May 4, 2024, 11:02am

That’s not what start up values are for. That’s circadian lighting. You can do it with automation or there’s even a 3rd party integration.

Start up values are defaults.

They don’t change.

iDevice · May 4, 2024, 11:41am

I know, but even in safe mode, it doesn’t change anything.
The slowdown (in my case) seems to have appeared between the loss of frontend and when it connects again, after that, timing seems the same than previous versions, I have a few slow integrations like Synology DSM, Axis, Reolink that can take up to 25s to initialize, but that is usual, nothing changed there.
Here, the anomaly is that it now takes 30s or so between the loss of connection and when the browser connects again with the startup popups where it was a few seconds with 2024.4.x.
Anyway, thanks for the link to bdraco’s post, I will look into it.

SteffenDE · May 4, 2024, 12:44pm

Here also 2024.5.1 very slow and CPU load definitely significantly higher than in 2024.4 so I get many Timing Warnings and Errors in the log. I do not find the root cause if it realy any custom intergration (I do not have Dreame Vacuum).

New are these warnings and errors in 2024.5:

homeassistant.helpers.translation] Failed to load integration for translation: Invalid domain xxx
[homeassistant.components.recorder.db_schema] State attributes for sensor.watchman_missing_entities exceed maximum size of 16384 bytes. This can cause database performance issues; Attributes will not be stored
[homeassistant.components.sensor] Updating snmp sensor took longer than the scheduled update interval 0:00:10

I’m using these custom integrations:

hacs
powercalc
dwd_pollenflug
daikin_onecta
edge_tts
temperature_feels_like
miele
pirateweather
auto_backup
spook
custom_templates
watchmann
ipmi
places
browser_mod
scheduler
daikin_residential_altherma

Anybody find one of these causing a slow HA?

Steffen

Mariusthvdb · May 4, 2024, 12:57pm

which are those? we cant help guessing about your unposted errors.
also, turn on debug: true and asyncio debug (profiler service) for startup Loggins that have beter info than the default HA log
see 2024.5: Just a little bit smaller - #89 by bdraco for instructions

SteffenDE · May 4, 2024, 1:30pm

Have enabled debug mode and there a many lines after restart.

On of the last and coming again ist that about IPMI Intergration:

2024-05-04 15:28:01.221 WARNING (SyncWorker_27) [homeassistant.helpers.frame] Detected that custom integration 'ipmi' calls async_dispatcher_send from a thread at custom_components/ipmi/server.py, line 303: async_dispatcher_send(, please report it to the author of the 'ipmi' custom integration
2024-05-04 15:28:01.223 ERROR (MainThread) [custom_components.ipmi] Unexpected error fetching IPMI coordinator data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 315, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ipmi/__init__.py", line 223, in _async_update_data
    await self.hass.async_add_executor_job(self.ipmiData.update)
  File "/usr/local/lib/python3.12/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/ipmi/server.py", line 303, in update
    async_dispatcher_send(
  File "/usr/src/homeassistant/homeassistant/helpers/dispatcher.py", line 203, in async_dispatcher_send
    hass.verify_event_loop_thread("async_dispatcher_send")
  File "/usr/src/homeassistant/homeassistant/core.py", line 440, in verify_event_loop_thread
    frame.report(
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 162, in report
    _report_integration(what, integration_frame, level, error_if_integration)
  File "/usr/src/homeassistant/homeassistant/helpers/frame.py", line 203, in _report_integration
    raise RuntimeError(
RuntimeError: Detected that custom integration 'ipmi' calls async_dispatcher_send from a thread at custom_components/ipmi/server.py, line 303: async_dispatcher_send(. Please report it to the author of the 'ipmi' custom integration.

and this:

024-05-04 15:27:27.168 ERROR (MainThread) [aiohttp.server] Error handling request
Traceback (most recent call last):
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py", line 452, in _handle_request
    resp = await request_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_app.py", line 543, in _handle
    resp = await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_middlewares.py", line 114, in impl
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/security_filter.py", line 92, in security_filter_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/forwarded.py", line 83, in forwarded_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/request_context.py", line 26, in request_context_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp_session/__init__.py", line 199, in factory
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/auth.py", line 295, in auth_middleware
    return await handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/http/headers.py", line 32, in headers_middleware
    response = await handler(request)
               ^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/http.py", line 73, in handle
    result = await handler(request, **request.match_info)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/shelly/utils.py", line 264, in get
    return await self._ws_server.websocket_handler(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aioshelly/rpc_device/wsrpc.py", line 508, in websocket_handler
    await ws_res.prepare(request)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_ws.py", line 152, in prepare
    payload_writer = await super().prepare(request)
                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_response.py", line 417, in prepare
    return await self._start(request)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_response.py", line 425, in _start
    await self._write_headers()
  File "/usr/local/lib/python3.12/site-packages/aiohttp/web_response.py", line 505, in _write_headers
    await writer.write_headers(status_line, self._headers)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/http_writer.py", line 130, in write_headers
    self._write(buf)
  File "/usr/local/lib/python3.12/site-packages/aiohttp/http_writer.py", line 75, in _write
    raise ConnectionResetError("Cannot write to closing transport")
ConnectionResetError: Cannot write to closing transport

code-in-progress · May 4, 2024, 1:32pm

That pretty much sums it up.

Logan42 · May 4, 2024, 2:42pm

Hi!

Anybody else having strange effects in the energy dashboard since 2024.5?

I have a shelly 3EM and have a helper for it to sum up the three “energy” entities for the dashboard. Additionally I have those three entities separately in the “detailed usage of specific devices” section.

That worked flawlessly from the start some months ago.

But since two days (likely since ugrading to 2024.5(.1)) the general view doesn’t show any hourly values anymore, but only one entry at 2-3 o’clock with the total amount of the counter (a few thousand kwh), instead of just the amount of the increase of the counter within that hour. The detailed view on the other hand still shows hourly values for the three counters over the whole day, just with the change for each hour.

Anybody else with that behaviour? Or any clue what’s happening?

Logan42 · May 4, 2024, 2:55pm

added a screenshot to maybe better show what I described above:

maxym · May 4, 2024, 3:52pm

Somewhere I saw info that beta version of this integration is free of this issue. But might be mixing different issues.

petro · May 4, 2024, 3:55pm

1.0.4 and the beta are free of the issue.

Ildar_Gabdullin · May 4, 2024, 4:04pm

Some theme-related changes were added in 2024.5 - and using variables in a custom theme may break Z-index.
No idea how using a “filter” var may affect this.

type: vertical-stack
cards:
  - type: entities
    entities:
      - input_select.test_value
  - type: entity
    entity: sun.sun

Theme:

theme3:
  ha-card-backdrop-filter: blur(5px)

Issue

Ishmu07 · May 4, 2024, 5:44pm

ecobee update is inconsistent. The default preset_modes follow the new consistent lower case format but custom modes still require capital letters if that is how they are named. Updating to lower case results in API errors.

mirekmal · May 4, 2024, 6:00pm

Seems something changed in 2024.5 regarding iCal integration. In connection to Synology Calendar it seems to work, but throws error in log file every time calendar is accessed:

2024-05-04 17:49:46.254 ERROR (SyncWorker_51) [root] Ical data was modified to avoid compatibility issues
(Your calendar server breaks the icalendar standard)
This is probably harmless, particularly if not editing events or tasks
(error count: 32 - this error is ratelimited)
NoneType: None
2024-05-04 17:49:46.254 ERROR (SyncWorker_51) [root] --- 
+++ 
@@ -14,7 +14,6 @@
 X-SYNO-EVT-COLOR:#3A61A0
 RECURRENCE-ID;TZID=Europe/Warsaw:20240503T001500
 DTEND;TZID=Europe/Warsaw:20240504T234500
-DURATION:PT23H30M
 END:VEVENT
 END:VCALENDAR

While error is self explanatory, I doubt Synology brakes the iCal standard… especially that until 2024.5 it worked perfectly fine.