Esp8266 ed http, che fatica!

Operazioni di restauro della stazione meteo, allagata e poi ripristinata con un nuovo circuito stampato, qualche sensore nuovo, connettori stagni e fori di sfogo dell’umido. Una persona ragionevole pensa “il più è fatto” e “basta rimettere il software vecchio e tutto funzionerà come prima”. Nemmeno per sogno. Il software vecchio funziona, ma non carica i dati sul server.

Il caricamento dei dati sul server avviene attraverso un banalissimo script PHP che viene invocato da un GET HTTP, con tutta una serie di parametri, una cosa di questo tipo:
http://192.168.x.y/meteo/add.php?temperatura=19.48&umidita=77.29&pressione=995.74&dewpoint=15.40&direzione=234.45&velocita=7.22&pioggia=0&sensore=tetto

Sul server la cosa funziona così:
192.168.x.r – – [20/May/2018:19:38:36 +0200] “GET /meteo/add.php?temperatura=22.68&umidita=52.19&pressione=99696.80&dewpoint=12.38&direzione=234.45&velocita=1.03&pioggia=0&sensore=tetto HTTP/1.1” 400 0 “-” “-“

Tutto finisce con un “400, bad request”. Se la chiamata viene inviata da un browser (copia ed incolla della STESSA stringa), tutto funziona:
192.168.x.k – – [20/May/2018:19:38:43 +0200] “GET /meteo/add.php?temperatura=23.22&umidita=50.15&pressione=99699.11&dewpoint=12.27&direzione=165.76&velocita=6.91&pioggia=0&sensore=tetto HTTP/1.1” 200 453 “-” “Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36”

Ho cercato informazioni in rete ed ho visto che il protocollo HTTP, con il metodo GET, richiede che siano passati una serie di parametri al server:
GET
Host
User-Agent
Connection

Ottime informazioni si trovano su questo link. In pratica RFC che descrive il protocollo. Una prima versione del mio firmware inviava una stringa senza “user-agent”. Aggiunto questo parametro l’errore è rimasto. Il debug del problema lo ho effettuato con tcpdump sotto linux, impostando l’opzione “-vvv”, che analizza completamente il protocollo. Analizzando bene il traffico, ho notato che il campo host era valorizzato in modo errato. Come si evince dal RFC, la mancata valorizzazione del campo comporta un “bad request” da parte del serve. Ho modificato il codice impostando il campo “host” a “localhost” e tutto ha iniziato a funzionare. Vabbè, ho perso 3 giorni di tempo, sono stato due ore sul tetto ma ho imparato un sacco di cose! Di seguito l’analisi del protocollo fatta con tcpdump.

GET /meteo/add.php?temperatura=19.54&umidita=72.92&pressione=99537.58&dewpoint=14.55&direzione=94.69&velocita=0.00&pioggia=0&sensore=tetto HTTP/1.1
Host: localhost
User-Agent: wget/1.12
Connection: close

Questo invece il codice in ESP8266:

void http_client(){
Serial.println(“HTTP CLIENT: ———————————————————————–“);
Serial.print(“Host: “);
Serial.println(host);
Serial.print(“Port: “);
Serial.println(httpPort);
if (!WFclient.connect(host, httpPort)) {
Serial.println(“connection failed”);
++wrong;
error_flag=1;
return;
}
String agent = “wget/1.12”;
String hosth = “localhost”;
delay(100);
String url = “/meteo/add.php?”;
url += “temperatura=”;
url += temp;
url += “&umidita=”;
url += humi;
url += “&pressione=”;
url += pres;
url += “&dewpoint=”;
url += dewp;
url += “&direzione=”;
url += wdirection;
url += “&velocita=”;
url += wspeed;
url += “&pioggia=”;
url += pioggias;
url += “&sensore=”;
url += sensore;

Serial.print(“Requesting URL: “);
Serial.println(url);

WFclient.print(String(“GET “) + url + ” HTTP/1.1\r\n” + “Host: ” + hosth + “\r\n” + “User-Agent: ” + agent + “\r\n” + “Connection: close\r\n\r\n”);

unsigned long timeout = millis();
while (WFclient.available() == 0) {
if (millis() – timeout > 10000) {
Serial.println(“>>> Client Timeout !”);
WFclient.stop();
return;
}
}

E per adesso… funziona.