Photon breathes cyan but is offline

I believe changes were recently made cloud-side to improve this. Let’s bring in @Dave, who surely has more on that!

Firmware side, I just added a fix so that if the cloud isn’t talked to within 15 seconds, the system automatically displays this in the LED (goes back to breathing green). That will rule out a potential source of inconsistency - when the cloud truly does become disconnected but the device is stuck in a loop and unable to update the LED to reflect the connection status.


I just got a Photon device a couple days ago, and used my iPHONE to activate it yesterday. It seems to be breathing cyan, but it is listed as offline on my iPHONE and in my Dashboard. I have tried to install it about 4 times now, exact same results. Really just regurgitating what everyone else is saying, except that this is a problem out of the box.

1 Like

Have you tried resetting the device? That may help bring it online.

1 Like

I have reset it several times. I have reclaimed it several times. Granted, I have only been playing with this for 8 hours over 3 days. I did notice something interesting… When I go into the DashBoard, the device is listed as off line, but the Last scene time stamp is correct. Infant, I am able to disconnect the power for about 20 seconds, re power it, and the DashBoard timestamp will refresh with the correct time. So I am able to confirm that the device is claimed by my account ( several times ), It is listed in dashboard, but with a brown dot. The Mobile apps also list the devices as off line.
So, my amateur theory is that the problem is in the cloud. The device is reporting that it is attaching but that is the end of what it is doing. Perhaps the device really is in off line mode? but I would imaging that the device would start running the tinker firmware at this point.

Perhaps I should confirm some issues.
1… The photon, out of the box, once it is claimed, should default to the tinker firmware ( true or false ).
2… The Photon, out of the box, once it has been claimed, should report as online ( true false )?
3… The photon, after it is claimed, should be breathing cyan ( true False ).

I ordered 3 more devices just for giggles to see if I can get something to work.

Any suggestions on what to do next?

The only thing I can think of is that the Wireless network is passing through an apple AirExtreme network device, which is attached to a CABLE MODEM HUB, which has wireless turned off. My provider is comcast. I am thinking of turning the hub back on to see if that is the issue.

I have tried alternative power supplies but I do not think that is the issue.

I would also like to suggest that someone at tech support look at my device ID and see if they can spot something interesting. I would list it online but I am not sure if that is safe. perhaps someone in tech support can email me?


You can PM your device ID to me, and I’ll take a look!

Following our test-fleet of Photons through their boot-cycles on the Dashboard, I’ve noticed the following issue:

Occasionally, the device comes online (publishes Device Online), then immediately publishes Device Offline, but continues to “breath cyan”. It appears as offline on Build, and through the CLI command particle list, however, I can still flash the device and call functions/variables.

Investigating further, I noticed that if I hit the Cloud at /devices the device will be listed with {connected:false}, but if I check the Cloud at devices/ITS_DEVICE_ID it will tell me it is connected.

So it seems like whatever is keeping track of the Photons’ online/offline state is getting messed up because of a faulty Device Offline publish.

Another annoying bug, is that the response JSON from devices/ITS_DEVICE_ID only contains the field last_heard when the device is connected, which is annoying for obvious reasons… :stuck_out_tongue:

Update -
Still experiencing this on the Photon (build V0.4.6), but not the Core. Both are connected to a T-Mobile wifi hotspot. It gets flakey occasionally (the hot spot), loses connections from time to time, and sometimes even shuts itself off.

Sometimes the Core has a problem reconnecting and I’ll have to power cycle it. Sometimes but more rare the Photon will have problems reconnecting too, flashing cyan and require a power cycle.

Currently and occasionally, the Photon is breathing cyan and shows connected to wifi hotspot (per the hotspot), but the hotspot is not connecting to the internet. The Core is correctly flashing cyan as it tries to connect to the cloud but fails.

Node.js Particle list correctly shows both offline.

Note - after restarting wifi hotspot - Core reconnected to cloud, but Photon still breathing cyan and never showed reconnecting to hotspot. Need to power cycle Photon for it to reconnect.

1 Like

I’ve been tracking this issue as well - I have both the original Core and a newer Photon, both running identical code. After a short (indeterminate) time of running, Photon shows as “offline” in both Node.js as well as in my android control app (but still breathing cyan) until reset via button or power cycle. Curiously, the published functions continue to work regardless, and flashing via web still works too. Frustrating trying to work around this.

Which version of system firmware is installed on both units? This could be caused by the loop() function blocking code for more than 10 seconds. With 0.4.6 firmware, we detect this and change the LED color to indicate the cloud has been disconnected.

I’m glad I checked, I assumed both were on 0.4.6 firmware, but actually the Core is running 0.3.6 and doesn’t go offline, while the Photon is running 0.4.6 and does. I can’t get to the unit until later to see if the LED shows the cloud as disconnected, but if that were the case would flashing OTA still work? I can still call functions if I ignore the fact that it is offline and can always push a new build to either system.

As for the software functions; loop() is doing a lot of work but it couldn’t be blocking for any length of time or the code wouldn’t do what it is supposed to. In this particular case I’m running a lightly-modified but for all intents and purposes stock version of MessageTorch ( as part of my Halloween decorations, so you can take a look at the code to see what is happening inside loop() if you’re curious.

If you can still call functions, then the device isn’t really offline, even though the cloud says it is. OTA updates should still work also. cc: @Dave

[quote=“mdma, post:25, topic:15121, full:true”]If you can still call functions, then the device isn’t really offline, even though the cloud says it is. OTA updates should still work also. cc: @Dave

I guess that’s what I’m trying to say - the device lists as offline on the Web IDE, CLI, Android API, and everywhere else, even though I can OTA, call functions, monitor variables, etc. The main headache is the android API because it throws exceptions when trying to call functions on an offline device, checked real-time.

Just to clarify in my case the photon is not connected, not publishing, and as best I can tell, not running my code.

Thanks, I definitely don’t want to lump these things together if they aren’t related. My user code is humming along, so intensely in fact (pushing data out as fast as possible over SPI) that it’s almost never not doing something.

Looking at the actual SPI transfer functions, there is a call to __disable_irq(); immediately prior to the data transfer, followed by an __enable_irq(); This is getting called very frequently, transferring 300 LEDs worth of data over WS2812. Might this be affecting the background Photon processes?

I might add some kind of heartbeat event just to test the ability to publish data.

One more data point - publishing events is unreliable from both the Core and Photon. “Status” events are transmitted every 5 seconds, but only appear to make it to the cloud every 10-30s from either… Dashboard shows 2 events from the Core for every 1 from the photon… and then the photon goes offline and stops sending the events.

However, using CLI to “monitor” a variable on each system in a 5 second loop results in more consistent event publishing and neither system showing offline. Going on an hour now with both listed online as expected.

(edit: typo - both systems are still online, somehow external polling keeps the cloud on life support)

Hey dave… I resolved the problem as you suggested. I cam cup with a little trick as well that was not documented. I would document this trick ( which I kind of forget how to do but can review notes ) if I was confident that you have more issues like this out there in the field. If there are no devices with old firmware out there, then probably not worth the effort.


I am submitting more questions if you get a chance to look at them… basically, I want to see if I can add an RFID reader and a GPS. any samples. Any examples for mifare tags?

I am also interested in distance data for WiFi… and if I can increase the distance. Ideally, I do not mind a slow network but I would like to get a mile or half mile transmit receive… even if I have to add an antenna.


Just saw something similar again today with a Photon running 4.7. Breathing Cyan and showing offline on one API endpoint but online in others. Posted here:

Hi, Facing same issue my photon is breathing cyan but is offline in my dashboard and android Particle app.
Last connection time Feb 28th 2016 at 6:56am me from India.

And one more thing Particle.connected() is returning true coz then only my photon gets connected to my MQTT broker and its connected right now.

My firmware 0.4.9

EDIT: I tried flashing firmware OTA and it worked, seems photon is connected but dashboard and android app not showing proper state.

Ping @Dave for some insight into what’s happening cloud side.

1 Like

Hi @blackadmin,

Make sure you’re calling Particle.process enough if you’re not running in automatic mode. The online / offline state changes based on if your device is responding to pings from the cloud, but the cloud will still try to send commands anyway in the event that isn’t working to help recover from this kind of scenario.

I hope that helps!