I have been using Arduino WiFi shield to log sensor values to google spreadsheet. It logs perfectly.

But when I try to run it for a longer period it just stops sending. sometimes it stops after 20 minutes and sometimes it stops after 4-5 hours. The code is below. By the way the firmware version of Arduino WiFi shield is 1.1.0. I usually connect it the laptop to run the code, so I can see the serial monitor. There were no errors shown. For the last two tests I connected it to a 12V power supply.

In trying to find the root cause of this problem I ran a network trace, and the trace suggests the problem lies either in the WiFi101 driver, the WiFi Shield firmware, the Arduino Mega 2560 firmware, or any combination of the three. I say that because it is the Arduino that is issuing retry's to the client.

Summary of what I can tell so far:

The "freeze" occurs whether use the WiFi101 card as a Web Server or Web Client.

The "freeze" happens if I access the card using either of the following methods:

My client was a Windows 2012 Server, running power shell script as admin (script is given further below)

I ran NetMon on the server where I was doing the request (For those of you who do a lot of network trace captures, I know running the sniffer on the same machine as the client is not the best practice, but in my case, the server was not busy doing anything else, it has plenty of memory and CPU speed, and under those circumstances I think it was not a bad approach to do the capture)

What you see:

The trace looks normal for a while,

After a few minutes, the WiFi101 card issues a retry (for more information on this, see MSDN explanation)

Hi,I'm a owner of a MKR1000, and i think we got same problem.I was trying to control a home device through a webpage on my wifi board but, after a few hours working fine, it stops responding http requests from a webrowser.This issue was explained in this post:

http://forum.arduino.cc/index.php?topic=401107.0

After a lot of issues and debugs, i concluded it's because a problem in the wifi part of the sketch, soi extracted all unnecessary code to detect the problem.Finally, and to be sure, i loaded the example included with the WiFi101 library, named 'AP_SimpleWebserver', and cleaned the unnecessary sentences (basically, deleted all the 'Serial.println()' ones).So the code lasts this way:

A simple web server that lets you blink an LED via the web. This sketch will print the IP address of your WiFi Shield (once connected) to the Serial monitor. From there, you can open that address in a web browser to turn on and off the LED on pin 9.

If the IP address of your shield is yourAddress: http://yourAddress/H turns the LED on http://yourAddress/L turns it off

if (client) { // if you get a client, String currentLine = ""; // make a String to hold incoming data from the client while (client.connected()) { // loop while the client's connected if (client.available()) { // if there's bytes to read from the client, char c = client.read(); // read a byte, then if (c == '\n') { // if the byte is a newline character

// if the current line is blank, you got two newline characters in a row. // that's the end of the client HTTP request, so send a response: if (currentLine.length() == 0) { // HTTP headers always start with a response code (e.g. HTTP/1.1 200 OK) // and a content-type so the client knows what's coming, then a blank line: client.println("HTTP/1.1 200 OK"); client.println("Content-type:text/html"); client.println();

// the content of the HTTP response follows the header: client.print("Click <a href=\"/H\">here</a> turn the LED on<br>"); client.print("Click <a href=\"/L\">here</a> turn the LED off<br>");

// The HTTP response ends with another blank line: client.println(); // break out of the while loop: break; } else { // if you got a newline, then clear currentLine: currentLine = ""; } } else if (c != '\r') { // if you got anything else but a carriage return character, currentLine += c; // add it to the end of the currentLine }

// Check to see if the client request was "GET /H" or "GET /L": if (currentLine.endsWith("GET /H")) { digitalWrite(led, HIGH); // GET /H turns the LED on } if (currentLine.endsWith("GET /L")) { digitalWrite(led, LOW); // GET /L turns the LED off } } } // close the connection: client.stop(); }}

Due to the absence of Serial outputs, you wont be informed about your board ip address, but this could be done asking your router's DHCP client's list.This code starts working perfect but, after a variable time, stops responding the webbrowser.I asked Arduino Support, but got still no response.It would be very helpfull if someone could also verify this behaviour, and find some explanation.Thanks!

Arduino Support pointed out to you this github issue (https://github.com/arduino-libraries/WiFi101/issues/72 ) where we are helping another user with a similar problem. You can speed up the resolution of this issue by providing our engineer with the code so he can figue out where the bug is.

@mephala see the above github issue. please help out by providing your code

People we're here to help but the only way to determine if the problem is in our code, Atmel's code or your code is by providing us with something that consistently reproduces the bug.

The MKR is as glitchy as h3ll and I am reasonably sure its not a code issue.

I suspect its an Arduino or Atmel issue. as people are seeing it with a variety of sketches from reading here and the dropout times vary wildly from a couple of hours to a couple of days.

It could I suppose be some sort of buffer issue (best guess)

It may not be the answer you were looking for but its the one I am giving based on either experience, educated guess, google or the fact that you gave nothing to go with in the first place so I used my wonky crystal ball.

A simple web server that lets you blink an LED via the web.This sketch will print the IP address of your WiFi Shield (once connected)to the Serial monitor. From there, you can open that address in a web browserto turn on and off the LED on pin 9.

If the IP address of your shield is yourAddress:http://yourAddress/H turns the LED onhttp://yourAddress/L turns it off

This example is written for a network using WPA encryption. ForWEP or WPA, change the Wifi.begin() call accordingly.

if (client) { // if you get a client, Serial.println("new client"); // print a message out the serial port //String currentLine = ""; // make a String to hold incoming data from the client boolean lenght=1; while (client.connected()) { // loop while the client's connected if (client.available()) { // if there's bytes to read from the client, char c = client.read(); // read a byte, then Serial.write(c); // print it out the serial monitor if (c == '\n') { // if the byte is a newline character

// if the current line is blank, you got two newline characters in a row. // that's the end of the client HTTP request, so send a response: if (lenght == 0) { // HTTP headers always start with a response code (e.g. HTTP/1.1 200 OK) // and a content-type so the client knows what's coming, then a blank line: client.println("HTTP/1.1 200 OK"); client.println("Content-type:text/html"); client.println();

// the content of the HTTP response follows the header: client.print("Click <a href=\"/H\">here</a> turn the LED on pin 9 on<br>"); client.print("Click <a href=\"/L\">here</a> turn the LED on pin 9 off<br>");

// The HTTP response ends with another blank line: client.println(); // break out of the while loop: break; } else { // if you got a newline, then clear currentLine: // currentLine = ""; lenght=0; } } else if (c != '\r') { // if you got anything else but a carriage return character, // currentLine += c; // add it to the end of the currentLine lenght=1; }

// Check to see if the client request was "GET /H" or "GET /L": /* if (currentLine.endsWith("GET /H")) { digitalWrite(9, HIGH); // GET /H turns the LED on } if (currentLine.endsWith("GET /L")) { digitalWrite(9, LOW); // GET /L turns the LED off }*/ } } // close the connection: client.stop(); Serial.println("client disonnected"); }}

To sum up what I found during a week of trying to debug the WiFi problem, if you use server code, expect it to run for 6 minutes up to 2 hours once the server is called to the point that it becomes unresponsive.

I found putting and using booleans in certain places when certain code is written increases the time until the crash by a little bit, which suggest an overflow problem. This overflow problem was not from the code I wrote, and seems to be caused in the WiFi firmware.

Interestingly, if you use the server it causes the crash relatively quickly, if you have server code in the program but it is never called, it will not freeze. Even more interesting, is that server almost always crashes the arduino once called within 20 minutes, client code crashes the arduino once called as well, but it usually takes a few hours and is not nearly as quick to crash as the server code. Either way, your arduino will not run two days without crashing if client or server code is called.

Post 30 of the link I provided on the post above provides even more diagnostics from another person.

Quote

Sorry to break this to you but you are playing with inherently broken hardware.

This thread has the most complete summary of the many issues affecting the WiFi shields TCP communication.http://forum.arduino.cc/index.php?topic=128424.0

I also did some experimenting myself.http://mssystems.emscom.net/helpdesk/knowledgebase.php?article=51

I think at one point I tried calling the server code, then unattached the wifi shield before the crash accorded. Interestingly, that didn't stop the crash. I am confident that the problem is in the wifi firmware, which no one ever really looks into.

Hi,When looking for a solution to the same problems in my temp logging setup, i kept finding the presented solutions to the described problems rather complicated.Starting from the view that simplicity often beats complexity i looked at the most often used code to build some kind of webserver on any arduino-like platform.It looked to me that a very likely candidate to cause the freezes was the whileclient() statement mostly used to detect the presence of a webclient and to start the delivery of the required html code.I replaced the while(client.available()) with if(client.available()) and PRESTO since then my Wemos D1 based templogger works as stable as a rock.It seems that once in awhile the client fails to properly close the connection, causing the server to lock itself into an endless serving loop hence rendering the whole setup locked.I hope this solution works for you as it worked for me: Like a miracle!

I also found that my MKR1000 device would stop sending data and the sketch would stop running. I am using the "B" version of the MKR1000 device, Arduino 1.8.0, and Arduino 0.13.0.

After a series of experiments, I found a solution. I observed that my sketch would run and the sketch sent sensor data through PushingBox to my Google Sheet for a few minutes. But the sketch would stop executing. I know this because I was sending a character to the connected OLED screen and screen updates stopped.

Refer to the project, "Send MKR1000 Data to Google Sheets", by Stephen Borsay on the Arduino Project Hub at the link, https://create.arduino.cc/projecthub/detox/send-mkr1000-data-to-google-sheets-1175ca.

In Stephen's loop(), I see that he exemplifies the following pseudocode:

In the script, Stephen's comment "//for MKR1000, unlike esp8266, do not close connection" triggered me to challenge the statement. I am glad I did!So I modified the function by adding a stop command to the client:

After the addition of the stop command, I found that my MKR1000 script continually sent sensor data to PushingBox and my Google Sheet. In my case, my timer is set to 1 hour and I have been continually sending data for 50 hours and running.

So now I have a robust, reliable sketch that sends sensor data through PushingBox to my Google Sheet. Try this suggestion in your own sketch and post your results. Cheers!

I also am using a MKR1000 version B running Stephen Borsay's code. However, even if I do add the client.stop() command, my sketch updates my google sheet for only 15 seconds or so, then the WiFi cuts out, but my sketch continues to run fine.

I don't know if I configured my router incorrectly or if there is an error in my code. Have you run into this problem?