I did have one instance in the past couple days where it froze up yesterday. (2021.12.1 app and HASS v2021.12.3.
I updated to HASS 2021.12.5 but found that pages/sections would remain empty and other odd behaviors, so I rolled back to 2021.12.3.
Looks like next big update isn’t until Feb.
I continue to struggle with this issue… I have been trying update every time to the latest versions (on both sides) and still have a lot of issue…
Even now with a new phone… It happens the same…
For the users that are struggling with this behaviour are you still having issues? Your instances are accessed throw outside (external link), if so are they from nabu, or your owns (like duckdns)?
Is seems with 2021.12.7 the issue is gone for me
I access my instance from outside only via VPN
iOS-2021.12.1 and core-2021.12.7 in concert should resolve most cases of this, but the workaround we’re doing may still have some missing cases. If you reproduce the issue with the previously mentioned versions or newer please provide info about what happened when it showed problematic.
Seems improved for sure, no issues yet. Trying to get back in the habit of using the app as I became accustomed to using chrome for awhile, but so far so good! Thank you!
I’m on the latest versions and still have issues. It seems to happen when I open more-info dialogs and the history is loaded
Are you still having issues with this thing?
One thing, how do you access to your system? Is remotely outside of your local network? If so, are you using nabu?
mine seems to be solved
I use only an internal url. from outside I connect via VPN
I still have issues, and I try to use it through external url (port FW) and from nabu and happens the same on both, this done by url from safari and add it to home screen, I’m not sure how, I think is not really the same that open it always on safari. and on the app of home assistant, it seems to work…
I’m still seeing issues, both internally and externally, not using Nabu Casa.
As mentioned, this is happening when I open more-info dialogs and the history is loaded.
Am I the only one still seeing this?
I don’t see it anymore
Mine has been good as far as I’ve noticed and I open quite a few more -info windows also. Are you fully up to date in app and HA?
Yes, I’m fully updated.
It happens when I tap an entity and open the “More Info” modal. HA freezes until the history is loaded.
What are you running on and do you have any idea how large your database is and are you using SQLite ? Does your history page take a long time to load also?
I’m using an external MySQL DB. The history page takes a few seconds to load, but that was always the case. The app behavior is clearly a regression compared to a few versions ago.
Is this still an issue for anyone (besides me)? To be more clear, its not freezing, but it is taking forever to load, and I have to keep swiping down to refresh. It’s almost as if it keeps timing out on communication back to my server. If I try from a desktop browser (Mac or PC), no issues whatsoever.
I am running HA 2022.3.6, IOS 15.3.1, and whatever IOS app is most recent as of today. Been having this issue for a few HA and IOS versions with no luck. It doesn’t matter which IOS browser I use (chrome, safari, or duck duck). I am happy to pull log files, just not sure which ones will help.
Still happening for me, but seems to be different than yours - it’s unresponsive when the history loads in more-info cards. I’m pretty sure this is a regression and that in past versions history loading wasn’t blocking the UI
I’m not sure I can explain why pulling to refresh doesn’t fix it across browsers. That should force a brand new connection. It’s possible there’s something else happening in your configuration which could explain it, like which reverse proxy you are using.
Without pulling to refresh being involved, it makes sense that this happens in every browser on iOS, because at the core they’re all the same engine. In iOS 15, Apple changed the WebSocket implementation from their previous WebKit-specific one to a more general system one; this system implementation is absolutely awful at detecting it’s been disconnected for any reason, and so you’re waiting through the period where it is disconnected but it hasn’t figured that out.
The app is doing a workaround of forcing the WebSocket connection to restart when it believes it needs to happen, but it’s not actually able to determine with certainty that it’s happening as it’s just guessing. It’s possible to add more cases to when it believes it’s connected but it’s not, but this requires figuring out a way to describe that situation that isn’t based on the connection itself. For example, the app will force a connection restart if the app’s been in the background for a while, because that’s the most common scenario.