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.


I’ve just done a minor change to my code. My variables are defined at the very beginning of setup.
Now for some reason the variables and functions have vanished from the console.
I seriously don’t get it. I’ve picked up the photon after a year or more to do a project and now realise why I dropped it back then.


I’ve not encountered this problem again. What device firmware are you using? Maybe share your code.
You still have this even after restarting the device? There is/was some degraded service today so maybe check once fully resolved, although it seemed limited to Electrons not Photons.


Well, it’s still doing it.
Its a simple program, sending data to thingsboard most successfully I might add - thanks to another contributor.
However - this starter bit of code requires real data and not the random generated stuff.
So - I added a bit of serial UART code, which didn’t seem to be working ( removed from this snippet ) and put some particle variables in to monitor stuff.

There are two issues -

  1. The Console now ( still ) does not show the variables, where as it did a few hours ago. It suddenly stopped displaying.

  2. There’s a third variable that has been commented out - it causes a compile error :-
    ./wiring/inc/spark_wiring_cloud.h:83:25: call of overloaded ‘_variable(const char [7], const unsigned int&)’ is ambiguous

My code, less the token is attached.
I’ve restarted the photon several times, recompiled, reloaded and restarted the console.
It’s been a struggle today!

//  Last update:  04/15/18
#include <PubSubClient.h>

#define TOKEN           "MYTOKEN-OF-COURSE"
#define LED             7
#define MQTTPORT        1883

char aquabuffr[128];
char aquabuf[128] = "aquabuf";
char* aquabufptr;
unsigned int aquabufindx;
//unsigned int countrry;   // THIS GIVES A COMPILE ERROR  -  see below
char serdata;

char thingsboardServer[] = "";
char attributes[] = "{\"firmware_version\":\"0.7.0\",\"software_version\":\"1.0\"}";
char mqttPub[128];
TCPClient pubsub;
PubSubClient psClient((Client &) pubsub);

void setup(void) 
//    Particle.variable("countr", countrry); // THIS GIVES A COMPILE ERROR  -  see above
    Particle.variable("buff", aquabuf);
    Particle.variable("serial", serdata);  
    pinMode(LED, OUTPUT);

    psClient.setServer(thingsboardServer, MQTTPORT);
    snprintf(mqttPub, sizeof(mqttPub), "%s", attributes);
    psClient.publish("v1/devices/me/attributes", mqttPub);

void loop(void) 
    if (!psClient.connected())

void sendTemp(void)
    float t = 630;//sensor.readTemperature() * 1.8 + 32.0;  
    float ec = 8.5; //sensor.readHumidity();
    float ph = 8.5; //sensor.readHumidity(); 
    float flow = 8.5; //sensor.readHumidity(); 
    t = randoma (17,25);
    ec = randoma (0,2000);
    ph = randoma (1,15); 
    flow = randoma (3,40);     
    // Prepare JSON payload
//    snprintf(mqttPub, sizeof(mqttPub), "{\"temperature\":%.2f,\"humidity\":%.1f}", t, h);
     // Prepare JSON payload
    snprintf(mqttPub, sizeof(mqttPub), "{\"temperature\":%.2f,\"conductivity\":%.1f,\"pH\":%.1f,\"flow\":%.1f}", t, ec,ph,flow);   
    // Send payload
    psClient.publish("v1/devices/me/telemetry", mqttPub);               // Topic, payload

//TOKEN QJ0ZlNI7RuyXP8c3aY8z

void serverConnect(void)
    while (!psClient.connected())
        Serial.println("serverConnect(): Attempting to connect to Thingsboard server");
        if (psClient.connect("Photon", TOKEN, NULL))                    // ClientID, User, PW
            Serial.println("serverConnect(): Connected");
            Serial.println("serverConnect(): Connection failed, retry in 3 seconds");
void blinkLED(void)

// returns a random integar between minVal and maxVal
int randoma(int minVal, int maxVal)
  // int rand(void); included by default from newlib
  return rand() % (maxVal-minVal+1) + minVal;


I have tested the above code as is - just added my token and it publishes perfectly on my TB test environment


Particle.variable only supports:

  • int
  • double
  • string


unsigned int countrry;   // THIS GIVES A COMPILE ERROR  -  see below
char serdata;

are not supported if you change to

int countrry;   // THIS GIVES A COMPILE ERROR  -  see below
int serdata;

both work okay. I don’t see serdata being used anywhere so you need to type and use it accordingly



OK Shane.
I made another test program and the variables worked… I have’t been back to use variables on my ‘live’ project as I’ve got the serial uart up and running and its easy to send debug info that way.

OK on the ‘Unsigned int’ … that’ll be me jumping from a different IDE to this one!


I am using release 1.4.4 on my Xenons/Boron network and I was having this problem as well (erratic function/variable registration) until I moved them to the beginning of Setup. Before they would sometimes register if I flashed them 5 or more times. Very unpredictable. Now no problems. Would be good to document this. I am using SYSTEM_THREAD(ENABLED). Had a similar problem with Particle.subscribe. I see it is listed as an "enhancement’ particle-iot/device-os.


It already is :wink:

When using SYSTEM_THREAD(ENABLED) you must be careful of when you register your variables. At the beginning of setup(), before you do any lengthy operations, delays, or things like waiting for a key press, is best. The reason is that variable and function registrations are only sent up once, about 30 seconds after connecting to the cloud. Calling Particle.variable after the registration information has been sent does not re-send the request and the variable will not work.


Thanks, I see it now in the Reference (System Threading Behavior). There are a lot of updates in the docs that I had not seen, and that I continually rescan. Is there a documentation release log that might list changes to the Docs, References, etc. or a way to indicate when/where changes are made to the documentation? Would be helpful to get a handle on the continually evolving documentation/product. I did see particle-iot / docs, but not something like a blog or release notes for doc updates. Realize that the process is very dynamic, but can be difficult to constantly review a large (and increasingly well written) document database.


This particular update was commited 14.08.2018