to save battery we want the photon to deep sleep as much as possible. the 0.6.1 Particle.publish option WITH_ACK should finish the publish before returning according the documentation. but the code below does not publish anything (most of the time, on occasion it will publish). only when i add back the 3 seconds delay it will consistently publish the event.
we do see the publish taking much longer (> 100 ms) with the WITH_ACK compared to without (< 10 ms).
are we doing something wrong? what more do we need to “flush” the publish?
I just had a similar experience with Mesh devices (running 1.1.0 and 1.2.1-rc.2)
Hence I would renew my assessment given back in May 2018 that the issue was closed prematurely. @BDub, although tagged back then there was no further comment from Particle’s side in the issue linked above (#1165).
Particle.publish returns a “future” bool and doesn’t actually block until the return value is accessed. Something like the following will result in expected blocking behavior without requiring explicit/arbitrary delays.
Then it would also be good to get a cross-reference to any of the functions that could potentially “harm” the functionality (e.g. WiFi.off(), Mesh.off(), System.sleep(), …) and samples how to deal with them.
See this discussion
I also tried WITH_ACK (instead of delay()) to prevent Mesh.off() from cutting the connection before the event was sent, but that didn’t help.
How would one go about this?
Since this issue affects Mesh endpoints ability to publish, wouldn’t it be wise for @will to add it to the list of Gen 3 known issues? Maybe we can get a top-down approach addressing the problem (or at least documenting it).
Would using waitUntil or waitForalong with a bool test successfully block until the publish is complete?
I’m just not clear on how I can check the truthiness of Particle.publish if it returns a future bool and I want to have code that runs contingent on the outcome of its success (such as turning off the radio).
Do I need to save the bool first, then run something like a waitUntil? From what @joel is describing, if Particle.publish is not immediately checked it will not block, and waitUntil may not return until the future event has complete and thus is unable to block if used alone. So something like this:
If you write the result into a (classic) bool the assignment causes the blocking and the following if statement is executed after the fact.
If you use a “future bool” by using auto instead of bool you can execute some code between the assignment and the value check. If the value is already present by the time your “in-between code” was executed not further blocking will occure, but if the “in-between” was faster the blocking will occure at the check, till the value materialises.
BTW, waitUntil() does not take a boolean as input parameter but a function pointer to a function that returns a bool and takes no parameters.
e.g taking waitUntil(Particle.connected) means to “repeatedly” execute the function and wait for it to change from known false to known true.
But with Particle.publish() it’s a different situation - there you start of with “not yet known” to true or false respectively - waitUntil()/waitFor() are not meant for such a scenario.
You just have to check the return value coming out of the Particle.publish in some fashion. You can do so in a blocking fashion (by accessing it as a standard bool) or in a non-blocking fashion (by accessing it via the underlying Future).
See code snippets already posted in this thread for examples of both methods. Choose one and adapt as necessary to your code.