Yes. It was actually a crappy one (temporary fix I forgot about). After replacing it with a decent cable, there was no change. Things worked fine, until they didn’t.
Right now, I can access the web ui, but things load really slowly – to the point where I cannot do anything with HA because by the time, something loads (for example, creating a helper), minutes have passed. In fact, just now it has lost connection in between me clicking on “add helper” and it trying to load the popup that is supposed to load within a second.
Is this something?
24-03-25 13:02:23 ERROR (MainThread) [supervisor.homeassistant.api] Timeout on call http://172.30.32.1:8123/api/core/state.
24-03-25 13:02:23 WARNING (MainThread) [supervisor.misc.tasks] Watchdog missed an Home Assistant Core API response.
24-03-25 13:05:49 ERROR (MainThread) [supervisor.homeassistant.api] Timeout on call http://172.30.32.1:8123/api/core/state.
24-03-25 13:05:49 INFO (MainThread) [supervisor.auth] Home Assistant not running, checking cache
24-03-25 13:07:16 ERROR (MainThread) [supervisor.homeassistant.api] Timeout on call http://172.30.32.1:8123/api/core/state.
24-03-25 13:07:16 WARNING (MainThread) [supervisor.misc.tasks] Watchdog missed an Home Assistant Core API response.
These are all from the SUPERVISOR logs. The IP address there must be internal only. This is an actual error from now where I have no access to the web ui.
I am connected directly through the local network. hassOS on ethernet, my PC on ethernet, same switch, same VLAN. I use the phone through wifi to debug as well, because if ethernet worked and wifi wouldn’t, I’d know there might be something to investigate. But there is no difference between ethernet and wifi.
Yeah. That’s how it always was. Blazing fast. Lights were zigbee2mqtt, controlled locally. But even when controlling from on the road (via VPN connection, not nabu), things worked decently quick. This all just happened recently.
There doesn’t seem to be any network activity on the host at all.
I tested this by curling a website from that host in a tmux split. Then, there would be small numbers. So while I am currently trying to access HA, there is absolutely no I/O activity. But there should be, correct? It cannot serve the pages without it.
I don’t run pfsense on the hass machine. It is a dedicated firewall. When testing this, I deactivated the addons via ha addons stop <name>
through ssh. I deactivated all of them except for ssh (obviously), it did not make a difference.
Just checked the pfsense logs. There is nothing about that hosts ip address in there except for DHCP requests. No blocks, no filters, nothing.
I got rid of addons that I thought I wouldn’t really need - or at least could do without: piper, whisper, openwakeword, vscode.
At the moment, only official addons are installed. This doesn’t have to mean anything, but the way I see it - aren’t the Home Assistant yellow / blue devices sold by (and therefore, I assume, recommended by) the Home Assistant team not “just” raspberry pis with additional hardware? Yet, these addons are official… I see this as “these addons should run fine alongside hassos on our recommended hardware”. Maybe that’s wrong.
But then there’s two other things: 1) This is an intel NUC, not a raspberry pi. There’s 32GB of RAM. There’s an Intel(R) Core™ i7-8809G CPU @ 3.10GHz with 8 cores (if I read the output from cat /proc/cpuinfo
correctly). Shouldn’t this be enough for hassos with a couple of officiall addons?
And then, perhaps more importantly, 2) this system has been running perfectly fine for years. Yeah, I sometimes add (also remove) integrations and (less frequently) addons – but it has always been working quickly as expected. No lag, no being logged out of the web ui, no losing connection (not even with wifi).
The heavy lifting for frigate is done by a google coral USB stick, but I stopped this addon as well to see whether this would make a difference. It didn’t.
Now, typing all this took me some time. The helper entity from the beginning of the post that I tried to create finally got to the point where I could select what type of helper I’d like to create; then (now that I just checked) it lost connection again.
Btw., everything is already up to date. supervisor 2024.03.0, os 12.1. All addons and the HACS stuff are up to date.
So I’d understand if I had just installed Home Assistant on this device and nothing would work. Then I’d say “it’s too much work for the device”. But again, the device has been working fine like this for ages. I even disabled integrations that have been working without issues just to see if it was going to work as a “bare minimum” (only addons and integrations I really need to use on a daily basis, no fun / experimental / useless stuff). Even that didn’t make any difference. Things are disabled atm., so the system should run faster, if anything. But the issue is still there.
But also, I should mention again that, often, Home Assistant itself works fine. I am not able to access the UI, but walking in the hallway in the evening will result in the lights automatically turning on. While going crazy not finding a solution for this, I will get a signal notification (including multiple camera snapshots) when the front gate opens.
Hopefully, this log I posted above gets us anywhere. I am currently working on a fresh configuration in a dockerized environment on my PC. So if nothing works, my plan is to set up a fresh install on the actually hass machine and have everything relevant ready to copy there. I also have daily backups, but installing them doesn’t seem to make any difference, either.
So while a fresh install might be the best I can do, it is also kinda risky. If there is anything wrong with my current configuration, I cannot use my backups – so I’ll have to start fresh from scratch and do everything (connecting services, create those automations and helpers that aren’t in package yaml files) manually.