owntracks sends same GPS data twice causing duplicates

[TheQuickster]

I have owntracks sending data to my own system but I'm seeing some strange behaviour that I can't seem to identify if it is normal or not?

At random times, owntracks sends the same GPS point through to my system. The owntracks logs show that a new packet has been created but with the same GPS point as previously sent successfully. There are no errors in the owntracks log nor any errors in my system but it seems like some data goes missing after the duplicate GPS point is sent through.

The dual points are sent one after the other (anything up to 10 minute apart) but doesn't seem to matter if the device is moving or not.

• App build number: 2.5.3
• Android version: 7.0 + 14
• Device: Samsung S6 + S21
• Installation source: Google Play

[growse]

Can you post a (location redacted) example of the messages?

I'm wondering if they've got the same created_at or t attributes.

More generally, is it just the same latlng, or the exact same message. The latter's probably a bug. The former, less certainly so.

[TheQuickster]

Here are 2 JSON payloads that happened consecutively. The lat land lon for each is the same, as is the tst but the created_at is different. Is it possible that if a new GPS update has not happened, the current cached point is used?

[{'_type': 'location', 'BSSID': 'xx:xx:xx:xx:xx:xx', 'SSID': 'xxxxxxxx', '_id': '2b650581', 'acc': 20, 'alt': 258, 'batt': 100, 'bs': 3, 'cog': 0, 'conn': 'w', 'created_at': 1733083629, 'lat': xxxxxxxxx, 'lon': xxxxxxxxx, 'm': 2, 'tid': 'S6', 'topic': 'owntracks/----------/S6', 'tst': 1733083629, 'vac': 0, 'vel': 0}]

[{'_type': 'location', 'BSSID': 'xx:xx:xx:xx:xx:xx', 'SSID': 'xxxxxxxx', '_id': '87a06f27', 'acc': 20, 'alt': 258, 'batt': 100, 'bs': 3, 'cog': 0, 'conn': 'w', 'created_at': 1733084157, 'lat': xxxxxxxx, 'lon': xxxxxxxxx, 'm': 2, 't': 'p', 'tid': 'S6', 'topic': 'owntracks/------------/S6', 'tst': 1733083629, 'vac': 0, 'vel': 0}]

[growse]

The difference here is that they have different triggers. The second is 't':'p' , which means it's been scheduled by the periodic location ping scheduler.

The created_at field is the time that the message was created, whereas the tst is the time the location fix was made. The fact that the tst is the same shows that it's the same location fix that's being sent both times, so there's been no new location from the device in the time between these messages.

Does that explain what's going on?

[TheQuickster]

Thanks @growse, yes that explains what is happening. I assume the ping is done because the device has not moved and therefore not sent a location for a period of time, so the ping is generated to let the server know that the device is still alive. A keep alive sort of thing.

The location information could be the same as the previous location because the device has not moved or it could be different so I can't just use this packet as a check-in as it could also indicate the device has moved.

[yonran]

I just installed owntracks. I made a 10min 1.8mi drive from approx 17:25 to 17:35 from home to school. But I also observed that all updates had the exact same location from 14:50 until 17:37:54. Note that Google Maps encrypted Timeline was no better; it shows an instantaneous trip from home to school at 17:38 and cannot show data points anymore. This is unexpected behavior because I thought that Owntracks should not send data points that are incorrect and indistinguishable from real location updates.

excerpt of rec/yonathan/oriole/2024-12.rec:

2024-12-10T14:50:45Z    *                       {"_type":"location","_id":"05b6f5bf","acc":13,"alt":23,"batt":62,"bs":1,"cog":56,"conn":"w","created_at":1733842246,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733842245,"vac":15,"vel":6,"_http":true}
…

2024-12-10T17:26:42Z    *                       {"_type":"location","_id":"5e13f79e","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"w","created_at":1733851602,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733851602,"vac":100,"vel":0,"_http":true}
2024-12-10T17:31:22Z    *                       {"_type":"location","_id":"edae8684","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"m","created_at":1733851882,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733851882,"vac":100,"vel":0,"_http":true}
2024-12-10T17:36:41Z    *                       {"_type":"location","_id":"4271a324","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"m","created_at":1733852201,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733852201,"vac":100,"vel":0,"_http":true}
2024-12-10T17:37:54Z    *                       {"_type":"location","_id":"01a5f87f","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"m","created_at":1733852274,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733852274,"vac":100,"vel":0,"_http":true}
2024-12-10T17:37:54Z    *                       {"_type":"location","_id":"d5b3d826","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"m","created_at":1733852276,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"t":"p","tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733852274,"vac":100,"vel":0,"_http":true}
2024-12-10T17:38:58Z    *                       {"_type":"location","_id":"33a1a68c","acc":30,"alt":24,"batt":56,"bs":1,"cog":0,"conn":"m","created_at":1733852338,"lat":SCHOOL_LAT,"lon":SCHOOL_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733852338,"vac":2,"vel":0,"_http":true}

(I have redacted the 10-digit home location and school location using find and replace. But the exact same HOME_LAT, HOME_LON was present for the duration of the drive).

I’m using monitoring mode: Significant Changes, Location Interval: 60s, Minimal location displacement: 0.

config.otrc:

{
  "_type" : "configuration",
  "_id" : "9e891ec7",
  "waypoints" : [ ],
  "_build" : 420503003,
  "autostartOnBoot" : true,
  "cmd" : true,
  "connectionTimeoutSeconds" : 30,
  "debugLog" : true,
  "deviceId" : "oriole",
  "dontReuseHttpClient" : false,
  "enableMapRotation" : true,
  "encryptionKey" : "",
  "experimentalFeatures" : [ ],
  "extendedData" : true,
  "fusedRegionDetection" : true,
  "ignoreInaccurateLocations" : 0,
  "ignoreStaleLocations" : 0.0,
  "locatorDisplacement" : 0,
  "locatorInterval" : 60,
  "mapLayerStyle" : "GoogleMapDefault",
  "mode" : 3,
  "monitoring" : 1,
  "moveModeLocatorInterval" : 10,
  "notificationEvents" : true,
  "notificationGeocoderErrors" : true,
  "notificationHigherPriority" : false,
  "notificationLocation" : true,
  "opencageApiKey" : "",
  "osmTileScaleFactor" : 1.0,
  "password" : "",
  "pegLocatorFastestIntervalToInterval" : false,
  "ping" : 15,
  "publishLocationOnConnect" : true,
  "remoteConfiguration" : false,
  "reverseGeocodeProvider" : "Device",
  "showRegionsOnMap" : false,
  "theme" : 2,
  "tid" : "le",
  "url" : "http://192.168.29.3:8083/pub",
  "username" : "Yonathan"
}

[growse]

The location information could be the same as the previous location because the device has not moved or it could be different so I can't just use this packet as a check-in as it could also indicate the device has moved.

Correct. The device generates locations from the configured providers (GPS, Network, Passive etc.) and supplies them to apps along with a timestamp that the 'fix' was made. There's nothing stopping the device supplying the same Location (with the same fix time) multiple times - OT tries to ignore locations where the timestamp hasn't changed.

Ping is a bit of a special case. As you say, it's a little bit like a keepalive, and it just reaches into the cache to fetch the last known location - this may have the same latlng / tst as a previously sent one, as you're seeting.

One option here is to allow people to ask for 'pings' to be "high accuracy". This means that periodically, if in Significant Changes mode, the device will switch into high accuracy mode for a single point and then dispatch that. It's a little complex though, as the very act of switching to a high accuracy mode will generate a fresh location, which will be delivered to OT via the usual mechanism and then published (not as a ping).

I guess what I'm saying is that it might be unusual for a ping to have a never-before-seen location attached to it. 🤷

--

@yonran

2024-12-10T17:26:42Z    *                       {"_type":"location","_id":"5e13f79e","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"w","created_at":1733851602,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733851602,"vac":100,"vel":0,"_http":true}
2024-12-10T17:31:22Z    *                       {"_type":"location","_id":"edae8684","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"m","created_at":1733851882,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733851882,"vac":100,"vel":0,"_http":true}
2024-12-10T17:36:41Z    *                       {"_type":"location","_id":"4271a324","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"m","created_at":1733852201,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733852201,"vac":100,"vel":0,"_http":true}
2024-12-10T17:37:54Z    *                       {"_type":"location","_id":"01a5f87f","acc":100,"alt":23,"batt":57,"bs":1,"cog":0,"conn":"m","created_at":1733852274,"lat":HOME_LAT,"lon":HOME_LON,"m":1,"tid":"le","topic":"owntracks/Yonathan/oriole","tst":1733852274,"vac":100,"vel":0,"_http":true}
2024-12-10T17:37:54Z    *                       {"_type":"location","_id":"d5b3d8

The fact that the lat and lng fields are the same, but the tst is increase means that the device thinks that it's still in one place. it's essentially fibbing to OT (and apparently google) that it received a location fix at 1733852274 for your home location (which you're saying isn't true).

Some devices do this. OT has no way of knowing that the device is lying to it, sadly :(