I have been trying to pull all the pieces together for having an Arduino measuring/controlling stuff that interacts with a web page on a simple server (Apache running on my Ubuntu system). I can find various tidbits and examples of parts of it but I have not been able to find a book or other good documentation that presents the pieces in one place. There have been lots of responses to others working on the same issues along the lines of "that is simple, just do xyz" or "you don't have a clue what you are doing", but does anybody have any good recommendations for a book (recent) that has the all the parts explained? Yeah, I've read the GET/POST information on the W3 site etc. Unfortunately, if you search for IOT or that sort of thing, you find LOTS of books and information oriented towards big commercial type things with many layers. I am looking for something that ties basic client/server applications together with GET/POST (I have php on the server), but have apparently not managed to get the right search terms. Suggestions for good reading / reference material appreciated.
I found https://www.ntu.edu.sg/home/ehchua/programming/webprogramming/HTTP_Basics.html to be very useful.
I modifed the example WebServer sketch included with the IDE installation to be able to handle GET or POST data.
GET data is easy. POST data is a bit harder.
Which Arduino?
If you are talking about the Uno/Mega then I'd say forget about it the results are at best poor and you are forcing them to do something they where not designed to do.
If you are talking about the Yun then you put the client/server on the linix side in which case you will find lots and lots of info (including books) out there.
Mark
The Arduino was not intended as the web server - it is simply going to be taking temperature measurements, controlling the heater and passing the measurements along to the main server (with mySQL running behind it for logging the data/times). I will check out the link provided by ieee488 - that should help. (my current plan is some form of Arduino - either uno or smaller that handles the measurements and PWM into a FET for power control and then sends the data to the main server via ESP8266 using GET so the actual loading on the Arduino should be fairly minimal.
The w5100 base ethernet cards usually have an SD card holder, so large web files can be served from the SD card. A large web page can be served from another server elsewhere and just contain appropriate links to the arduino web server itself.
No no - the Arduino will only be a controller that periodically "reports in" to the server on the Ubuntu Linux machine with current temperature and power information (using wifi) via a HTTP GET. Without the wifi part, it is currently running on a little PIC processor with lots of room to spare in FLASH. It is a heater for the hummingbird feeders for when we get the periodic cold snaps here in the Seattle area (the resident Annas hang around all year so they are happy when the syrup is not frozen on those very cold nights).
What I was looking for here was some pointers to good books or info that helps tie all the little pieces together (like the examples Zoomkat has posted etc.)
Basic client test code you might modify and add the data reporting to for sending to the server.
//zoomkat 3-1-13
//simple client checkip test
//for use with IDE 1.0.1 or later
//with DNS, DHCP, and Host
//open serial monitor and send an e to test
//for use with W5100 based ethernet shields
#include <SPI.h>
#include <Ethernet.h>
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; //physical mac address
char serverName[] = "checkip.dyndns.com"; // test web page server
EthernetClient client;
//////////////////////
void setup(){
if (Ethernet.begin(mac) == 0) {
Serial.println("Failed to configure Ethernet using DHCP");
// no point in carrying on, so do nothing forevermore:
while(true);
}
Serial.begin(9600);
Serial.println("Better client ip test 3/1/13"); // so I can keep track of what is loaded
Serial.println("Send an e in serial monitor to test"); // what to do to test
}
void loop(){
// check for serial input
if (Serial.available() > 0) //if something in serial buffer
{
byte inChar; // sets inChar as a byte
inChar = Serial.read(); //gets byte from buffer
if(inChar == 'e') // checks to see byte is an e
{
sendGET(); // call sendGET function below when byte is an e
}
}
}
//////////////////////////
void sendGET() //client function to send/receive GET request data.
{
if (client.connect(serverName, 80)) { //starts client connection, checks for connection
Serial.println("connected");
client.println("GET / HTTP/1.1"); //download text
client.println("Host: checkip.dyndns.com");
client.println("Connection: close"); //close 1.1 persistent connection
client.println(); //end of get request
}
else {
Serial.println("connection failed"); //error message if no client connect
Serial.println();
}
while(client.connected() && !client.available()) delay(1); //waits for data
while (client.connected() || client.available()) { //connected or data available
char c = client.read(); //gets byte from ethernet buffer
Serial.print(c); //prints byte to serial monitor
}
Serial.println();
Serial.println("disconnecting.");
Serial.println("==================");
Serial.println();
client.stop(); //stop client
}
I am looking for something that ties basic client/server applications together with GET/POST (I have php on the server), but have apparently not managed to get the right search terms. Suggestions for good reading / reference material appreciated.
Well, IoT is all pretty new, Arduino is pretty niche, and - I don't want to sound like a jerk here - it isn't really all that difficult. The bits bolt together in a straight line.
The Arduino does some stuff, and at intervals it wakes up ethernet and sends a HTTP message (It really should be a POST, you know) to the webserver. The webserver catches it with some revolting php so-called computer language (dammit: I really have to learn php), and stuffs the gear in a database. Some other php serves it up in response to a web request as nicely formatted HTML, possibly with one of those thingamajig headers that tells the browser to refresh the page at intervals.
Each of these bits can be coded and tested by itself - it's not one big mess of code that either all works or all doesn't work when you switch it on.
If there's a web page on making an arduino thermostat that drops data onto an apache webserver, you are probably going to have to write it. Which, incidentally, is something you should totally do.
I don't want to sound like a jerk here - it isn't really all that difficult. The bits bolt together in a straight line.
So where is your "it isn't really all that difficult" code?
Thanks for the example Zoomkat. I will experiment with it shortly (this all reminds me of my college days ... back in the early 70's !! Where it was either "intuitively obvious" or "left as an exercise for the student" 
As far as Php goes, the book "Php and MySQL web development" is fairly good.
Actually, as far as GET vs POST goes, (correct me if I'm wrong in my understanding here), while GET is less "secure" because it passes the parameters in the url, that very fact makes it ideal for my purpose for debugging since I can create an url with the parameters stuck on as a test, create a bookmark for that and then use that to verify my php page on the server is handling the information correctly THEN I can work with the Arduino code to make it send the same information (there is nothing about the information being passed that is "sensitive" simply temperature and power information). POST would be harder to debug since you can't create that from a simple url pointing at the php page on the server.
One question on the MAC address - I notice that lots of the examples I have seen seem to have an arbitrary MAC address stuck in (zoomkat's example uses
byte mac[] = { 0xDE, 0xAD, 0xBE, 0xEF, 0xFE, 0xED }; //physical mac address
I realize that unless they are actually talking to each other on a LAN with no hops, the MAC address should not really matter as long as they are not the same. Does anybody actually bother to find the real MAC address? I notice with the ESP8266, you apparently have to query it since it is not on the bottom like it is in most hardware I am familiar with. Seems odd that they don't print the mac address on the bottom though.
I notice with the ESP8266, you apparently have to query it since it is not on the bottom like it is in most hardware I am familiar with. Seems odd that they don't print the mac address on the bottom though.
I think that there is somewhat of a "registration" or allocation process for mac addresses on products that have a critical/sufficient need for a unique mac address. The arduino is a hobby product, so no real need for the extra process overhead. From what I understand the ESP8266 is made for use in commercial products, so unique mac addresses may be necessary to prevent possible conflicts in consumer products using the ESP8266 chips.
The Arduino doesn't need a MAC address since it is not connecting to the Ethernet, however, the ESP8266 (or a Ethernet shield etc.) do because they connect to the Ethernet. In general, the MAC address is a 48 bit number with 24 bits being vendor specific (vendor ID) and 24 bits being a "serial number". The MAC address only really will cause a problem if it matches another device on the same local segment of the network in most cases (TCP headers have the source IP destination IP and the mac of the device on each end of the local segment which gets changed as the packet moves through the network. From what I have read, the ESP8266 does have a MAC address you can retrieve with a query to it (although I'm not sure how good they have been about using unique numbers - maybe they all have the same one although I didn't find any comments to that effect). The IP addresses in the packet (src, dest) only change through the whole journey if they go through something using NAT for example. Using an arbitrary MAC address is probably fine on your local network until you try to put two or more of your devices on the same segment of the network with the same MAC address then odd things happen.