I have an Issue with the android companion device tracker.
My location usually works. Unfortunately sometimes when i come home it stops updation a few kilometres away from home.
I followed the Troubleshooting Guide and it seems all relevant updates are being skipped due to “very old location” despite being more accurate.
I suspect this may be due to my setup of a “zone within a zone”.
There is one big Zone around my Home for triggering heating, which is correctly detected. After that all location updates are skipped.
I think that is intended behaviour. You might want to consider using small zones (where being in the zone is accurate enough) combined with the proximity integration. As an added bonus, you will know if you are nearing the zone or moving away from it.
Edit: I accessed the logs and these are the most recent Location evaluations:
Line 1217: 04-12 10:28:51.228 10309 10309 D LocBroadcastReceiver: Received location update.
Line 1219: 04-12 10:28:51.259 10309 22412 D LocBroadcastReceiver: Last Location:
Line 1220: 04-12 10:28:51.259 10309 22412 D LocBroadcastReceiver: Coords:(
Line 1222: 04-12 10:28:51.259 10309 22412 D LocBroadcastReceiver: Bearing: 0.0
Line 1223: 04-12 10:28:51.260 10309 22412 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
Line 1224: 04-12 10:28:51.260 10309 22412 D LocBroadcastReceiver: Skipping location update due to old timestamp 1744445424100 compared to 1744446531260
Line 1242: 04-12 10:29:47.257 10309 10309 D LocBroadcastReceiver: Received location update.
Line 1244: 04-12 10:29:47.276 10309 22412 D LocBroadcastReceiver: Last Location:
Line 1245: 04-12 10:29:47.276 10309 22412 D LocBroadcastReceiver: Coords:(
Line 1246: 04-12 10:29:47.276 10309 22412 D LocBroadcastReceiver: Accuracy: 100.0
Line 1247: 04-12 10:29:47.276 10309 22412 D LocBroadcastReceiver: Bearing: 0.0
Line 1248: 04-12 10:29:47.278 10309 22412 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
Line 1249: 04-12 10:29:47.278 10309 22412 D LocBroadcastReceiver: Skipping location update due to old timestamp 1744445484204 compared to 1744446587278
Line 1270: 04-12 10:30:53.586 10309 10309 D LocBroadcastReceiver: Received location update.
Line 1272: 04-12 10:30:53.602 10309 22412 D LocBroadcastReceiver: Last Location:
Line 1273: 04-12 10:30:53.602 10309 22412 D LocBroadcastReceiver: Coords:(
Line 1274: 04-12 10:30:53.602 10309 22412 D LocBroadcastReceiver: Accuracy: 100.0
Line 1275: 04-12 10:30:53.602 10309 22412 D LocBroadcastReceiver: Bearing: 0.0
Line 1276: 04-12 10:30:53.604 10309 22412 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
Line 1277: 04-12 10:30:53.604 10309 22412 D LocBroadcastReceiver: Skipping location update due to old timestamp 1744445544208 compared to 1744446653604
Line 1297: 04-12 10:31:47.820 10309 10309 D LocBroadcastReceiver: Received location update.
Line 1299: 04-12 10:31:47.834 10309 22412 D LocBroadcastReceiver: Last Location:
Line 1300: 04-12 10:31:47.834 10309 22412 D LocBroadcastReceiver: Coords:(
Line 1301: 04-12 10:31:47.834 10309 22412 D LocBroadcastReceiver: Accuracy: 100.0
Line 1302: 04-12 10:31:47.834 10309 22412 D LocBroadcastReceiver: Bearing: 0.0
Line 1303: 04-12 10:31:47.836 10309 22412 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
Line 1304: 04-12 10:31:47.836 10309 22412 D LocBroadcastReceiver: Skipping location update due to old timestamp 1744445604208 compared to 1744446707836
Line 1337: 04-12 10:32:54.751 10309 10309 D LocBroadcastReceiver: Received location update.
Line 1339: 04-12 10:32:54.771 10309 16823 D LocBroadcastReceiver: Last Location:
Line 1340: 04-12 10:32:54.771 10309 16823 D LocBroadcastReceiver: Coords:(
Line 1341: 04-12 10:32:54.771 10309 16823 D LocBroadcastReceiver: Accuracy: 100.0
Line 1342: 04-12 10:32:54.771 10309 16823 D LocBroadcastReceiver: Bearing: 0.0
Line 1343: 04-12 10:32:54.772 10309 16823 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
Line 1344: 04-12 10:32:54.772 10309 16823 D LocBroadcastReceiver: Skipping location update due to old timestamp 1744445664316 compared to 1744446774772
Line 1376: 04-12 10:33:32.850 10309 10309 D LocBroadcastReceiver: Received location update.
Line 1378: 04-12 10:33:32.863 10309 22412 D LocBroadcastReceiver: Last Location:
Line 1379: 04-12 10:33:32.863 10309 22412 D LocBroadcastReceiver: Coords:(
Line 1380: 04-12 10:33:32.863 10309 22412 D LocBroadcastReceiver: Accuracy: 100.0
Line 1381: 04-12 10:33:32.863 10309 22412 D LocBroadcastReceiver: Bearing: 0.0
Line 1382: 04-12 10:33:32.864 10309 22412 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
Line 1383: 04-12 10:33:32.864 10309 22412 D LocBroadcastReceiver: Skipping location update due to old timestamp 1744445724420 compared to 1744446812864
I searched for documentation regarding zones but could not find that this is intended behaviour.
In my opinion that would also make the accurate - location sensor redundant when within a zone.
I should also mention that the bigger Zone is set to “passive” which should let the Tracker entity take the “Home” Zone. But this does not work if the location is not updated.
Most zones are used for buildings. In buildings gps is not accurate. If there’s any documentation, it would probably be with the settings the companion app has. So maybe you can tweak those. But as proximity is built to avoid using large zones, I doubt zone behavior is going to be changed to improve large zone behavior at the expense of small zone behavior, where GPS fluctuations would require the phone to send constant updates that have no meaning, draining battery.
I understand your point regarding accurate gps updates, but why would the “entered zone” updates be skipped.
And i verified that the location is within my “Home” Zone.
There’s no point in convincing me, I don’t contribute to the code. My advice: large zones make HA work worse, Proximity makes HA work better. So either leave it, accept the shortcomings and wait for some one to change it (with little hope), or avoid the problem.
Ok… it works again.
I dont understand what went wrong for the last two hours.
As you can see in the following table this are the readable times of these log entries:
Line 1217: 04-12 10:28:51.228 10309 10309 D LocBroadcastReceiver: Received location update.
Line 1219: 04-12 10:28:51.259 10309 22412 D LocBroadcastReceiver: Last Location:
Line 1220: 04-12 10:28:51.259 10309 22412 D LocBroadcastReceiver: Coords:(
Line 1222: 04-12 10:28:51.259 10309 22412 D LocBroadcastReceiver: Bearing: 0.0
Line 1223: 04-12 10:28:51.260 10309 22412 D LocBroadcastReceiver: Begin evaluating if location update should be skipped
Line 1224: 04-12 10:28:51.260 10309 22412 D LocBroadcastReceiver: Skipping location update due to old timestamp 1744445424100 compared to 1744446531260
Location Time
Recieve Update Time
2025-04-12 08:44:17
2025-04-12 09:04:28
2025-04-12 08:45:17
2025-04-12 09:05:42
2025-04-12 08:46:17
2025-04-12 09:07:04
2025-04-12 08:47:17
2025-04-12 09:08:08
2025-04-12 08:48:17
2025-04-12 09:09:13
2025-04-12 08:49:17
2025-04-12 09:10:13
2025-04-12 08:50:17
2025-04-12 09:11:18
2025-04-12 08:51:17
2025-04-12 09:12:09
2025-04-12 08:51:24
2025-04-12 09:12:13
2025-04-12 08:51:28
2025-04-12 09:12:13
2025-04-12 08:51:31
2025-04-12 09:12:13
2025-04-12 08:51:35
2025-04-12 09:12:13
2025-04-12 08:51:41
2025-04-12 09:12:13
2025-04-12 08:53:26
2025-04-12 09:14:49
2025-04-12 08:53:30
2025-04-12 09:14:49
2025-04-12 08:53:36
2025-04-12 09:14:58
2025-04-12 08:53:41
2025-04-12 09:14:58
2025-04-12 08:53:45
2025-04-12 09:14:58
2025-04-12 08:53:51
2025-04-12 09:15:16
2025-04-12 08:53:56
2025-04-12 09:15:16
2025-04-12 08:54:01
2025-04-12 09:15:16
2025-04-12 08:54:06
2025-04-12 09:15:16
2025-04-12 09:15:12
2025-04-12 09:15:16
My question is: Why would it take approx 20 minutes for the app to recieve the updates. Or why wasnt the location updated at e.g. 08:44:17.
The last row is the first successful update with the “accurate location” setting enabled.
I disabled that again and now every location update is late ~20min again.
Hard to tell, it could be time differences between the device recording it and the one receiving it. It could be the phone is late in delivering to HA due to power management, it could be the companion app sleeping or thinking the updates are not relevant, it could be logging is late but it was recorded in time. If you think it a bug, create a github issue for it. It won’t be seen here.
What I do know is the companion app has different behavior for updates inside and outside a zone. It also needs to do something for overlapping zone resolution. It is a complex problem, half of which is outside HA influence.
If the app is complaining about the time of the location report that’s nothing you can do. Every location update comes from Google with a timestamp of when the location was taken. They can send us a report from a week ago so those skips are indeed valid.
Ok, a restart of the phone fixed the problem.
After the restart nerly every Update is a “Duplicate” and approx every 15 mins an Update is sent anyway (this seems like reasonable behaviour).
I will try to notice if the problem ever occurs again and try to recreate it, at the moment i am clueless what caused it.
No, high accuracy mode is disabled
I don’t think any are related because in my case there is a valid location update in the app, it just isn’t sent because it’s “too old”
Thank you for these suggestions, i will implement the high accuracy mode as mentioned in the documentation example.
Unfortunately that wouldn’t have helped in my problem earlier today because my location was stuck a few kilometres away from home.
I think so too. My hope is that it was just a one time quirk.
I’m just wondering why the location was not updated when the information was current.
Information for future reference:
App Version: 2025.1.2-full
Android Version: 13
Device: Samsung Galaxy S20FE 5G
Build:
Settings: as suggested in location troubleshooting (disabled energy management)
Phone was in energy saving mode - Problem persisted while charging
Problem went away after restart
