Focusing on how they use same overall API is a bit beside the point and doesn’t answer the question at hand:
is the full stream processed over the websocket in the same way?
Because it isn’t, it’s done very differently using a separate API method.
1 Like
I’ve tested this for a couple of days now. The companion app does run better than a browser window on my normal instance. It still seems to suffer the same fate though. Slow downs and crashes are predictable, they just seem to take longer to appear when compared to the browser window. A browser window on the “entity restricted” instance is far and away the best choice in terms of performance. It’s instant response on this hardware, and doesn’t seem to slow down or exhibit any degradation. The “entity restricted” test tablet hasn’t been restarted or refreshed in 4 days and is just as snappy as when it was first deployed.
1 Like
If you install the SQLite Web add-on then you can run the sql query below to identify your most active entities, assuming you’re running the default database. You might find big offenders that you don’t need and you can simply disable them. I have whole house power monitoring, my gas and water meters, and local bluetooth device location. Those entities are near constantly updating and there’s a lot of them, but I need/want that information so I can’t just disable them. I haven’t come up with another way to keep those entities and have decent dashboard performance, besides creating a second home assistant instance.
SELECT
states_meta.entity_id,
count(*) cnt
FROM
states
LEFT JOIN states_meta ON (
states.metadata_id = states_meta.metadata_id
)
GROUP BY
states_meta.entity_id
ORDER BY
cnt DESC;
2 Likes
I dug in a little more on this one, found the WebView debugging option in the companion app so I could watch the websocket. It is using the newer compressed state method, so that’s something. Unfortunately it’s still watching all entities so makes sense you’re still running into the same thing. Selectively subscribing is more complex so I could understand why that hasn’t been implemented (yet?)
I came to the same conclusion that the only real way around this for now is multiple home assistant instances.
2 Likes
I wanted to add my two cents here:
I have multiple screens around the house: NSPanel Pro 120 (web page), NS Panel Pro (companion app side loaded), Samsung Smart Fridge (web page), Fully on a older Sony Tv.
They have all run sluggish. You can see some are new and well powered and some are low end.
The UX has been pretty terrible on all of them.
I disabled cardmod and it helped.
What really helped was completely disabling 2 BLE scanners! They flood traffic constantly, and right to the front end.
Thank you to everyone on this post to help me find the problem.
I’ll propose this out of ignorance, but why would HA send hidden entities out this websocket? That seems like some low hanging fruit that would not be needed. I already have them excluded from the logger (also excluded call_service), but even when they were not visible, they still flooded the socket.
I +1 the subscribe solution, but I’m not a front end dev and not going to touch that one.
1 Like
Totally agree, This was the same in my setup. I have 6 wallpads, a computer and several phones and while the PADs are the slowest, they are not that slow and no BLE helped immensely.
Really a shame 
I love the Thinksmart View 8 in our living room as smart clock.
But the dashboard often lagged and took long to load.
I followed the advice of using a second HA instance yow, and it’s WAY faster, as I also have a lot state updates in my main HA installation (e.g. whole house with almost every device / outlet is used for energy monitoring).
As I can’t disable these entities, a second HA instance might be the only way.
Still hate the idea, as I also need the dashbaords on the first instance, as I can’t use the second one on my mobile, where I also rely on voice assistant and more …
I just cobbled together this:
homeassistant-entity-filter-proxy
It filters the websocket traffic to only the entities you need.
I currently don’t have a big homeassistant instance to properly test the performance improvements of this.
Issues and Pull requests welcome
4 Likes
Nice! I vibe-coded something similar in python and it’s been working well for me.
I took a slightly different approach where it watches the websocket and reads the lovelace config as it’s requested. Handy because it’s dynamic, the downside is the unfiltered subscribe_entities has already come through. I left that in place and start filtering them for the client after parsing the dashboard.
The other nice thing is you can go to another page like /developer-tools/state, refresh, and you’ll get the unfiltered entities again. I looked briefly if I could detect the page change but that wasn’t straightforward.
I’ll give yours a go, I have a bunch of chatty entities so it should be a decent test.
Works great,
My wall tablet started to work faster.
Can you create home assistant addon for that ?
Works well on my Pi5 (2Gb) with touchscreen. Would freeze occasionally then I started added more ESPHome Presence Sensors and then it started to freeze constantly. Lots of troubleshooting and I saw the huge amount of sensor updates via websocket which led me to this post and your proxy.
Thank you!
Now i see 1 sensor update a second vs 20+
I’m very interested in trying this, but unfortunately I’ve never worked with Go before. I’ve been doing some reading and have been trying to build this application using the golang docker container. I’ve gotten closest with the following command:
docker run --rm -v "$PWD":/usr/src/myapp -w /home/kevin/app/homeassistant-entity-filter-proxy-main golang:1.26.0-bookworm go build -v
Which gives me the following error:
go: go.mod file not found in the current directory or any parent directory; see 'go help modules'
I’m running this from the “homeassistant-entity-filter-proxy-main” referenced in the command and where the go.mod file is located. Anyone have any beginner Go tips?
For anyone with old devices i created an homeassistant addon/app based on the work of DragonHunter274.
This addon adds an entity status throttler that limits the update frequency (entity status updates per second) to a configurable interval. So older devices do not get too much load from homeassistant. As an addition you can use globs to exclude or include entities in the configuration of the addon.
This is a first version developed mainly for me and allows me to use my older and low performance android tablets without crashes.
Just try it if you like: GitHub - fuslwusl/homeassistant-entity-filter-proxy: Reduced update interval and amount of data for low power Homeassistant clients · GitHub
Install the addon and use port 8124 (instead of 8123) for the Homeassistent connection on low performance devices.
3 Likes
Thanks for the work @fuslwusl, I’m trying to use the app but it seems like I can’t make it work… not sure if I’m doing something wrong (probably I am).
Apart from installing the app, configuring it and starting it, should I do anything else?
EDIT: it seems the app is stopping by itself if “include all entities” is not set to true. If I change that to true, the app works as it should but of course it is not supposed to be like that I guess.
My configuration:
homeassistant_url: http://homeassistant:8123
access_token: >- supersecret
listen_addr: ":8124"
dashboard_url_path: ""
include_all_entities: false
state_update_interval: 3s
transparent: true
extra_entities: []
include_entity_globs: []
exclude_entity_globs: []
This is the log I see and the URL ending with 8124 is not working:
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
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
s6-rc: info: service legacy-services: stopping
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: warning: service s6rc-oneshot-runner is marked as essential, not stopping it