Yun Problem- Code or the machine itself?

I am having a problem with this program on my YUN in wireless mode:

#include <Bridge.h>
#include <YunServer.h>
#include <YunClient.h>
#include <Console.h>

// Listen to the default port 5555, the Yún webserver
// will forward there all the HTTP requests you send
YunServer server;

void setup() {
  // Bridge startup
  pinMode(13, OUTPUT);
  digitalWrite(13, LOW);
  Bridge.begin();
  Console.begin();
  digitalWrite(13, HIGH);
  delay(5000);
  digitalWrite(13, LOW);

  // Listen for incoming connection only from localhost
  // (no one from the external network could connect)
  server.listenOnLocalhost();
  server.begin();
  Console.println("The system has begun.");
}

void loop() {
  // Get clients coming from server
  YunClient client = server.accept();
  
  Console.println("Yun CLient is setup. Waiting to connect client now");
  // There is a new client?
  
  Console.println("Waiting to recognize client.");
  if (client) {
    Console.println("There seems to be a client started.");
    // Process request
    process(client);

    // Close connection and free resources.
    client.stop();
  }

  delay(50); // Poll every 50ms
}


void process(YunClient client) {
  // read the command
  String command = client.readStringUntil('/');
  command.trim();
  Console.println("I am inside the Process function.");
 if (command == "led13on") {
       digitalWrite(13, HIGH); 
      Console.println("I should be processing my ledon command now.");    
       
    }
    else if (command == "led13off") {
       digitalWrite(13, LOW);
    }

}

The problem is: My code gets to :

YunClient client = server.accept();

but never progresses past the

 if (client) {

Can anyone say why the client would not be present, or recognized? I know for a fact that the wireless connection is present or I could not upload the program code. I put in all these little debugging Console prints in to localize my problem.

FYI, I have recently reimaged the YUN based on the info I read with the 1.5.3 SysUpgrade. I have tried resetting everything on the board thereafter to no avail.
Any suggestions will be appreciated.
I did not have that problem prior to “upgrading” and I don’t have a prior image to go back to as far as I know.

Thanks,
houdinihar

What is trying to connect to the sketch? You use server.listenOnLocalHost() which makes me think it’s waiting for a connection from a local Linux process. Did the upgrade delete the code for that process, or something needed by that process?

You use server.listenOnLocalHost() which makes me think it's waiting for a connection from a local Linux process. Did the upgrade delete the code for that process, or something needed by that process?

Thanks for the reply/query Shapeshifter. I don't know enough about the communication process between the various YUN components to make an intelligent reply, and I would not know if something were deleted by the upgrade.

Hopefully Federico will see this and respond, too. As it stands, my YUN is just a nice conversation piece now. I don't know what else to do.

houdinihar

So what is trying to connect to your sketch? Is it an external computer, or something internal on the Linux side of the Yun?

houdinihar:
::::SNIP::::

Hopefully Federico will see this and respond, too.
As it stands, my YUN is just a nice conversation piece now.
I don’t know what else to do.

@houdinihar,
it’s unlikely Federico will respond. You are talking to the people who do technical support. We are volunteers. That’s the way it works. If you want timely help, please answer the question.

What are you using to connect to your Yun?

Jesse

Thanks for the clarification Shapeshifter. It must be the Linux side. The web page itself from my www folder makes it through the wireless router to my computer browser. It is easily seen, but as I said, the program itself never advances past the seeking a client code, ie, it never finds a client to connect to. I hope this is somewhat helpful.

houdinihar

Now answering Jesse. I appreciate all the volunteers trying to help us out. Again as noted earlier, prior to this new image upload I had no problems with my YUN.

What are you using to connect to your Yun?

I am going through my Netgear router which recognizes my board with a 192.x.x.x IP. The IDE recognizes the wireless IP and the password to sign onto my board is recognized and allows the program to be uploaded to the YUN.

houdinihar

houdinihar: Now answering Jesse. I appreciate all the volunteers trying to help us out. Again as noted earlier, prior to this new image upload I had no problems with my YUN. I am going through my Netgear router which recognizes my board with a 192.x.x.x IP. The IDE recognizes the wireless IP and the password to sign onto my board is recognized and allows the program to be uploaded to the YUN.

@houdinihar, thanks for the response, and repeating. Could you please check the IP of your router, your Yun and any machines that you are using to connect to it? I assume the are all on the same subnetwork, but it never hurts to double check.

Next, please make sure you can connect to the webserver on your Yun. If you are on the factory default setting, you can connect to the Yun, as http://arduino.local/ . If you cannot see that try, http://192.168.240.1/

FWIW, the IP of the machine you use to connect to the Yun should start with 192.168.240

TIA Jesse

Jesse,

Thanks for the response.
Since my YUN is already assigned its own IP by the router, the 192.168.240.1 is no longer valid. And I am able to access the YUN through its own assigned IP by the router.

As an aside, the USB light is on even though I’m not not connected to the YUN via the USB, but through the micro-USB power input. Don’t know if it matters or not.

Also, interestingly, the HttpClient sample works perfectly:

#include <Bridge.h>
#include <HttpClient.h>
#include <Console.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);

  Console.begin();

  while (!Console); // wait for a serial connection
}

void loop() {
  // Initialize the client library
  HttpClient client;

  // Make a HTTP request:
  client.get("http://arduino.cc/asciilogo.txt");
 Console.println("Downloading the .txt file now.");
  // if there are incoming bytes available
  // from the server, read them and print them:
  while (client.available()) {
    char c = client.read();
    Console.print(c);
  }
  Console.flush();

  delay(5000);
}

houdinihar

houdinihar: As an aside, the USB light is on even though I'm not not connected to the YUN via the USB, but through the micro-USB power input. Don't know if it matters or not.

That is normal. That LED might have had something to do with USB originally, or maybe that was an intention that was never fulfilled. Either way, all it means at this point is that the Yun has finished booting up it has nothing to do with the USB port.

Also, interestingly, the HttpClient sample works perfectly:

That sketch is completely different. In there, the HTTPClient object is making an outbound connection to a server and retrieving a page. It is initiating a connection.

In the sketch you originally posted, the YunServer object us waiting is waiting for an incoming connection, and will create a YunClient object when a connection is established. Something external to the sketch must attempt to make a connection, otherwise it will forever sit there waiting for one, just as you report.

houdinihar: but as I said, the program itself never advances past the seeking a client code, ie, it never finds a client to connect to.

There seems to be a misunderstanding here - it never will find a client to connect to, it's waiting for a client to connect to it.

Lets look at it from another viewpoint: the HHTPClient example is placing a telephone call to a server, getting the information it wants, and then hangs up. The sketch you posted in the first post, however, has plugged in the telephone, and is now waiting patiently for the phone to ring so it can answer it. The phone won't ring until someone calls it.

You said it worked with the previous system version. How did it work, what ate you expecting it to do? It's waiting for something to make a connection to it. You say it used to work - that's why I keep asking what was connecting to it? This doesn't make sense. I don't think the sketch is set up to do what you think it does, so I don't understand how it could've worked before the upgrade.

Problem solved. OK all. Now for what I have discovered by working on this all evening. There were some mistakes I made, but learned from.

  1. Basic stuff--I forgot to place the zepto.js inside the www folder when I created a new index.html--so it never got loaded. I think was the major malfunction.
  2. As Shapeshifter mentioned in his clear explanation

Something external to the sketch must attempt to make a connection, otherwise it will forever sit there waiting for one

. There were times when I did not reload the index.html file, so a client never became available then. 3. There were some simple coding errors I made, but which nevertheless impacted my project.

So , a hearty thanks to all who gave it their best shot in helping a newbie work through all this.

houdinihar