Glad to know this is not just a problem I am having. Would love to see this addressed, have been quite confused at why a raspberry pi 4 with 8gb of ram is constantly freezing and crashing with a dashboard that fits on a 7" touchscreen. Let alone any lower tier device.
Hopefully this will be optimized at some point but in the meantime I may have to do some entity purging and try out the remote home assistant setup.
2 Likes
Oh, so you mean “buy better hardware” actually was the answer? I’m shocked, I tell you, shocked.
@exx, are you done trolling this thread yet? Yes, buying better hardware is always an option when purchasing something new. But there’s a lot of old used gear out there that people either already have or can buy on the cheap. I don’t think it’s unreasonable that one should be able to run a limited status device on something like that without shelling out for top of the line hardware. Most of the example uses I’ve seen are largely the ability to turn devices on and off and provide status on those and other devices on the system. That seems like something cheap hardware should be able to do don’t you think?
4 Likes
I’m not trolling anything. There’s a difference between “old” and OLD. There’s a difference between “cheap” and CHEAP.
At no point did I say someone needs to run out and buy a $1500 tablet to run a dashboard, so don’t even attempt to put your ridiculous words into my mouth. But if you think you’re going to run a dashboard on a device that you paid $50 for a decade ago, then I repeat unto you - BUY BETTER GEAR.
I’ve had absolutely zero issues buying refurbished brand name tablets that are 2-3 generations old for <$100 from Amazon and running crazy amounts of dashboard pages, streaming video from BlueIris, and all manner of other stuff to them. It is completely possible if you stop getting upset and look at the problem objectively.
I can run a dashboard on an ESP32 because esphome uses per-entity subscriptions. If you have a ton of entities & events, any system will eventually get bogged down trying to keep up with lovelace’s superfluous updates. This is basically an efficiency and scaling issue that’s already accounted for on the backend.
Yes, we could throw money at the problem. However while it’s not everyone’s concern, I’ll bring up again that one of the primary values is “the ability to repurpose old hardware, you won’t have to toss a perfectly functioning device just because there’s a newer model.” If that’s true, addressing this would be in line with that value. If that’s less interesting as the foundation and Nabu Casa grow, well that happens in bigger orgs but maybe the page should be updated to reflect it.
For me, this is a hobby that I pour way more time into than necessary. Yes a new tablet would sweep this issue under the rug, but personally I find an excuse to dig in more and maybe learn some UI dev more worthwhile.
4 Likes
Not always the best answer. eWaste has become a very big problem in our disposable society. Reusing old hardware for simple things like dashboards would help in reducing eWaste when phones and tablets become outdated.
5 Likes
There is a VAST difference between “will it run” and “will it perform well”. If you knew as much about computers as your posts would lead one to believe, you’d stop with your straw man arguments.
In case you need an illustration, please allow me to point you at an age old meme: “But will it run Crysis?”
If there were no need for differing levels of performance for different users, there would only be one tablet, and one PC, and one car, and one truck, and one boat, and one airplane, and one ANYTHING else on the market. But some people only need to check email and browse the web, while others need to run ridiculously complex video games and render 4k movies. Some people only need to drive themselves (alone) 3 blocks to go to work, and others need to drive 100 miles each way. Some people need to haul drywall, and some people need to haul cars.
The simple fact of the matter is that at SOME point, old hardware is no longer performant. There is no way around this, and all the wailing and lamentations in this thread are nothing more than that. Progress should not stop - or even slow down - in the interest of supporting hardware that is so old it can no longer even function on the built-in battery. That would deprive the ENTIRE rest of the userbase from taking advantage of newer, better functionality that is more complex, and by definition, requires better hardware.
Frankly, this entire discussion makes about as much sense as someone complaining to Microsoft “What do you mean I can’t run Windows 11 on my 486 dx2??”
I have a HA dashboard up and running. When I double-click “websocket”, Chrome displays this page; any ideas?
Edit: Disregard. Instead of double-clicking websocket, I need to click the messages tab.
I see that you filed an updated ticket 
Here’s the link, in case anyone reading this wants to add to it: Web socket entity updates excessive spam · Issue #24166 · home-assistant/frontend · GitHub
2 Likes
For anyone interested in the subscribe_entities command, I was able to get it working in my flutter app but it’s in a much different format than the state_changed events. I’m not finding documentation for it, there’s some comments in the implementation but I found the home-assistant-js-websocket client code more useful.
Additionally, here’s the PR from Paulus where it was added and noted an ~80% reduction in payload size. So not only is it sending way fewer events, each one is much smaller.
1 Like
You are clearly just a troll and an abrasive, useless naysayer with zero intention of any useful contribution to this discussion and are doing nothing but lying to people and gaslighting them into believing that their devices are inadequate when no such thing is true.
Using the techniques I outlined above, I got all 12 of my cheap Kindle Fire tablets to display and run all of my dashboards smoothly and very performantly while only consuming less than 1W each. They are not “old” hardware I bought them specifically for this purpose – and recently. My front door tablet for example is now displaying a very full dashboard complete with 4 outdoor security cameras (!) while running very fast and meeting my requirements.
I have said it before and I will say it again, this is a home assistant frontend architecture/design problem. This is not a “cheap”/“old”/“bad hardware” problem. The user should not have to bend over backwards using the workarounds I outlined above to get a reasonable smart home working in a small-ish to medium-ish sized home with some power monitoring thrown in.
7 Likes
Some more details about my setup for people actually trying to make their tablets work for them again:
I got most/all of my previous functionality back by creating 100s of Filter sensors by hand in configuration.yaml since there is no UI way to do this right now (big oof for people not comfortable doing file editing like this):
sensor:
- platform: filter
name: "Living Room HVAC Mini Split L Power Draw Average"
entity_id: sensor.living_room_hvac_mini_split_l_power_draw
filters:
- filter: time_simple_moving_average
window_size:
minutes: 2
- filter: time_throttle
window_size:
minutes: 1
Of course I only did this for sensors I use/show in my dashboards to further reduce the quantity/frequency of sensor updates. time_simple_moving_average creates an average for the specifed duration (2 minutes of past readings) but updates every single time the underlying sensor updates so I have to further filter it with the time_throttle filter to cut down the frequency of updates.
Then, on the 2nd HA instance, using the “Remote Home Assistant” integration as mentioned before, I had to manually add each and every one of these filtered sensors by hand into the “included entities” config option. Unfortunately the UI they have for that is useless in large setups because it makes a tiny dropdown with thousands of items that you can’t search and can only manually scroll through and the sensor names are so long they are not fully visible – so you’re stuck manually adding it to config files this time too; however, this time it’s a total nightmare. You have to dig into the .storage/core.config_entities file and edit the internal HA JSON structure there to add the large list of desired filtered sensors to . Also if you mess up your HA won’t start and you’ll have a tough time getting to those files to fix it, so you have to be careful. This is very rough to have to do and even more so for less experienced users. I will open a request with Remote-HA to ask them for an improved config dialog that just provides a text box and lets you paste a list maybe.
For those trying to do what i’m doing, the line/entry in HA core config entries JSON is the line that has "domain":"remote_homeassistant" for that item and then you put your entities you want to see into "include_entities":["sensor.foo_average", "sensor.bar_average"]
1 Like
Great information! I noticed this while looking at the websocket data stream and briefly saw this mentioned in some commit messages but didn’t write down or commit to memory the location of that information. Thank you for your help and for the comment on the frontend ticket.
1 Like
Already using zigbee2mqtt since ZHA gave me issues a few years back. Z2M has been way better and more robust than ZHA ever was for me. I highly recommend switching in general but it won’t resolve the performance issue with the dashboards.
Also, Indeed! made an updated ticket 
surprised it was noticed haha… Hopefully eventually it will get some traction. All I want is for it to be accepted as a recognized issue and given some kind of “planned” status. That way if some random open source contributor has some extra time it could be something they pick up. Can’t fix a problem until it’s admitted that there is one, and that’s all I’m trying to accomplish – getting admission of the problem.
2 Likes
Wut?
There are plenty of us who have hardware that isn’t old and still have abysmal responsiveness and crashes. You seem to want nothing more than to “dunk” on people rather than actually contributing anything useful to the conversation.
3 Likes
Another unintentional finding tonight, I assume most people are using card-mod? I was looking into something else and turned on debug: true for it. I see a stream of CardMod Debug: (Re)connecting msgs in the console which seem to match up with each state_changed event.
So every websocket message is causing a card-mod refresh() → rebuild in the browser which is probably the main source of the performance issues we’re seeing.
3 Likes
I can confirm that my dashboard performance improved immeasurably when I got rid of cardmod.
I also took this as an opportunity to clean up old integrations and entities, and can confirm that that vastly sped up my dashboard pages. They are now back to being usable.
A big culprit seemed to be a defunct “glances” integration, as soon as I deleted that everything was much snappier and stopped crashing. But general entity/integration housekeeping and cleanup seemed helpful too.
3 Likes
Year of 4-year old hardware is too old for home assistant, apparently.
It is extremely disappointing that this is what we’re dealing with but, it’s OSS. I don’t have web dev experience or I would at least give it a go. I’m assuming there are monsters hidden that rely on this insane behaviour to work properly, otherwise this would of been dealt with a long time ago.
All I know is, tablets are a terrible experience with Hass. On desktop every 10-15 mins or so, I need to refresh the page before it will actually issue commands and if I leave the tab open for an hour or more, I get the dead tab “snap, something went wrong” page. Sometimes the Hass tab is 1-2 GB memory usage, which seems crazy to me but idk.
Any which way, I really hope that this is being worked on.
