PublishQuequeAsyncRK - WITH_ACK issue - any solution?

Firmware Libraries
1

@rickkas7’s excellent PublishQuequeAsyncRK library has a known issue when using Particle.publish() with the WITH_ACK flag:

// For reasons that are not entirely obvious to me, you can't use WITH_ACK. If you specify it
// on the Photon or Electron, Particle.publish will immediately return false. This only happens
// with this code running in a separate thread. It works fine from the main thread.

This is an issue because I need the event to positively make it to the Particle cloud.

I can create a situation where the routine thinks it has sent it okay, but it does not make it because I have (purposely) turned off the data on my mobile hotspot.

This should be solved by using WITH_ACK in the Particle.publish() call.

It looks like the work around is provided in the statement “works fine in the main thread”.

Q1. How does one achieve that?

Q2. Any other suggestions on what I should try to get this library working with WITH_ACK?

Q3. Does anyone know if there is a similar library that caches to SD CARD rather than/as well as, retained memory?

Thanks!

2

Version 0.0.3 and later support WITH_ACK. The current version is 0.0.4.

1 Like
3

Aha! Too easy!

Could you point me to the correct repo? Sounds like I have picked up old code then…

4

It’s in the community libraries as https://github.com/rickkas7/PublishQueueAsyncRK. It looks like version 0.0.4 is available there.

5

Oh I see the problem. I forgot to change some of the comments. It does actually work.

1 Like
6

@rickkas7, then I am not going mad!

As there is no issue with using WITH_ACK per se, we can concentrate on the issue as described. I don’t think it is within the library itself, but Particle.publish().

I will characterise and report back.

7

@rickkas7 happy to report, case closed!

Works as expected using WITH_ACK

  • every cached unsuccessful event has made it to the cloud once data+wifi has been established
  • have not had a case, so far, of having thought that an event was sent, but was not actually received (which was my issue using NO_ACK when I was “forced” to use it due the erroneous comment reads)