Significant changes mode often thinks we're at home when we're not about android HOT 20 OPEN

Thanks, I'll try that for a while.

from android.

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.

from android.

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

from android.

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.

from android.

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.

from android.

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

from android.

{
  "_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
}

from android.

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.

from android.

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?

from android.

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:

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.

from android.

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.

from android.

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.

from android.

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.

from android.

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.

from android.

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.

from android.

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.

from android.

@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.

from android.

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.

from android.

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

from android.

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?

from android.