duplicate messages in HTTP mode

[da-mkay]

Hi there,

first of all thank you for all the great work at owntracks!

I use the iOS app in HTTP mode and try to understand the messages I receive.
Sometimes I get kind-of duplicates. I know that duplicates are possible with MQTT and qos=1. But in case of HTTP I guess messages are sent just once, right?

But please have a look at what my server receives:

{"lat":latA,"lon":lonA,"batt":40,"acc":46,"bs":1,"p":100.694,"vac":122,"topic":"owntracks/mkay/phone","conn":"m","m":1,"tst":1709970594,"alt":38,"_type":"location","tid":"MK"}
{"lat":latB,"lon":lonB,"batt":40,"acc":54,"bs":1,"p":100.734,"vac":22,"topic":"owntracks/mkay/phone","t":"v","conn":"m","m":1,"tst":1709970601,"alt":39,"_type":"location","tid":"MK"}
{"lat":latB,"lon":lonC,"cog":22,"batt":40,"acc":44,"bs":1,"p":100.734,"vel":0,"vac":2,"topic":"owntracks/mkay/phone","t":"v","conn":"m","m":1,"tst":1709970604,"alt":35,"_type":"location","tid":"MK"}
{"lat":latA,"lon":lonA,"batt":40,"acc":46,"bs":1,"p":100.734,"created_at":1709970604,"vac":122,"topic":"owntracks/mkay/phone","conn":"m","m":1,"tst":1709970594,"alt":38,"_type":"location","tid":"MK"}

The 4th message is basically the same message as the first message, even with the same (old) tst, but sent 10 seconds after the first one.
The only difference is the p property and the added created_at property. I think that created_at is added just because the time of the GPS-fix is different than the time the message was sent.
But why do I get that 4th message anyways?

And a second question:
When is that created_at property added?
In my logs I see it in two cases:
1. on ping-triggered messages (I guess that makes sense if ping sends the last known location)
2. when receiving the duplicates mentioned above.
But what logic is causing this exactly?

All the best!
da-mkay

[ckrey]

created_at is added when tst differs from the current time

Duplicates may happen with MQTT QoS1 or HTTP when no positive acknowledge is received from the backend.

In your example there is no duplicate, but another location update was triggered.

The 2nd and 3rd location update in your example was triggered by "visiting" a significant location (Controlled by 2Settings/Privacy/Location Services/System Services/Significant Locations")

[da-mkay]

Yes, location 2 and 3 are no duplicates. They even have different coordinates. I just added it here from my logs to show that the app sent some location updates between the 2 duplicates 😉

But why is location 4 not a duplicate of 1? They have same tst and everything except for p and created_at.
According to your information a duplicate could be caused by a missing acknowledgement in HTTP-mode. This would explain the 4th message for me (maybe HTTP response got lost). But according to your post, this is not the case here, because you wrote that these are no duplicates.
But why is this 4th message then send 10 seconds after sending that same message using same tst?

[ckrey]

Sorry, I didn't answer one of your questions:
The created_at property is added when the message is created and queued. It is not added or updated when (re-)transmitted.
The same applies to the p (pressure) property.

I cannot explain why location 4 still shows the timestamp of location 1, but location 2 and 3 have a newer timestamp. I guess it is because locations 2 and 3 were triggered by the "Frequent Location Monitoring" ("t":"v") which delivers out of band location updates...