Photon is not running or maintaining its connection to WiFi for more than 20 hours

It seems that this Photon is not able to run continiusly for 24 hours without rebooting itself
or disconnecting from the WiFi network!
Initially I tried it with the Tinker FW and then with the simple code blow and the
device behavior did not change.
Sometimes it is only getting disconnected form the network (few rapid blinking in cyan)
and then re-connects to the network (breathing cyan).
Sometime it is rebooting itself (few rapid blinking in red followed by multi-color flashing) and shortly after, it connects to the network.
These events are random and are not following any pattern or time interval!

All other devices on the WiFi network stay connected and do not exhibit similar behavior.

==============

int testPin =  D6;
int testState = LOW;
unsigned long previousMillis = 0;
long OnTime = 1*(60000UL);
long OffTime = 30*(60000UL);

void setup() 
{
  pinMode(testPin, OUTPUT);      
}

void loop()
{
  unsigned long currentMillis = millis();
 
  if((testState == HIGH) && (currentMillis - previousMillis >= OnTime))
  {
    testState = LOW;
    previousMillis = currentMillis;
    digitalWrite(testPin, testState);
  }
  else if ((testState == LOW) && (currentMillis - previousMillis >= OffTime))
  {
    testState = HIGH;
    previousMillis = currentMillis;
    digitalWrite(testPin, testState);
  }
}

===============

The Photon is powered by a 5V, 1A USB wall charger and is placed about 1’ from the router to avoid any possible interference. The FW is 0.4.6

===============

The Photon is Turned on and connected to the network

Oct  5 15:30:14 dnsmasq-dhcp[304]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx 
Oct  5 15:30:14 dnsmasq-dhcp[304]: DHCPOFFER(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  5 15:30:14 dnsmasq-dhcp[304]: DHCPREQUEST(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  5 15:30:14 dnsmasq-dhcp[304]: DHCPACK(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
========= 
Oct  6 03:30:10 dnsmasq-dhcp[304]: DHCPREQUEST(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx  
Oct  6 03:30:10 dnsmasq-dhcp[304]: DHCPACK(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
=========
Rebooted itself and re-connected to the network after approximately 20 hours!

Oct  6 11:34:31 dnsmasq-dhcp[304]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx
Oct  6 11:34:31 dnsmasq-dhcp[304]: DHCPOFFER(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  6 11:34:31 dnsmasq-dhcp[304]: DHCPREQUEST(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  6 11:34:31 dnsmasq-dhcp[304]: DHCPACK(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
=========
The Photon has been breathing cyan but it is not accessible with either the app nor the Particle IDE build
From

Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx
Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPOFFER(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPREQUEST(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPACK(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 

To 

Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx
Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPOFFER(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPREQUEST(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 
Oct  6 19:12:43 dnsmasq-dhcp[304]: DHCPACK(br0) 192.168.1.xxx xx:xx:xx:xx:xx:xx 

Router  b/g/n 2.4GHz
RSSI: 0 dBm	SNR: 0 dB	noise: -74 dBm	Channel: 7
=========
Photon

MAC               Associated Authorized    RSSI  PSM Tx rate Rx rate Connect Time
xx:xx:xx:xx:xx:xx Yes        Yes              -1dBm No      64M     26M    20:04:17
xx:xx:xx:xx:xx:xx Yes        Yes              -1dBm No      26M     1M      00:00:10
1 Like

I also have noticed a tendency in a couple of my programs to reset randomly with 0.4.6 that were fine in 0.4.5. I’m not confident enough that it’s not my coding that’s the problem so I’d be interested if other people have experienced this. For instance the following TCPClient code ran without red-blink resets on 0.4.5 whereas on 0.4.6 I seem to get resets randomly (varies between 30 mins to an hour):

//fine on 045 but panics randomly on 0.4.6
//loosely adapted from @Hootie81 & @jon1977 in community.particle.io
#include "application.h"
SYSTEM_MODE(MANUAL);
int serverPort = 6123;
uint32_t lastTime;
char read_char;
char clientmsg = 'x';
char replymsg = '9';
byte server[] = {192, 168, 1, 157};
bool complete;
TCPClient client;
char outmsg[50];
void out(const char *s) {client.write( (const uint8_t*)s, strlen(s) );}
void setup()
{
  pinMode(D6,OUTPUT);
  pinMode(D7,OUTPUT);
  pinMode(D3,INPUT);
}//setup()

void loop() {
  WiFi.disconnect();
  System.sleep(D3, RISING, 4);
  if (digitalRead(D3)) {digitalWrite(D6,HIGH);delay(200);digitalWrite(D6,LOW);}

  while (!WiFi.ready()) {
    WiFi.connect();
    while(WiFi.connecting()){}
  }// while (!WiFi.ready())

  complete = false;
  //don't unsuccessfully persist beyond 10 secs, just go back to sleep
  lastTime = millis();
  while ((!complete) &&  (millis() - lastTime < 10000)){

    if (client.connect( server, serverPort)) {

    if (client.connected()) {
     sprintf(outmsg,"%c",clientmsg);
     out(outmsg);

     lastTime = millis();
     while ((!client.available()) && (millis() - lastTime < 5000)) { } //critical 10000

     lastTime = millis();
     while ((millis() - lastTime < 300)) {}//plays better with nodejs server?

     while (client.available()) { //now get confirmation from server that server received msg
      read_char = client.read();
      if(read_char == replymsg ) { //we got confirmation
        digitalWrite(D7,HIGH);delay(10);digitalWrite(D7,LOW);
        client.read();
        complete = true;
      }//if(read_char == replymsg )
    }//while (client.available())
   }//if (client.connected())
  }//if (client.connect( server, serverPort))
  client.read();
  client.flush();
  client.stop();
 }//while (!complete) //!!!!!!!!!!!!!!!!
// prevent nodejs ECONNRESET, not necessay with another photon??
  lastTime = millis();
  while ((millis() - lastTime < 500)) {}//prevent nodejs ECONNRESET
delay(1);
}//loop

EDIT: Ah, just saw this post https://community.particle.io/t/tcpclient-unstable-in-0-4-6/16249; perhaps the same issue

Based on my experience the 0.4.6 is more stable than prior releases.

I have noticed that my photon stops randomly too. Initially I wasn’t sure if it was signal strength related, it was -65dB so i have added an external antenna and got it back to -40dB. basically it just stopped waking up from sleep (based on time and WKP pin did nothing) so i had to pull the battery and plug it back in and it starts working again.

Because the Photon is inside a sealed box i cant see what its doing…

Maybe we could now get SOS details stored in a retained variable and published at the next cloud connection? what do you think @mdma

@Hootie81, there is a issue posted for this:

my code is using publish and functions only… not sure if its SOSing or not because of where it is and how random it is

1 Like

From my experience 0.4.6 is not more stable on any of my code I’m using.

1 Like

Although the TCPClient calls may cause similar behavior, my code and the Tinker FW exhibit the unstable nature of the device and its FW as well!

Hi @Rons,

Just to check, what’s the DHCP lease time on your network? I’m wondering if maybe the photon isn’t renegotiating its DHCP lease properly or something, which might explain a consistent disconnect / reset cycle.

Thanks!
David

Hi Dave,

The DHCP lease time on my router is set to 86400.

BTW - i just checked the wireless log and in the past 90 minutes the Photon disconnected and re-connected Itself more than 4 times.

Is it possible to create a log file for Photon to figure out what the issues are with its connection to the WiFi network and its unpredictable behavior? I am willing to send my Photon back so you guys can check it and hopefully solve the network connectivity problem and random rebooting for all the users who are experiencing similar issues.

Thanks

Hi @Rons,

Actually yeah! A Wireshark capture of the traffic for the Photon might help us see a potential error if you’re familiar with that tool. We deployed some code yesterday, which might explain a burst in reconnections during that deploy.

If you’re typically seeing 24 hour disconnects, and your lease time is set to 24 hours, I’m guessing it’s related. Can you try changing your lease time and see if that changes the cycle of the resets?

Thank you!
David

Hi @Dave,

I used the Wireshark long time ago and I will install it this evening on my PC. Let me know the setup you like see and I’ll take care of it. Also, my other concern is the Photon rebooting itself! I don’t believe that is network related, or is it?

Lastly, let me know what I should change the lease time to.

Thanks,
Ron

Hi @Rons,

If you aren’t frequently adding many dozens of new devices to your home network, I think a lease time of a week (86400*7 == 604800) should be safe to try. I suspect that a much longer lease time, once the photon is reset and has a new IP / new lease, is that it’ll start resetting once a week, instead of once a day. If that’s the case, we can focus on that being the issue. For a faster turnaround, you could try a 2 day lease (86400 * 2), etc.

Thanks!
David

Hi @Dave,
I changed the DHCP lease time to 2 days and the Photon IP address remained the same.

I ran the Wireshark with its default profile for 7 hours and I extracted the information pertaining to the Photon.

3961	1783.882501000	192.168.1.1xx	224.0.1.1xx	CoAP	61	NON, MID:0, POST, /h (text/plain)
3961	1783.882501000	192.168.1.1xx	224.0.1.1xx	CoAP	61	NON, MID:0, POST, /h (text/plain)
3970	1797.082295000	Universa_xx:xx:xx	Broadcast	ARP	60	Gratuitous ARP for 0.0.0.0 (Request)
3971	1797.087480000	0.0.0.0	255.255.255.255	DHCP	350	DHCP Discover - Transaction ID 0xabcd0001
3972	1797.144023000	0.0.0.0	255.255.255.255	DHCP	350	DHCP Request  - Transaction ID 0xabcd0002
3973	1797.190650000	Universa_xx:xx:xx	Broadcast	ARP	60	Who has 192.168.1.xx  Tell 192.168.1.1xx
3974	1797.333102000	192.168.1.1xx	224.0.0.1	IGMPv2	60	Membership Report group 224.0.0.1
3975	1797.784133000	192.168.1.1xx	224.0.1.1xx	CoAP	61	NON, MID:0, POST, /h (text/plain)

I flashed the Photon with the Tinker app yesterday and the longest it ran without rebooting or disconnecting from the network was 9.5 hours.

Oct  9 19:15:44 dnsmasq-dhcp[6020]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx 

Oct 10 04:51:56 dnsmasq-dhcp[6020]: DHCPDISCOVER(br0) xx:xx:xx:xx:xx:xx
1 Like

Hi @Dave,

The destination 224.0.1.187 does not exist. Could this be the source of the problem?
Every time there is an issue with the Photon, the Wireshark log file registers a similar information.

3961,"1783.882501000","192.168.1.1xx","224.0.1.187","COAP","61","NON, MID:0, POST, /h (text/plain)' 

Header checksum: 0x1034 [validation disabled]
    [Good: Fales]
    [Bad: Fales]
  Source: 192.168.1.1xx (192.168.1.1xx)
  Destination: 224.0.1.187 (224.0.1.187)
  [Source GeoIP: unknown]
  [Destination GeoIP: unknown]

Thanks,
Ron

Hi @Rons,

Hmm, that’s probably the UDP broadcast announcing the new IP address of the device, maybe that’s causing a fault, or maybe that UDP socket isn’t cleaned up / reused properly. I’ll offer this info to our firmware team and see if sparks any ideas. :slight_smile:

Thanks,
David

Hi @Dave,

Thanks for passing the information to the FW team.
The Photon with the Tinker app ran for 17 hours then rebooted and then for 9 hours and rebooted. Although I changed the DHCP lease time to 2 days, I am not noticing much improvement!
Unless you want me to run addition tests/diagnostics, I will disconnect the Photon for a while and hope that a fix will come soon.

Thanks,
Ron

Hi Dave,

The Photon has been running without disconnecting or rebooting for over 70 hours! I have not made any changes to my network and I am wondering if you guys made changes to reduce or eliminate the issues some of us were experiencing?

I am experimenting with the Photon and connecting a LightBlue Bean and a two input relay board to it. I am using the Bean accelerometer for motion detection with IFTTT via Particle.publish() and Blynk to control the relay and monitor the input from Bean!

BTW - I have not been able to connect to Photon via serial port through WiFi. I installed the Particle CLI on my MBP running El Capitan and I am able to login but when I try

particle serial list
No devices available via serial

particle serial wifi
! serial: No devices available via serial

I have read all the documents and threads in reference to this topic, but none are working for me!

Thanks,
Ron

Hi @Rons,

I think a CLI update was released recently that fixes serial issues on El Capitan:

Thanks!
David