Issues with firmware 0.7.0

Have you or can you try a different brand router to see if the same behavior exist?

Same problem here using an ISP modem -> netgear orbi -> photon setup.

When my modem reboots or looses its internet connection all my photons (0.7.0) are restarting after the modem comes back online. I didn’t see this at 0.6.3.

1 Like

I just noticed that the only photon that didn’t restart is not running Blynk. Are you running Blynk?

@Maarten_CH, no I’m not using Blynk.

I just started I new test flashing my devices with Tinker and soon after I reboot my router they all started going online/offline…

@rickkas7, is Particle working on the issue?

Yes, this is being investigated. I don’t have an update on what has been found so far, however.

One contributing factor in some cases is that 802.11n is not working in 0.7.0 and later. In some networks, this might cause a fallback to 802.11b or 802.11g, which could cause issues in certain network configurations, but this is likely not the entire problem.

1 Like

I’m leveraging softAP mode for transacting all of our P1 device setup and provisional data exchange. It’s a simple operation where our Android app pings specific URL’s on the P1 endpoint and the P1 constructs and replies with data for that specific URL request. Some of these replies are close to 6KB.

System.freeMemory() is the go/no-go determinant factor for the size of the result->write() response. I can reliably get my large 5K+ replies when .freeMemory() > 29K, and it appears to fail linearly from there based on the free.Memory() vs. result->write() response size.

I’m going to attempt a downgrade of system firmware to 0.6.3. and see if that makes a difference

It appears on multiple devices that I’m not seeing any exposed functions or variables once I go to 0.7.0. Anyone else seeing this?

@ctmorrison I have a very simple test sketch that includes a function and a variable (and some publishes). I just flashed it to a 0.6.2 Photon, and then changed the target Device OS to 0.7.0 and flashed again. The function and variable continue to show up in Console.


Here’s my code. I’ve been doing this for quite some time, but just can’t figure out what I’m doing wrong and I’m a bit flustered. I have the Photon running 0.6.3 at this time. None of the exposed variable or functions show up in console. Perhaps I’m just too tired to see what I’m doing wrong all of a sudden. Thanks!

 * Project dualGarageDoorControl
 * Description:  Used to control two garage doors via a single Particle device
 * Author: ctmorrison
 * Date: 20180712

 #include "math.h"
 #include "NCD2Relay.h"

 #define __FILENAME__ (strrchr(__FILE__, '/') ? strrchr(__FILE__, '/') + 1 : __FILE__)

 NCD2Relay relayController;

 int leftDoor = 1;
 int rightDoor = 2;
 double lastUpdate = 0;
 double now = 0;

 char gDeviceInfo [200];

 int pRightDoor(String command);
 int pLeftDoor(String command);
 int pReset(String command);
 char gSystemFW[20];
 String leftDoorStatus = "open";
 String rightDoorStatus = "open";

 void leftDoorOpen(const char *event, const char *data){
     leftDoorStatus = "open";
 void leftDoorClosed(const char *event, const char *data){
     leftDoorStatus = "closed";
 void rightDoorOpen(const char *event, const char *data){
     rightDoorStatus = "open";
 void rightDoorClosed(const char *event,const char *data){
     rightDoorStatus = "closed";

 void setup() {
     Serial.println("Program has started");
     //this makes critical application information available
     snprintf(gDeviceInfo, sizeof(gDeviceInfo)
             ,"Application: %s, Date: %s, Time: %s, System firmware: %s, SSID: %s, RSSI: %i"
             ,(const char*)System.version()  // cast required for String
             ,(const char*)WiFi.SSID()       // cast not required but always safe when in doubt if String or char*
     //Turn the relays off and indicate so on their respective status variables

 void loop() {
     now = millis();
     if (now<lastUpdate) {
         lastUpdate = 0;
     if ((now-lastUpdate) > 15000) {
         lastUpdate = now;

 int pRightDoor(String command) {
   return 1;

 int pLeftDoor(String command) {
   return 1;

 int pReset(String command) {
   //function to call to remotely reset Photon
   return 1;

I’ve flashed a very simple program from and it works fine. Could it be something to do with Particle Dev? I just updated the CLI to 1.32.4 earlier today.

I uninstalled CLI and reinstalled it and continue to get the following messages when the install progresses:

[Toms-MacBook-Pro-13:~] tom% sudo npm install -g --unsafe-perm particle-cli
npm WARN deprecated node-uuid@1.4.8: Use uuid module instead
npm WARN deprecated parser-byte-length@1.0.2: renamed to @serialport/parser-byte-length
npm WARN deprecated parser-ready@1.0.2: reanmed to @serialport/parser-ready
npm WARN deprecated parser-delimiter@1.0.2: reanmed to @serialport/parser-delimiter
npm WARN deprecated parser-regex@1.0.2: reanmed to @serialport/parser-regex
npm WARN deprecated parser-cctalk@1.0.2: reanmed to @serialport/parser-cctalk
npm WARN deprecated parser-readline@1.0.2: reanmed to @serialport/parser-readline
/usr/local/bin/particle -> /usr/local/lib/node_modules/particle-cli/bin/particle.js

> serialport@6.2.0 install /usr/local/lib/node_modules/particle-cli/node_modules/serialport
> prebuild-install || node-gyp rebuild

> spawn-sync@1.0.15 postinstall /usr/local/lib/node_modules/particle-cli/node_modules/spawn-sync
> node postinstall

+ particle-cli@1.32.4
added 542 packages from 349 contributors in 28.373s
[Toms-MacBook-Pro-13:~] tom%

Something simple, but could you try placing the functions/variables at the beginning of setup, before the delay? There’s a limited window in which those can be registered and the delay might cause you to miss that.


@Moors7, thanks for the suggestion. That’s exactly what was causing the problem with variable and functions not being exposed. Odd…the code was working in the past (well…the delay did not impede exposing the variable and functions). I had inserted the delay so I could flash the device and get the serial monitor up and running. Something changed along the way and I was assuming it was due to something in the cloud or my rushed attempts to get the devices updated to 0.7.0 from an earlier version.

As always, this community is amazing! Thanks, again!


I too had noticed that instantiating variables and functions immediately after startup was paramount to their success for registration. Delaying this will indeed cause instantiation to go unregistered.

Can you give an update on this?
I really hope this problem will be solved soon.

Have you tried 0.8.0-rc.9?

This thread does touch on multiple issues, so which one are you refering to with “this problem”?
And since there have been multiple fixes incorporated in all the versions since 0.7.0, it might well be that it already was fixed - who knows if you don’t tell which one you are grappling with.

I should have been more precise… I have the same problem as @bacichetti

My photons are restarting when my modem reboots or has no internet connection for a few minutes. This became a problem after upgrading from 6.x to 0.7. I’m now running 8.0 rc9 on three photons and see the same behavior. The photons seem to run pretty stable, same code in another location runs for weeks, but my crappy ISP hardware make my photons restart collectively.

I did some tests and restarting my modem makes the photons restart as well, it’s very reproducible. The device vitals in the console show strong wifi and 42kB of 81kB used.

My setup: modem wired to Netgear Orbi -> photon.

Not sure if I should include something in the software to handle disconnects to prevent these reboots but I hope, since other people have seen this as well, that this is fixed in the firmware.

1 Like

I know that Netgear Orbi doesn’t natively support two seperate SSIDs for 2.4GHz & 5GHz networks, but that’s something you could try.

I also have an Orbi installation, but I have set two different SSIDs (requires some minor hacking of the router).

BTW, are you running your Orbi as AP or router?

Since I don’t seem to have such problems, can you post a minimal test code that exhibits the problem for me to test it on my Orbis? (I’m running them as AP where my cable modem manages the network)

It’s setup as AP, the ISP modem is assigning IP addresses.

I’m on holiday so additional testing is not so easy at the moment. When I’m back I could connect 1 of the three photons to the ISP modem (turned off now), reboot the modem and see if this photon behaves the same as the Orbi connected photons.

If this is the case I will test with a simple code and let you know. Thanks for your input!

1 Like

I guess this issue never got resolved. I see more topics talking about the same problem. Its truly a pain to see the Photon dropping the connection. My solution was to downgrade to firmware V0.6.3 which works very solid. This is what you need to do to downgrade:

1- Get the firmware from this link:

Just scroll down until you see it.
2- Enter DFU mode, follow this steps:
Enter DFU Mode (Yellow blinking.) Press reset and setup together, release reset when it blinks yellow.

Flash part1:
dfu-util -d 2b04:d006 -a 0 -s 0x8020000 -D system-part1-x.y.z-photon.bin

Flash part2
The unit should still be blinking yellow:
dfu-util -d 2b04:d006 -a 0 -s 0x8060000:leave -D system-part2-x.y.z-photon.bin

If the Photon keeps upgrading itself to the latest firmware, do the following:
Using the Web IDE, pick firmware 0.6.3, then flash any program to the photon , after that perform again the dfu-util firmware upgrade. The Photon will stay on 0.6.3 firmware. My two cents.