Still having issues with "WITH_ACK" flag on particle.publish()

Moving this to a new thread since it seems like a different issue than the ones that are currently open.

On particle.publish() ACK returns false even though the publish goes through. This happens regularly and is easily repeatable.

Did a search on GitHub issues and it looks like they have all been closed except this one. https://github.com/particle-iot/device-os/issues/1679. This seems to be a bit different, though I can't confirm.

Also read through GitHub - rickkas7/particle-publish-blocking: Tips for preventing Particle.publish from blocking on the Electron from @rickkas7
Not seeing anything that should cause this behavior.

Running 1.2.1 on Electron with SYSTEM_MODE(SEMI_AUTOMATIC); SYSTEM_THREAD(ENABLED);

Using a regular bool to make sure it blocks until ACK is received. In this particular example, the publish happened successfully but returned false.

bool success;
    success = Particle.publish("telemetry", json.getJson(), PRIVATE, WITH_ACK);
    if (!success) {
      appLog.warn("Telemetry did not send successfully.");
    } else {
      appLog.trace("Telemetry sent successfully.");
    }

0000017291 [comm.dtls] INFO: session cmd (CLS,DIS,MOV,LOD,SAV): 4
0000017291 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000017293 [comm.protocol] INFO: message id 4070 complete with code 0.00
0000017293 [comm.protocol] INFO: rcv’d message type=13
0000017443 [comm.protocol] INFO: Posting ‘M’ describe message
0000017597 [comm.protocol] INFO: rcv’d message type=1
0000022643 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000022643 [comm.protocol] INFO: message id 4074 complete with code 0.00
0000022645 [comm.protocol] INFO: rcv’d message type=13
0000023272 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000023272 [comm.protocol] INFO: message id 4073 complete with code 0.00
0000023274 [comm.protocol] INFO: rcv’d message type=13
0000032250 [comm.protocol] TRACE: Reply recieved: type=2, code=69
0000032250 [comm.protocol] INFO: message id 4076 complete with code 2.05
0000032252 [comm.protocol] INFO: Received TIME response: 1575147734
0000032252 [comm.protocol] INFO: rcv’d message type=12
0000032607 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000032607 [comm.protocol] INFO: message id 4071 complete with code 0.00
0000032609 [comm.protocol] INFO: rcv’d message type=13
0000033889 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000033889 [comm.protocol] INFO: message id 4072 complete with code 0.00
0000033891 [comm.protocol] INFO: rcv’d message type=13
0000035109 [comm.protocol] TRACE: Reply recieved: type=2, code=0
0000035109 [comm.protocol] INFO: message id 4075 complete with code 0.00
0000035109 [comm.protocol] INFO: rcv’d message type=13
0000036240 [comm.protocol] TRACE: Reply recieved: type=2, code=128
0000036240 [comm.protocol] INFO: message id 4077 complete with code 4.00
0000036240 [comm.protocol] INFO: rcv’d message type=15
0000039241 [app] WARN: Telemetry did not send successfully.

It looks like

rcv’d message type=15

indicates an “error” but I haven’t been able to get any helpful debug information on it.

Hi @dcliff9 - would you mind sending me your Device ID and some timestamps of missing ACKs and I’ll take a peek in our backend?

Are you waiting for Particle.connected() to be true before publishing? With SYSTEM_THREAD(ENABLED), if you publish before connected, and it takes more than 20 seconds to connect, Particle.publish will return false (20 second timeout), but also there’s a good chance the event will still go out after that.

Unfortunately yes. Our current setup is a state machine in which once Particle.connected() is true, we wait for a valid time from the cloud to set our internal time. Only then do we we publish.

Just for kicks, I have also tried hard coding some soft delays (with Particle.process) on both sides of the publish after Particle.connected() and before disconnecting. Tried as high as 60 seconds for my own sanity. Doesn’t seem to alleviate the issue.

Just to be sure: Are you calling Particle.publish from a thread other than the loop thread? The publish works but the future does not and there’s a special technique you need to use to retrieve the future value from a worker thread.

It is in a call chain that derives from loop().
FYI, Marek had me open a support ticket. (Ticket 85172)

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.