Photon Crashing After Several Variable calls


I am writing a web app and am using Javascript setinterval to repeatedly request variable values. This was fine with one variable, but once i started requesting 3 my photon crashed (solid cyan LED). I am guessing it can’t cope with 3 requests very close together? Does this seem a likely cause?
If it is, I guess I can create a JSON string with my 3 variables and then extract in my JS, or stagger the requests.


Solid Cyan LED is not a sign of the Photon crashing. If you want some help then maybe posting your code? Are you using SYSTEM_THREAD(ENABLED); show the registration of the Particle Function and the Function handler.

Do you wait for the return code before sending the next command/function API call?

1 Like

Apologies for not replying sooner. Been bogged down homeschooling my children.
Code is here:
The javascript is sending API calls in very quick succession with no delay between, I think this was this issue. Going forward I am going to try to do the API calls from PHP to hide the access token from the client, so this post can probably be closed now?

Thanks for your help.

A few things to note

  • you are using deprecated syntax for exposing your variables, you would now merely write Particle.variable("temperature", temperatureInC)
  • you should register Particle.variables() as early as possible in setup()
  • you should not use such long delay()s but rather opt for a non-blocking approach
  • try to avoid String and rather use C-strings (aka char array)
  • all your Particle.publish() calls should be scoped PRIVATE
  • make sure that none of your divisions ever divide by zero
  • you should not publicly post access tokens or API keys

Solid cyan indicates a deadlock (often between system and user application firmware) when both try to access a shared resource (e.g. a HW interface).

Thanks. I shall take all those points on board and try to improve the code. My C isn’t great so need to do a bit of learning.

I have incorporated most of the suggestions above into this revision

Thanks for doing that. Is the delay method you used better than using the elapseMillis library or is it doing much the same thing?

It’s doing pretty much the same thing without the need for a “library” - you can’t really get a lot shorter than this three-liner.

If you have a look at the implementation of the elapsedMillis “library” you’ll see there would merely be some extra definitions you won’t be using after all :wink:

1 Like

Thanks Again