Photon functions and variables missing after no changes


I have a Photon that has been working fine until 4/8 late afternoon/evening. Today the same Photon is online and broadcasting events to the cloud, but all functions and variables are “missing”. Both on my custom mobile app and on going to the device it shows it is online but that there are no functions or variables (which cannot be true since the same variables are being published to the console! I’ve checked but everything shows good.

I had someone confirm that the Photon is breathing cyan as normal.

Any ideas?

[EDIT] Add more weird behavior. The Particle Android app shows the device as offline (I’ve logged out and logged in again and still shows offline.) But build web IDE shows it as online, and console shows it as online and streaming events.
The device firmware is 0.6.0.

I re-flashed the same code to the device (since build IDE sees it as online). NOW it is back online with functions and variables. But that doesn’t explain how they disappeared from an otherwise ongoing working device?

Exposed function not showing up on Photon

I am seeing the same thing today, as well as 2 days ago. The code is still executing, and sending data to Ubidots, but none of my variables or functions work from the CLI, nor do they show up when I do a Particle list. I’ve tried flashing from Dev and the web IDE. I saw this problem flashing two different programs to two different Photons, with code that has worked well for months. I had made small additions to the programs, but commenting them back out still resulted in the loss of my functions and variables after re-flashing.


Thanks, glad (and not) to see someone else is experiencing it. With your pointer I’ve now found the other thread discussing it. I had the same issue happen 2x more, and now it has been stable for a few days (as it was for months before). I don’t have any code in my setup before function/variable registration that could take more than 5 seconds so that doesn’t seem to be the problem.


Yeah, I’m still trying to figure out if when the the registration happens makes a difference or not. Are you running with SYSTEM_THREAD enabled?


It is not enabled for this Photon and code that I’m experiencing this issue with. I have it enabled on other devices where I have not experienced the problem. I take it you have it enabled and having the problem?

I really don’t have anything funky. Potential candidates if any may be antenna selection, use of product ID, I mention inclusion of math only since I had a problem that my code stopped working if I didn’t include it, and use of EEPROM. But I doubt, and this has been such a random occurrence on something that worked before. It seemed like registered functions were unregistered somehow…or my device powered down or had wifi issues and when reconnecting failed some registration aspect.


//For product management
PRODUCT_ID(1111); //ID changed for sharing 

#include "math.h"

/* Function prototypes -------------------------------------------------------*/
int tinkerDigitalRead(String pin);
int tinkerDigitalWrite(String command);
int tinkerAnalogRead(String pin);
int tinkerAnalogWrite(String command);

//variables omitted

void setup()
EEPROM.get(addressOffset, Offset);

if(!(Offset > -999.9)) { //Or checking that it is not nan (not a number)
  // EEPROM was empty -> initialize value
  Offset = -0.0000;
  EEPROM.put(addressOffset, Offset);
    //Register all the Tinker functions
    Particle.function("digitalread", tinkerDigitalRead);
    Particle.function("digitalwrite", tinkerDigitalWrite);
    Particle.function("analogread", tinkerAnalogRead);
    Particle.function("analogwrite", tinkerAnalogWrite);
  Particle.function("Calibrate1", calvalone);
    Particle.variable("ControlTemp", ControlTemp);
    Particle.variable("wifiStrength", wifiStrength);

void loop()


The same answer here as in the other thread

Put your registration of Particle.variable() and Particle.function() before anything else in setup() otherwise you might miss the registration window after connect.
You can’t register too early, but too late.


This isn’t in the docu.

I’ve got hundreds of them running, have been using them for 2 years and today is the first time (to my knowledge) that I’ve been sprung by this undocumented feature when a customer was asking why their temperature target wasn’t working. Seemed quite bizarre and asked them to repeat it and spotted a ‘Function XXXX not found’ in my logs. Placed function registration at the top and particle list particleID showed the full function list. A good opportunity to improve my log alerting for this situation.

@will Could someone please docu this please?
@ScruffR’s phrasing works for me!


PS, rather than crawling through firmware code, it’d be helpful to have an offhand confirmation of ScruffR’s point that registering cloud functions/variables can never be too early.

IE, if you register it at the start, is it absolutely going to register it in the distant future when it goes online? There may be WiFi waitfors, delays, wifi configuration thats wrong, etc etc, and finally magically goes online (for the half of the world that has old 20Mhz WiFi that is).


I have not encountered the problem again after moving the registration code right up front (although, I never experienced it before moving for probably a year plus either so not sure what happened to change…wifi router issues, cloud issues, photon hardware who knows!)

@mterrill with hundreds of devices and time frame sounds like the occurrence is rare and random from the user perspective, but nonetheless a big issue when it does occur.

So I’d concur with the suggestion to include something in the documentation about essential/important to do it first thing.


It’s not an official statemen by Particle, but how I know the system works is that with Particle.function(), Particle.variable() and Particle.subscribe() you fill the respective objects into the “cloud bucket/collection” of data. This collection lives independent of the state of the cloud connection in your device in system. So you can fill objects into this bucket at any time, BUT the device only ever informs the cloud of what’s in that bucket during the connection process (with some time window).

But while documenting this would be needed, having this behaviour extended to also allow late registration and targeted unregistration of individual objects would be more desirable (as proposed ages ago)


There was some new code in my last firmware that took advantage of waitFor etc so I had changed where the .connect() was. Still, beta testing over 2 months hadn’t picked it up. I was observing roughly 30% (very rough guess based on a full particle list) at the time. Placing cloud functions above connect fixes it for everyone.