Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.orgThis page is browser friendly, by the way. Make your browser's window less wide than your whole screen and you will find the narrower columns much easier to read. For more tips, see my Power Browsing hints.
The ArduSimpSrv is a server.
You have just used a "server". When you fetched the page you are reading, your browser, a web client, (Firefox? Safari? Whatever: the client software) connected to the server from which the HTML for what you are looking at can be gathered by any web client. It sent you the HTML, and whatever you're reading this on (the client hardware) has made it available in a wet-ware (your eyes) friendly form.
I have, elsewhere, shown you how to create a web server with an Arduino, my ArduServer. That has it's uses. It's pros and cons. The ArduSimpSrv is a simpler device, so it won't do things that an ArduServer will, but because the overheads of serving HTML have been eschewed, there's more space in the Arduino, so it can do more in other directions. The "price" for this? You won't be able access an ArduSimpSrv with a web browser. Client machines will need to be running client software written for the ArduSimpSrv. You can't even access it with telnet. Sorry. That's the "bad news" The good news is that a free simple client program for interacting with a ArduSimpSrv is available, fear not! More on that in a moment.
If you would like a list of "live" ArduServers and ArduSimpSrvs to access a ArduSimpSrv, that link's "for you!". Just remember that to access an ArduSimpSrv, you need to fetch the (free) bespoke client software! That link will take you to a page discussing my ArduServer and ArduSimpSrv demos. You may have come to THIS page FROM THAT page. (The link opens in a new tab or window, so you can get back here easily.) There's a link there for downloading the free ArduSimpSrv client software. (If you are just getting started with these things, the "plain vanilla" "Arduserver" is the way to go. You access those with an ordinary browser.)
(If you want to try running before you walk, you can "skip to the answer", the ArduSimpSrv sourcecode. That will open in a tab or window, to make it easy to get back to here.)
Wow! Devices visible across the internet! Clients talking to servers! All pretty grand!
Are you afraid it might be too grand for you, at the moment? Don't be! The hardest parts can all be overcome with nothing more than one PC, an Arduino with an ethernet shield, and a LAN.
(An aside, for the benefit of client / server newbies: We won't be doing it here, you can even do client/ server work in a single computer. No one said that the client software and the server software had to be in different computers, did they?)
We'll start by having your PC talk to your ArduSimpSrv through the wires of your LAN. Once that'd working, it isn't a lot more effort to allow "outsiders" in, to connect to your ArduSimpSrv to the world through your LAN's connection to the internet. (Your ArduSimpSrv "talks" to your LAN's router. Where the requests from the router to the ArduSimpSrv came from and where the services from the server go once they've been sent to the router are questions of little concern to the ArduSimpSrv.
A big PC will be involved in programming the Arduino, but it will not be involved in the serving of the web page. It can be unplugged, turned off, etc, once the Arduino has been programmed.
You'll need an "always on" internet connection, e.g. "broadband" or DSL or ADSL. You don't need a "static IP address", if that's worrying you. (We'll come back to that issue). You'll need a router, but you almost certainly already have one, if you've met the first requirement, above. You'll need a way to connect your Arduino to your LAN, i.e. an Ethernet interface.
You'll need to be careful about how badly you compromise the security of your system. You have to "open a door" to allow clients in. Try to avoid throwing open every door of your system.
I should mention that the software presented here requires a Wiznet W5100. The less expensive shields using Microchip ENC28J60 interfaces can probably be programmed to do exactly what the software here does. (If you do that, I'd love to post your code, or at least a link to it.)
(This page was started in 2011. Please see my "March 2015 ENC28J60 update" page before buying or using one of them! (That page will open in a new tab. Just close it to come back here.))
I happened to use an "Ethernet Pro" from Sparkfun, supplied (very quickly!) in the UK by Hobbytronics.co.uk to create the ArduSimpSrv. Any Arduino with a W5100 based ethernet interface should do. It doesn't matter if the ethernet interface is on the Arduino board, or on a separate PCB.
Actually, it would be more accurate to say that PCSensor.com and Fungus, from the Arduino forum, created ArduSimpSrv! The former gave me the idea of how simple things could be, and the latter wrote the code I specified. But without proper documentation, any project is lost. I hope that I am supplying that vital ingredient.
A scrap of Good News, to cheer you up: You won't need any third party libraries for this work. Third party libraries have their place, but it is always nice when there is no YAC (Yet Another Complication) isn't it?
You may feel that the ArduSimpSrv doesn't do much. If so, remember: it is merely a demonstration of some basic concepts. It provides you will a shell which you may expand to do many things.... whatever you want it to do! By all means get in touch, if you are wondering "could it do....?". (Please say you came from "art5SimpSrv.htm")
The ArduSimpSrv watches for incoming commands. It can serve more than one client "concurrently"... although this aspect has not been as extensively tested as I would wish. I am but a "one-eyed king", as far as TCP/IP is concerned. I'm trying to help the "blind" out there. If some two-eyed king has comments, they would be enthusiastically considered. I am particularly curious about whether I should be calling the "c.stop" which is currently remmed out, and curious about whether multiple clients accessing the server concurrently is going to lead to tears. (I do at least have a reasonable background in the hardware and software of Arduinos and clones.)
The final ArduSimpSrv, as described here, can do the following.
It can respond to "turn LED on"/ "turn LED off" commands... the LED being connected to the ArduSimpSrv. It can give clients the current reading from its light sensor. It can tell a client how many incoming requests have been processed since it was last re-booted. It still "responds" to the $BB$82 command... but that is a scrap left over from the development path. The response is meaningless... but consistent! (We start by making it respond to that command, for reasons you don't need to worry about!) (If I ever get this web page finished, I hope to add a small "frill" which will cause the ArduSimpSrv to emit a tiny "beep" each time someone accesses it, just to alert me to the fact that someone is trying it.)
New features are quite easily added to the Arduino code which runs the server.
It is not so easy to make the relevant complementary changes in the client software, but neither is it rocket science to extend the shell you are given.
The following will program an Arduino with Ethernet to be a server at 192.168.0.242, serving on port 5202. Those numbers appear... once... in the code below. Change them, if you need your ArduSimpSrv someplace else. (The device's MAC address is also in the code, although you would be VERY unlucky to find that you need to change that... unless you are using multiple derivatives of this demo. (All of the devices on one LAN must have different MAC addresses.)
It may be a bad idea to use any of the following at the same time as a W5100 based shield. I am working on a similar list for ENC28J60 interfaces... it seems it might be the same as the list below, minus D4, An0 and An1... but your work might as well be W5100 friendly, too, don't you think?
... and D13, but this last one only if you "care" that on the shield it goes to an LED, and from there through a resistor to ground. (This merely parallels the same thing on many Arduino and clone boards... BUT, to digress from the digression, BE AWARE that the software behind "setup()" and "loop()" pulse D13 high briefly before executing whatever you specified in "setup()".)
Of course, I unwittingly used some of those lines in my designs. The designs SEEM to work, but it would be a good idea to take what I've put on those lines and move them elsewhere. I will gradually be revising my designs as follows....
In every case, to modify the software is easy... but you will need to look carefully to see whether what is currently online has been modified or not.
To change the line used for, say, the phototransistor watching the LED in, say, ArduServer2, the line....
client.print("<br>Analog input 0 reads: <b>");
client.print(analogRead(0));
... must be changed to...
client.print("<br>Analog input 1 reads: <b>");
client.print(analogRead(1));
... and you are done! (You'll have to move one wire on your breadboard, too, if you had it wired for the original design.)
(Digression: Is nothing every easy? In 99.0% of my code, such a change would merely have been a matter of changing something like the "const byte bLEDpin=8;" at the start of the program. But in this case, to avoid fighting with... not hard... getting the prompt to identify the channel, I took a shortcut and specified the channel explicitly instead of a global variable. Sigh.
Sorry! I could have done without this, too! When will the Official Arduino Site have proper documentation of the ethernet shield and library?? I am working on getting all my pages converted to the "new standard"... in the meantime, you'll just have to stay alert!
The code below only responds to the $BB$82 command. It is just a first step in our journey. The more capable ArduSimpSrv code emerges later in this tutorial.
//
// TCP004: A simple server... not a web server... for Arduino
// Basic version. One command, one (static) response.
// See TCP005 for expanded, "useful" version.
// The client software for this is TCP002 (See below)
// Ver: 04 Oct 2011
// Requires purpose crafted client software.
// TCP002.exe in....
// http://sheepdogguides.com/zips/TCP001.zip
// ... is suitable.
// If you know of, or have written, Linux
// equivalents, please contact http://sheepdogguides.com/
//
// See http://sheepdogguides.com/arduino/art5simpsrv.htm
// for a guide to TCP004
//
// This code is in the public domain.
//
// It requires a W5100 based ethernet interface, although converting
// the software to run with a Microchip ENC28J60 should not be hard.
#include <SPI.h>
#include <Ethernet.h>
//The following determine the MAC address and IP address
// that will be in the ethernet shield on your Arduino.
//Both must be unique on your LAN
uint8_t mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xEE };
uint8_t ip[] = { 192,168,0,242 };
//The following determines what port the server will listen on.
int iSPort = 5202;
Server server(iSPort);
//TKB: Write up Ethernet Pro issues: At Sparkfun page ANSWER the %v/3.3v? question, pointing out that Ethernet Pro
//described as "Ethernet shield on an Arduino Pro" and that both 3v3 and 5v Pros sold!
//Also discuss problem of BUB/Optiboot, and tell people to look at ModernDevice page, where things explained nicely for us!!
//Also: BUB 3v3 // Ethernet Pro Gnd.... BUB's 3v3 NOT CONNECTED in SOME cases.
//ARGHHH!
//Ask about/ discuss c.stop.....
void setup() {
// Initialize the W5100 ethernet chip
Ethernet.begin(mac, ip);
// Start the serial library (for debug output)
// The serial monitor is not required for the server's operation.
Serial.begin(9600);
// Start the TCP server
Serial.print("Opening server...\n");
server.begin();
}
void loop()
{
Client c = server.available();
if (c.connected()) {
Serial.print("Incoming connection!\n");
// Read two bytes from client
uint8_t b1 = c.read();
uint8_t b2 = c.read();
// Debugging: Show me what the client sent
Serial.print("The client said 0x");
Serial.print(b1,HEX);
Serial.print(" 0x");
Serial.print(b2,HEX);
Serial.print("\n");
// Deal with the connection
if ((b1 == 0xBB) and (b2==0x82)) {
// N.B.. Maximum size of response is 68 bytes (enough for 32 sensors)
uint8_t response[68];
// Create a response
uint8_t *r = response;
*r++ = 0xBB;
*r++ = 0x82;
*r++ = 0x01;
*r++ = 0x01;
*r++ = 0xFF;
*r++ = 0xFF;
// Send it
c.write(response,r-response);
};
// Close the connection... TKB: close connection or stop server? Don't want latter!
//TKB REMMED OUT, as CONNECTION REPEATEDLY CLOSED...
//c.stop();
//seems to work! (Didn't (properly) with c.stop... server shut down?
};//end of Loop()
}
That code will respond to a simple request, and send a simple answer. We WILL be expanding the repertoire into more useful things... but that part is easy... you can probably "fly" with your own ideas, off of the foundation the above provided. The request and the response were relevant to a now defunct project I was working on... don't try to figure out why you would make the particular request, nor what the particular response is good for... apart from being a simple example of a client / server interaction!)
The request it responds to is the two byte sequence...
$BB $82
That "request" is sent from the client to the server. It is quite like when you send something to your printer. Your computer (the printer's "client") sends something. Because of this, the printer (the "server") does something. The analogy breaks down here, as what the printer does isn't, in any simple sense, "seen" by the "client"... but if the analogy helped, good. If not... just move on!)
The response, the thing the server sends back to the client is...
$BB $82 $01 $01 $01 $FF $FF
I WILL write much more about this... later!
No promises... but you may find mine online at...
(That URL also hosts other things you may find interesting. Use just "http://mon7nc.dyndns.org", with a browser, e.g. Firefox, to see my FarWatch remote premises/ weather monitoring system in action. Replace the :5202 with :81, still using just a browser, to see my ArduServer... web service with input and output across the internet, with just a browser sufficient as client. (Doing away with the "bespoke" client which ArduSimpSrv needs might seem like a good idea, but it limits the potential of the system. But if a mere ArduServer will meet your needs, it is an option.)
So much for the server. What about a client? I can give you a ArduSimpSrv client for Windows, TCP006. (That's a .zip file with the finished .exe inside it. The .exe is not a "setup" type program.) If anyone would like to create clients for the Linux and Mac people, I will be delighted to put links to them from here.
If you wan to write your own client, be it a better one for Windows, or for another operating system, you can download the zip with the sourcecode for my tutorial on programming TCP/IP with Delphi, in it you will find some compiled applications. As in the case of TCP006, those are the finished .exe's, not "setup" type programs. The one you need is TCP002.
If you have set up your own ArduSimpSrv, at 192.168.0.242 (you can change the IP address) on your LAN, or if my demo is up at mon7nc.dyndns.org, then download TCP006 or TCP002. Run it. Put 5202 in for "port", put 192.168.0.242 or mon7nc.dyndns.org in for "server", and click "Send" (or "Cmd BB: Static reply"). If the server is running, you should get "G:01 +031.93" back. (That is what TCP002 and TCP006 "translate" the "$BB $82 $01 $01 $01 $FF $FF" it received into.)
TCP002 is a little fragile. Stop it and restart it if you want to change parameters. Make the changes before hitting "Send". TCP002 creates an .ini file someplace on your disk, by the way. In your Windows directory, I think. Sorry. I believe that it at least uses a sensible name, "TCP002... something".
TCP006 is more sophisticated, but not open source.
Once you have that working, new ideas will arise. Re-save TCP004 as TCP005, change the program's name in the rems at the top of the program. We are going to make TCP005 do some rather fancier things than TCP004 did. The new stuff is relatively trivial, and doesn't give away any new secrets of doing client / server work... but it turns the program into something more interesting than TCP004!
(Recall that if it suits you better, you can just download the finished ArduSimpSrv code, TCP005.)
The next bit, an early use of an LED, can be skimmed over... but bits of the following will be carried forward into the "final" TCP005.
When turning TCP004 into TCP005, the first thing I did was add an LED (with a resistor) on digital line 5. (I won't promise to keep it there... but where the LED is connected is defined by a single line in the program, "uint8_t bLEDpin=5;"... or some other number instead of 5. Don't change the "8" in "uint8"! (P.S.: Since writing this tutorial, I've revisited it, to move the LED we are talking about, among other things. Mr. Murphy was watching... I moved the LED to digital line line 8, so now there are two "8"'s in the correct version of the bLED setting line, but I trust you to keep your 8's straight. "8" is a lucky number to many, many people, after all! <^_^>)
Before you connect your LED, you should know that you're going to want to have it shine on the light sensor which we will add in a minute. I wired the LED from the digital line to ground (through the usual resistor), as I find it less confusing to have setting line high ("on") turn on the LED. (The LED on line 13 of my Ethernet Pro seemed to have some problem... it didn't "work" right for some reason. Anyway... it would have been hard to get the light sensor "looking" at it.)
You can get things going nicely by...
Create a global boolean called boLEDOn. Create two subroutines: LEDOn() and LEDOff(). They... not too surprising, I hope, turn the LED on and off.... and they make the state of boLEDOn whatever it should be. In Setup() configure the pin for output, and call the LEDOn() subroutine.
Just before....
c.write(response,r-response);
... add...
if (boLEDOn) {LEDOff();} else {LEDOn();};
Hey presto! Now anyone watching the actual ArduSimpSrv can see each time a $BB $82 command is issued.
(That little escapade was just a quick way to be sure the LED hardware is working right, and to check that the LEDOn() and LEDOff() routines were built correctly. The changing of the LEDs state each time a $BB $82 command comes in is not included in the version of TCP005 shown below.)
Next, add a light sensor on analog input 1. (I.e., the second one, the one after "AnalogIn0".) As with the LED, you can put the sensor on the analog port of your choice. The code below assumes it is on Analog1.
Now we need to...
This document, sheepdogguides.com/arduino/art5SimpSrv.htm, is the definitive documentation for the ArduSimpSrv client/server protocol, by the way.
I've decided on the following rules for my commands....
Commands will consist of two bytes.
The second byte will be the inverse of the first. This will provide a crude "checksum"-like check that a command is valid.... not that, for the moment, that the program is doing any clever error handling or reporting. It looks at what it got. If it is a valid command, it processes it. If not, it ignores it.
"Commands" $00-$0F are reserved for the internal use of client software, and should never be sent to the server
I'm grouping my commands as follows....
All responses, including the acknowledgement of a "responseless" command, will begin with the first command byte. (This is to make parsing of the replies easier... if you know what command is being replied to, it is easier to know what the format of the reply ought to be!)
(I will "speak" in hex, throughout....)
The first nibble of the commands in the categories a-d above will be 5-8, respectively. In other words, to take an example, the command $58 can be expected to be something that requires no parameters, and returns nothing more than an acknowledgement.
"Turn LED off" is a good example. To that, I am assigning the command $50.
"Turn LED on" will be assigned to $51.
"Read Light Sensor" will be assigned to $71, because the sensor is on channel 1. (Eventually, it will probably make more sense to use an $8x command, and send the "which channel" datum as a parameter... but for now we will keep things simple.
(It doesn't, of course, have to be a light sensor connected to the analog input, but I will keep speaking of light sensors, to keep the example concrete.)
I said that the commands would consist of two bytes. With the "checksum" second byte, our commands are.... in addition to the legacy $BB $82, which is now rather redundant and pointless, we have...
We will acknowledge all $5x commands with three bytes as follows: The first byte will merely be the command itself, "said" back to the client. The second byte will be the original command byte AND'd with binary 01010101. The third byte will be the original command byte XOR'd with binary 01010101. This simple scheme will not be hard to program, and it will give us some indication, at the client, that the command we sent was received by the server. (This may not be my greatest bit of design, but it will do to put down a "marker" for something which may one day be improved!) (Thus: $50 will be acknowledged with $50$00$05; $51 will be acknowledged with $51$00$04)
The "Read light sensor" command will return...
the command, repeated back ($71),
the original command byte AND'd with binary 01010101,
followed by two more bytes, giving the value seen on the analog input, MSB first.
That will be followed by the exclusive OR of the two bytes, again a basic checksum.
So: A $71 command, when Analog1 is seeing $1234 will return $71$51$12$34$26.
... I am going show you farther down this page!!! (The online ArduSimpSrv runs the fancier code, which responds to all the commands described here. The online demonstrator ArduSimpSrv has the promised LED and light sensor connected to it.
A little diversion: The ArduSimpSrv also makes a little "beep" each time it processes a client request. All of the relevant code is pretty straightforward. Search for lines with "Beep" in them. And now, back to work...
Before I deal with that code, I am going to implement another command: $7F. When a $7F is issued, it will be sent with it's inverse ($80), and will cause the ArduSimpSrv to return: The command byte ($7F) AND'd with binary 01010101: $55, followed by a two byte number, MSB first, showing the number of times it has processed a pair of bytes from the client since it was booted, followed by those two numbers XOR'd. Thus, if $1233 commands have been processed, and the ArduSimpSrv receives a $7F$80, (the checksum byte for $7F is $80), then the ArduSimpSrv will respond with: $7F$55$12$34$26. (It responds with $1234, because it counts the command just received, before answering.)
First we'll create a global variable for that, calling it iCommandsAccepted. We will initialize that to zero in Setup(). We will increment it by one just after the lines...
uint8_t b1 = c.read(); uint8_t b2 = c.read();
Even without implementing the $7F command, we can see that is working, simply by adding....
Serial.print(" ");
Serial.print(iCommandsAccepted);
... just before the debugging line...
Serial.print("\n");
... and then watching iCommandsAccepted go 1, 2, 3, 4... by using the serial monitor. As we know it is working, the next thing is to implement $7F, so the client can see how many commands have been processed. This, however, will require not only changes to the code in the ArduSimpSrv, but also in the client software. So be it! But ArduSimpSrv's changes first...
You won't see any scraps of the following ugly kludge in the final TCP005... but just as an illustration of the things you can do...
While I was developing TCP005, and had got this far, I used the $BB $82 handler to see if I was going to be able to return iCommandsAccepted to the client. I just changed...
*r++ = 0xBB;
*r++ = 0x82;
*r++ = 0x01;
*r++ = 0x01;
*r++ = 0xFF;
*r++ = 0xFF;
... to....
*r++ = 0xBB;
*r++ = 0x82;
*r++ = 1;
*r++ = 01+(iCommandsAccepted >> 8);//1 + MSB of iCommandsAccepted
*r++ = iCommandsAccepted & 0xFF;//LSB of iCommandsAccepted
*r++ = 0xFF;
...for long enough to see if I was on the right track, and then put the code back, and settled down to a "proper" $7F handler. That is a messy kludge, make complicated by various factors to do with what the client software is doing with the two bytes we messed with, the fact that problems arise if either is zero, etc., etc.... but when you learn to eschew the temptation of trying something quick and dirty, I will redouble my efforts in the same worthwhile direction.
The $7E command: I have created a $7E command... but not tested it yet! The job of the $7E command is to return a string to the client to tell the client which version of the ArduSimpSrv the client is dealing with.
The $7E command will cause the ArduSimpSrv to return: The command byte ($7E) AND'd with binary 01010100: $54, followed by three bytes number, MSB first, showing the version of the software, as defined in the bVerMostSB, bVerMidSB and bVerLSB bytes, followed by the last two numbers XOR'd. Thus, if the version is $00$01$02, and the ArduSimpSrv receives a $7E$81, (the checksum byte for $7E is $81), then the ArduSimpSrv will respond with: $7E$54$00$01$02$03.
In TCP004, there is a section that looks like this....
// Deal with the connection
if ((b1 == 0xBB) and (b2==0x82)) {
// N.B.. Maximum size of response is 68 bytes (enough for 32 sensors)
uint8_t response[68];
// Create a response
uint8_t *r = response;
*r++ = 0xBB;
*r++ = 0x82;
*r++ = 0x01;
*r++ = 0x01;
*r++ = 0xFF;
*r++ = 0xFF;
// Send response
c.write(response,r-response);
We're going to create some subroutines which will process the different commands. They will be called "ProcessBB82", "Process7F80", etc. We'll come to those in a moment. For now, we'll revise the above, making it more clear....
// Deal with the command
if ((b1 == 0xBB) and (b2==0x82)) {ProcessBB82};
if ((b1 == 0x7F) and (b2==0x80)) {Process7F80};
// Send response
c.write(response,r-response);
... and no, of course that won't work until we've taken care of some other things.
First of all, the c.write(response,r-resonse) was inside the block processed only if the condition of the "if" was met. To avoid needing multiple instances of c.write(..., I have introduced a new global boolean variable, boValidCommand. Inside each command processing subroutine, it is set true. It is used thus...
// Deal with the command..
boValidCommand=false;//set true within command processors
if ((b1 == 0xBB) and (b2==0x82)) {ProcessBB82};
if ((b1 == 0x7F) and (b2==0x80)) {Process7F80};
// Then, if command seen, send response...
if (boValidCommand) c.write(response,r-response);
Unfortunately, my grasp of pointers is imperfect, and I had to "mess with" the way the string of bytes accessed by c.write was defined. Here's enough of the working code, at this stage, to show you how I got out of the corner I'd painted myself into....
(snip...)
uint8_t response[68];
// N.B. Size of response limited by what you put in prior line.
// Be careful not to overrun the buffer.
uint8_t bRespLen;
boolean boValidCommand;
(snip...)
void ProcessBB82(){
uint8_t *r = response;
*r++ = 0xBB;
*r++ = 0x82;
*r++ = 0x01;
*r++ = 0x01;
*r++ = 0xFF;
*r++ = 0xFF;
bRespLen=6;
boValidCommand=true;
}
void Process7F80(){
(similar)
boValidCommand=true;
}
(snip...)
void loop(){
Client c = server.available();
if (c.connected()) {
Serial.print("Incoming connection!\n");
// Read two bytes from client
uint8_t b1 = c.read();
uint8_t b2 = c.read();
++iCommandsAccepted;
(snip debugging lines...)
// Deal with the command...
boValidCommand=false;//Set true within a command processor, if one found
if ((b1 == 0xBB) and (b2==0x82)) ProcessBB82();
if ((b1 == 0x7F) and (b2==0x80)) Process7F80();
// Send response
if (boValidCommand) c.write(response,bRespLen);
};//End of if c.connected (then...) block
(snip final lines)
From the above, you can see the essence of everything that is left to reach the goals we set at the outset. The details can be found in the following code. TCP002 can interact with the improved, multi-command serving ArduSimpSrv, but it will only send the rather dull $BB$82 command, and receive the rather dull $BB$82$01$01$FF$FF, which TCP002 translates into "G:01 +031.93"... but it WILL "work" with TCP002 as client.
To see the other commands served, you have to use TCP006. Be sure you have a version from after 6 October 2011. The version ID is the date in the window's title bar. (Some preliminary versions were released, which did not have all the features available now.) You can turn the LED connected to online demonstrator ArduSimpSrv on and off. You can see readings from the phototransistor connected to one of its analog inputs. (You'll get about 00004 when the LED is off, something a little over 00100 when it is on.) You can see the number of times the server has responded to a request since it was last booted. It still can send the rather pointless "BB" command... It sends a $BB$82 command, which gives rise to a fixed response that is "translated" into "G:01 +031.93" if all is well. The command and the response are scraps of where this project began, and do not represent anything meaningful at the moment!)
You can tell the software to read the device repeatedly. If you turn this on, please do not set the read frequency to more than once a minute, if you want to leave it running for a while. In fact, probably best not to leave it running for extended periods, unless you are really, really keen. For short tests, feel free to read at the maximum once per second... but remember that others out there may want to play, and if too many people are reading at once per second, you may "break" the ArduSimpSrv. It is easier to bring down with a denial of service attack than, say, eBay.
There's lots of work to be done on TCP006 still, to make it robust and user friendly... but you can already see what is possible! I hope you like it... it took hours and hours to create! I'm sorry to say that the sourcecode for TCP006 will not be released. The basics behind it are explained here. The "frills" are my "trade secret", for a commercial app I am working towards.
If you have actually done all of the above, so far you have a ArduSimpSrv which can be accessed with client software running on any PC on your LAN.
To make your ArduSimpSrv "visible" to the world, you "only" need do xxx the same things done to make either of my ArduServers visible to the world. Eventually, I hope to split that information off into its own page. For now I fear I must ask you to read through the tutorial on ArduServer2, where the information does reside. I apologize for making you dig through the ArduServer2 stuff to find the bits you need. There's not "a lot"... when you know how. You need a domain name, i.e. something like my mon7nc.dyndns.org (although it can be simpler, if you like!). You need a way to keep the DNS appraised of the current IP address of your domain. You need to configure your firewall and anti-malware software to allow requests from clients into your LAN. That's "all". <^_^>
I've done a separate guide to why you need, how to set up dyndns service.
The sourcecode for the finished ArduSimpSrv is hosted on its own page. You just copy and paste from that page to your Arduino compiler/ uploader.
I hope that was useful. Let me know if there are areas which weren't adequately explained? Let me know what "Gotchas" got you?
(I also hope that not too many people read this page before the link to the complete sourcecode was inserted! Sorry!)
Page tested for compliance with INDUSTRY (not MS-only) standards, using the free, publicly accessible validator at validator.w3.org
CSS behind the page checked, at least once upon a time!, with http://jigsaw.w3.org/css-validator/
Why does this page cause a script to run? Because of the Google panels, and the code for the search button. Also, I have some of my pages' traffic monitored for me by eXTReMe tracker. They offer a free tracker. If you want to try one, check out their site. Why do I mention the script? Be sure you know all you need to about spyware.
....... P a g e . . . E n d s .....