you hsould really follow along with all the troubleshooting and perform all the steps. Then if you still have issues come back with logs please.
I think the first thing most of us have done if we’ve made it this far is look at the troubleshooting guide.
The guide states to make sure “Single Accurate Location” is enabled, however it seems disabling it has potentially resolved my issue.
I’ll be monitoring for the next week or so just to make sure it’s not a coincidence.
I wish that was the case but in most cases it is not, if it were I would see much more logs than are actually posted.
Most users run into issues because they enabled the setting under this sensor to include in sensor updates but htat is not required. Single accurate location sensor is used to get a more accurate location if the previous location was not accurate enough. The logs will show when it is used. It should not get used all that often but it still has its uses. It is also used for things like request_location_updates and also tasker can be used to trigger updates. The previously linked location section in the companion docs describe how each and every sensor works.
The logs always speak the truth when it comes to location updates. Thats why we even show you what type of logging to expect for troubleshooting.
I think you mentioned above that Single Accurate Location should be turned off, but the Docs seem to indicate that it could help with location accuracy. Any chance you might explain the differences?
Not to turn it off. But there is a sensor setting to “Include in sensor updates” That should be turned off as it is off by default but some users turn it on hoping it will fix some issue and forget to turn it off.
When you go to the page to enable a sensor you also see the settings that a sensor might have. I am specifically referring to a setting for the sensor.
1 Like
After having the high accuracy setting turned off for about 24 hours, I can verify that it has fixed the device tracker entity not updating at all. However, it has not fixed the slowness to report updated locations to HA. Looking at entity history from this morning it took about 20 minutes after getting home for my device_tracker entity to update.
The Home Assistant app has every permission granted, and every battery or data saving option I could find disabled. Google Maps is even showing my location correctly, while HA stubbornly refuses to update.
Workarounds such as using bluetooth device connections or wifi SSID’s simply aren’t reliable or suitable for many people, and shouldn’t be needed in lieu of what most users consider to be a core function. For example, I often work on my car with my phone paired to its radio, and I frequently disable wifi on my phone to test things such as site performance on “regular” speed networks.
I am currently auditing my logs to remove sensitive information and will be posting them soon. From my brief look it seems like the app just isn’t checking the device location frequently enough, which should seriously be a user definable setting.
The app does not check for location updates. The app makes a request to Google to provide updates and then waits for updates to be sent to the app by Google. You will see a log line for Location update received that is when Google sends the app an update.
FWIW, I’m also using a OnePlus Nord (same as TS) and the problems started after upgrading to Android 12…
I’m using all default settings in the companion app, and have all battery saving disabled for HA.
@dshokouhi I was wondering to myself this morning…
My Plex server has a troubleshooting button, where it will grab, zip, and download all the log files to be shared with support. I think PiHole takes that one step further by automatically uploading them somewhere and then you only have to share a code with staff.
Is that possible with the Companion app? If so, it might save you (guys?) some time. Additionally, needing LOGCAT data is a pretty high barrier to entry. While having a ‘button’ like that may increase support requests (due to the lower barrier of entry), it may simplify your process to resolve them.
Thoughts? Apologies if you’ve already thought of this and it really isn’t possible.
Configuration > Companion App> Show and share logs
Also mentioned in companion docs 
1 Like
And you had thought of it!
Does that give you everything you need though? I’ve been following this thread and you needed LOGCAT data. Or is that data not available to the app?
Our internal logcat reader goes by our apps PID which is assigned by Android so we get all the logs for our app. The PID stays active as long as the app was not killed by the system, it can also change under other circumstances which are out of our apps control. You’ll want to check the logs as soon as the issue happens. If it happens overnight or you notice you never see the logs going up to when the issue occurs then we will need to use another app to get more historical logs. Its best to reproduce the issue and check the logs immediately after (if possible). When it comes to location issues its also best to capture 10 minutes of logs to look at the decision making process for a few reports.
1 Like
I’ve been experimenting for weeks to get my OnePlus Nord to update location with Android 12.
It works fine for a short time and then stops working and there is no “LocBroadcastReceiver” in the logs
So, it just so happened that I had cause to get a new phone this week, and this exact same behaviorhas now also happened on a brand new Pixel 6a. I only just noticed that it had happened now, so I didn’t have the chance to try to pull any logs yet, but all the symptoms are the same - High Accuracy was turned on, HA thought it was still on, but at some point overnight it stopped sending location updates or even accessing location data at all.
check that hte app has proper access to stay in teh background. One Plus devices usually have extra settings a user needs to check to ensure the app is not killed in the background. dontkillmyapp.com has some good tips here. The fact that it only works for a short time suggests this is the case for you.
im starting to suspect this is a play services issue, the latest beta uses the latest library provided by Google and we even switched away from the deprecated methods. All the app can do is register for updates and wait for Google to send them. We dont even set an expiration so that they continue to send updates non-stop. Our request for location updates has not changed for quite some time. As this was working fine in the past it is most likely a play services issue. If that is the case its out of our hands unfortunately.
That makes sense, but at the same time - my wife’s phone (which works fine) is running the same version of Play Services that my other phones are. I’m not sure what to make of that.
could be an edge case in play services, that woudl explain why not every user sees the issue. Are you on the play services beta channel?
Well I have opened up a PR to take a crack at the updates stopping issue. My PR will begin to keep track of the time the last location update was received. Then it will add some leeway time based on some defined parameters. In the case of high accuracy mode it will wait double the defined interval. For background updates it will wait double our defined max wait time (roughly 7 minutes). Then the next time the app does a sensor update check it will perform this evaluation and if too much time has passed it will restart the services.
Would appreciate some user feedback on testing, please refer to this comment for the link to the debug APK file. Also please keep comments on testing in the issue so its easier to keep track of.
https://github.com/home-assistant/android/issues/2681#issuecomment-1200074851
1 Like
Disabling high accuracy seems to have only temporarily fixed my device_tracker update rate. I’m back to the slow, seemingly random location updates, even when other apps can see my location correctly.
As dshokouhi said, this seems like it’s potentially a play services issue. I’ve attached my log, and you can see the app isn’t getting any updates on location, even over an entire hour. The baffling part is that others have noted certain apps such as Life360 still get regular location updates in the background, while HA seems to only get them whenever Google is feeling charitable.
Log posted here
Having the service restart after it times out waiting for an update seems like a good “for now” fix while Google either clarifies location updates (does it use a default timeout if one is not provided?) or fixes it. I may have to give the testing APK a try just to see.
The part that really intrigues me is the that whenever it is in this state where it seems to not update it’ll just randomly update after a good while without having even opened the app.
they very well could have this fix applied as well, I saw a few mentions of this approach on stackoverflow 
no, unless they broke something there. This is the API to tell google to stop after sometime (which our app does not call)
any feedback on the changes is greatly appreciated 
at least in my testing the restart worked when I used the incorrect variable
is that a zone update or a background update though?