All i’m trying to say is that broadcasting all entity updates to all devices regardless of what they’re interested in is poor design/architecture. It’s the equivalent of sending all chat DM messages between all users on a chat platform to every single user on the entire platform and just having their frontends filter out just the DMs meant for them. In my analogy, your advice is the equivalent of telling people on the chat platform to chat less frequently or for the platform to shed some users rather than calling for a fix to the platform to implement some kind of pub/sub architecture that gets only the desired messages delivered to/from the correct users. Do you see why it makes me believe your recommendation is unreasonable or a joke?
Anyhow, I’m sure that as home assistant use continues to grow and people’s smart homes continue to get larger and have more devices that more and more people will have this same issue I have. I’m sure then the issue will get more interest/traction maybe eventually leading to a fix. Unfortunately I don’t currently have enough bandwidth in my life to assist with a fix myself; however, I do believe that acknowledging that there is a problem (i.e. documentation or an issue ticket) is the first step toward a potential fix or improvement rather than just telling users to use less sensors or have them update less frequently when they’re already updating at the default/reasonable rate.
I switched to Home Assistant (from SmartThings) about a year ago. Initially I had one Samsung wall tablet and it worked great. I’ve since added more and the latest is a 14" Chinese tablet bought off Amazon, but brand new. The new tablet (only a week in service) routinely takes an hour or more to update device statuses.
Since our home is a large footprint ranch, many devices, especially door locks, are distant. Knowing their status and being able to lock them and confidently knowing they are locked is a big part of the reason we have wall tablets. My wife is now resorting to pulling out her phone because the tablet cannot be trusted.
Today I found a 10-year old small tablet in a drawer, and thought it would make a perfect dashboard.
But not so - it takes a couple of minutes to load the simplest dashboard having only three light switches on it, and then it is so sluggish to interact with that it is practically unusable. I have “only” about 350 entities in my HA. “Normal” web pages load and interact acceptably.
I built my Home Assistant system on the basis that it is not Apple, Google, Amazon or any other boxed-in environment, and that I can do pretty much what I want. For me, it is kind of like the Linux of smart-home systems.
Telling people to “buy better hardware” is a non-sequitur. The hardware really is just about adequate for the job. It does follow from basic software design that one shouldn’t flood the clients with data they don’t want.
I’m running Home Assistant version 2024.12.3, and am looking forward to be able to put my outdated hardware to good use!
Alright, then that there seems to be a viable workaround with additional “remote” HA instances is still better than nothing.
Thanks.
P.S.
But the thought of these constant streams of superfluous data to each dashboard still itch my developer mind. It’s not “technology support”, just seems… unnecessary.
I looked at the websocket event stream, and didn’t find it to be overly chatty in my case, so I guess my old hardware just can’t cut it anyway.
I see I’m not the only one surprised that a simple dashboard can lag terribly on a wallpanel. Mine is brand new PoE powered tablet based on Rockchip RK3566 with an Android 13 on board.
On the other hand my websocket is chatty, but I don’t believe it’s like in OPs case. It gets a spike when MODBUS devices are polled.
Well, it seems I’m going to spin up another HA instance
Yes, this is exactly what I wished would happen as I have a number of old Android tablets and phones that would serve as perfect dashboards but I cannot get HA to load on them. I ended up to using Tileboard and now I have a number of functional Dashboards working around my home without having to spend on new hardware.
That doesn’t mean it’s feasible. Browsers change at a fast pace and they break old functionality. ha will always try to keep up but if their frontend doesn’t support a toolset, then it just won’t work. E.g. iPad v2 isn’t supported because Apple drastically changed safari between then and now. Not much you can do about that.
Have you tried switching from ZHA to Zigbee2mqtt? If so, does it solve this problem or at least improve things?
Asking because I’m researching how best to implement dashboards in my home. I’m currently on ZHA because I don’t yet understand Z2M well enough to switch to it, but I would invest effort in switching to Z2M if it resolves issues like this.
Many thanks @codicusmaximus for pointing out the unfiltered websocket traffic, I also have a ton of updates from power monitoring and mmwave sensors. I thought I’d kept things to a minimum by excluding a bunch from the recorder, but didn’t notice these “tucked away” through the websocket connection.
While I don’t love it, I now have three HA instances in proxmox connected through remote-homeassistant.
Main HAOS instance
HA Container for power monitoring (and separate mysql db)
HA Container to host tablet dashboards
Using remote-ha I’m only importing the entities I use for the dashboards, and it’s noticeably more performant on a Fire HD 8 (2020). This also reduces the number of custom dashboard integrations that I use elsewhere. Similarly those are always loaded whether the current dashboard uses them or not.
This works better for me for now, but it’s definitely more trouble than would be expected from new HA users. I’ll check if there are any related feature requests yet. I agree as the number of connected devices & data grows, this could be addressed much more cleanly in HA core.
I am also having issues, specifically with android tablets.
I have tried the HA app and fully kiosk browser with much the same results.
The HA app runs really well on mid-range android phones, but similar or better spec tablets are basically unusable.
I have tried a Samsung S9 FE+ and a Lenovo M10 Plus Gen3 and dashboard performance on both of these devices is horrible, slow to load basic dashboards, slow to update entity status like light changes, however, on a quite old Surface Pro, the dashboard runs really well in both Edge and Firefox.
I have checked the web socket activity, and it seems to only be getting between 2 and 6 updates per second.
Surely there is a solution to use these android tablets that doesn’t involve multiple instances of Home Assistant? (not sure if that would help in my instance anyway)
Still no acknowledgement that there’s a fundamental weakness of design/architecture of the entity updates → dashboard refresh pipeline to address. I tried by making this ticket but it got completely ignored https://github.com/home-assistant/frontend/issues/22115
I spent most of the evening digging deeper into this and I have found that there are already things in place to facilitate the possibility of having something like this i.e. subscribe_entities in commands.py (in websocket_api component). The HA backend in the core allows you to subscribe to specific entities already; however, the HA frontend is not equipped to utilize this functionality.
I am not a frontend dev at all and am a bit lost on web stuff but even I managed to cobble together a simple test/proof of concept:
In Chrome console issuing: var hass = await window.hassConnection;
Looking at the events in “websocket” in Network / Messages (the screenshot I posted earlier showing the fast flow of messages), expanding the JSON and noting down the subscription ID numbers labeled “id” and then forcing an un-subscription from all topics producing entity state updates (since it’s not possible to modify a subscription we have to blow away entity update subscriptions to then make new subscriptions only for entities we care about). I ended up running the following (your IDs may very): await hass.conn.sendMessagePromise({type: "unsubscribe_events", subscription: 43}); await hass.conn.sendMessagePromise({type: "unsubscribe_events", subscription: 44}); await hass.conn.sendMessagePromise({type: "unsubscribe_events", subscription: 3});
Subscribing to the only things we care about await hass.conn.subscribeMessage(function (result) {}, {type: "subscribe_entities", entity_ids: ["sensor.living_room_av_circuit_power_draw"]});
After doing the above steps, my web socket now only contains the entity updates for the single entity “sensor.living_room_av_circuit_power_draw” – unfortunately, this does not result in UI updates or any action becuase I used a blank anonymous function function (result) {} and don’t do anything with the update messages since I don’t know how to monkey patch them into the live session inside of chrome console yet. It’s already taken me quite a few hours of digging to get to where I’m at now.
Based on my findings, HA frontend is the one dropping the ball here. This functionality and ability to solve this problem exists in the core and is exposed yet nothing is taking advantage of it or exposing it to the user for use in the frontend.
I don’t expect the frontend to perform discovery and find all the entities it needs to listen to right out of the box at this time, but maybe the ability to have a simple per-dashboard-tab configuration to provide a manual list of entities to pass to the subscribe functions instead of just subscribing to everything like it does now would be a huge boon.
Nice, meanwhile I’ve gone down the rabbithole of a custom frontend with flutter. This is total overkill but I was curious how far I could get with AI. Turns out most of the work had already been done with prolace. That still has the same issue of subscribing to all state_changed events, but that should be solvable with subscribe_entities.
Not sure if this will go anywhere besides my own custom dashboard, and I don’t really want to reinvent the wheel, but using an alternative frontend could be an option.
