Long Term Photon Connection Stability

I made a test app that was

void loop()
{
   WiFi.RSSI();
}

It ran for hours without issue. Please double-check on 0.4.5 since connection stability was specifically addressed in that release.

I totally agree - hard resets should not be necessary.

1 Like

The only thing I might add to the discussion (and to my earlier comments) @mdma is that the issue for me wasn’t a basic app (Tinker in my case) running for hours without issue. This was not a problem. The issue was running for days without encountering the fast flashing cyan, thereby requiring a hard reset. (I believe others have posted similar observations on other threads).

As mentioned, that was all with 0.4.4 … I’ve recently switched to 0.4.5 and am trying it again (with the Weather Shield and Phant posting app as previously mentioned). So far so good for about 36 hours.

To your last comment … is it a reasonable expectation (or the goal) that the device should be able to maintain a persistent cloud connection indefinitely?

I am using 0.4.5. Ok, so I don’t think that WiFi.RSSI() is causing the problem. I am using a Photon in a SparkFun battery shield along with an Adafruit SI1145 UV breakout board(I2C) along with a SparkFun soil moisture probe (analog read) and a SparkFun soil temperature probe(Dallas-OneWire)-no parasitic power. The program takes sensor readings then prints out values to the serial line which is also printing out upload communication data/success, then uploads data to Phant (SparkFun), then uploads the same data to Dweet.io. After about 6-8 times through the loop it goes into flashing cyan and requires a hard reset. If I include WiFi.RSSI() readings and include them in the data stream it does not seem to affect the number of times through the loop before failing with flashing cyan. However, one interesting data point is that the WiFI.RSSI() value is around -59 until the last successful upload set where the WiFi.RSSI() reading is 2. At this point it flashes cyan. I believe the problem is related to uploading to two separate servers.

For this program and hardware I can get around the problem by putting it into deep sleep after a data upload. It wakes up and then uploads correctly as I never get the flashing cyan after one data upload to both servers.

Unfortunately, I see the same problem when trying to upload data from the SparkFun Photon Weather Shield to two separate servers. I can’t use deep sleep with the weather shield as I am continuously collecting rain, wind, and wind direction data. The flashing cyan is a show stopper in the weather shield-for the time being I am limited to uploading to a single server (Wunderground) and that does seem more stable.

@mdma, So my SparkFun Photon Weather Shield has been running a little less than 24 hours uploading ONLY to Weather Underground every 5 minutes and not uploading to www.dweet.io and NOT using WiFi.RSSI(). About two hours ago it stopped uploading to Weather Underground, it also does not show online via Build or Dev yet the Photon is STILL breathing cyan. The only way to get it back showing in Build or Dev and uploading to Weather Underground is a hard reset. Gosh this is frustrating, Any advice on how to keep these Photons online continuously? BTW, I have seen the breathing cyan but not available via Build or Dev and not uploading data several times in the past week. Do I need to program in a hard reset every 12-24 hours? Given it is a weather station and will be deployed outside not in a convenient location for manual resets there really needs to be a solution here. Better stability or some remediation programming on my part. Suggestions welcome.

I have a Photon sending data to an emoncms server every 10 seconds and it currently has 11 days uptime since the 0.4.5 release.

Is it possible a memory leak or something similar in your code is causing the failure?

I’m also having Photon stability issues - just posted here :
Cloud stability and Core / Photon differences

My Photons don’t seem to have problems reconnecting to the network, and I don’t know if they actually lose the WiFi or if the cloud goes down. I’m running 0.4.5.

In 0.4.6, the device will detect if it cannot talk to the cloud and will change the status LED. Do you see any other kind of activity that indicates loop() is still working?

Good question, currently when the weather station is deployed I can’t connect a usb line so I can monitor serial output so the only evidence of loop function is successful data upload. I could add blinking D7 to the loop so when it get’s to the breathing cyan but not uploading or showing up in Build or Dev as online it would indicate if the loop is working. I can visualize the Photon without disassembling the weather station so that might work.I will post my results once the test is completed.

It is certainly possible but I doubt it. Most of the code is from the SparkFun Photon Weather Shield Guide and most of that code has been around for some time in various forms. The only thing I am doing differently is uploading data from all sensors to Weather Underground using the TCP client calls.

@mdma, re: your 0.4.6 comment, can you discuss what will be displayed with the status LED that is different from current indications? I have assumed that sustained fast flashing cyan (connecting to the cloud) is already an indication that a device cannot connect. Is this a misunderstanding on my part? Can you describe the proposed distinction between fast flashing cyan any any new indications? Thanks.

The distinction is that the device can show breathing cyan when it is infact offline. This can happen if the main loop is blocked, so that the system cannot service the cloud connection. When the cloud isn’t sent a regular heartbeat, it will disconnect. The change in 0.4.6 makes it visible that the device is now disconnected by reverting to breathing green until a connection can be re-established.

In a nutshel, it helps ensure the connection status on the LED more closely reflects reality even if the device is stuck in an infinite loop. This is a separate issue to when the device is blinking cyan.

2 Likes

I apologize if I’m threadjacking but I think I’m having a similar problem. I have a Photon that’s running some basic LED blinking code to make sure it runs OK long term. dashboard.particle.io says the device went offline Sep 24th 2015 at 4:58 am (US Pacific) and the CLI ‘particle list’ also shows offline, but the Photon is still happily blinking the LEDs, the Photon status LED breathes blue like normal, it responds to ping, and “particle get (device) (var)” returns valid data (I’m publishing uptime, which I can see increasing on each call, and an analog pin reading of a temp sensor, which seems to be accurate).

I flashed it with 0.4.5 last weekend. It ran for about a day before going offline like above (e.g. reporting offline but seemingly OK) so I rebooted in case it was a fluke. I can reboot again but thought I should check to see if you want me to try anything else first.

Thanks for elaborating on the 0.4.6 status LED indication @mdma, for clarifying breathing vs. blinking cyan … (and for pointing out we may be mingling a couple of different issues here). My line of comments/questioning has been related to those instances of a non-blocking app (Tinker?) where there is a random loss of cloud connection, and failure to auto-reconnect (blinking cyan). (I do realize your last post indicates a different failure mode … one where the app is preventing the re-connect).

I need to learn much more about this, but am assuming that the Photon OS provides the heartbeat, not the app?

(Updating my earlier post, the 0.4.5 Photon I currently have running on the SF Weather Shield, posting to Phant, is still humming along well at 100+ hours now with no disconnects. Longest interval I’ve gone for so far … encouraging).

1 Like

Just to follow up on my SparkFun Photon Weather Shield and breathing cyan when it is in fact offline. I added a blinking of D7 for one second to the loop just before it updates weather sensor data. It now has been up for about 24 hours without loosing a cloud connection, the longest so far. I will continue to monitor.

That's correct. So long as loop() is being exited, or delay() is called, then the photon can send the heartbeat. With multithreading, the heartbeat will always be sent independently of what the app is doing.

Great … thanks @mdma … missed this before, but it helps my understanding.

Thanks again,
Larry

Does that mean there must be a delay() in the loop (or exiting the loop()) currently or is multithreading in place with 0.4.5 or is multithreading part of a future release? If multithreading is not yet in place that might explain why adding a 1 second blink of D7 is allowing my weather shield Photon setup to remain connected to the Cloud. I am now at about 36 hours and two night cycles (it’s solar powered) and it is still blinking and uploading.

Yes. loop() exit or delay() must be called at least every 15 seconds for the cloud connection to remain active.

I did not know that, I bet several others with cloud connection problems aren’t aware of this either. Will multithreading be added at some point in the future? Thanks

1 Like

@mdma, So with firmware 0.4.6 that was just released I presume with a separate system thread, loop() exit or delay() DOES NOT NEED TO be called at least every 15 seconds for the cloud connection to remain active. Is that correct? Also after updating to 0.4.6 I get a cloud boolean error for alert-it previously worked in earlier firmware versions, code snippets below

"#include “SparkFunMAX17043.h” // Include the SparkFun MAX17043 library
double voltage = 0; // Variable to keep track of LiPo voltage
double soc = 0; // Variable to keep track of LiPo state-of-charge (SOC)
bool alert; // Variable to keep track of whether alert has been triggered

Spark.variable(“voltage”, &voltage, DOUBLE);
Spark.variable(“soc”, &soc, DOUBLE);
Spark.variable(“alert”, &alert, INT);

Perhaps there is a problem now with the SparFunMAX1703 library??

Thanks,
Bill