Issues with firmware 0.7.0


@ScruffR, thanks for the reminder!

My actual production firmware uses exactly what you suggested

const char FIRMWARE_VERSION[] = "neo-app-p1_0.10.8.0";

I’m not sure why I changed when assembling the test code.


@armor, can you keep us posted here about your ticket?

@rickkas7, if Particle needs more data on the issue, can you contact me?


@armor, @rickkas7, @ScruffR.

I keep repeating the tests and I found that rebooting my router either triggers the issue or speeds the problem.

After a device reset it could take hours to start seeing they going offline/online again, but it happens in minutes if I reboot my WiFi router.


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.


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.


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

SoftAP not working in 0.8.0-rc.4?

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.

Particle's plans for getting firmware to 1.0