Particle.publish() stops working for Boron

Troubleshooting
1

I opened this up as a ticket already and received a response suggesting to post it here. I have a suspicion that something is falling over on the server side BEFORE the server gets far enough along to echo an event, call my webhook, or otherwise leave some sort of evidence that it tried to run. It reminds me of an HTTP 500, which I would either see on the server error_log or through raw response headers.

Anyway, here’s what we are observing. We know the publish is going out (hourly). We know we are connected to cellular and to Particle. We know the call “worked” from the firmware point of view. But we also know that no event is generated, our webhook is not called, and absolutely zero bytes returned from the Particle server. The “zero bytes returned” is the 100% consistent signature of this issue when it happens.

Here’s what we see from the cellular side (AT&T 3rd party - with visibility through their portal):
Bytes 1803 Up ,0 Down
Duration 00:00:28

I’ve asked in the ticket for someone to check the logs (timestamp was included in ticket) to look for clues. Note that a hard power down and back up of the Boron resets the situation, then it runs fine (hourly cycles) for a number of hours, then falls into this “black hole”. My hope is that the answer lies in the Particle server logs.

One additional note, the way we “sleep” on the hourly cycle is:

        Particle.publish("spark/device/session/end", "", PRIVATE);
        Particle.process();
        Cellular.off();
        fuel.sleep();
        delay(10000);
        System.sleep({}, {}, 3540);
        // zzz...
        System.reset();
2

Have you tried something like this?

        Particle.publish("spark/device/session/end", "", PRIVATE);
        for(uint32_t ms = millis(); millis() - ms < 2000L; Particle.process());  // Allow time for background to clear send buffer
        Cellular.off();
        fuel.sleep();
        for(uint32_t ms = millis(); millis() - ms < 10000L; Particle.process()); // Different version of delay(10000)
        System.sleep({}, {}, 3540);
        // zzz...
        Cellular(on);  // To be sure modem is ON before reset
        for(uint32_t ms = millis(); millis() - ms < 1000L; Particle.process()); // Wait for modem to turn ON (??)
        System.reset();
1 Like
3

I’ve been testing the idea for a Boron to Sleep for an Hour and then Shutdown/Restart (after Sleeping) using the EN Pin, w/ a GPIO through a 22k resistor. I perform the Shutdown after an unsuccessful Manual Connection Attempt, or every 24 hours. No problems so far.


inline void softDelay(uint32_t t) {
  for (uint32_t ms = millis(); millis() - ms < t; Particle.process());  //  safer than a delay()
}

void setup() {  }
void loop()  {  }

void goToSleep() {
  // Step through the process safely to ensure the lowest Modem Power during Sleep.
  Particle.disconnect();  
  softDelay(2000);  
  Cellular.off();  
  softDelay(3000);                  
  System.sleep( {}, {}, sleepTime); // Make sure to sleep before performing the SHUTDOWN with EN Pin
  softDelay(5000);
  digitalWrite(shutdownPin, LOW);   // Full System Shutdown.
  System.reset();                   //Just in Case the shutdownPin wasn't connected to EN Pin, as a failsafe.  Should never reach this line of CODE.
1 Like
4

Thank you for these ideas. I will definitely try going to sleep more gracefully. The idea of a power recycle is also great. I was thinking that I needed to use a TPL5110/1 to do that.

Regarding the support ticket I have left the Boron in this strange hourly state where it sends bytes to the Particle server and receives 0 bytes in return in a hope of getting a reply from Support about what is happening on the server. Here’s the most recent:
image