Team, I've developed a very simple HTTP client application completely based on the HTTPClient example from the IDE which runs OK for some time and then suddenly stops working. In some occasions the Yun recovers after awhile but most of the times hangs and the only way to bring it back to life is by performing a full reset (off and on again)
My WiFi is pretty stable and I have other devices connected to the same network working properly even when the Yun stops.
In order to eliminate the (highly probable) possibility of an error on my sketch I've slightly modified the original example (see code below) an got exactly the same behavior.
The modifications I made are:
remove (comment) the Serial communication operations in order to be able to leave the Yun working by itself unattached to other computer.
added a Led feedback in order to "see" if the Yun is or not operating.
Hope I've been clear and it should be easy to reproduce the problem.
I'd really appreciate any hints on what can be done to overcome the issue.
Many thanks in advance, Simon
/*
Yun HTTP Client
This example for the Arduino Yún shows how create a basic
HTTP client that connects to the internet and downloads
content. In this case, you'll connect to the Arduino
website and download a version of the logo as ASCII text.
created by Tom igoe
May 2013
This example code is in the public domain.
http://arduino.cc/en/Tutorial/HttpClient
*/
#include <Bridge.h>
#include <HttpClient.h>
void setup() {
// Bridge takes about two seconds to start up
// it can be helpful to use the on-board LED
// as an indicator for when it has initialized
pinMode(13, OUTPUT);
digitalWrite(13, LOW);
Bridge.begin();
digitalWrite(13, HIGH);
//Serial.begin(9600);
//while (!Serial); // wait for a serial connection
}
void loop() {
//turn the led to show we are starting a new loop
digitalWrite(13, HIGH);
// Initialize the client library
HttpClient client;
// Make a HTTP request:
client.get("http://arduino.cc/asciilogo.txt");
// if there are incoming bytes available
// from the server, read them and print them:
while (client.available()) {
char c = client.read();
//Serial.print(c);
}
//Serial.flush();
// turn the led Off to indicate completion
digitalWrite(13, LOW);
delay(5000);
}
the example is really very easy, because I can find no fault.
my experience with arduino is that you do not have much space for programs at the 32U page.
I have the web applications and logik, in my case SQL Datas, placed on the linino in PHP
and transfer only the commands to the hardware via
bridge.get and
bridge.put
on the 32U that works quickly and safely.
I dont know your target projekt, but my experience is to get the job done linino in php or phyton........
I'm running your sketch since 2 hours and it hasn't failed yet (I haven't kept on watching the led since then, I just see that is blinking the expected way)
Could the problem be related to something else going on the linux side? Like some cron-driven process or something generating big log files or filling up the ram?
Federico, as always thank you very much for your support... and I'm very glad you are testing it, hopefully you will be able to reproduce the problem and of course fix it!
Regarding your remarks:
I'm running your sketch since 2 hours and it hasn't failed yet (I haven't kept on watching the led since then, I just see that is blinking the expected way)
No surprise to me, some times it hangs after a short period of time ( < 2 hours) and sometimes runs for more than a day
Could the problem be related to something else going on the linux side? Like some cron-driven process or something generating big log files or filling up the ram?
I have no clue, I've no experience with Linux the only thing I can tell you is that the simple sketch is the only thing I've loaded.
hi all
the problem with the bridge has been here several times discussed.
the bridge example is simple, but it transfered a lot of bytes on the bridge.
and that is in all cases that have been reported here the problem.
I transfer only 10 bytes at a time in my project that works for days with no problems
Unfortunately the solution that worked for you wouldn't help in my case, I have to send an API ( "get" request) that is 100 characters long and the server will not understand if it is not sent all at once. I then receive 14 bytes back from the server.
Bottom line I wouldn't say that in my case the transfer involves "...a lot of bytes on the bridge..." and besides I guess the Yun should work no matter what or otherwise the limit should be part of the spec.
I understand Simon, but unless someone pops out with a working fix, you'll have to wait. I'm very sorry for this and I'll try to make it fixed either by me or someone else