woopsicle
commented
2 years ago I have the same issue every few days. Running 'ha core rebuild' fixes the issue quickly, but still annoying to happen in the first place. All addons stop working, as do some other things such as my aircon (izone), webrtc (HACS installed) streams and turning on/off lights (which are not controlled by an addon). Sensors keep working only really. I get the same for the Observer status page. Nothing obvious in the logs, the first thing that happens is my aircon stops working (even though its still on the network etc).
A few extracts: `
2022-04-06 15:44:19 WARNING (MainThread) [pizone.discovery] Connection to controller lost: id=000025800 ip=192.168.1.106
2022-04-06 15:44:19 INFO (MainThread) [homeassistant.components.izone.climate] Controller 000025800 disconnected due to exception:
2022-04-06 15:44:19 INFO (MainThread) [pizone.controller] Attempting to reconnect to server uid=000025800 ip=192.168.1.106
2022-04-06 15:44:21 WARNING (MainThread) [pizone.discovery] Controller reconnected: id=000025800 ip=192.168.1.106
2022-04-06 15:44:21 INFO (MainThread) [homeassistant.components.izone.climate] Reconnected controller 000025800
2022-04-06 15:50:24 WARNING (MainThread) [pizone.discovery] Connection to controller lost: id=000025800 ip=192.168.1.106
2022-04-06 15:50:24 WARNING (MainThread) [pizone.discovery] Unable to complete <coroutine object Controller._refresh_system at 0x7f76e38732c0> due to connection error
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/pizone/controller.py", line 472, in _get_resource
async with self._sending_lock, session.get(
File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 1138, in __aenter__
self._resp = await self._coro
File "/usr/local/lib/python3.9/site-packages/aiohttp/client.py", line 634, in _request
break
File "/usr/local/lib/python3.9/site-packages/aiohttp/helpers.py", line 721, in __exit__
raise asyncio.TimeoutError from None
asyncio.exceptions.TimeoutError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/local/lib/python3.9/site-packages/pizone/discovery.py", line 364, in _wrap_update
await coro
File "/usr/local/lib/python3.9/site-packages/pizone/controller.py", line 369, in _refresh_system
values = await self._get_resource(
File "/usr/local/lib/python3.9/site-packages/pizone/controller.py", line 486, in _get_resource
raise ConnectionError("Unable to connect to the controller") from ex
ConnectionError: Unable to connect to the controller
2022-04-06 15:55:37 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /store request
2022-04-06 15:55:37 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /core/info request
2022-04-06 15:55:37 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /host/info request
2022-04-06 15:55:37 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /os/info request
2022-04-06 15:55:37 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /info request
2022-04-06 15:55:37 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /supervisor/info request
2022-04-06 15:55:37 WARNING (MainThread) [homeassistant.components.hassio] Can't read Supervisor data: 
RudolfRendier
shbatm
github-actions[bot]
The problem
After some random amount of uptime my HA Core looses the ability to connect with the supervisor. Until I restart core via de HA CLI.
What version of Home Assistant Core has the issue?
core-2022.3.7
What was the last working version of Home Assistant Core?
No response
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
This is the System Health after a restart, because the information won't load when it happens.
System Health
Home Assistant Community Store
GitHub API | ok -- | -- GitHub Content | ok GitHub Web | ok GitHub API Calls Remaining | 4853 Installed Version | 1.23.0 Stage | running Available Repositories | 1018 Downloaded Repositories | 21Home Assistant Cloud
logged_in | false -- | -- can_reach_cert_server | ok can_reach_cloud_auth | ok can_reach_cloud | okHome Assistant Supervisor
host_os | Home Assistant OS 7.5 -- | -- update_channel | stable supervisor_version | supervisor-2022.03.5 docker_version | 20.10.9 disk_total | 30.8 GB disk_used | 15.0 GB healthy | true supported | true board | ova supervisor_api | ok version_api | ok installed_addons | Samba share (9.5.1), Terminal & SSH (9.3.0), Vaultwarden (Bitwarden) (0.15.0), AdGuard Home (4.4.5), MariaDB (2.4.0), UniFi Network Application (1.1.4), WireGuard (0.6.0), ESPHome (2022.2.6), deCONZ (6.12.0), Spotify Connect (0.11.0), Duck DNS (1.14.0), Nginx Proxy Manager (0.11.0), Mosquitto broker (6.0.1), Node-RED (11.1.0), Studio Code Server (4.2.0)Lovelace
dashboards | 5 -- | -- resources | 8 views | 16 mode | storageSpotify
api_endpoint_reachable | ok -- | --Example YAML snippet
No response
Anything in the logs that might be useful for us?
Additional information
The :8123/hassio-page shows the Troubleshooting-tips
Troubleshooting
The link for the observer points me to: http://homeassistant.local:4357/ But that's not the correct name, with the right name it shows:
Home Assistant observer
Supervisor: | Connected Supported: | Supported Healthy: | Healthy
:8123/config/info doesn't load the 'Health'-segment
This makes I can't load i.e. deCONZ via the sidepanel. Unable to load the panel source: /api/hassio/app/entrypoint.js.
I created an notification for when the deCONZ CPU usages goes stale (for 30mins), which is indicative of the error occurring. My zigbee lights also start failing, but weirdly enough not right away. Today I received the notification at 5:18 AM and around 20 minutes later the lights could still be turned on. Now, an hour, or maybe two later, nothing responds.
deCONZ is just an example and the most annoying case, but i.e. VS Code Server add-on has the same issue. I though for a while it was related to the purge at night, but I disabled auto_purge and rescheduled it to some other time of day, but no effect.
I had this problem on a Pi3 and it's still present after I migrated to a NUC i3 using proxmox. Suspected a flaky sdcard to be the issue, but that's not the case.