Publish Latency & Particle_Published_At

General
1

Using a webhook, is {{PARTICLE_PUBLISHED_AT}} tagged by the device or by the Particle Cloud?

We are seeing a LIFO effect when making subsequent publishes (at no less than one second intervals) that log to our database.

EDIT: We believe that we may be seeing varying latency on publishes which will show up in the wrong order. I hope that clarifies the question.

Added:

Well clearly the device’s time and published_at have two different sources…

event: Time
data: {"data":"Thu Mar 15 13:41:48 2018","ttl":60,"published_at":"2018-03-15T13:41:50.611Z","coreid":"56002a000b51343334363138"}

This is showing two seconds between the two. So, if we are working with a Particle Cloud generated timestamp for published_at, then could latency affect some events such that newer publish()s are received before older ones?

tested like this:

void loop()
{
  auto publishTime = [&](uint32_t frequency){
    static uint32_t lastMillis = 0;
    if (millis() - lastMillis > frequency) {
      Serial.println(Time.timeStr());
      Particle.publish("Time", Time.timeStr());
      lastMillis = millis();
    }
  };
  publishTime(1000);
}

anyone seen this before?

2

Yes, the published at time is generated by the cloud, basically when the CoAP packet arrives.

The reason I didn’t answer sooner as I’m really not sure how the retry works. Given your symptoms my guess is that if you don’t have WITH_ACK (blocking publish) you can get events out of order.

Say you send an event, and it gets lost. It’s not a blocking send, so you immediately send another event, and that goes through. But then the retry kicks in and the original event goes through.

I don’t know that it’s how it actually works, that just conjecture of how you would see those symptoms and it would make sense if it worked that way.

2 Likes
3

Right, not using WITH_ACK.

Ok, so “the retry” is a device generated event?

The device is looking for confirmation that the data frame was received by the tower?

4

I’m about 90% certain this is how it works:

For Electrons, since the underlying communication channel is UDP, there is no guarantee that the CoAP packet will arrive at the destination.

When you do a publish the event packet is sent to the cloud.

If you use the NO_ACK flag, that’s it. If it gets there, it get there, and if not it’s lost.

If you use WITH_ACK is specified, the Particle.publish call will block until it gets an ACK back from the cloud to indicate that the event was received. It will try 3 times.

Otherwise, an an ACK is still requested, but the Particle.publish does not block.

This allows you to get into the situation you described. There is not a queue of outgoing events, where it keeps trying the first event until it succeeds. Instead, when you Particle.publish it immediately tries to send the event.

However, at the same time, the system firmware on the device is checking to see if there are any unacknowledged events. If there are, they’re retransmitted, up to 3 times.

I think that’s how you’re getting out-of-order events.

2 Likes
5

Thanks

Terrific response, I really appreciate it