I don’t think ESP has enough memory or grunt for web page rendering or running JavaScript at all. There is a massive difference in compute (10x-100x) between ESP and even the lowest tier Android stuff. But our points conceptually stand. I recognize that the Fire HD isn’t a powerhouse but it’s very obvious that it should be able to display a simple dashboard to operate a few switches in a reasonably performant way.
1 Like
I would look at slowing down those energy sensors. HA is really not designed to deal with lots of quick updates - as you have demonstrated.
Same situation here, lots of power and mmwave sensors. Websocket flooded with messages too. Terrible performance with an old Fire HD8. I “solved” it by launching another HA instance and using remote homeassistant from HACS to link the second HA instance to the main one, and sharing only the entites I want to display on the Fire HD8 to that second HA instance. It works but its not a solution for everyone, I have a couple NAS running so I can easily launch a second HA instance.
This is definitely something that needs to be optimized. We don’t need to buy new tablets just for this, we should be allowed to repurpose old hardware as dashboards. Isn’t sustainability one of the principals of the Home Assistant
2 Likes
This is surely a joke or a troll post. Not an option. They’re not even that fast I just have a lot of them. I don’t really have a mansion or a large home… it’s 1400sq ft. I do have a lot of smart home devices because I’m putting together a smart home… not a few smart bulbs in a bedroom or two. My use case isn’t even that heavy.
This reminds me of terrible performance of the history component a year or two back that thankfully got a MASSIVE performance rewrite that 10x’ed or 100x’ed the performance of that component. We need something like that but for the entity update web socket stuff. The solution is obvious – only subscribe to updates for entities used on the current dashboard page and not everything.
Back in the days before the history component rewrite i had to completely disable history tracking or reduce it to a few hours since it was killing performance of the entire HA installtion (and it made me have to migrate from a RasPi4B to a VM running on AMD Ryzen)
1 Like
I just stumbled upon this idea myself as well and implemented this exact setup (it’s why I returned to this thread to post my findings but was surprised to find another person end up doing the same exact thing!). I finally have tablets working again, but very cut-down with just the bare minimums since I CBA to cherry pick the necessary sensors I want so I just kept switches, lights, and climate basically.
But as you said, running two home assistant instances and bridging them with remote-homeassistant HACS plugin is kind of a horrific mess and workaround to solve a problem with terrible optimization in HA itself. This needs a real solution and needs to be on some roadmap or at least a “to-do” item. I am not sure how to get this on the devs’ radars.
I will say remote-homeassistant itself is impressively slick and nice. Definitely a great tool in the toolbelt to have.
1 Like
It’s not. If you have multiple sensors that report values < 1 second firing constantly, it will overflow the event loop on low end hardware.
There are changes coming to the frontend in the next release that improve performance but there’s no guarantee it will solve your problems.
1 Like
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.
2 Likes
I suggest you look over the recent frontend changes before continuing your tirade.
1 Like
So is there a solution to this issue?
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. 
Help! 
Buy better gear?
That is not a specification…
I concur completely with the OP.
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!
Happy new year!
2 Likes
It’s very unlikely that HA will ever support any technologies older than 5 years.
1 Like
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 
Wait… isn’t one of the Open Home Foundation’s values about consuming less? Did I miss something?
“With the ability to repurpose old hardware, you won’t have to toss a perfectly functioning device just because there’s a newer model.”
2 Likes
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.
1 Like