I have seen other references to this before, but the explanations have not fitted.
My entire HA installation (except for web clients) is on a small SSD on a Raspberry Pi 5 in the garage. It’s a very small HA installation with very few entities.
The Pi is in the garage because I need to use BLE communications to our Tesla. The Pi is on Wi-Fi because our network hub is about 20 metres away in the study, and I have no hard-wired network to the garage. I have a Wi-Fi repeater (same SSID, different RF channels - as recommended) in between. I have HA configured to use IPv4 with a fixed IP address using the DHCP server in the network hub.
Everything else (phones, computers, etc.) works fine this way.
After a period of inactivity, I get very a very slow initial response (timeouts through to minutes of response time) on the HA UI. If I send a series of pings the Raspberry Pi, it seems to start responding, then the HA UI springs to life as well.
Automations seem to be working in the interim - it’s just the UI that stops responding.
I’m by no means adept at diagnosing this kind of problem. If anyone knows of settings or other things that I could change, I’d be grateful for any hints.
You could try moving the pi to cabled network temporary, see if that solves it. If it does, you can buy a cheap ESP32, configure it as a bluetooth proxy and place that in the garage.
Try this. In the UI, click your user profile at the bottom left of the side bar. Then, in your profile page, check that Advanced mode is on - if it’s not, turn it on (hard refresh or clear your browser cache just in case).
Then, in the same profile page, scroll down to the Browser settings section - you’ll see a “Automatically close connection” option. Turn it off and your connection should no longer disconnect after 5 minutes.
Thanks @fleskefjes, but I was looking for experience regarding causes and remedies, rather than suggestions as to how to change things willy-nilly in the hope of improvement.
BTW the following link may be relevant, although it is a bit dated. On reading around, I discovered that Raspberry Pi Wi-Fi has a rather poor reputation.
WiFi in general isn’t really recommended for HA. The Pi, with no WiFi antenna to speak of, makes a non-ideal situation much worse.
I’d second @fleskefjes’ suggestion to use a bluetooth proxy for your Tesla and move your Pi back to where it can be wired.
Alternatively, if you don’t wanna experiment with a bluetooth proxy or move your Pi around, trying a powerline adapter might give you more stability than a WiFi connection.
Because devices on your network that are meant to recieve and send data reliably perform best on a cabled connection. A wifi repeater adds latency and removes bandwidth.
I take your point, except a variety of other bandwidth consuming devices all work just fine on this network. As another reader said, this is 2024 - in my experience, both WiFi and Pi “just work” these days. I’ll relocate the repeater to be a bit more central between the Pi and the hub, and see what happens.
Firstly there was misinformation in my original post. The gadget that I called a Wi-Fi “repeater” is actually a Netgear EX6100v2 set up as a second AP, on a hard-wired Ethernet cable from the hub. It is set to 2.4GHz Chanel 6.
When the (AU) National Broadband Network finally arrived, we were given a new Telstra hub. I forgot to check the Wi-Fi channel allocation setting. When I had a look today, it was set to “Auto (20/40MHz)” bandwidth, and had selected itself onto Channel 13 (which I didn’t even know was a thing at 2.4GHz). Anyway, I set it to Channel 1 and 20MHz.
For now, things seem to be quite snappy. Cross fingers.
Just when I thought I had fixed the problem, it came back even worse. This time the EX6100 Access Point couldn’t even get an IP address from the hub. It turned out that the EX6100 was slowly dying (or at least the Ethernet port was). I replaced the AP with a new tplink RE450 (Netgear no longer has an equivalent product) and everything started running as smooth as silk. The upside is that I got to open up the EX6100 and do some trouble shooting. There are only two components between the Ethernet port and the main gubbins under the shield - a “magnetics” assembly (unlikely culprit) and a Qualcomm Ethernet driver (my money’s on this). The EX6100 surprised me with the level of technology present in such a small and cheap component. Trouble’s a-brewing, however: With the recent advent of non-interoperable products for Wi-Fi networking, I think Wi-Fi is about to lose its once lovely gloss.
