The ESP8266 modules are very commonly sold and can be picked up very cheaply.
The module itself looks like this.
These modules are 3.3 volts. so I bought a USB to UART (3.3v) module in order to experiment/test the ESP8266 from my computer.
The USB module looks like this once the ESP8266 is plugged into it.
Now there are heaps of examples of how you connect these up to Arduino boards or program them directly; most of the Arduino examples use nice wrappers to get the ESP8266 up and running really quickly, but I wanted to use only the AT commands from my PIC microcontroller project to connect to the internet and pass data to a web server, and also get data back from the web server.
After a lot of messing about (I mean lots and lots of pain and hurt!) I found a nice workflow that worked for me; that's not to say it will work with your module as these modules slightly vary between the firmware versions.
The process below describes using the ESP8266 with AT commands to pass data to a web server and then see the returned data from the web server.
For example, to send a web server the temperature read by your microcontroller.
eg. http://myserver.com/mypage.aspx?t=120
What I did was create a c# console app to connect to the ESP8266 using the serial port and send it all the AT commands it needed to call a test aspx page on a web server which then returned some dummy JSON back to the module.
The first thing I did was use Realterm on the PC to connect to the ESP8266 using the 115000 baud and slow that down to 9600, if you need to do this you can do that by sending the "AT+CIOBAUD=9600\r\n" command; this is so when the ESP is talking to my project my microcontroller has more time to process the data.
The command sequence that worked for me was..
1. AT+RST\r\n
2. AT+CWMODE=1\r\n
3. AT+CIPMUX=0\r\n
4. AT+CIPSTART="TCP","X.X.X.X",80\r\n
5. AT+CIPSEND=N\r\n"
6. (GET command, see notes)
7. AT+CIPCLOSE\r\n
Step 4, when I tried initially using "http://myserver.com" all I got from the ESP8266 "400 Bad Request" so, if you're having issues try the server IP address instead.
Step 5, N is the total number of bytes sent in the GET request; the only gotcha is to count these properly, in c# you can count the length of a string using strMyString.Length, this will cater for the "\r\n" characters in the string. i.e "/r/n" is 4 characters but it's 2 bytes long.
Step 6, this to me was the odd part, in that the GET request seemed to fail but work on some servers; now, I think the issue was the GET request headers didn't match the requirement of the web server.
The headers that worked for me were..
url_get = "GET http://myserver.com/mypage.aspx?t=120 HTTP/1.1\r\n " +
"Host: myserver.com\r\n " +
"Connection: keep-alive\r\n " +
"Accept-Charset: ISO-8859-1,UTF-8;q=0.7,*;q=0.7\r\n" +
"Cache-Control: no-cache\r\n " +
"Accept-Language: de,en;q=0.7,en-us;q=0.3\r\n" +
"\r\n";
I may have over-cooked them a little but it seemed to work fine.; you could play around and reduce them down to the minimum required by the web server.
Note: if you use HTTP/1.0 you don't require the "Host" header but if you use HTTP/1.1 you need to add that to your GET call.
Sending the commands it quite easy, but the tricky part is parsing the buffer of returned bytes in a way that triggers the next command in the sequence; as you don't want to send the next command until the previous command has finished. So, in the c# code I created a routine to check the serial read buffer for a particular string match; the required strings I used for the step sequence above were..
Step 1. If you use this prior to your calls you need to look for "WIFI GOT IP\r\n"
Step 2. "OK\r\n"
Step 3. "OK\r\n"
Step 4. "OK\r\n"
Step 4. "OK\r\n"
Step 5. ">" The > is the prompt for you to input the GET command string
Step 6. Once the GET has completed you can look for the ":HTTP/1.1 200 OK" string, and within that buffer of bytes; also within that buffer it will tell you how many bytes are returned; this appears in the "+IPD," part of the string; in my case, it looked like this..
Here you can see the string "+IPD,357" so this tells us there are 357 bytes in our buffer of returned bytes from the server, so you can then process through the buffer and pull out all the info you need.
I hope this helps anyone wanting to implement the ESP8266 in their project using only the AT commands.
