Owntracks reports out of order

I was noticing some odd behavior recently when my wife would leave the house - HA would show her as “away”, but then she would show up as “home” again a short time later and sometimes stay that way, even though she was not.

She is running Owntracks on iOS and I have been recording reports using ot-recorder. What looks like is happening is that her phone reports her away, but subsequently sends an out-of-time-sequence message with her back at home. Then, depending on the location logic in OT/iOS, sometimes it never makes another report the whole day while she’s gone, until she’s on her way back home.

I can tell the message are out of sequence because Owntracks places a timestamp as a field in each message, and the timestamp for some of these is prior to the previous message’s timestamp.

Has anyone seen this before? I don’t know if the problem should be addresses in Owntrack, in MQTT, or in HA. In one of those places I’m thinking there should be logic that says “if the timestamp from this message is before the timestamp from the last message on this topic, ignore it”, but not sure where. Or if someone has already solved this?

Below are some reports, in order, from ot-recorder. The first one is the first message received by ot-recorder in the morning (once she has left the house). The 2nd message, though I’ve redacted it, shows her BACK at HOME, but you can see the timestamp is from BEFORE the first message. And the 3rd is her on her way to work.

Although the delay between msg1 and msg2 in this case wasn’t that big, I’ve seen sometimes that msg2 doesn’t come for 15+ minutes, and by that time she’s at work and her phone doesn’t report again for hours cause she’s not moving. So when that happens, HA thinks she’s home all day.

Thanks in advance for the thoughts/help.

{
  "t": "c",
  "tst": 1500646148,
  "acc": 65,
  "_type": "location",
  "alt": 56,
  "lon": <redacted>,
  "vac": 10,
  "lat": <redacted>,
  "batt": 44,
  "conn": "m",
  "tid": "am",
  "ghash": "<redacted>",
  "cc": "US",
  "addr": "<redacted>",
  "locality": "<redacted>",
  "isorcv": "2017-07-21T14:09:08Z",
  "isotst": "2017-07-21T14:09:08Z",
  "disptst": "2017-07-21 14:09:08"
},
{
  "t": "v",
  "tst": 1500646117,
  "acc": 16,
  "_type": "location",
  "alt": -1,
  "lon": <redacted>,
  "lat": <redacted>,
  "batt": 100,
  "conn": "m",
  "tid": "am",
  "ghash": "<redacted>",
  "cc": "US",
  "addr": "<redacted>",
  "locality": "<redacted>",
  "isorcv": "2017-07-21T14:08:37Z",
  "isotst": "2017-07-21T14:08:37Z",
  "disptst": "2017-07-21 14:08:37"
},
{
  "tst": 1500646521,
  "acc": 65,
  "_type": "location",
  "alt": 8,
  "lon": <redacted>,
  "vac": 20,
  "lat": <redacted>,
  "batt": 100,
  "conn": "m",
  "tid": "am",
  "ghash": "<redacted>",
  "cc": "US",
  "addr": "<redacted>",
  "locality": "<redacted>",
  "isorcv": "2017-07-21T14:15:21Z",
  "isotst": "2017-07-21T14:15:21Z",
  "disptst": "2017-07-21 14:15:21"
},

I’ve noticed this too with my other half’s iPhone, doesn’t seem to affect my Android device.

I think it’s the ios owntracks app cacheing an update that it then sends later, even though it has since sent a more up to date one, but knowing bugger all about Apple devices I’ve left it for others to submit a bug report to owntracks directly.