# Long Term Photon Connection Stability **URL:** \ **Category:** Troubleshooting\ **Created:** [July 29, 2015, 5:40pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925 "2015-07-29T17:40:07Z")\ **Posts on this page:** 20\ **Page:** 5
**Author:** ![Quentin](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/quentin/32/5602_2.png) [@Quentin](https://community.particle.io/u/Quentin)\ **Post date:** [September 24, 2015, 6:00pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/81 "2015-09-24T18:00:25Z")
I’m also having Photon stability issues - just posted here : [Cloud stability and Core / Photon differences](https://community.particle.io/t/cloud-stability-and-core-photon-differences/15926) 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. ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [September 24, 2015, 7:25pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/82 "2015-09-24T19:25:56Z")
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? ---
**Author:** ![wmjenk](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/wmjenk/32/6734_2.png) [@wmjenk](https://community.particle.io/u/wmjenk)\ **Post date:** [September 24, 2015, 7:45pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/83 "2015-09-24T19:45:44Z")
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. ---
**Author:** ![wmjenk](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/wmjenk/32/6734_2.png) [@wmjenk](https://community.particle.io/u/wmjenk)\ **Post date:** [September 24, 2015, 7:49pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/84 "2015-09-24T19:49:24Z")
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. ---
**Author:** ![ljd2](https://avatars.discourse-cdn.com/v4/letter/l/f19dbf/32.png) [@ljd2](https://community.particle.io/u/ljd2)\ **Post date:** [September 24, 2015, 8:30pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/85 "2015-09-24T20:30:04Z")
@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. ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [September 25, 2015, 2:50am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/86 "2015-09-25T02:50:49Z")
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. ---
**Author:** ![potatotron](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/potatotron/32/7097_2.png) [@potatotron](https://community.particle.io/u/potatotron)\ **Post date:** [September 25, 2015, 8:06pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/87 "2015-09-25T20:06:13Z")
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](http://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. ---
**Author:** ![ljd2](https://avatars.discourse-cdn.com/v4/letter/l/f19dbf/32.png) [@ljd2](https://community.particle.io/u/ljd2)\ **Post date:** [September 25, 2015, 10:53pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/88 "2015-09-25T22:53:14Z")
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). ---
**Author:** ![wmjenk](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/wmjenk/32/6734_2.png) [@wmjenk](https://community.particle.io/u/wmjenk)\ **Post date:** [September 26, 2015, 2:26am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/89 "2015-09-26T02:26:27Z")
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. ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [September 26, 2015, 3:45am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/90 "2015-09-26T03:45:12Z")
> [@ljd2](#): > > but am assuming that the Photon OS provides the heartbeat, not the app? 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. ---
**Author:** ![ljd2](https://avatars.discourse-cdn.com/v4/letter/l/f19dbf/32.png) [@ljd2](https://community.particle.io/u/ljd2)\ **Post date:** [September 26, 2015, 4:50am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/91 "2015-09-26T04:50:31Z")
Great … thanks @mdma … missed this before, but it helps my understanding. Thanks again, Larry ---
**Author:** ![wmjenk](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/wmjenk/32/6734_2.png) [@wmjenk](https://community.particle.io/u/wmjenk)\ **Post date:** [September 26, 2015, 1:01pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/92 "2015-09-26T13:01:55Z")
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. ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [September 26, 2015, 5:05pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/93 "2015-09-26T17:05:55Z")
Yes. loop() exit or delay() must be called at least every 15 seconds for the cloud connection to remain active. ---
**Author:** ![wmjenk](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/wmjenk/32/6734_2.png) [@wmjenk](https://community.particle.io/u/wmjenk)\ **Post date:** [September 26, 2015, 5:12pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/94 "2015-09-26T17:12:05Z")
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 ---
**Author:** ![wmjenk](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/wmjenk/32/6734_2.png) [@wmjenk](https://community.particle.io/u/wmjenk)\ **Post date:** [October 2, 2015, 8:14am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/95 "2015-10-02T08:14:46Z")
@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 ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [October 2, 2015, 8:20am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/96 "2015-10-02T08:20:07Z")
The problem is that you’re passing a boolean pointer to a function that is expecting an int pointer. The type of the variable is `INT` and so should be your local variable. change `bool` to `int` and the problem will disappear. As it was, the system would be using 4 bytes for the variable value, yet in RAM the application was only allocating 1. Depending upon the data before and after, you could end up with a very unusual variable value. The new compiler checks are there to prevent this. The system threading behavior is described in the docs where you’ll find the answer to your question about maintaining the cloud connection. [https://docs.particle.io/reference/firmware/photon/#system-thread](https://docs.particle.io/reference/firmware/photon/#system-thread) ---
**Author:** ![wmjenk](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/wmjenk/32/6734_2.png) [@wmjenk](https://community.particle.io/u/wmjenk)\ **Post date:** [October 2, 2015, 8:36am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/97 "2015-10-02T08:36:55Z")
Thanks, makes sense, I had borrowed the offending code from SparkFun’s example on how to use the MAX17043.h and thanks for the link. ---
**Author:** ![legoguy](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/legoguy/32/7408_2.png) [@legoguy](https://community.particle.io/u/legoguy)\ **Post date:** [October 23, 2015, 7:37pm UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/98 "2015-10-23T19:37:52Z")
As of 0.4.7, I have had this “rapid flashing cyan” situation pop up twice – once in SEMI\_AUTOMATIC mode, the other in AUTOMATIC mode. It just sits there forever, only to be fixed by power cycle or reset button. My RSSI was around -71 (not that great), and I have a feeling it just dropped the connection and encountered some kind of block while trying to reconnect. - I’m using `SYSTEM_THREAD(ENABLED);` - I’m using Retained memory: `STARTUP(System.enableFeature(FEATURE_RETAINED_MEMORY);` - While the fast-flashing-cyan is taking place, my Application is still running (an interrupt is flashing an LED along with the rotation of my anemometer, as designed) - I have a `TCPClient` (to send data to Weather Underground) that currently does not check the wifi or cloud status before trying to establish its own connection, maybe I should change that. I _do_ have code that kills any existing connection to WU if it takes longer than 5s to receive a reply, but I don’t think my application would be getting to that point if a connection failed to establish in the first place. Is this still considered to be a system firmware issue (getting stuck on fast-flashing cyan)? (ping @mdma for good measure) ---
**Author:** ![legoguy](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/legoguy/32/7408_2.png) [@legoguy](https://community.particle.io/u/legoguy)\ **Post date:** [October 24, 2015, 12:29am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/99 "2015-10-24T00:29:20Z")
Apparently I was incorrect. The first time that this happened after installing 0.4.7, the device locked up rapid-flashing cyan as described above. Now that I’ve had a chance to come home and look at the state of the Photon after its second lock-up, it looks as though this time it was a rapid-flashing-_green_ lockup, if that means anything. ---
**Author:** ![mdma](https://sea2.discourse-cdn.com/flex026/user_avatar/community.particle.io/mdma/32/1924_2.png) [@mdma](https://community.particle.io/u/mdma)\ **Post date:** [October 24, 2015, 1:54am UTC](https://community.particle.io/t/long-term-photon-connection-stability/13925/100 "2015-10-24T01:54:53Z")
Thanks for the update! The color change really helps. I will look to add measures to detect these long wait times and try to kick start the system to reconnect. The fast flashing green means it’s trying to resolve an address with the AP. These are things outside of our direct control, but we can at list detect it’s taking a while and try to kick start the Wifi subsystem! 😄 [Previous page](https://community.particle.io/t/long-term-photon-connection-stability/13925.md?page=4) [Next page](https://community.particle.io/t/long-term-photon-connection-stability/13925.md?page=6)