marcuscatchpole:
BridgeClient client = server.accept();
My impression is that this code waits for someone to go to the Yun's local address.
No, it doesn't. The YunServer's .accept() method is a non-blocking call, and will return quickly to let you know if there is a new connection or not.
Using the YunServer is a multi-step process. It's rather powerful, but not trivial to use. To make it a bit more complicated, there are two ways to use it: as a web request handler, or as a simple TCP serial stream connection. Let's start this at the beginning...
The first thing you need to do is create an instance of the YunServer object. This is typically a global file-level object. However it's declared, it should just be created once and you use that single instance for the life of the sketch (in other words, don't create it locally inside a function.) You can have multiple YunServer instances if needed, with each listening on its own port. The YunServer constructor takes an optional argument to indicate the port is should use, with a default of 5555 if none is specified.
YunServer server1; // A YunServer that listens on the default port 5555
YunServer server2(); // Another YunServer that listens on the default port 5555
YunServer server3(255); // A YunServer that listens on port 255
With your server(s) declared, the next thing to do is start them up so they listen for incoming connections. This is typically done in the setup() function. Here you have two choices: should the server look for incoming web requests, or should it just handle plain TCP communications streams?
When handling web requests, the server responds to URLs in the format http://arduino.local/**arduino**/*whatever*. The key here is that the first token in the URL after the address is /arduino/ - when the web server running on the Linux side sees one of these type of requests, it will initiate a connection with the YunServer in the sketch, and pass it the remainder of the URL that follows the /arduino/ token. To start the YunServer in this mode:
server.listenOnLocalHost();
server.begin();
The server.listenOnLocalHost() call tells the server that it should only accept connections from the local web server, and not direct incoming connections from other computers. A computer makes a web request to the Yun, the web server on the Linux side accepts the request and passes it on to the YunServer. When using this mode, the YunServer must have been created to use the default port of 5555.
The other way to use the YunServer is for straight TCP streams. To start the YunServer in this mode:
server.noListenOnLocalHost();
server.begin();
The server.noListenOnLocalHost() call tell the server that it should not accept connections from the local web server, instead it directly listens for external incoming connections. This is usually used with a different port than the default 5555. When a computer makes a TCP connection to the Yun using the port specified when the YunServer was created, that connection goes directly to the YunServer.
Now, with the server set up and started, it's time to accept a connection. This is typically done in the loop() function (or in your own function called from loop()):
YunClient client;
client = server.accept();
if (client.connected())
{
// Handle communications with the client
client.stop();
}
The server.accept() call checks to see whether there is an incoming connection pending, and always returns a YunClient object. If there was a pending connection attempt, that client object will be connected to the socket and ready to communicate. If there was no pending connection, .accept() still immediately returns a client object, but that client will not be connected to anything. The client.connected() call tells you whether or not the client has an active connection.
If the client is connected, you can then communicate with it. YunClient derives from Stream, so you can do all of the same read and write methods like you would with a Serial port: you can call client.available() to check for data, client.read() or client.readStringUntil() to get data from it, and client.print() or client.println() to send data to it. There are lots of other read/write functions as well - anything you can do with a Serial or Console object, you can do with YunClient as well.
If you are using it as a web request handler (you used the default port and .listenOnLocalHost()) then what you will read from the client is the remainder of the URL that follows the /arduino/ token. What you write to the client is whatever data you want to return to the requesting web browser.
If you are using it as a TCP socket, then what you read from the client is whatever the remote computer is sending you, and what you write is whatever you want to send to the remote computer.
When you are done with the client, always call client.stop() to properly close and release the network socket. If you don't do this, the YunServer will stop accepting connections after about 256 connections.
Thoughts?
Yes... while YunServer/YunClient has a reasonable level of functionality, I don't typically use them. I much prefer doing as much processing as possible on the Linux side, where the processor runs much faster and has a lot more memory and resources. The sketch runs quite slowly, and has a very limited amount of code space and RAM. My favorite part of the Bridge library is the Process object - I will write a Python script that does the majority of the work, and run it from the sketch using a Process object. Like YunClient, Process also derives from Stream, so all of the typical read/write operations work with a Process object as well: anything written to the Process object appears at the standard input of the corresponding Linux process, and any output printed by the Linux process can be read from the Process object.
I have done similar data logging/web display projects as you describe. The way I would approach your project is to have the sketch in a loop that waits the five minutes until it is time to collect another data sample, then collect that data and call a Process object. That Process calls a Python script on the Linux side, passing it the data. The Python script reads the passed data and writes it to a SqlLite database, or to an RRD database. Finally, a web application written in Bottle runs on the Linux side to serve up the data. Basically, the sketch is a minimalist I/O handler, and the real work is done in Linux. The two halves of the Yun do the part that they do best.
I describe a similar architecture here: HowTo: Using RRD - Round Robin Database