That’s a question that the logs will help answer
alright, but i’m not sure what i should be looking for…that’s more what i was asking.
Ok you can share the logs again if you don’t understand them.
1 Like
I’ve created template sensors for GPS speed for both my and my wife’s phones, as an attempt to understand when the app is getting updates from Android. I’ve converted m/s to mph, to make it easy to correlate speed data with our daily commutes.
So far, the sensor history shows that the update rate is poor, infrequent and unreliable.
Is this a valid approach to checking the reliability of the GPS data update?
No you want to look at the logs to see if reports are being skipped. The decision making process to send a location update are printed in the companion app logs. Make sure to start with the location troubleshooting steps linked earlier in this thread.
I grabbed a log file after driving in to work this morning. What’s interesting to look at?
08-30 08:41:37.946 13540 13576 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 08:41:39.916 13540 23735 D LocBroadcastReceiver: Background location updates appear to have stopped, restarting location updates
08-30 08:41:39.916 13540 23735 D LocBroadcastReceiver: Removing background location requests.
08-30 08:41:39.940 13540 23735 D LocBroadcastReceiver: Registering for location updates.
08-30 08:41:40.006 13540 13576 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 08:41:54.225 13540 13576 D LocBroadcastReceiver: Background location updates appear to have stopped, restarting location updates
08-30 08:41:54.225 13540 13576 D LocBroadcastReceiver: Removing background location requests.
08-30 08:41:54.235 13540 13576 D LocBroadcastReceiver: Registering for location updates.
08-30 08:41:54.378 13540 23735 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 08:42:39.303 13540 23735 D LocBroadcastReceiver: Background location updates appear to have stopped, restarting location updates
08-30 08:42:39.304 13540 23735 D LocBroadcastReceiver: Removing background location requests.
08-30 08:42:39.322 13540 23735 D LocBroadcastReceiver: Registering for location updates.
08-30 08:42:39.417 13540 13576 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 08:42:40.920 13540 13540 D LocBroadcastReceiver: Received location update.
08-30 08:42:40.930 13540 13540 W LocBroadcastReceiver: Location accuracy didn't meet requirements, disregarding: Location[fused ******,****** hAcc=1899.999 et=+12d0h24m8s653ms alt=135.538281664994 vAcc=20.580078 {Bundle[EMPTY_PARCEL]}]
And then later on
08-30 08:55:13.384 13540 13540 D LocBroadcastReceiver: Received location update.
08-30 08:55:13.393 13540 13540 W LocBroadcastReceiver: Location accuracy didn't meet requirements, disregarding: Location[fused xxxx,xxxx hAcc=1700.0 et=+12d0h36m42s498ms alt=135.538281664994 vAcc=24.312788 {Bundle[EMPTY_PARCEL]}]
08-30 08:55:17.817 13540 23735 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 08:57:13.394 13540 13540 D SensorReceiver: Received intent: android.intent.action.TIME_TICK
08-30 08:57:13.403 13540 13575 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 08:57:13.407 13540 13575 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 08:57:13.448 13540 13540 D LocBroadcastReceiver: Received location update.
08-30 08:57:13.451 13540 13540 W LocBroadcastReceiver: Location accuracy didn't meet requirements, disregarding: Location[fused xxxx,xxxxx hAcc=1700.0 et=+12d0h38m42s603ms alt=135.538281664994 vAcc=24.312788 {Bundle[EMPTY_PARCEL]}]
08-30 08:57:15.337 13540 13575 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 09:00:41.696 13540 13540 D SensorReceiver: Received intent: android.intent.action.TIME_TICK
08-30 09:00:41.697 13540 13540 D SensorReceiver: Received intent: android.intent.action.TIME_TICK
08-30 09:00:41.701 13540 23735 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 09:00:41.708 13540 23735 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 09:00:41.713 13540 13575 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 09:00:41.715 13540 13575 D UrlRepository: localUrl is: true and usesInternalSsid is: false
08-30 09:00:41.832 13540 13540 D LocBroadcastReceiver: Received location update.
08-30 09:00:41.834 13540 13540 W LocBroadcastReceiver: Location accuracy didn't meet requirements, disregarding: Location[fused xxxx,xxxx hAcc=1700.0 et=+12d0h42m10s892ms alt=135.538281664994 vAcc=24.312788 {Bundle[EMPTY_PARCEL]}]
The last log line that says it was skipped. Are those accurate coordinates that you removed? Because accuracy there is 1700 which is much higher than the default of 200.
All three lat/long values are identical, and are out by about 250 m in distance, and about 15 minutes in time from the closest I would have been to that position. I arrived at work at 09:00 but the location in the logs relates to a position I was close to, 15 minutes in the past and approx. 7 miles/11 km from where I actually was at 09:00.
To me, it’s interesting that the three values for lat, long and altitude are exactly the same - this looks like frozen data to me, rather than successive updates, even if I was stationary?
What are the units for hAcc? is a large value good or bad?
Hard to tell the report was already skipped due to accuracy. Time evaluation comes after accuracy checks.
Meters
It’s going to vary from device to device you’ll need to go by the data in the logs to determine that. If you see a lot of reports being skipped then yes you should increase the setting. Some users in rural areas will need to make the value higher, that is why it’s user configurable.
alright, i’ve started trying to tinker with this again…i can’t for the life of me get the high accuracy based on zone to work. i have it set to only apply when entering home zone, with an offset of 10k meters. it stays on when i’m home, and if i turn it off manually it never turns on. if i turn it on when i’m out (and the phone is already detecting me as away), but still inside the expanded zone, it stays on but never turns itself off when i get home.
i have no idea what i’m doing wrong, but i just can’t get this to work. ever.
lately it works sometimes, but the times it doesn’t work I don’t notice until we’re long past the point where I can get logs to find out what is going on.
example: tonight I arrived home at 12:58am, according to my person tracker. according to the high accuracy sensor, that was turned on at 12:53am which makes sense for the size of my expanded home zone. so far, so good.
however it’s now 3:23am and I just noticed that HA mode is still on. it never turned off when I got home…and now the earliest log I have is 3:01am, which is useless.
is there a way to extend how long the logs are saved for before being cycled?
it happened again tonight. we arrived home about 2 hours ago, and just now i noticed that HA mode is still on. as such, the logs are again useless.
can anyone help me figure this out? it’s so insanely frustrating…
1 Like
Hey guys, I had the same problem and this is what fixed it for me:
-
Sign out from all mobile devices from everybody.
-
Go to home assistant using a BROWSER and start deleting each and every entity related to those mobile devices, one by one, by hand, on the entities screen. P.S.: If entities start to get recreated while you delete them, check if you’re signed out on all devices.
-
After deleting all entities, go to Settings > Integrations > Mobile app
-
Delete each and every phone in there. If there’s any phone with entities, delete the entities first.
- If any phone is disabled in this list, re-enable it, delete the entities, and try to delete it again, in this order.
- If you get errors while trying to delete phones or some weird “Not loaded” messages while deleting phones, restart Home Assistant and redo step 2 onwards. I had to restart Home Assistant multiple times for this to work until no errors or messages were displayed and everything was effectively deleted.
-
Do this until you feel you have a clean slate on anything related to mobile devices, and then sign in on all devices again. Entities should get recreated, so check if they don’t end with “_1” or something, because if they do, then there was something left to delete before signing on again, so redo step 2 onwards. I had to restart Home Assistant multiple times for this to work until no errors or messages were displayed and everything was effectively deleted.
-
Once phones and entities are properly created, go to Settings > People, go to each person, and check if the only devices that belong to the people are the main phone devices that you want to be used as location trackers, so no Macs, computers, tablets, anything other than each person’s main mobile phone should be there.
-
Test it and post it here if that works for you.
I hypothesize that the zone people tracker is not getting updated because of these ghost phones created by Home Assistant. These get recreated every time you sign-in with the same account, so avoid signing out and back in again on the same device, otherwise, you’ll have to make sure your entities are not messed up and each person’s main device is the only one liked to the person at hand.
Is this a bug worth creating tickets on Home Assistant’s GitHub? Is this reproducible? I can’t say for sure because I don’t want to mess up my entities, it’s a pain to delete each entity by hand (I couldn’t find any way to delete entities in bulk).
I discovered this post and though that maybe it would help me resolve my zone triggering issues. I figured I’d give it a try, and wrote out what I did because it ended up being different. I waited to post until I could say whether it worked or not. It didn’t. 
Below is what I wrote, and I’m leaving it here just to show that the procedure that @edgarfroes suggested wasn’t possible for me (and also that my crazy attempt to clear everything out didn’t do anything either).
It turns out that my issue was simpler: Data Saver mode was preventing zone enter/exit from being detected on the device. Maybe someone else will land here with Data Saver enabled or at least can double check that before going through the obnoxious steps to clear everything.
Here’s what I tried before discovering the Data Saver issue:
I was having trouble getting Android geofencing working with Zones, so I tried this, but couldn’t get entities deleted when the integration was active. So I did the following:
Disable Mobile & Netgear integrations firstStop HA withha core stopBackup entity registry withcp .storage/core.entity_registry .storage/core.entity_registry.bakDelete all phone related entries from.storage/core.entity_registryMake a copy of the edits,cp .storage/core.entity_registry .storage/core.entity_registry.editStart HA againha core startDiff the changes after startdiff .storage/core.entity_registry.edit .storage/core.entity_registrywhich showed nothing (I think the registry gets written during shutdown & maybe periodically)Restart HA withha core restartDiff the changes again and ensure no phones appeareddiff .storage/core.entity_registry.edit .storage/core.entity_registryDelete & reinstall mobile app on my Andriod phoneSetup the mobile app again and re-enable the Netgear integration
Thanks for the guide, @edgarfroes. I appreciate that this community is full of people who share their experiences and clearly document what worked for them. It didn’t work, but gave me something to try, and the confidence to continue digging until I found what my issue was. 
This is not a solution, but if you have issues with this can you try the following:
Set your phone screen timeout to 10 or 30min and keep the app active while you are leaving/entering your zones.
I have done multiple tests like this and my phone has no issues at all with the location updates if the app is active and the screen is on. When the screen is off i run into all the same problems described here.
It must eiter be a setting i’m missing, or there is just something wrong with the Mobile app on android