Green Breathing When Idle

Hi everyone,
I’ve got a Photon connected to a few sensors, with code that reads from webhooks once every hour. It’s been working fine, but I just noticed that my Photon is breathing green at the moment rather than cyan. I’m between 1-hour cycles right now.
I don’t think I’ve got any code that disconnects me from the cloud; is there some sort of “sleep” mode the particle goes into if it doesn’t interact with the cloud for a long period of time?

I’ve not had any trouble connecting to the cloud, so I think a reboot of the device would probably bring it back to cyan, but I don’t want to do that because then I have to start over with the testing I’m doing with the device right now.
Because I’ve not really identified this as an urgent issue yet, I’m mainly just interested in learning a bit more about breathing green (I’ve read on the site/forums, but most of what I’ve found is just saying that it means no cloud connection).
So, what sorts of things can cause the Photon to breath green? What sorts of things can bring it back to cyan (with or without reboot, inside or outside of code)? Stuff like that. If there’s already an article that outlines all that, I’ll happily take a link, too!

Thanks everyone!

e.g. blocking code, which doesn’t allow loop() to finish regularly cause the cloud connection to drop out.
But there are also other possible reasons. Being able to have a look at your code might limit the possible answers.

I have a similar issue that I think I’ve narrowed down to a single webhook.

Breathing green means the Cloud maintenance functions (Particle.process()) haven’t run in a long enough period. These normally run at the end of each loop() and I believe during delay() calls but I’m not certain about the latter. This happens if your code gets stuck in a while loop for long enough and probably lots of other reasons as well.

A watchdog timer might be helpful here or even an external watchdog chip. You might even call Particle.process() in a software timer if your code is executing properly but you’re still getting the breathing green.

My concern with breathing green is it likely means the code isn’t running as intended so it’s an issue that needs to be solved. In my case, I think my webhook may occasionally return data that is not in the expected format or doesn’t read properly and causes some sort of unknown crash. However, like @bjjesteadt I haven’t spent the time to completely debug it yet.

@ScruffR, I’m happy to show code; however, it’s really long. What would you recommend as the best way to upload a lot of code from desktop IDE?

@bveenema, what exactly do you mean about the delays? Are you saying my webhook calls run whenever there’s a delay in my code?

Also, at this point I’ve changed my mind from “mildly interested” to “rather concerned,” because it has now “slept through” its expected hourly webhooks. I’ll try rebooting it at this point.

No. Particle.process() is called during delays.
https://docs.particle.io/reference/firmware/photon/#particle-process-
From the docs:

Particle.process() checks the Wi-Fi module for incoming messages from the Cloud, and processes any messages that have come in. It also sends keep-alive pings to the Cloud, so if it’s not called frequently, the connection to the Cloud may be lost.

Your webhook is triggered during calls to Particle.process() as this is when your device is retrieving data from the cloud.

This is the case for single threaded mode. With SYSTEM_THREAD(ENABLED) delay() does not need to attend to the cloud connection, so it’s disabled there.

I’d add a word here like: “My concern with inadvertent breathing green is …”, since breathing green might be a perfectly fine state when you only need WiFi connection but no Particle cloud.

1 Like

is it possible this is just a cloud issue right now? I rebooted the device and it’s now cyan; however the desktop ide says the compiler timed out.

Seems like two sides of the same coin, possibly?

Possible but not likely. A quick check of the Particle Cloud services shows everything is operational at the moment.

https://status.particle.io/

There could be a configuration issue on your network that prevents successful connection to the cloud, but if you’re on the same network you set up the device on that likely isn’t the case

You don’t need to upload the code. The easiest way to share code from the Web IDE, is to click on the “Share This Revision” button. This will give you a link that you can post here, which will allow forum users to see your code.

Unfortunately Desktop IDE doesn’t sport such a feature (yet - something similar is planned tho’).

For Desktop IDE you could use something like Dropbox or GitHub.

1 Like

Particle Breathing Green Tips

Breathing green mode can be confusing to new Particle programmers but fortunately it’s usually easy to recover from.

I can’t flash my Photon anymore

Breathing green means that Wi-Fi is on, but you’re not connected to the Particle cloud. Because of this, you cannot flash your Photon from the cloud. That includes Particle Build (Web IDE), Particle Dev (Atom IDE) and Particle CLI cloud-based flashing commands.

Fortunately, you can usually get around this by entering safe mode, breathing magenta.

Hold down RESET and SETUP (or MODE), release RESET and continue to hold down SETUP/MODE until the Photon/Electron blinks magenta, then release SETUP/MODE. The device will then go through the normal sequence of colors: blinking green, blinking cyan, fast blinking cyan, then breathing magenta. Once breathing magenta, you should be able to OTA flash again.

But to get rid of the breathing green, you’ll probably need to make some changes to your code.

Do not unclaim your device

This rarely if ever fixes anything, and it sometimes can make things much worse. Resist the urge to do this. It never fixes a blinking green problem.

Cause 1: Blocking the loop

In this simple program, you’ll breathe cyan, then about 10 seconds later, you’ll go to breathing green. Why? You’ve blocked the loop from returning, and in the default threading and system mode, that stops the cloud from being processed, which causes breathing green.

Don’t do this:

void setup() {
}

void loop() {

	// Don't do this: preventing loop from returning will cause breathing green
	while(true) {

	}
}

Of course your code probably has a more subtle bug than that. For example, if you have a function that’s called from setup or loop that never returns, that can cause problems.

Some libraries that deal with sensor hardware might behave strangely when the hardware is not available, which could cause a call to block forever as well.

Solution 1: Add some Particle.process() calls

One way to solve this is to sprinkle Particle.process() calls in code that blocks. You might do something like this:

void waitForSwitch() {
	while(digitalRead(D7) == HIGH) {
		// Without the following line, you'd go into breathing green
		Particle.process();
	}
}

In general it’s better to structure your code so it always returns from loop(), but if that’s not a viable solution, you can sprinkle some Particle.process() calls in your code.

Solution 2: Enable SYSTEM_THREAD

The other solution is to use SYSTEM_THREAD mode.

SYSTEM_THREAD(ENABLED);

You insert this at the top of your source file. What it does is run the cloud processing in a separate system thread, so if you block your loop, the cloud will still be serviced and you will stay in breathing cyan instead of going to breathing green.

The only thing to be careful is that when you do this, your loop code will run before connected to the cloud. One solution is to add this in your setup() code, before you do any Particle.publish calls:

waitUntil(Particle.connected);

You might also do something like this in loop():

if (Particle.connected()) {
	Particle.publish("myEvent", PRIVATE);
}

Side note: Wi-Fi only mode

While all of the causes above were unintentionally causing breathing green, you can also do it on purpose. Using the SEMI_AUTOMATIC or MANUAL system mode and only bringing up Wi-Fi and not the cloud will cause intentional breathing green. You would do this if you’re sending data to a local server and not using the cloud at all, for example.

5 Likes

@ScruffR I will do that in a bit here, thanks.

@ScruffR,
Here’s a link to my .ino file in google drive.
https://drive.google.com/open?id=1wRZAA8moTQ4YmlCvf0ioKPSnx83R370Y

At the moment, by the way, it’s breathing cyan. It hasn’t done green since this morning. I am still unable to flash code via cloud though; it’s telling me it timed out or encountered an error.

Some things I have seen in your code.

  1. Particle.variable() is a one-time call for any variable you want exposed to the cloud. These variables should be set up in setup() as early as possible.
  2. If you want your code to run for extended periods of time without reset or deep sleep, you should stay away from String and rather use char[].
  3. You should consider use of arrays and loops over code blocks that basically do the same thing just on a different set of variables
  4. Reduce the use of delay() which makes your code less responsive
  5. Particle.publish() events should be marked as PRIVATE
  6. Consider snprintf() over “stacked” Serial.print() blocks to make the code compacter and more readable

My top suspect for the green breathing issue is 2 and 1 is a missapplication of the function and hence needs changing.
The other points are mainly a question of style.

1 Like

Sounds good, thanks. I figured out why my code’s been throwing a “compiler timed out” error. I added a new particle.variable, and the variable name was more than 12 characters in length /:b

However, @ScruffR, upon moving my particle.variables into setup, the ones that reference floats no longer update? Any idea what that’s about? The variables themselves are declared above the setup block, and then their values are assigned in the loop block below.

Are the variables really floats? Particle.variable should be int, string, or double. See if changing the floats to doubles fixes the problem (though I don’t know why it would have worked before, when you had the Particle.variables in loop).

@Ric, that’s fair; they are actually doubles. I said float because that’s what the iOS app labels them.