Photon breathes cyan but is offline

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 (https://github.com/plan44/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
[/quote]

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.

vince…

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.

thanks
vince

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!

Thanks,
David

@Dave I am using AUTOMATIC mode with THREAD enabled, my device is offline but still breaths cyan, this happens sometimes, dashboard shows the correct status.

Sorry to chime in, but just to clarify

How do you check the "is offline" bit?
The info in dashboard/app is no relyiable indicatior if it is online or not.

Especially your "EDIT" in a previous post would suggest it's online but just not recognized as such properly.

For good error analysis an exact understanding of your actual problem (correct use of terms) is important.

1 Like

I’m not sure about the dashboard / other apps, but the CLI hits the API directly and presents the offline/online bit correctly. Can you check it there?

Thanks,
David

1 Like

@ScruffR Device offline means not connected to cloud, as Photon breaths cyan but I am not able to do OTA., this happens very rare.

And also my photon running MQTT client gets disconnected from server and no OTA update, dashboard shows disconnected state but still photon breathing cyan.

Not being able to OTA is no indicator for being offline either.
If your application firmware starves the cloud tasks of processing time you are technically still online but not responsive enough to perform a successful OTA update or other tasks while other online tasks (like variable retrieval or publish) might still work.

That’s an interesting observation @ScruffR. I’m seeing similar behavior like @trackdork in several Photons of mine. I’m running SYSTEM_THREAD(ENABLED), and I’m explicitly casting SYSTEM_MODE(AUTOMATIC). Even though it’s technically not necessary to call Particle.process() when you’re running automatic system mode, I’m still calling Particle.process() periodically throughout my loop application in an attempt to keep the cloud connection up to date. I’m always able to re-flash firmware to these Photons when they exhibit this strange behavior, but I dislike the idea of manually resetting the Photon to re-establish full connection to the cloud. I use Mobicle (made by Control Everything) as a platform to publish events, monitor variables, and observe system status of my Photons; when the Photon is in this cloud connection limbo state, I can’t access any of the Photons in the Mobicle app. I know that Particle isn’t responsible for 3rd party integrations like Mobicle, but I’d thought I’d mention as it’s pertinent to this issue.
Aside from manually pinging the cloud with Particle.process(), do you know of any tips to maintain full connection to the cloud?