Next thing to learn


I suppose it’s this one: Tutorial: Webhooks and Responses with Parsing (JSON, Mustache, Tokens)

That said, have a look at the newly released rules engine since that can do as much as, and so much more than, Webhooks, in a possible easier ‘graphical programming style”.


@Moors7 reposted the link. I’ve completely integrated this into my program as you suggested and it seems to be working as planned on my photon test platform. Not going to upload it to the active photon until it’s been running for a couple of weeks without locking up. Don’t want to confuse anything if it starts breathing green again. This was a great suggestion. It eliminated the need for a lot of hardware and a bunch of code. Appreciate the guidance.


Where do I find information on the rules engine?


You can request beta access here:




Well, I got to upload the new firmware anyway. After 7 days of running without a hitch it got stuck breathing green again and it appears to have locked the application code again. Happened at 0535 according to the LCD. The program should have just been running the loop code at that point which is a series of if statements waiting to run functions based on set times and a function to refresh the LCD. I’m going to make a troubleshooting post on this and include the code that was running when it froze this time. I was keeping this post open so I can show you guys the webpage I make for it once I get that done but I’ve got to get this whipped first.


Link to my new post


With much assist I was able to get past the breathing green issue. Here is a link to the thread. I’ve had to put off working on the web page. Hurricane Michael displaced my family and they are currently staying with me. A little too chaotic for learning. Here is the thread. Photon Breathing Green and code locks up


Pretty close to being finished with this project. Everything is done and I’m trying to go back and make sure I understand everything I’ve written by thoroughly commenting on it. Then I’ll post everything I have. So far, going very well but I do have one question about strtok(). @LukeUSMC did a very understandable tutorial on Webhooks and I have been able to adapt it to my project and I am getting the info I need but I want to understand one portion of the following code:

int forecastday1 = atoi(strtok(strBuffer, “/”~"));

This is the first call to strtok and I don’t understand what the “/” means. The ~ is the delimiter between the pieces of data and it’s in the response template. But nowhere in the response template is there a /. In subsequent calls NULL is in place of the “/” and I understand that. Just not what the initial “/” is for. Thanks in advance for any guidance.


I think this should rather be a backslash (\), right?
If it was a forward slash (/) I’d agree that it would not make sense.

But if it in fact is a back slash the delimiter string would be looking like this "\"~" and means that strtok() should break the string at each occurence of either a double quote (") or a tilde (~). But the thing is, how do you write a double quote inside a string that is wrapped in double quotes without actually ending the string?
That is where “escaping” comes into play. That backslash tells the compiler that the character that follows has a special meaning and hence should be treated differently than normal (i.e. “don’t break the string here but embed the double quote”).

If you look at the code hilighting of the following three statements you might get the picture

char goodString[] = "double quote \" escaped";       // everything red is part of the string
char badString1[] = "double quote " not escaped";    // why is the comment not gray? we need another "
char badString2[] = "double quote /" badly escaped"; // with the wrong slash                         "


… if you provide a link to said tutorial along with that statement, we could see whether a backslash or a forward slash was used :wink:


Backslash it was. Thanks. Now, not only can I do it, but I can understand it.


I deactivated the SIM and retried setup again and this time it connected to LTE and is operating normally.

I also have the exact same problem. Blinking green for hours. Console shows SIM with no device ID. I live in an area with strong AT&T, Verizon coverage. Location: USA


@fouad2000, I spent a lot of hours scouring the forum for an answer to this problem. 9 times out 10 the poster would find that their code was stuck in a loop so I would suggest that you start there. However, there were some that were sure that their code wasn’t stuck and yet the problem still continued to happen. One thing that seemed to be a trend was to make sure that you are using SYSTEM_THREAD(ENABLED). This allows the “OS” of the photon to run even if the code gets stuck in a loop. I came across another where the poster had determined that turning the WiFi off and back on would stop the problem. So, the following code is what I have been putting into my project and I haven’t had a breathing green failure since mid October 2018. Basically it includes the SYSTEM_THREAD(ENABLED) and 2 counter functions. One starts counting if the photon is attached to the WiFi but not the cloud. If it stays this way for 5 minutes, it turns the WiFi off. The second turns the WiFi back on after a minute. I deployed both of these “fixes” at the same time so I’m not sure both are needed but I know that together they work. I’ve never used the cellular version of the photon but I’m sure that there is a similar function to turn off the radio and then turn it back on gain. You’ll just have to change and on to what commands are needed for your version.

SYSTEM_THREAD(ENABLED);//Added so that program would still run if WiFi locked up

int countLoop;//This and the next 6 variables are used to shutdown WiFi and restart it if connection to the cloud is lost for over 5 minutes.
int countWIFILoop;
int countLoopWIFI;
int offWIFIcount;
unsigned long lastCheck;
unsigned long lastWIFICheck;
unsigned long lastCountWiFi;

void setup()


countLoop = 0;//This line and the next 6 just set initial values for the counters used for WiFi shut off/on for extended cloud loss
lastCheck = 0;//
lastWIFICheck = 0;//
lastCountWiFi = 0;
countWIFILoop = 0;//
countLoopWIFI = 0;
offWIFIcount = 0;//


void loop()
cloudOutDisconnect();//Function to turn off WiFi if cloud has been disconnected for 5 minutes
onWifiAfterOne();//Function to turn Wifi back on after being off for one minute

void cloudOutDisconnect()
/*I've had a lot of problems with my photon "breathing green" and locking up the program.  Did a lot of 
looking online for solutions and the result is that I added the system thread enabled in the beginning of the 
program and added the next two functions to combat that.  The first turns off the WiFi if the photon
has been connected to the WiFi but NOT the cloud for 5 minutes.  The second turns the WiFi back on
after a minute.  I deployed both fixes at the same time and it has worked with no glitches for
over a month.  Not really sure if both are needed or just one or the other.  All I know is it worked.*/
if((!Particle.connected()) && (WiFi.ready()))
    unsigned long now = millis();
    if(now - lastCheck >= 1000)
        countLoop ++;
        lastCheck = millis();
        if(countLoop >= 300)
            Serial.print("WiFi turned off at ");
            offWIFIcount ++;
            countLoop = 0;
else(countLoop = 0);

void onWifiAfterOne()
    unsigned long now = millis();
    if(now - lastWIFICheck >= 1000)
        countWIFILoop ++;
        lastWIFICheck = millis();
        if(countWIFILoop >= 60)
            Serial.print("WiFi turned back on at ");
            countWIFILoop = 0;
else(countWIFILoop = 0);

Ok. There’s my fix. I hope it helps you out. It’s not fancy or very elegant but it works for me.

Photon Breathing Green After Several Hours

I just wanted to take a moment and update everyone on the status of the project. Everything came together quite nicely. I used @Bear 's suggestion and went with a web page for control and was able to eliminate the LCD. I used @VideoLiam 's suggestion and wrote a webhook to get sunrise/sunset times from the TSA website and added an offset that is adjustable from the web page controls. I also did another webhook that I’m pretty sure will allow the program to automatically adjust for daylight savings time. I’ll find out if it works in March. I also used IFTTT to send me notifications on the door and water status twice a day shortly after the door opens or closes. Still having a problem with the photon rarely locking up. Once breathing green and once breathing another color but I don’t remember which one. So, even though it’s only twice since October, it could be a big problem if I’m out of town for a couple of weeks and can’t get someone to stop by and hit the reset button. To combat this, I’m using an Aurduino Beetle to read one of the photon pins that I’ve set to toggle HIGH/LOW constantly. If the toggling stops for 5 minutes, the Beetle activates a relay that will trigger a reset on the photon. I suspect this is happens because my project is on the extreme edge of the WiFi but I don’t really have a place to add another extender that would get it closer.

All in all this has been an incredible learning experience for my first ever project. I appreciate all the help from everyone who has helped me. In addition to those already listed, @ScruffR, @Moors7, and @Rftop for the feedback in the comments. I also used the tutorials of @bko Tutorial: Spark Variable and Function on One Web Page and @LukeUSMC Tutorial: Webhooks and Responses with Parsing (JSON, Mustache, Tokens) I’m working on putting everything on hackster but that will be a little while. I’ll post a link when I do. Thanks again for all the assists.


Hi Driver1rn,

Thaks for the update, and lovely to see your project coming together. How content are the Hens?

Just as an additional thought on the photon stability, there is a firmware/device os update to version 1.0.0.

It might be worth checking what version your current build is running on and consider upgrading if neccessary. It provides for some device logging which might be useful for troubleshooting.



I did update since the last episode so maybe that will make all the additional work unneeded. Everyone is quite content.


I too have a coop that is controlled by a Photon along with several Photons controlling other equipment at my house. I have the same situation as you and couldn’t use any OS about 6.3. The last couple weeks I was determined to get it very reliable because I am going to control the temp and humidity on two freezers and can’t afford them going down. I am using the same code you have above except I am using system mode semiautomatic. Because of that after the wifi is turned on I do a Particle.connect. I have a 5 second delay between the WiFi.on and Particle.connect. I found the sometimes it took too long for the Particle.connect to happen and the Photon would stay down.

The second thing I did was I have a setting on my router called roaming assistant. It is supposed to disconnect a client when the signal level drops below -70 dbm. I disabled that. I also assigned static IP’s in the router for each Photon. Those two things stopped my Photons from going offline occasionally and I can use OS 1.0.0 now.


Thanks for that info. I’ll look at my router and see if I can make those same changes. I have a lot of confidence in the Beetle fix but I’d really like to avoid all that trouble.