@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?
2 Likes
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.
1 Like
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.
cheers,
ParticleD
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() {
delay(5000);
Serial.begin(9600);
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"
,__FILENAME__
,__DATE__
,__TIME__
,(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*
,WiFi.RSSI()
);
Particle.variable("deviceInfo",gDeviceInfo);
Particle.function("pReset",pReset);
Particle.function("pRightDoor",pRightDoor);
Particle.function("pLeftDoor",pLeftDoor);
relayController.setAddress(0,0,0);
//Turn the relays off and indicate so on their respective status variables
relayController.turnOffAllRelays();
}
void loop() {
now = millis();
if (now<lastUpdate) {
lastUpdate = 0;
}
if ((now-lastUpdate) > 15000) {
lastUpdate = now;
}
}
int pRightDoor(String command) {
relayController.turnOnRelay(rightDoor);
delay(100);
relayController.turnOffRelay(rightDoor);
return 1;
}
int pLeftDoor(String command) {
relayController.turnOnRelay(leftDoor);
delay(100);
relayController.turnOffRelay(leftDoor);
return 1;
}
int pReset(String command) {
//function to call to remotely reset Photon
System.reset();
return 1;
}
Iāve flashed a very simple program from build.particle.io 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.
4 Likes
@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!
3 Likes
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