wow, thanks for the report. i cannot believe i forgot to include that in my header =(
at least it is a "simple" mistake in that it is not an issue with the fundamental code base used in the project.
i will make the change. i also look forward to hearing about the other bugs you discovered.
i am glad you like the code. i have no issues with you using it, that is why i posted it here 
8)
pico:
I've been adapting your ARECS code as a demo to connect to the Internet using my wireless RFXduino system, and you'll be pleased to hear that in the process I found your browser bug!It's a doozy, actually. Basically, you were forgetting to send response headers before your html in your sendPage() function! So instead of getting
HTTP/1.1 200 OK
Server: arduino
Cache-Control: no-store, no-cache, must-revalidate
Connection: keep-alive
Content-type: text/html
Automated Reptile Environment Control Systembody {font-family: Verdana, Arial, sans-serif;background: #fff;margin: 0px auto;padding: 0 0 20px [...]by way of a response, the browsers were just getting hit directly withThe differences in the browsers behavior just reflected how they individually handled the (fairly extreme) situation. IE10 and Chrome were the most liberal, simply recognizing it as html, and assuming some default response header values that seemed to work pretty well. Firefox was a bit more conservative, and treated it as text/plain rather than text/html content-type, and so it would show a nice screen full of html tags. Safari just turned it's nose up at the whole thing and did a good job of pretending it didn't receive anything. As I was debugging this today, it took a while for the penny to drop, as it didn't occur that browsers like IE and Chrome could work at all without getting some sort of response headers. It was looking a FF "View Page Info" that first alerted me to the fact that the content-type was being set as "text/plain" rather than "text/html". How could that be? Something subtly wrong with the response headers? Well, yeah... like they were completely missing! :) Anyway, I also found a few other less serious bugs, which I will document more fully after I've had a bit more of a play with and test the system, but I thought I'd give you all a quick heads up on the "incompatible browser" issue. I've got it working using RFXduino with IE10, Chrome (WIndows and Android), Firefox (Windows and Android), and Safari (Windows). Basic changes (should also work if using ethernet shield, although I haven't tested directly): In sendPage(), changesendProgMemAsString(client, (char*)pgm_read_word(&(contents_main[CONT_TOP])));
  //wdt_reset();
  //sendUriContentByIndex(client, nUriIndex, requestContent, 0, CONT_TOP);to// send response headers
  sendProgMemAsString(client, (char*)pgm_read_word(&(contents_main[CONT_HEADER])));
// send HTML header
  sendProgMemAsString(client, (char*)pgm_read_word(&(contents_main[CONT_TOP])));
  //wdt_reset();
  //sendUriContentByIndex(client, nUriIndex, requestContent, 0, CONT_TOP);
and in htmldata.h, changePROGMEM prog_char content_main_header[] = "HTTP/1.0 200 OK\nServer: arduino\nCache-Control: no-store, no-cache, must-revalidate\nPragma: no-cache\nConnection: close\nContent-Type: text/html\n";
toPROGMEM prog_char content_main_header[] = "HTTP/1.1 200 OK\r\n"
"Server: arduino\r\n"
"Cache-Control: no-store, no-cache, must-revalidate\r\n"
"Connection: keep-alive\r\n"
"Content-type: text/html\r\n"
"\r\n";Thanks for your nice system -- I hope you don't mind me adapting it as a demo for my purposes! It has some nice technical and design features that makes it quite a nice showcase program for my system, I think. In my configuration, all the SD card storage can be on the Raspberry Pi gateway device, and so it's like a mini "cloud" server for all the Arduinos connecting through it. Also, things like the RTC function are also virtualised, so the only thing the ARECS Arduino has to do in terms of real devices is manage the relays. I'm thinking I'll be able to get the fully converted program running on a 328 Uno-class board, but we'll have to see how converting the html strings from progmem to SD flash affects performance. But I thought you'd like a heads-up on the browser issue in the meantime.