Significant changes mode often thinks we're at home when we're not

[chewi]

Hello. My family and I use the Android app, connecting to Mosquitto in MQTT mode, along with Recorder, all running on my ARM board at home. Everything works fine except that it often thinks we're at home when we're not. We typically use Significant changes mode. Anecdotally, I would say Move mode works better, but I tend not to use it as I find this is too much data.

I've waited a while before reporting this to try and catch it in the act. Today, I left home twice for around an hour each time, over 2 miles away the second time, and yet it claims I never left. Mobile reception around here is usually passable, if not very good.

I had thought it was simply not sending updates for long periods, possibly because of battery or data restrictions, although I had done everything I could think of to prevent those from being an issue. Today's finding seemed to show otherwise. I was going to send the actual debug logs from the moment where I knew I was definitely over 2 miles away, but annoyingly the logs seem to have rotated while I was writing this. I know that it logged SendLocationPingWorker followed by the coordinates for my house. That means OwnTracks is sending a location update to Mosquitto, right? If so, does that mean the device is lying about its location? I've tried to give it all the permissions it needs, including precise location. I even used another location-based app at that moment, and it was very accurate.

I had thought perhaps this was an issue with Android 13, but my daughter's older phone on Android 9 doesn't seem much better.

I'm a software engineer and am happy to dig in as deep as you require. I just need some direction.

• App build number: Version 2.4.12 (420412000)
• Android version: 13 (LineageOS 20)
• Device: Motorola Edge (2020) aka racer
• Installation source: Google Play

[jpmens]

Could you please check and report on the values of locator displacement and locator interval configured on your device?

[chewi]

{
  "_type" : "configuration",
  "waypoints" : [ ],
  "_build" : 420412000,
  "autostartOnBoot" : true,
  "cleanSession" : false,
  "clientId" : "racer",
  "cmd" : true,
  "connectionTimeoutSeconds" : 30,
  "debugLog" : true,
  "deviceId" : "racer",
  "enableMapRotation" : false,
  "experimentalFeatures" : [ ],
  "fusedRegionDetection" : true,
  "host" : "aura-online.co.uk",
  "ignoreInaccurateLocations" : 1000,
  "ignoreStaleLocations" : 0.0,
  "info" : true,
  "keepalive" : 3600,
  "locatorDisplacement" : 100,
  "locatorInterval" : 300,
  "locatorPriority" : 2,
  "mapLayerStyle" : "OpenStreetMapNormal",
  "mode" : 0,
  "monitoring" : 1,
  "moveModeLocatorInterval" : 10,
  "mqttProtocolLevel" : 4,
  "notificationEvents" : true,
  "notificationGeocoderErrors" : true,
  "notificationHigherPriority" : false,
  "notificationLocation" : true,
  "opencageApiKey" : "",
  "osmTileScaleFactor" : 1.0,
  "password" : "********",
  "pegLocatorFastestIntervalToInterval" : false,
  "ping" : 30,
  "port" : 8883,
  "pubExtendedData" : true,
  "pubQos" : 1,
  "pubRetain" : true,
  "pubTopicBase" : "owntracks/%u/%d",
  "remoteConfiguration" : true,
  "reverseGeocodeProvider" : "None",
  "showRegionsOnMap" : false,
  "sub" : true,
  "subQos" : 2,
  "subTopic" : "owntracks/+/+",
  "theme" : 0,
  "tid" : "CW",
  "tls" : true,
  "tlsCaCrt" : "",
  "tlsClientCrt" : "",
  "tlsClientCrtPassword" : "",
  "username" : "chewi",
  "ws" : false
}

[jpmens]

The two relevant values are

"locatorDisplacement" : 100,
"locatorInterval" : 300,

I'd like to suggest you try setting these to 50, 30 respectively, on-the-fly, using the configuration editor in OwnTracks on the device.

I have had very good experience with those numbers with our Android app.

[chewi]

Thanks, I'll try that for a while.

[chewi]

Things were initially looking good, as recorded locations were looking more "interesting". I was at home this morning while my wife and daughter left for different places, so I took the opportunity to check the situation. OT was still claiming they were at home. 😞

I sent a reportLocation to my wife's phone while watching mosquitto_sub and tcpdump. The report came back immediately, and I could see the data going in and out to various IPs. The timestamp was current, but the coordinates were still at home, and it even showed our home SSID. I checked the IP addresses again. Two internal IPs. I checked the router. One was my phone. The other was my wife's phone. IT'S COMING FROM INSIDE THE HOUSE!! 😱 I looked over and saw my wife's phone sat right there on the sofa. 😂

After laughing out loud quite a bit, I tried the same with my daughter's phone.

{"_type":"cmd","action":"reportLocation"}
{"_type":"location","acc":100,"alt":114,"batt":74,"bs":1,"conn":"m","created_at":1695628861,"lat":12.3456,"lon":12.3456,"m":1,"t":"r","tid":"KB","tst":1695628821,"vac":100,"vel":0}

Again, the timestamp was current, and the coordinates were still at home, but no SSID this time, as this phone really isn't at home. Everything about that report, such as the battery level, seems correct except for the location. What do you make of that?

[growse]

The reportLocation command should kick OT into making a PRIORITY_HIGH_ACCURACY location request for a single point, which then gets posted to MQTT. You're rightly getting a "type": "r" message back, but the fact that it's got an out-of-date location means that the device has reported that to OT.

This is the method called to request the location:

android/project/app/src/main/java/org/owntracks/android/services/BackgroundService.java

Lines 527 to 543 in 47ffad4

	@SuppressWarnings("MissingPermission")
	public void requestOnDemandLocationUpdate() {
	if (missingLocationPermission()) {
	Timber.e("missing location permission");
	return;
	}
	LocationRequest request = new LocationRequest();
	request.setNumUpdates(1);
	request.setPriority(LocationRequest.PRIORITY_HIGH_ACCURACY);
	request.setExpirationDuration(TimeUnit.MINUTES.toMillis(1));
	Timber.d("On demand location request");
	locationProviderClient.requestLocationUpdates(request, locationCallbackOnDemand, runThingsOnOtherThreads.getBackgroundLooper());
	}

What's interesting is the delta between the tst and created_at fields is 40 seconds. created_at is the timestamp that the message was created (ie just before posting to MQTT), whereas tst is the timestamp of the location as reported by the device (locations come with timestamps). Do you know what the time delta was between sending the command and receiving the response?

This is a frustrating problem, because even though OT has asked for the most accurate, precise and timely location, the device has chosen to deliver one that's out of date. We've seen some device manufacturers behaving worse than others on this. There's even a flag on the API called setWaitForAccurateLocation (https://developers.google.com/android/reference/com/google/android/gms/location/LocationRequest#public-locationrequest-setwaitforaccuratelocation-boolean-waitforaccuratelocation) which defaults to true, that should prevent this exact problem. And yet it seems that your device is behaving as though this is false.

(I'll update the next release to not assume the default and explicitly set this, so that might fix the issue? Seems unlikely though).

In your original message, you mentioned that you were using a Motorola Edge (2020) aka racer with Lineage 20 - is that the same for the device here?

As a workaround, can you try adding a waypoint (geofence) for your home address? Moving in/out of these regions should be pretty reliable, and might kick the device into noticing that it's actually changed location.

[chewi]

I haven't changed anything yet, but it didn't notice I went to the office yesterday. It did notice the day before, although it only seemed to pick up the trail part way through.

Do you know what the time delta was between sending the command and receiving the response?

I think it came back almost immediately. I should test again to be sure, but everyone is home right now.

In your original message, you mentioned that you were using a Motorola Edge (2020) aka racer with Lineage 20 - is that the same for the device here?

Not quite, but they are all Motorolas, which could be relevant.

• Me: Motorola Edge (2020) aka racer + LineageOS 20
• Wife: Moto G7 Plus aka lake + LineageOS 20
• Daugther: Moto G4 Plus aka athene + AOSIP 9.0 (Android 9)

I'll set up some geofences today.

[chewi]

Update. I had thought perhaps geofences had helped a little, but it was hard to say for sure. I also turned off Battery Saver on the G4 Plus, and I'm fairly sure that helped, even though we'd previously whitelisted OwnTracks.

Checking today though, I see that the server hasn't seen a change from my Edge for 6 days, even though I've travelled several miles on multiple occasions. This time, I happened to notice that the phone says "6d" above the notification. Could be interesting?

I've also found that the geofences can be a bit erratic. I can see them laid on the map and they look sensible, but sometimes the app claims we've entered the high school when we've been nowhere near it. I didn't make the radius that large, so I don't think this is due to wobbly GPS.

[wir3z]

Try changing the "ignoreInaccurateLocations" to "500" which will prevent accuracies more than 500m from triggering a report. I've found that I get spurious accuracy values (1799.99 on occasion). That would blanket trigger all regions in that radius.

[chewi]

Good idea! I had it set to 1000, which is within range of the high school, but I didn't realise it worked like that in terms of regions.

[wir3z]

I just noticed at "0" I was getting occasional "you are at all your kids work and friends places, all at once" !

[growse]

Tuning ignoreInaccurateLocations downwards is a good idea, thanks for that. In my experience, there's a lot of devices that'll chuck out just plain wrong locations with the accuracy set at something vague like "400m" - they're doing their best and guessing based on spurious GSM / Wifi data, but for most cases it's unhelpful. You end up with a trace that looks a bit like this:

I just noticed at "0" I was getting occasional "you are at all your kids work and friends places, all at once" !

Setting it to 0 turns off the filter. Any location the device presents to OT will be posted to the network, regardless of accuracy.

I run on 150 on my Pixel 6a, and that gives me acceptable results.

[wir3z]

I run on 150 on my Pixel 6a, and that gives me acceptable results.

What do you use for "locatorPriority"? I was using "3" (High Power/GPS), but trying to see the balance of "2" (Balanced/Wifi/cell -- default for significant mode). I was thinking the "block level accuracy" of "2" wasn't good enough for automations.

Looking at my data, 150 seems like a more fitting value as well.

[growse]

I use Significant Changes (which is 2) most of the time. It really affects how often the device should wake OT up to provide it with a location. 3 will explicitly keep the GPS / other providers awake and scanning to provide timely locations, whereas 2 is more of a "best efforts, give me a location when it's changed a bit and based on what other apps are asking for locations".

The problem we find is that the way in which different make/models of devices behave under Significant Changes Mode varies wildly.

[Biliskn3r]

I get around this issue by sending an MQTT update to all our phones every hour, which switches Owntracks to "Move" tracking. After 1 minute, it will switch back to "Significant" changes. You can automate this if you use Home Assistant or have MQTT setup, etc.

[growse]

In the new version, sending the reportLocation command should do exactly this. Puts the location into "high battery usage, high accuracy mode for one single location", which should generate a single, GPS-sourced location.

[chewi]

@growse, which version do you mean? 2.5.0?

I can easily set up a cron job to do this, although I wonder whether the app should periodically do this by itself when in Significant Changes Mode.

[wir3z]

I use Significant Changes (which is 2) most of the time. It really affects how often the device should wake OT up to provide it with a location. 3 will explicitly keep the GPS / other providers awake and scanning to provide timely locations, whereas 2 is more of a "best efforts, give me a location when it's changed a bit and based on what other apps are asking for locations".

The problem we find is that the way in which different make/models of devices behave under Significant Changes Mode varies wildly.

I have noticed this as well. To @chewi 's comment, why not the ping message have a high accuracy location? That already exits, is a user configurable interval.

[growse]

It's a good idea, I'd be slightly mindful of higher battery use, but think it would be minimal.

[atpanos]

I have similar issue with leaving home for 20 min to go pick up some stuff like a mile away.
OT never tracks this movement.
I use the same settings...
Is there any hint that this is a software issue?