There were many in the previous posts above including:
2024.5+: Tracking down instability issues caused by integrations.
Did you try any of those?
I just wanted to reiterate the problem may be with the most recent update. I tried refreshing my browser (i.e. chrome) but unable to reach HA via my Nabu Casa address either. If I recall I had a similar instance with an update and had to power down my RaspberryPi and back up again which fixed the problem (although I’m not comfortable doing this on a regular basis). Just thought the community should know. P.S. I do not have the Dreame Vac Integration installed.
I am having the same problem after updating to 2024.5.0. In my case it’s Zigbee2MQTT the responsible: Home Assistant crashes and reboots; then, after a few seconds (when Z2M starts), it crashes and reboots again.
I managed to quickly stop the addon shortly after one of the boots and deselect “Start on Boot”, but I don’t know what to do next.
I’ve tried updating Z2M (I was on 1.36.0-1 and updated to 1.37.0-1) but the problem persists.
@iway and @Emile31 how do you downgrade the HA Supervisor?
Thank you very much
Same problem (I think) and this situation is pretty messed up. The only nonstandard integration I have is frigate, so there’s no way an update should be so catastrophic. I can’t even load into safe mode, so I’m hoping I can even recover. What a disaster…
I have zigbee2mqtt running as well an suspect it being the culprit.
1 Like
zigbee2mqtt at current 1.37.1-1: HA hangs after start and is unusable.
With zigbee2mqtt disabled, all works smoothly and fast.
1 Like
Same here. Tried with Z2M v1.36.0-1 and v1.37.0-1.
Now who should responsible for a fix? Z2M or HA? I don’t know if I should post a issue on Z2M’s GitHub.
What’s your MQTT broker?
I have all of those components at those versions in my prod install currently and it runs like a screaming banshee. (way fast)
Mines Mosquito 6.4.0
Mosquito 6.4.0 here too.
Running on a RaspberryPi 3.
The pi3 only has 1 Gb memory. With the Zigbee2MQTT add-on running, it probably runs out of memory. You can try to increase the swap size.
1 Like
Still, it was working beautifully until the Home Assistant Operating System 2024.5.0 update
Update: apparently, disconnecting the coordinator, rebooting and plugging it back in solves the problem.
Read it in an issue in HAOS github, just tested, and worked.
Update #2: Rebooting the system with the coordinator plugged in causes the problem to return.
1 Like
Thank you for your solution, it worked for me as well.
The only other solution I had found was to stop the Zigbee2MQTT addon (which is not practical with my connected devices).
I’m still having major issues with HASS crashing since 2024.5. Safe mode seems to be stable, but of course I can’t run normally in safe mode. It has been hit or miss when I disable/enable a few integrations at a time. I can’t seem to narrow it down to a single issue. I even suspected it may be my PC. So I moved to another PC and have the same issues. I also updated the VirtualBox thinking that may be the issue… Still no luck. I finally have it running somewhat stable but now integrations are not loading properly such as Tank Utility… Has anyone confirmed this is a HASS issue that needs and will be fixed? I’m loosing hair quickly!
I’m getting in over my head… I don’t know what any of this really means:
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:147
First occurred: 1:50:10 AM (10 occurrences)
Last logged: 1:51:30 AM
Error doing job: Error on transport creation for incoming connection
Traceback (most recent call last):
File “/usr/local/lib/python3.12/asyncio/selector_events.py”, line 235, in _accept_connection2
await waiter
File “/usr/local/lib/python3.12/asyncio/sslproto.py”, line 578, in _on_handshake_complete
raise handshake_exc
ConnectionResetError
Logger: asyncio
Source: runner.py:190
First occurred: 1:54:26 AM (3 occurrences)
Last logged: 1:54:26 AM
Executing <Task pending name=‘Task-18578’ coro=<RequestHandler._handle_request() running at /usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py:452> wait_for=<Future pending cb=[Task.task_wakeup()] created at /usr/local/lib/python3.12/asyncio/base_events.py:448> cb=[Task.task_wakeup()] created at /usr/local/lib/python3.12/site-packages/aiohttp/web_protocol.py:527> took 0.152 seconds
Executing <Task pending name=‘Task-18579’ coro=<WebSocketHandler._writer() running at /usr/src/homeassistant/homeassistant/components/websocket_api/http.py:169> wait_for=<Future pending cb=[_chain_future..call_check_cancel() at /usr/local/lib/python3.12/asyncio/futures.py:387, Task.task_wakeup()] created at /usr/local/lib/python3.12/asyncio/base_events.py:448> created at /usr/src/homeassistant/homeassistant/util/async.py:40> took 0.140 seconds
Executing <Task pending name=‘Task-18579’ coro=<WebSocketHandler._writer() running at /usr/src/homeassistant/homeassistant/components/websocket_api/http.py:169> wait_for=<Future pending cb=[_chain_future..call_check_cancel() at /usr/local/lib/python3.12/asyncio/futures.py:387, Task.task_wakeup()] created at /usr/local/lib/python3.12/asyncio/base_events.py:448> created at /usr/src/homeassistant/homeassistant/util/async.py:40> took 0.106 seconds
The strangest part is that after enabling the profiler: Set asyncio debug, I haven’t crashed at all! Am I correct to assume that the debugging is slowing it down enough that it no longer crashes? Whatever was done in 2024.5 to speed things up may need another look.
Logger: homeassistant
Source: /usr/src/homeassistant/homeassistant/runner.py:147
First occurred: 1:50:10 AM (4513 occurrences)
Last logged: 1:21:37 PM
Error doing job: Error on transport creation for incoming connection
Traceback (most recent call last):
File “/usr/local/lib/python3.12/asyncio/selector_events.py”, line 235, in _accept_connection2
await waiter
File “/usr/local/lib/python3.12/asyncio/sslproto.py”, line 578, in _on_handshake_complete
raise handshake_exc
ConnectionResetError
Has anyone tried updating to 2024.6.0 I really hope this is fixed in this version, but I am scared to try it.
EDIT: I was able to successfully update to 2024.6.0 with no issues, I decided to just go for it.
Damn, upgraded to 2024.5 and my RPI bootloops. I have to fresh install as I don’t have a RPI5 HDMI adaptor. What a PITA.
How much testing was done before release?