Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Particle.keepAlive() API does not work #1482

Closed
technobly opened this issue Jan 27, 2018 · 3 comments · Fixed by #1536

Comments

@technobly
Copy link
Member

commented Jan 27, 2018

Bug Report

Expected Behavior

You can call Particle.keepAlive(30); at any time and it should ping the server every 30 seconds. The system should keep track of the last TX/RX time and compare against the keepAlive interval (which if changed to a shorter setting may kick off a ping).

Observed Behavior

No activity in the log output every 30 seconds as expected when keepAlive is set before we are connected to the Cloud.

Steps to Reproduce

  • Run the test app and observe the log output.
  • Fails to work in THREADED or NON-THREADED mode
  • Tested with system firmware 0.7.0-rc.4 and 0.8.0-rc.1

Test App

SerialLogHandler logHandler(LOG_LEVEL_ALL);

SYSTEM_THREAD(ENABLED);

void setup() {
    Particle.keepAlive(30); // send a ping every 30 seconds
}

Workaround

Call keepAlive after we are connected to the Cloud.

void loop() {
    static bool once = false;
    if (!once && Particle.connected()) {
        Particle.keepAlive(30); // send a ping every 30 seconds
        once = true;
    }
}

@technobly technobly added this to the 0.8.0-rc.3 milestone Feb 22, 2018

@ScruffR

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2018

Maybe the "expected" behaviour should be that you can call Particle.keepAlive() anytime (prior or after connection) or at least like Particle.variable(), Particle.function() and Particle.subscribe() before up to a few seconds after the connection and still work as expected.

@technobly

This comment has been minimized.

Copy link
Member Author

commented Feb 22, 2018

Expected behavior is just that, that you can call it any time and it just sets the ping interval. The system can keep track of the last TX/RX time and compare against the keepAlive interval (which if changed to a shorter setting may kick off a ping).

@technobly technobly modified the milestones: 0.8.0-rc.3, 0.8.0-rc.4 Apr 5, 2018

@kubark42

This comment has been minimized.

Copy link
Contributor

commented Apr 6, 2018

Agreed with @technobly that the expected behavior is that there be no race condition for setting the keepAlive interval. Once set anywhere in the code, this should be propagated and preserved.

On a personal note, I spent a while independently rediscovering this bug, including an hour spent debugging with Particle's tech support. The bug also exists in 0.6.4 and 0.7.0. Think the fix will be backported?

P.S. As a follow-up, I found that the workaround can be simplified by keeping the code in setup(), as follows:

void setup() 
{
  // .
  // .
  // .

  Particle.connect();

  // Wait endlessly until the Particle is connected
  while (Particle.connected() == false) {
  }

  // Set the keep alive time. If this is too short, we won't be able to contact the Electron from the
  // Particle cloud.
  // NOTE: THIS MUST BE DONE AFTER THE PARTICLE IS CONNECTED. The upshot is
  // that in MANUAL or SEMI_AUTOMATIC modes this needs to be called after
  // Particle.connect() is successful.
  Particle.keepAlive(30);

  // .
  // .
  // .
}
kubark42 added a commit to kubark42/docs that referenced this issue Apr 6, 2018
[Firmware.md] Document 3rd-party SIM issues
When multi-threading, a situation arises with `keepAlive()`. This is documented
on github, at particle-iot/device-os#1482.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.