I’m having an odd problem with electrons disconnecting.
I have a few (~10) of electrons in the field, set to report at 5-minute intervals. A handful of these (5) handshake regularly but either don’t report, or report intermittently. All 5 of these initiated a handshake in the last 8 hours (one just 20 minutes ago), but none are responding to a Ping.
Any idea what could be causing these units to fall off? I don’t think it is an issue with Keepalive (currently set to 500s), as these units report regularly on some occasions as well.
If the device actively reports to the cloud the keep alive setting is secondary, since the device will establish the connection in the process. However, with a "wrong" keep alive, the way back may be blocked prematurely, causing pings fail to reach the device as the UDP channel may have been closed by the provider already.
As of your main issue, we'd need to see some code.
Ok, and now it’s back! What is the code I should be posting to help figure this out? Just for reference:
The particle almost immediately connects and starts breathing cyan upon reboot. a handshake shows up on the particle console, but a ping returns no response, activating an onboard function returns no response, and schedule 5-minute interval data posts do not show up.
Unfortunately it wasn’t developed in the web IDE. it is in our Github, which I could share with you.
They periodically re-handshake, so they’re able to connect, they just don’t seem to be unreachable despite physical and 3rd party validation of connection (breathing cyan and Soracom).
You can post a link or PM it if you don’t what to share it publicly.
Have you tried with lower values keep alive?
Due to a bug in some versions before 0.8.0-rc.4 you need to reapply the keep alive value after each reconnect.
The best would be to setup a System.on() handler that reapplies the value each time cloud_status changes to connected.
PM’d @ScruffR, but wanted to keep the covnersation here alive as well in case it proves useful to someone else in the future.
I have not yet figured out the issue, but I’m now documenting another interesting issue around this. Below is a screenshot from 4:39 PM. As you can see, the Particle has just published data (and has continued to do so since), but the Ping is returning a failure. Attempting to run the functions on the right also return failures.
Those are the symptoms for an incorrectly set keep-alive. You have to set that in your user firmware for all 3rd-party SIM cards, as explained here.
Also, there’s a specific way you need to set it in certain firmware versions, or the change won’t take:
In system firmware 0.6.2 through 0.8.0-rc.3, there is an issue where the Particle.keepAlive value does not stay properly set. The workaround is as follows:
Create a global variable, such as:
bool hasSetKeepAlive = false;
And add this to your loop:
if (Particle.connected()) {
if (!hasSetKeepAlive) {
hasSetKeepAlive = true;
Particle.keepAlive(120);
}
}
else {
hasSetKeepAlive = false;
}
Basically, you need to set the keep alive only after successfully connected to the Particle cloud, and every time you’ve disconnected.
This solution works, but seemingly requires that I keep the keepalive ping 120 seconds or fewer (soracom’s idle time out is, supposedly, about an hour).
If I set the keepalive period to longer (say 5 minutes), when that interval comes, the indicator LED switches to rapidly blinking cyan and the particle disconnects.
It depends what they mean with "idle timeout"
The keep alive is used for UDP hole punching to keep the path between the device and the cloud open for UDP packets from the cloud to the device.
If I set the KeepAlive to a short enough interval that it doesn’t lose connection with the console everything is peachy, but that is relatively data intensive.
If I set this to a period which is long enough to lose connection with the console - say 600 seconds - the electron should reconnect and re-handshake on that interval, and then stay connected for a period. This doesn’t seem to be happening for whatever reason. Any ideas here?
