Companion app extremely slow on Iphone

[Solarflor]

Checklist

• [X] I have updated to the latest available Home Assistant version.
• [X] I have cleared the cache of my browser.
• [X] I have tried a different browser to see if it is related to my browser.
• [ ] I have tried reproducing the issue in safe mode to rule out problems with unsupported custom resources.

Describe the issue you are experiencing

My wife have Iphone 13 and I have iPhone 15. Both phone’s companion app works extremely slow. It takes 15-20 seconds to register button clicks on dashboards or just moving through it . Tried clearing front end cache. Tried reset. Tried reinstall. Same result If I open HA with Safari I have the same problem. No proplem with Chrome.

Describe the behavior you expected

The problem started with previous version of HA version but now it is impossible to use it. Also other users are complaining the same problem with Iphone

Steps to reproduce the issue

1.The probelm appear in the main menu, Panoramic and other Dashboards 2. 3. ...

What version of Home Assistant Core has the issue?

2024.5.1

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue with?

No response

Which operating system are you using to run this browser?

No response

State of relevant entities

No response

Problem-relevant frontend configuration

No response

Javascript errors shown in your browser console/inspector

No response

Additional information

No response

[themistymay]

Adding a +1 to this and attaching some logs from an impacted iPhone. ha_logs.zip

[themistymay]

I can also confirm, safe mode does NOT fix the issue.

[fhardy32]

I am also having same problem, on all of my IOS devices, 2 iPads and iphone

[Johndowne]

It’s so annoying - yes here too on iOS iPhone and iPad - doesn’t seem much better in browser though.

[rodrigofragadf]

I have the same problem here on IOS and Android too. Slowness when navigating between tabs, clicking buttons, scrolling pages, etc. I noticed that this doesn't happen when browsing the settings pages but any operation on the dashboard is slow. This does not happen when using the computer.

[jamesdeck]

Same problem here even after upgrading to the latest iOS app today.

[chemgeek]

+1, this has been an issue for a few weeks now.

[emarvegt]

Same problem here. In a browser everything is fine, but in the app it’s frozen or freezingly slow. A reinstall of the app and updating to the latest version did not fix the problem.

[54Comet]

Same problem here. Companion app on iPhone 13, iphone 15 and iPad Pro are unusable. Also unusable from safari on iOS on all three devices. Stutters and lags. Can’t get nodered to even try to launch from sidebar. UI is snappy and works well in chrome browser on windows 10 machine.

[Solarflor]

It seems no one has been assigned to solve this issue.

[nicholashead]

By any chance y’all using iBeacon/have it installed?

[jamesdeck]

I’m not using iBeacon. On May 26, 2024, at 9:35 AM, Nicholas Head @.***> wrote: By any chance y’all using iBeacon/have it installed?

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

[themistymay]

By any chance y’all using iBeacon/have it installed?

No

[Johndowne]

By any chance y’all using iBeacon/have it installed?

No not me (had to Google it!)

[emarvegt]

No.

On Sun, May 26, 2024 at 17:01 Johndowne @.***> wrote:

By any chance y’all using iBeacon/have it installed?

No not me (had to Google it!)

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/frontend/issues/20728#issuecomment-2132251661, or unsubscribe https://github.com/notifications/unsubscribe-auth/AH27B5KVWJQ4L4H5MYW7BC3ZEH2M5AVCNFSM6AAAAABHGZ5GX6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZSGI2TCNRWGE . You are receiving this because you commented.Message ID: @.***>

[silamon]

There have been reports before, more info can be found here: https://community.home-assistant.io/t/very-slow-performance-from-lovelace-dashboard/551612.

If somebody can look into this and give more information, an improvement can be made.

[themistymay]

There have been reports before, more info can be found here: https://community.home-assistant.io/t/very-slow-performance-from-lovelace-dashboard/551612.

If somebody can look into this and give more information, an improvement can be made.

I’ll confirm this is not my issue. I have a iOS device (same model and OS version as impacted devices) that is not impacted by slowness of the exact same dashboards.

[ahrens26]

+1

[blackgold9]

+1

[majuss]

2024-05-30_13.32.22+0200.logs.zip Here are the logs of an impacted iPhone 13. Problem is present since beginning of April.

[54Comet]

There have been reports before, more info can be found here: https://community.home-assistant.io/t/very-slow-performance-from-lovelace-dashboard/551612.

If somebody can look into this and give more information, an improvement can be made.

https://community.home-assistant.io/t/very-slow-performance-from-lovelace-dashboard/551612 tracks a different problem that users have faced prior to this year. The current bug is different and appears to affect mobile devices only.

[loopy321]

Also experiencing very slow app response on iOS 16 after updating to app v 2024.5.1 from 2023.12.

Prior to update was very fast.

[loopy321]

I have reset the app (v. 2024.5.1), deleted the server and re-added in the app and updated HA to 2024.6.3 and the problems persists. It takes more than 1 minute to load the dashboard in the iOS app (iphoneX iOS v. 16.7.8) whereas in the 2023.12 version of the app it was very fast (~1-2 secs) on the same device.

See logfile here: https://gist.github.com/loopy321/35bf742b2e80f7c3a929f15e47c52040

Only thing I see in the above log is a bunch of the following message repeating multiple times a second: [hakit-work-queue] [Environment.swift:71] init() > WebSocket: Received: event: for HARequestIdentifier(rawValue: 31)

Any ideas on what to troubleshoot or where to look next?? Please.

[jamesdeck]

I keep updating to every new version in hopes something is going to fix this. I've uninstalled everything but essential integrations and restored from a backup but the problem is still there. The app is essentially dead for me unless I'm willing to wait 1-2 minutes to turn something on or off.

[themistymay]

Not seeing any dev comments but a growing number of user reports here and on forum. Maybe @balloob can help triage?

[themistymay]

Forum topic link: https://community.home-assistant.io/t/app-is-extremely-slow/710599

[Solarflor]

@balloob , @frenck , Hi guys, I believe the solution of this problem should be a priority a (vast) majority of HA user have HA running on IPhone. Any support is welcome. Thanks

[nicholashead]

I will say what helped me was removing the iBeacon Tracker integration and making sure all it's entities were removed. That seemed to really speed up the app for me. I wasn't even using that integration, but it keeps adding entities nonstop as it sees them.

So maybe the slowness is directly related to the number of entities/etc you have?

[majuss]

I have 1450 entities and everything is slow as hell. Somebody should open an issue inside the correct repository: https://github.com/home-assistant/iOS

[carsaig]

Same issue here. The iBeacon integration is not the issue - at least not in my case. As soon as I dare to scroll or press somewhere, the app crashes instantly. Unusable currently. I don't have the time currently to look into logs, sorry. Someone else needs to sort this out.

Update: I think I know, what the issue is It's the overall number of recorder entries created by entities and or logs/ errors, state changes etc. spamming the Sqlite DB. Especially if you have the BLE bluetooth tracker running, picking up thousands of devices nearby. Security measurements force bluetooth devices to rotate their mac addresses on very regular intervals, resulting in quadrillions of entries in monitoring, logging or other systems such as HA, if not filtered. But that's just one scenario of many possible. It could be a wifi tracker picking up devices with rotating mac addresses. Or If you use the (old) statistics function to record sensor data long-term with high-frequency updates and no frequency cap etc. - you will run into a massively growing DB in a very short time! Mine was >1 GB and there have been people with sizes bigger than 50 GB! Woha. HA has no limiting features for such scenarios in place - not out of the box. There is absolutely no logic to prevent such scenarios at the moment. HA records raw data without asking the user at time of implementation, which data shall be recorded. I mean - it is not HA's responsibility to catch all problems people invoke through bad design or lack of knowledge or plugins/ sensors spamming error logs etc. (looking at me) - But there could be measurements to just let the user decide at time of implementation, whether a sensor or device is generally picked up by the recorder and for wich timeframe. It could provide frequency caps etc. as an additional feature and or let me decide into which DB I want to sink all that stuff. The granularity should be controllable and not have a device throw a packload of data at HA recorder.

Looking for solutions: There is not THE solution. It requires a multi-level approach, highly dependent on you setup - until this is somehow handled by the core of HA itself - at some point down the road. The initial goal has to be to hinder high-frequent attribute or state changes hitting the DB, flooding it with useless or granular garbage. There are purge commands to that. I will not go into the details here, sorry.

I got my DB down to 400 MB from 1,2 GB. But it starts growing rapidly again...because I need to combat the root cause first. So cleaning processes need to be cron-jobbed until I solved the root-cause. The most successful approach mid-term: limit/ filter the domains and entities which are tracked by the recorder! That's really, really helpful and drastically cuts the number of events, states, etc. written to the DB. Either you exclude certain entities and domains (helps a lot, but doesn't cut it enough to be honest). Much more effective is to only allow/ include domains and entities in the filter you really care about and require long-term statistics. This dramatically cuts the size of the DB. Another hint: lower the number of days, the recorder holds data. For whatever reason, mine was set to 720 days. Jesus. I cut it down to 14 days for the moment and will go even lower, once I have a final solution.

I have 1134 entities in my setup, generating data. Hehe. ooops. A handful of them are badly maintained and generate a high number of log entries with errors. Error handling is another pain of HA, requiring sufficient strategies. Filtering only allowed entities deterministically - well...that's going to be a very, very cumbersome job. Solution: use regex patterns and wildcards. Much better. I'll only include the important 20% and ignore the rest. That still leaves me with hundreds of entities to look at. Manual labour. No fun.

Next: look at the size of your logs and decide, whether you could throw away a good part of it. I just kept 5 days and ditched the rest. That gave me back 2,3 GB! Holy moly. I kicked out half a dozen custom sensors I was not using anyhow. They were flooding my logs with all sorts of small glitches. Again: looking at the root-cause and debugging is the way to get this solved.

Furthermore: think of sinking the long-term statistic records into an external time-based DB like influxDB or similar. Spin up a docker either locally or on another machine nearby and sink that stuff in there. It might be beneficial to have a queuing and buffering mechanism in between to make sure, all entries are recorded correct if HA or the connection in between goes down. That's the route I am going to take once I cleaned up my mess. Grafana is already in use, I just need to fire up InfluxDB and I'm set. I'll just leave 5 days of history in HH for buffering and error correction.

That's my take on the issue on a high level. I'll whirl up a how-to hopefully soon and read deeper into the problem. The most straight-forward approach in a data-driven world always is: limit the amount of data you are tracking! Regulate it! Monitor it! Now the spoiler: Not an easy task and very techie in this case, to be honest. That's nothing you would pull off as a user without time for in-depth HA projects...

Hopefully this helps to understand the origin of the issue. And please feel free to correct me, if I'm wrong at some point. The effect after cleaning my DB is: the app runs blisteringly fast again. I have absolutely no clue about the App source-code and didn't look at it but with regards to the scenario invoking the issue, I guess, the app requests too many DB entries at the same time, without filtering it down to just the ones shown on the dashboards or filtering out related entities in the DB, thus crashing due to DB responding too slow, invoking time-outs which in turn crash the app. But that's just me guessing wildly. It might as well be some detail apple changed during one of the last updates.

[Ivan86NL]

For a +1; Here also having the same problem for several months now.

[Solarflor]

I think I know, what the issue is

but why only on IPhone

[carsaig]

I think I know, what the issue is

but why only on IPhone

Good question. No idea, whether the apps are OS-specific or whether the OS handle the datastream differently... There is no use in speculating from my side. Someone needs to debug what is invoking the lag on an iPhone, read some logs, etc. and possibly come up with a long-term solution. The issue can be approached from various sides: looking at the data stream and handling between app & platform or just ignore the lack of stream management of the app and focus on the root cause on platform side and deal with the app inconsistencies later. There has been done a lot on DB optimization on the HA core through recent updates, which is good news - but looking at the tables and entities structure...I am by no means a DB expert - it partially looks problematic the way string patterns are designed and written. At least I would assume this invokes problems downstream and requires an alternative approach or optimization efforts because some of these patterns were designed years back where devices just didn't flood systems with heaps of JSON at high frequency. Things are changing at high pace. But that's just me looking at this from far away. Part of the issue is definitely my lack of knowledge around the HA architecture when customizing things. This platform offers vast opportunities through customization but at the same time this scales the possibilities of failure, if not designed in an appropriate way, including thorough testing :-) yes. testing. Not just debugging. Unit-testing and regressions ideally :-) In other words: this platform requires quite a lot of knowledge and digging into, before working with it at scale.

As I mentioned: The fastest way forward and immediate solution to get the app working smooth again, is to limit the no. of DB requests by controlling the required entities and/ or domains sent to the recorder with a filter setting. This cuts the amount of DB clutter by roughly 80-90%. Next step would be to dig deeper into the actual root cause. In my specific case the cause for DB clutter was an nmap wifi tracker picking up too many mac addresses rotated regularly by mobile devices, despite filter settings (I was just not concise enough, using exclude rules instead of include), furthermore the bluetooth ble tracker flooding my db with known_devices due to same reason, and lastly badly designed sensors flooding the DB with state_changes every few seconds by default. Especially related to the bluetooth devices. And that scaled the amount of related/ connected data in the DB which was requested by the app. Probably the payload just exceeded some limit somewhere on the route to the App UI and crashed it. I am re-writing my sensors currently, learning better coding patterns and practice. I queried all the heavy-hitters in the DB but just for reference to understand where the problems arise and will proceed with inclusion rules on the recorder level, gradually re-adding domains and entities as required. As a last step I'll off-load long-term statistics to influxDB.

[Solarflor]

@carsaig one step per time. how I can confirm my DB is too crowded?

[carsaig]

@carsaig one step per time. how I can confirm my DB is too crowded?

1. Go to development tools in the HA UI --> Template and paste this to get an overview of entities in use:

`{% for d in states | groupby('domain') %} {% if loop.first %} Domains: {{loop.length}} {% endif %} - {{ d[0] }} ({{ states[d[0]] | count }})

• {{ states[d[0]] |map(attribute='entity_id')| list|join('\n - ') }} {% endfor %}`

2. Install two very helpful add-on's if you prefer UI-driven tools instead of CLI and raw SQL queries: dbstats sqlite web
3. Look into dbstats and/or sqlite web identify the heavy-hitters. Possibly fire some custom queries against the DB to dig deeper.
4. start creating a list of include entities for your recorder filter

[themistymay]

While @carsaig has some really great points here, it does not address the issue that I'm demonstrating at my house and instantiation.

Two iPhones, same model, connecting to the same instance of HA using the same dashboards.

• 1 phone has no issues
• 1 phone is basically unusable.

This points to something else and not the DB or integrations. I have included logs for the impacted iPhone to this issue (above). I have also validate the issue is still present in safe mode (where the impacted iPhone remains impacted).

[Solarflor]

2. dbstats

I have installed it but don't know how to config it

[carsaig]

2. dbstats

I have installed it but don't know how to config it

There is nothing to configure. Just install the add-on, let it show up in your side-pane and you're good to go.

[Solarflor]

There is nothing to configure. Just install the add-on

Not able to start the add-on. My HA OS is running on a NAS Virtual Machine.

[Solarflor]

2. sqlite web

Installed and it seems to run well. How I can use it to have usefull information?

[majuss]

Guys, this is the wrong direction! The database is not the problem. The same HA instance is lagging on iPhone 13 and 15 for me but Mi 10 and 12 have not a single problem. So why are you focused on the HA server @carsaig @Solarflor ? Please just open an issue inside the correct repository, this is the wrong one!

[Solarflor]

@majuss this is why I opened this issue here but it seems nobody have interested to splve this problem

[majuss]

Why did you opened the issue here and not in the ios repository? https://github.com/home-assistant/iOS

[carsaig]

Guys, this is the wrong direction! The database is not the problem. The same HA instance is lagging on iPhone 13 and 15 for me but Mi 10 and 12 have not a single problem. So why are you focused on the HA server @carsaig @Solarflor ? Please just open an issue inside the correct repository, this is the wrong one!

Simply because I wasn't aware the other issue existed. Or in other words: I didn't look for it because I just stumbled in here and was in a hurry. Sorry for that. Didn't mean to mash things up.

[themistymay]

Created issue: https://github.com/home-assistant/iOS/issues/2822

[loopy321]

FYI, I managed to get some significant improvement by starting over with my lovelace dashboards. I have not isolated which card was causing the problem, but load times improved drastically. If you are at a loss for what to try, this is my suggestion.

I went into the "raw configuration editor" copied everything to notepad and starting adding items back in.

It seemed that culprit was one of custom:weather-chart-card custom:mini-graph-card custom:apexcharts-card or my file sensor.videos:

      - type: custom:gallery-card
        entities:
          - sensor.videos

FWIW.

[beasthouse-au]

I managed to fix this by taking control of the default dashboard and saving it with nothing on it. I had also removed the custom cards like @loopy321 mentioned. Now I am getting fast speeds on the App and via the Safari Browser on iOS again.

[Solarflor]

managed to fix this by taking control of the default dashboard

How? opening a new one as default dashboard?

[beasthouse-au]

managed to fix this by taking control of the default dashboard

How? opening a new one as default dashboard?

I just opened the default dashboard, clicked edit and it comes up with the option to take control, which I did and also selected the start with empty dashboard option.

[Solarflor]

There should be something wrong in my lovelace setting How your have set it in your configuration file?

This is my setting

lovelace:
  mode: storage