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

configurable keepalive #913

Merged
merged 2 commits into from Mar 23, 2016

Conversation

@m-mcgowan
Copy link
Contributor

commented Mar 17, 2016

adds Particle.keepAlive(seconds) for UDP comms platforms (Electron) to allow the application to set the frequency that ping keep-alives are sent.

Example:

void setup()
{
   Particle.keepAlive(60*23);  // send keep alive ping every 23 minutes
}

A keepalive ping uses ca. 100 bytes of data.

Provides a solution for issue that users with 3rd party SIM's were seeing, certain carriers may have slightly quicker network timeouts, requiring a more frequent ping interval than every 23 minutes (which is the default).

@m-mcgowan m-mcgowan added this to the 0.5.x milestone Mar 17, 2016

@m-mcgowan m-mcgowan referenced this pull request Mar 17, 2016
17 of 17 tasks complete

@m-mcgowan m-mcgowan force-pushed the feature/ping_configuration branch from 523848f to 82fc113 Mar 17, 2016

@elijthomas

This comment has been minimized.

Copy link

commented Mar 17, 2016

If this uses 100bytes of data , that means the 1mb data cap will be used in approx 10000 keep alive calls . Which if set at 30 seconds will only be about 3 days. Is this correct ??

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Mar 17, 2016

1Mb isn't a hard cap, but yes, that's the ballpark for the data use. Please keep in mind that this isn't an issue with Particle SIM cards, which require only 3 pings per hour.

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Mar 17, 2016

It is possible to reduce the data usage considerably - possibly by a factor of 5 by sending a plain UDP packet rather than an encrypted DTLS packet. I am on vacation for 2 weeks this weekend, but will look into this when I return.

@bprobbins

This comment has been minimized.

Copy link

commented Mar 18, 2016

@m-mcgowan Very nice! Seems to solve issue #888 (electron stop mode sleep) for me - just set Particle.keepAlive(1320);//22 minutes. Any special steps we need take in code in the event the ping is unsuccessful (e.g., cloud reconnect)?
Edit: 22 minute pings stopped working for me. Had to use a keepAlive (600) //10 minutes to keep it working > 12 hrs

@technobly

This comment has been minimized.

Copy link
Member

commented Mar 18, 2016

I edited the example to keep people from immediately copy/pasting such a short ping rate into their apps. I realize this is not the Docs, but could easily make its way there as well.

adds `Particle.keepAlive(seconds)` for UDP comms platforms (Electron)…
… to allow the application to set the frequency that ping keep-alives are sent.

@technobly technobly force-pushed the feature/ping_configuration branch from 82fc113 to be6ea7e Mar 20, 2016

@technobly

This comment has been minimized.

Copy link
Member

commented Mar 20, 2016

I rebased against latest develop and forced pushed, so that we could test with NETWORK_STANDBY.

@bprobbins

This comment has been minimized.

Copy link

commented Mar 20, 2016

In my very unsystematic testing so far, I've found that the longer the stop mode sleep interval the more frequent I have to ping to enable publishing beyond 3- 6 hrs, or so it seems, With sleep interval of 30 mins, pings every 10 mins allows continued publishing longer than 12 hrs. However, if I ping every 19 mins, publishing fails in about 3 hrs
With sleep interval of 2 hrs and pinging every 10 mins, the startup publish and first wakeup publish at 2 hrs succeeds but fails after that (4 hrs).
This is the test app I used:

#include "Particle.h"

char publishStr[20];
volatile uint32_t start;
volatile int sleepInterval = 120; // 30;

void setup() {
  pinMode(D1, INPUT_PULLDOWN);
  Particle.keepAlive(600);//10 minutes
}//setup()

void loop() {

  sprintf(publishStr, "%i", sleepInterval);
  Particle.publish("e1", publishStr, 60, PRIVATE);

  start = millis();
  while (millis() - start < 6000UL) {Particle.process();}

  System.sleep(D1, RISING, sleepInterval * 60); 

  start = millis();
  while (millis() - start < 6000UL) {Particle.process();}

}//loop

@bprobbins

This comment has been minimized.

Copy link

commented Mar 20, 2016

Particle.keepAlive(300) - pinging every 5 mins did work overnight to allow publishing every 2 hrs, but that's (12 * 100 * 2) data bytes to keep it going, a little more than I'd like

@technobly

This comment has been minimized.

Copy link
Member

commented Mar 20, 2016

@bprobbins are you using a Particle SIM or a 3rd Party SIM?

When you sleep, no pings will occur while the processor is halted. Pinging really should only keep the Server to Device connection active (i.e. Particle.function() calls, and Particle.subscribe() events). When you wake up, and publish... it should always be able to get through if your cellular data connection is still active. The data connection can timeout after about an hour (but could be longer as well), and we will be forcing it to disconnect if sleeping for longer than 1 hour in the future. Therefore if you currently sleep for more than 1 hour, when you wake up you should disconnect and reconnect to ensure your data connection is active. Technically if you know you are sleeping for more than 1 hour, you should make sure you turn off the modem to conserve power and network resources. It will undoubtedly not be connected when you wake back up anyway.

bool disconnected() {
    return !Particle.connected();
}

void loop() {
    Particle.disconnect();
    waitFor(disconnected, 60000);
    Particle.connect();
    waitFor(Particle.connected, 60000);

    // Read sensors here

    // Publish events here

    // No need for delays anymore (as of 0.5.x)

    // Sleep for 2 hours with network on (don't do this...
    // but as an example, loop() will force a disconnect 
    // and reconnect upon waking back up)
    System.sleep(D1, RISING, 60*60*2, NETWORK_STANDBY);
}
@bprobbins

This comment has been minimized.

Copy link

commented Mar 20, 2016

@technobly , I have definitely been on the wrong track then. So is the fact that the keepAlive frequency seemed to affect publish success just a strange anomaly? Last night when I increased the keepAlive to every 5 minutes I was able to publish every 2 hrs last night without fail (using the above code but with 5 min keepAlive and no reconnect provisions) when in a previous test with a 10 minute ping it failed after 1 publish ( http://community.particle.io/t/electron-not-publishing-after-sleep-stop-mode/20348/49 ). It's all over my head. Is issue #888 a whole different matter? Sorry if I've been misconstruing things!
I am using a particle SIM
Last night's test 5 min ping, publish every 2 hrs:
image

@bprobbins

This comment has been minimized.

Copy link

commented Mar 22, 2016

So, I finally must have invoked the right deity. My code above (but without keepAlive since as you say it's inactive) worked the past 24 hrs no problem (no change in firmware). I'm back in the right universe!

@monkbroc monkbroc force-pushed the feature/ping_configuration branch from 77a9243 to 8062d04 Mar 23, 2016

@monkbroc monkbroc merged commit 8062d04 into develop Mar 23, 2016

2 checks passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details
continuous-integration/travis-ci/push The Travis CI build passed
Details
@elijthomas

This comment has been minimized.

Copy link

commented Apr 7, 2016

How do you compile it with keepalive, I keep getting ''class CloudClass' has no member named 'keepAlive''. My Electron is running 0.5.0-rc.1. I have tried compiling using build.particle and the CLI, however build.particle says its still running 0.4.8, but if i check the device in the terminal using 'v' i get 0.5.0

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Apr 7, 2016

The version on the device and the version you compile with aren't the same thing. You'll need to select the 0.5.0 release against your device in the web ide. On the CLI, you pass a --target 0.5.0-rc.1 flag.

@elijthomas

This comment has been minimized.

Copy link

commented Apr 7, 2016

Thankyou @m-mcgowan, super fast response and greatly appriciated ! That is compiling for the correct release now. On a side note, you wouldnt know why two of my electrons show up on build.particle as photons ? can i force flash the 0.5.0-rc.1 onto them as electrons somehow ? if you can tell me that ill owe you a beer when I come to san-fran next.

@m-mcgowan

This comment has been minimized.

Copy link
Contributor Author

commented Apr 7, 2016

If you send me a PM or email with the device IDs of the electrons that have an identity crisis I'll get it sorted. It may take a few hours.

@elijthomas

This comment has been minimized.

Copy link

commented Apr 7, 2016

Thanks I have PM you the device IDs

@technobly technobly deleted the feature/ping_configuration branch Oct 27, 2016

@technobly technobly removed their assignment Dec 10, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.