15.2 update - Lovelace Interface hangs

[RaSch75]

Describe the issue you are experiencing

on RPI4: Lovelace interface hangs maybe an hour after the update to 15.2. Background automations still worked - but the interface not accessible either local or through Nabu. Downgrade after reset to 15.1 works stable now for half a day, so it looks really like a 15.2 issue. (Also checked was the core update to 2025.4.2 that seems innocent, as well as the Z-Wave JS UI update that did not showed to be the core of the trouble)

What operating system image do you use?

rpi4-64 (Raspberry Pi 4/400 64-bit OS)

What version of Home Assistant Operating System is installed?

15.2

Did the problem occur after upgrading the Operating System?

Yes

Hardware details

SkyConnect (ZigBee) ZBT1
ZW090 AEON Labs Z-wave Stick (Gen5)

Steps to reproduce the issue

1.Update to HASS 15.2 and Core 2025.4.2 and Z-Wave JS UI
2.Lovelace hangs after a while(30min to 2h), automations still working (just UI hanging and not accessible through Browser (local and through Nabu)
3.Downgrade core to 2025.4.1 and downgrade Z-Wave JS UI
4.Lovelace working - but hanging after some time
5.Downgrade to HASS 15.1
6.All fine for > 1h
7.Update Core again to 2025.4.2 and latest Z-Wave JS UI
8.All fine still for >4h

...

Anything in the Supervisor logs that might be useful for us?

2025-04-15 13:47:46.176 INFO (MainThread) [supervisor.os.manager] Completed download of OTA update file /data/tmp/hassos-15.2.raucb
2025-04-15 13:48:32.903 INFO (MainThread) [supervisor.os.manager] Install of Home Assistant Operating System 15.2 success
2025-04-15 13:48:32.906 INFO (MainThread) [supervisor.host.control] Initialize host reboot using logind
2025-04-15 13:48:32.917 INFO (MainThread) [supervisor.addons.manager] Phase 'application' stopping 2 add-ons
2025-04-15 13:48:32.947 INFO (SyncWorker_4) [supervisor.docker.manager] Stopping addon_a0d7b954_nodered application
2025-04-15 13:48:33.493 INFO (MainThread) [supervisor.api.proxy] [a0d7b954_nodered] Home Assistant WebSocket API closed
2025-04-15 13:48:33.496 INFO (MainThread) [supervisor.api.proxy] [a0d7b954_nodered] Home Assistant WebSocket API closed
2025-04-15 13:48:37.653 INFO (SyncWorker_4) [supervisor.docker.manager] Cleaning addon_a0d7b954_nodered application
2025-04-15 13:48:37.846 INFO (SyncWorker_0) [supervisor.docker.manager] Stopping addon_core_configurator application
2025-04-15 13:48:41.849 INFO (SyncWorker_0) [supervisor.docker.manager] Cleaning addon_core_configurator application
2025-04-15 13:48:41.967 INFO (SyncWorker_2) [supervisor.docker.manager] Stopping homeassistant application
2025-04-15 13:49:06.140 INFO (MainThread) [supervisor.addons.manager] Phase 'services' stopping 0 add-ons
2025-04-15 13:49:06.141 INFO (MainThread) [supervisor.addons.manager] Phase 'system' stopping 1 add-ons
2025-04-15 13:49:06.158 INFO (SyncWorker_3) [supervisor.docker.manager] Stopping addon_a0d7b954_zwavejs2mqtt application
2025-04-15 13:49:36.753 INFO (SyncWorker_3) [supervisor.docker.manager] Cleaning addon_a0d7b954_zwavejs2mqtt application
2025-04-15 13:49:36.819 INFO (MainThread) [supervisor.addons.manager] Phase 'initialize' stopping 0 add-ons
2025-04-15 13:49:36.819 INFO (MainThread) [supervisor.plugins.cli] Stopping cli plugin
2025-04-15 13:49:36.826 INFO (SyncWorker_6) [supervisor.docker.manager] Stopping hassio_cli application
2025-04-15 13:49:40.456 INFO (SyncWorker_6) [supervisor.docker.manager] Cleaning hassio_cli application
2025-04-15 13:49:40.520 INFO (MainThread) [supervisor.plugins.dns] Stopping CoreDNS plugin
2025-04-15 13:49:40.528 INFO (SyncWorker_1) [supervisor.docker.manager] Stopping hassio_dns application
2025-04-15 13:49:44.315 INFO (SyncWorker_1) [supervisor.docker.manager] Cleaning hassio_dns application
2025-04-15 13:49:44.388 INFO (MainThread) [supervisor.plugins.audio] Stopping Audio plugin
2025-04-15 13:49:44.395 INFO (SyncWorker_4) [supervisor.docker.manager] Stopping hassio_audio application
2025-04-15 13:49:48.429 INFO (SyncWorker_4) [supervisor.docker.manager] Cleaning hassio_audio application
2025-04-15 13:49:48.523 INFO (MainThread) [supervisor.plugins.multicast] Stopping Multicast plugin
2025-04-15 13:49:48.530 INFO (SyncWorker_7) [supervisor.docker.manager] Stopping hassio_multicast application
2025-04-15 13:49:52.056 INFO (SyncWorker_7) [supervisor.docker.manager] Cleaning hassio_multicast application
s6-rc: info: service legacy-services: stopping
2025-04-15 13:49:52.584 INFO (MainThread) [supervisor.misc.scheduler] Shutting down scheduled tasks
2025-04-15 13:49:52.587 INFO (MainThread) [supervisor.docker.monitor] Stopped docker events monitor
2025-04-15 13:49:52.588 INFO (MainThread) [supervisor.api] Stopping API on 172.30.32.2
2025-04-15 13:49:52.594 INFO (MainThread) [supervisor.hardware.monitor] Stopped Supervisor hardware monitor
2025-04-15 13:49:52.608 INFO (MainThread) [supervisor.dbus.manager] Closed conection to system D-Bus.
2025-04-15 13:49:52.627 INFO (MainThread) [supervisor.core] Supervisor is down - 0
2025-04-15 13:49:52.629 INFO (MainThread) [__main__] Closing Supervisor
[11:49:52] INFO: Watchdog restart after closing
[11:49:53] WARNING: Halt Supervisor
[11:49:53] INFO: Supervisor restart after closing
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
cont-init: info: running /etc/cont-init.d/udev.sh
[20:01:32] INFO: Using udev information from host
cont-init: info: /etc/cont-init.d/udev.sh exited 0
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
services-up: info: copying legacy longrun supervisor (no readiness notification)
services-up: info: copying legacy longrun watchdog (no readiness notification)
[20:01:32] INFO: Starting local supervisor watchdog...
s6-rc: info: service legacy-services successfully started

Anything in the Host logs that might be useful for us?

File "/usr/local/lib/python3.13/site-packages/zigpy/endpoint.py", line 270, in request
    return await self.device.request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<11 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/zigpy/device.py", line 378, in request
    await send_request()
  File "/usr/local/lib/python3.13/site-packages/zigpy/application.py", line 841, in request
    await self.send_packet(
    ...<14 lines>...
    )
  File "/usr/local/lib/python3.13/site-packages/bellows/zigbee/application.py", line 921, in send_packet
    async with asyncio_timeout(
               ~~~~~~~~~~~~~~~^
        MESSAGE_SEND_TIMEOUT_MAINS
        ^^^^^^^^^^^^^^^^^^^^^^^^^^
        if not packet.extended_timeout
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        else MESSAGE_SEND_TIMEOUT_BATTERY
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ):
    ^
  File "/usr/local/lib/python3.13/asyncio/timeouts.py", line 116, in __aexit__
    raise TimeoutError from exc_val
TimeoutError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/zha/helpers.py", line 1352, in handler
    return await func(self, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/zha/light.py", line 184, in async_turn_on
    await self.entity_data.entity.async_turn_on(
    ...<6 lines>...
    )
  File "/usr/local/lib/python3.13/site-packages/zha/application/platforms/light/__init__.py", line 375, in async_turn_on
    result = await self._level_cluster_handler.move_to_level_with_on_off(
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<2 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 85, in wrapper
    with wrap_zigpy_exceptions():
         ~~~~~~~~~~~~~~~~~~~~~^^
  File "/usr/local/lib/python3.13/contextlib.py", line 162, in __exit__
    self.gen.throw(value)
    ~~~~~~~~~~~~~~^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 70, in wrap_zigpy_exceptions
    raise ZHAException("Failed to send request: device did not respond") from exc
zha.exceptions.ZHAException: Failed to send request: device did not respond

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/core.py", line 2814, in _run_service_call_catch_exceptions
    await coro_or_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 2837, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/adaptive_lighting/hass_utils.py", line 62, in service_func_proxy
    await existing_service.job.target(call)
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1007, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
        hass, entity, func, data, call.context
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1079, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 648, in async_handle_light_on_service
    await light.async_turn_on(**filter_turn_on_params(light, params))
  File "/usr/src/homeassistant/homeassistant/components/zha/helpers.py", line 1354, in handler
    raise HomeAssistantError(err) from err
homeassistant.exceptions.HomeAssistantError: Failed to send request: device did not respond�[0m
�[31m2025-04-15 23:33:24.393 ERROR (MainThread) [homeassistant.core] Error executing service: <ServiceCall light.turn_on (c:01JRXNXSXN:al:IFSG:ntrv:19): entity_id=['light.decke_tv_licht'], params=transition=45.0, color_temp=370, color_temp_kelvin=2702>
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/bellows/zigbee/application.py", line 926, in send_packet
    send_status, _ = await req.result
                     ^^^^^^^^^^^^^^^^
asyncio.exceptions.CancelledError

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 68, in wrap_zigpy_exceptions
    yield
  File "/usr/local/lib/python3.13/site-packages/zha/zigbee/cluster_handlers/__init__.py", line 86, in wrapper
    return await RETRYABLE_REQUEST_DECORATOR(func)(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/zigpy/util.py", line 136, in retry
    return await func()
           ^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/zigpy/zcl/__init__.py", line 378, in request
    return await self._endpoint.request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<9 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/zigpy/endpoint.py", line 270, in request
    return await self.device.request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<11 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/zigpy/device.py", line 378, in request
    await send_request()
  File "/usr/local/lib/python3.13/site-packages/zigpy/application.py", line 841, in request
    await self.send_packet(
    ...<14 lines>...

System information

System Information

version	core-2025.4.2
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
user	root
virtualenv	false
python_version	3.13.2
os_name	Linux
os_version	6.6.74-haos-raspi
arch	aarch64
timezone	Europe/Zurich
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.5
Stage	running
Available Repositories	1666
Downloaded Repositories	6

Home Assistant Cloud

logged_in	true
subscription_expiration
relayer_connected	true
relayer_region	eu-central-1
remote_enabled	true
remote_connected	true
alexa_enabled	false
google_enabled	false
cloud_ice_servers_enabled	true
remote_server	eu-central-1-3.ui.nabu.casa
certificate_status	ready
instance_id	88c8cbbe6fa349098c7d40a2ddf568d4
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 15.1
update_channel	stable

Additional information

No response

[sairon]

As there are literally no changes between release 15.1 and 15.2 that could have potentially change the behavior (the only change that makes 15.1 and 15.2 different for on RPi is #4016), there must be some other factor involved that made the device inaccessible. You shared Core logs instead of Host logs. The Core logs only show there was some problem with ZHA. This could have been cascading result of a lockup of the host system, however, it could have been the other way too.

As there's no fundamental reason for the OS 15.2 causing such issues if 15.1 is fine, I suggest to look for other sources of the problem. Starting by checking the Host logs at the time when the device was inaccessible, eventually retrying the upgrade and checking what exactly causes the frontend unreachability. As both frontend and the automation engine runs in the same container, it's more likely the problem is on different layer than OS.

[RaSch75]

Thanks - the host logs are empty when the frontend hung. From the change-logs I agree that it looks not like the 15.2, that's why I've tried last - but apparently it works on 15.1 and not on 15.2. I will wait for the next OS update and then check again in more detail. Am Mi., 16. Apr. 2025 um 15:58 Uhr schrieb Jan Čermák < ***@***.***>:

…

As there are literally no changes between release 15.1 and 15.2 that could have potentially change the behavior (the only change that makes 15.1 and 15.2 different for on RPi is #4016 <#4016>), there must be some other factor involved that made the device inaccessible. You shared Core logs instead of Host logs <https://my.home-assistant.io/redirect/logs/?provider=host>. The Core logs only show there was some problem with ZHA. This could have been cascading result of a lockup of the host system, however, it could have been the other way too. As there's no fundamental reason for the OS 15.2 causing such issues if 15.1 is fine, I suggest to look for other sources of the problem. Starting by checking the Host logs at the time when the device was inaccessible, eventually retrying the upgrade and checking what exactly causes the frontend unreachability. As both frontend and the automation engine runs in the same container, it's more likely the problem is on different layer than OS. — Reply to this email directly, view it on GitHub <#4030 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BEZLVYUZXAFGBNTHBY7VXAL2ZZOXPAVCNFSM6AAAAAB3IED7S2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBZGY4DANBWHE> . You are receiving this because you authored the thread.Message ID: ***@***.***> *sairon* left a comment (home-assistant/operating-system#4030) <#4030 (comment)> As there are literally no changes between release 15.1 and 15.2 that could have potentially change the behavior (the only change that makes 15.1 and 15.2 different for on RPi is #4016 <#4016>), there must be some other factor involved that made the device inaccessible. You shared Core logs instead of Host logs <https://my.home-assistant.io/redirect/logs/?provider=host>. The Core logs only show there was some problem with ZHA. This could have been cascading result of a lockup of the host system, however, it could have been the other way too. As there's no fundamental reason for the OS 15.2 causing such issues if 15.1 is fine, I suggest to look for other sources of the problem. Starting by checking the Host logs at the time when the device was inaccessible, eventually retrying the upgrade and checking what exactly causes the frontend unreachability. As both frontend and the automation engine runs in the same container, it's more likely the problem is on different layer than OS. — Reply to this email directly, view it on GitHub <#4030 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BEZLVYUZXAFGBNTHBY7VXAL2ZZOXPAVCNFSM6AAAAAB3IED7S2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQMBZGY4DANBWHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mt7479]

I have the same issue on x86_64 running on kwm without any kind of zigbee coordinator. A downgrade solved it for me too.

[eplinux]

I have the same issue on Raspberry Pi 4. Updated the core system yesterday - now lovelace is unreacheable.

[cedricdelecole]

I have the same issue after the udpdate to 15.2, but mine is running on Synology NAS on Virtual machine.
Here is what I had :

Restarted the Virtual machine and seems to be back for now

[PJFonseca]

I have the same issue after the udpdate to 15.2, but mine is running on Synology NAS on Virtual machine. Here is what I had :

Restarted the Virtual machine and seems to be back for now

Same thing with my installation on synology. Sometimes it works, some doesn't.

[mgrey]

Same here, upgrade to 15.2 locks lovelace (no updates, but numbers seems fine in the background).
Upgrade notice to 15.2 stays and can't be taken away.
I downgraded to 15.1 and ok again.

[Zerotwistknife7]

Same issue, Lovelace hung.

What's the method to downgrade? I tried restoring a previous backup and got the same results.

[mgrey]

Same issue, Lovelace hung.

What's the method to downgrade? I tried restoring a previous backup and got the same results.

I did:
ha os update --version "15.1"

[diedeno]

Same problems over here.
Network seems down, does not respond to ping anymore, all network related checks (e.g. opnsense, kmi weather, and so on) fail.
Rolled back to 15.1. (on Pi 4)
Waiting to see if problem goes away.
Edit: yes, a rollback is the solution. No doubt.

[Bredin76]

Same issue, Lovelace hung.
BUT - ping is OK
automatisations are OK

RFXcom rfxtrx looks down too.

Rollback in 15.1 solved the two problems ( lovelace + RFXTRX)

[MattHodge]

Same issue here. Twice now HA has become inaccessible over the network:

• Running in Proxmox VM
• Able to ping the server over the network
• Trying to curl lovelace fails: curl: (7) Failed to connect to <myhost> port 443 after 5 ms: Couldn't connect to server
• The host is working fine:
  • Can get shell
  • Can ping from HA server over the network fine
• A reboot fixes it but it came back again with same behaviour

Only happening since 15.2. Now rolling back to 15.1 (os update --version "15.1")