Archivi tag: esp8266

Esp8266 – Low Power (parte 2)

Come promesso nel precedente articolo, ho fatto qualche (decina) di prove per cercare di ottimizzare il funzionamento del sistema ed essere sempre più parco nelle richieste energetiche.
Lo sketch di partenza è quello che ha funzionato nei precedenti tests, molto “quick and dirty” con notevoli margini di ottimizzazione.
I parametri principali rilevati sono stati:
– Corrente media: 53,3 mA
– Corrente massima: 272,1 mA
– Energia 177 uA/h

Sketch versione 1

Il primo passo di ottimizzazione ha previsto una ridefinizione del delay imposto prima della attivazione del sensore DHT. Ho fatto diverse prove ed ho trovato che 1,7s consente una ottima ripetibilità delle misure. Inoltre ho epurato alcune funzioni che erano “eccessive”. Il risultato è stato molto incoraggiante:
I parametri principali rilevati sono stati:
– Corrente media: 39,6 mA
– Corrente massima: 242,1 mA
– Energia 132 uA/h
Non male!

Sketch versione 2

Per l’ultimo test ho rimosso anche tutti i “serialprint” che avevo inserito per monitorare il funzionamento del sistema. Vero che non sono molto “costosi” in termini energetici, ma richiedono tempo per essere eseguiti. Ed il tempo è energia, soprattutto se sono usati durante il periodo di connessione di ESP.
I parametri principali rilevati sono stati:
– Corrente media: 39,5 mA
– Corrente massima: 248,4 mA
– Energia 131,8 uA/h
Visti i risultati li avrei potuti anche lasciare!

Sketch versione 3 – Minimale

Rimangono da risolvere due interrogativi:
– cosa succede inserendo il codice per la gestione di MQTT;
– quanto incide la presenza di una sensore di luminosità.

L’introduzione del codice relativo ad MQTT non ha effetti apprezzabili sul funzionamento del sistema. In fondo si tratta di un paio di funzioni che non hanno altro effetto se non quello di trasmettere qualche frame aggiuntivo alla fine dello sketch. Se la comunicazione si mantiene a rate elevato, l’impatto “energetico” è davvero modesto.

Aggiunta del codice MQTT

Con queste figure, faccio un rapido conto (nella speranza che sia giusto, altrimenti, accetto critiche e correzioni che siano sensate): 0.130 uA/h sono l’energia di un singolo processo di acquisizione e notifica. Ne vorrei eseguire 6 in un’ora, con un assorbimento di 7.8mA/h. Se ipotizzo una batteria da 1500mA, vengono fuori circa 8 giorni di funzionamento (sono ben 11520 cicli di acquisizione). Non ci siamo.

NB: ho chiesto di commentare ma i commenti sono disabilitati. Non sono impazzito, basta mandarmi una mail o un WA. Non ne posso più di pubblicità di farmaci e di cancellare spam dal mio blog.

Esp8266 – LowPower

Da qualche tempo mi sono fissato per rispondere ad una sfida: realizzare un sensore di umidità, temperatura che sia alimentato a batteria, Wifi e che mi garantisca una grande durata dell’accumulatore.
Lavorare in “low-power” è interessante in quanto impone di rinunciare a “tutto il possibile”, per potere contenere il consumo di energia del sistema. Inoltre impone di lavorare con dispositivi che supportino una modalità di “deep-sleep” e che non richiedano il bacio di un principe per essere risvegliati.
Visto che tutti i miei progetti sono basati su ESP8266 e che ne ho ancora “diversi” nel cassetto, ho voluto provare con questo micro. Le informazioni di partenza per questa avventura le ho prese da questo sito, davvero chiaro.

Il prototipo lo ho costruito attorno al sistema di sviluppo basato su “breadboard” che avevo realizzato (troppi) ani fa. Qualche falso contatto da ripristinare, qualche integrato da rimuovere ma alla fine ha funzionato tutto. Ho iniziato con qualche sketch base, per riprendere mano e per fare dei test con i singoli componenti poi mi sono concentrato su alcuni aspetti specifici:
– quanto influisce il metodo di assegnazione dell’IP sul consumo?
– quanto influisce la presenza di un sensore di temperatura sul consumo?

Assegnazione degli IP e consumo.
Il processo di assegnazione di un IP ad un dispositivo IoT può avvenire in due modi: statico o tramite DHCP. Nel primo caso è necessario interagire e configurare ogni dispositivo a mano, possibilmente tenendo traccia degli indirizzi usati.
Nel secondo caso ci pensa un protocollo a configurare l’indirizzo IP, sfruttando un paradigma client server e lo scambio di 4 messaggi.
Per fare questa valutazione mi sono avvalso di un “DC Power Analyzer”, Keysight N6705B, equipaggiato con un cassetto N6762A (opzione 2uA) e N6752A. In pratica è un alimentatore da banco regolabile, estremamente preciso e controllabile da remoto, con funzioni integrate di oscilloscopio e data logger. Un bel giocattolo.
Ho compilato due sketch, uno con assegnazione statica ed uno con assegnazione dinamica dell’IP ed ho effettuato un test della durata di pochi minuti, a parità di condizioni di connessione e parametri di alimentazione.

Test con assegnazione STATICA
Lo sketch prevede la connessione all’AP, una operazione di controllo della validità della connessione, la lettura dell’ADC ed il deep sleep per 10 secondi.
Test eseguito su 5 minuti e 30 secondi, avviando il data logger e partendo dalla condizione di “sensore spento”. Il funzionamento del dispositivo è monitorato attraverso la porta seriale (file datalogdata22.edlg).

Esp8266 – No DHCP Verticale: 50mA div

La figura mostra un blocco di esecuzione del codice. Connessione, lettura del valore e spegnimento in deep-sleep del dipositivo. La maggiore parte del consumo è imputabile alla trasmissione WiFi che, anche se in modo impulsivo, richiede parecchia corrente. Le operazioni di connessione sono evidenziate dalla figura seguente, uno zoom della immagine precedente.

ESP8266 – No DHCP

Lasciando al programma della Keysight la “briga” di analizzare 5 minuti di segnale acquisito, si ottengono i seguenti parametri:
– corrente media 26,5 mA
– corrente massima 271 mA
– Energia: 2,2 mA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,131 uA/h per l’esecuzione.

Test con assegnazione tramite DHCP.
In questa serie di test è stato compilato uno sketch che ha le medesime funzioni del precedente ma che non prevede assegnazione statica degli indirizzi IP. Il sistema è stato analizzato in modo analogo al caso precedente (file datalogdata24.edlg). La forma d’onda del singolo trasferimento è del tutto analoga a quella vista nel caso di assegnazione manuale dell’indirizzo IP.

ESP8266 – DHCP

Lo stesso si può dire per lo zoom delle fasi iniziali della connessione, come mostrato nella figura successiva.

ESP8266 – Connessione

Analizzando il solito “blocco” di 5 minuti si ottengono i seguenti valori:
– corrente media 7,2 mA (dipende da quanti run sono stati catturati)
– corrente massima 286 mA
– Energia: 598 uA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,602 uA/h per l’esecuzione.

Il DHCP non ha effetto? Beh, il suo effetto non è evidente. Lo scambio di messaggi previsto dal protocollo DHCP è molto rapido, in quanto l’AP che sto usando è “scarico” (solo 5 client connessi), è molto vicino e consente al dispositivo di connettersi con un rate elevato, cosa che minimizza l’impatto dello scambio di frames dedicati al DHCP. Inoltre il traffico del DHCP è caratterizzato dal trasferimento di pochi dati, visto che è un protocollo “lightweight”, pertanto il suo effetto è pressoché trascurabile. Questo risultato è un vero sollievo in quanto nelle applicazioni IoT, potere contare sul DHCP è una vera “manna dal cielo”.

Il sensore DHT22
Uno dei sensori più usati in ambito hobbistico. Semplice da collegare, non presenta tutte le idiosincrasie di altri che usano I2C ed è solo moderatamente “energivoro”. Ha un tempo minimo di campionamento di 2 secondi e assorbe massimo 2mA in fase di misura.
Per poterne apprezzare l’impatto sul mio sistema, ho sviluppato un nuovo sketch che preveda l’uso di DHCP e che esegua le seguenti funzioni:
– controllo di connessione WiFi;
– accensione del DHT22 tramite pin del micro ESP8266;
– lettura del valore di ADC;
– lettura dei valori di temperatura ed umidità;
– spegnimento in deepsleep (10 secondi);
(file datalogdata25.edlg ).

ESP8266 con sensore DHT22.

Analizzando il solito “blocco” di 5 minuti si ottengono i seguenti valori:
– corrente media 34,1 mA (dipende da quanti run sono stati catturati)
– corrente massima 295 mA
– Energia: 2,8 mA/h
Un singolo “blocco” di esecuzione (6 secondi) richiede 98,602 uA/h per l’esecuzione.

Sketch “verosimile”
Acquisire dei dati di temperatura ed umidità con tale frequenza è davvero eccessivo. Ho aumentato la durata del deep-sleep a 60 secondi, in modo da campionare ogni minuto.

ESP8266 – Campionamento ogni minuto

Analizziamo l’intera “ora” di acquisizione (file datalogdata27.edlg): quanto costa in termini energetici?
– corrente media 9,8 mA (dipende da quanti run sono stati catturati)
– corrente massima 295 mA
– Energia: 9,8 mA/h
Con una batteria da 1500mA/h, possiamo fare circa 6 giorni, al netto della autoscarica.
Pochissimo! Occorre ottimizzare:
– ridurre il tempo di esecuzione dello sketch, “limando” al minimo i delay per l’attivazione del sensore DHT;
– ridurre la potenza di trasmissione del modulo WiFi, tanto siamo in ambiente domestico;
Non ritengo molto conveniente cambiare il sensore che “pesa” 1.5mA, a fronte del costo della trasmissione del messaggio. Nella seconda parte del post, ulteriori misure dopo avere fatto qualche esperimento di temporizzazione

Esp8266 – Un progettino easy.

Ho realizzato diversi sensori di temperatura basati su ESP8266 e DHT22, ormai ho il codice pronto, diversi alimentatori a 5V o 3.3V e posso fare un deploy molto veloce.

Partendo da un sensore che avevo “pronto” e funzionante in ufficio, ho voluto fare alcuni miglioramenti per fare un po’ di esperienza ed imparare qualche cosa. L’obbiettivo che mi sono prefissato è il seguente:
– aggiungere un display 16 x 2 collegato con I2C al micro, per visualizzare umidità e temperatura;
– implementare un client MQTT per visualizzare i dati di consumo elettrico sul display.

I classici display 16×2 sono controllabili attraverso un protocollo che prevede collegamento in parallelo di diverse linee dati. Si trovano alcune interessanti informazioni in questo link. Questo approccio era molto carino ai tempi dei PIC, dove le linee di I/O erano molte. I dispositivi ESP non hanno, a parte rare implementazioni che integrano dei moltiplicatori di I/O, tutte queste linee. Meglio ricorrere ad un convertitore I2C. Sono dispositivi a bassissimo costo che si possono facilmente reperire su Aliexpress o ebay ad un prezzo ridicolo ( da 1 a 2 euro).

Sono basati su PCF8574T, prodotto dalla NXP e catalogato come “Remote 8-bit I/O expander for I2C‑bus with interrupt”: volendone banalizzare il funzionamento, è possibile controllare e leggere lo stato della porte I/O attraverso opportuni comandi sul bus I2C.

Per farlo interagire con ESP8266, mi sono trovato molto bene con la libreria LCD_I2C, nella versione 2.3.0.
L’oggetto LCD è istanziato con poche righe di codice, ed è poi accessibile con delle funzioni per il posizionamento del cursore e la scrittura dei dati:
int lcdColumns = 16;
int lcdRows = 2;
LCD_I2C lcd(0x27, 16, 2);

L’unica seccatura è quella di dovere caricare uno sketch dedicato alla scansione del BUS I2C per trovare l’indirizzo dell’expander. In rete si trovano diversi tutorial, completi di codice.

Le funzioni per il posizionamento del cursore e la scrittura dei dati sono molto semplici:
lcd.setCursor(0, 0); // Or setting the cursor in the desired position.
lcd.print("T=");
lcd.print(tempe);

In poche parole, il collegamento del display al modulo ESP ha richiesto davvero pochissimo tempo.

La gestione di MQTT ha richiesto un minimo di attenzione in più, soprattutto per capire “come fare cosa” e gestire in modo opportuno funzioni e temporizzazioni. Il broker MQTT è residente su un server linux. Il sensore deve collegarsi al broker, iscriversi ad un canale e mostrare sul display il valore della potenza attualmente impiegata a casa. Non voglio reinventare la ruota, pertanto rimando ad una ricerca su Google il reperimento delle informazioni sul funzionamento del protocollo.
Per il corretto funzionamento della libreria, bisogna prevedere “a monte” la connessione del dispositivo alla rete, via cavo o via wireless, come mostrato da queste righe di codice:
WiFiClient WFclient;
PubSubClient client(WFclient);

Una volta istanziato l’oggetto client, occorre connettersi al broker ed essere pronti a ricevere i messaggi pubblicati sul canale di interesse. La connessione è gestita direttamente nel loop, ed occorre assicurarsi che nel loop non ci siano inutili perdite di tempo:
void loop() {
if (!client.connected()) {
reconnect();
}
client.loop();


Le funzioni accessorie sono la “reconnect”, che gestisce la connessione al broker (ampiamente documentata in rete).

Altra funzione importante la callback che si occupa della ricezione e della visualizzazione del messaggio MQTT:
void callback(char* topic, byte* payload, unsigned int length) {
Serial.print("Message arrived [");
Serial.print(topic);
lcd.setCursor(0, 1); // Or setting the cursor in the desired position.
lcd.print("P=");
Serial.print("] ");
for (int i = 0; i < length; i++) {
Serial.print((char)payload[i]);
lcd.print((char)payload[i]);
}
Serial.println();
}

Mettendo insieme ESP8266, codice, un level-shifter ed un paio di regolatori, sono riuscito a creare questo “mostro” che legge la temperatura da un sensore DHT, la mostra su un Display e, in calce a questo, mette il valore della potenza “consumata” da casa che gli arriva via MQTT. Come ogni progetto ci sono delle criticità che devo risolvere:
– il display fa schifo. Si tratta di uno dei tanti 16×2 che ho comperato alle fiere ai tempi dei PIC16F84, quando con 50.000 lire ti potevi comperare qualceh 16F84, un paio di 628 e una manciata di display per fare qualche progettino nerd. Per risparmiare prendevo sempre i “non retroilluminati”. Solo che adesso non si legge nulla. Devo mettere un nuovo 16×2 con retroilluminazione o passare ad un OLED.
– la board è alimentata da un trasformatore DIN da 8V, pertanto ho inserito un ponte, un elettrolitico ed un regolatore a 5V. Solo che il regolatore scalda e devo inserire un piccolo dissipatore per evitare che si surriscaldi. Appena lo smonto per mettere il nuovo display, faccio anche questa modifica.

Possibilità di miglioramento:
– inserire un pulsantino per gestire altre visualizzazioni: temperatura esterna, potenza assorbita dalla heat-pump, potenza prodotta dall’impianto FV etc.
– provare un display oled.

Home Assistant – Mqtt e sensori custom

Grazie alla segnalazione di alcuni studenti del corso di “Laboratorio ICT per la nautica e la domotica”, mi sono imbattuto in Home Assistant, una piattaforma per la gestione domotica molto gradevole e ben funzionante. In passato ho usato OpenHAB, ho dato una occhiata veloce a Domoticz ma HA mi è piaciuto tanto che lo eletto a base per lo sviluppo di un nuovo progetto.
Ho diversi sensori a casa, volti alla misura della temperatura in alcune stanze “critiche”, delle condizioni meteo e dei consumi elettrici. I dati raccolti da questi sensori (realizzati su base ESP8266), sono trasferiti ad un server collettore usando il metodo POST in HTTP. Sul server ci sono alcuni script PHP che raccolgono i dati, danno una prima “scremata” e li inseriscono in un database MariaDB. La fruizione dei dati avviene attraverso un terrificante sito web interno, che, attraverso delle tabelle, organizza i dati e consente di tracciare dei grafici scegliendo una diversa base dei tempi. Tutto questo “accrocco” funziona in modo decente, non ho mai perso dati, tutto è catalogato ordinato e preciso. Ci sono anche dei difetti: aggiungere delle automazioni è piuttosto complesso, la visualizzazione dei dati è poco “user friendly”, manca una APP per potere gestire tutto comodamente da SmartPhone.

Una volta conosciuto HA, ho deciso di migrare (piano piano) i dati su questa piattaforma, facendo in modo che il sistema riconosca quanto già presente in rete, ed integrando a mano tutto il resto.
Il primo step è stato installare HA in modalità completa (Home Assistant Operating System) come macchina virtuale nel server di casa. Operazione davvero banale, grazie all’uso di libvirt ed al fatto che ho già altre VM per il monitoraggio della rete dati. La piattaforma è risultata subito perfettamente funzionante ed ha “riconosciuto” alcuni dispositivi come il mio smartphone e la TV. Per integrare altri dispositivi ho seguito due strade:
– uso dei plugin custom presenti nella community di HA o su GItHUB;
– uso “massivo” di MQTT.
La prima via, ha risolto il problema dell’integrazione dello split Daikin (che mi ha fatto penare davvero tanto) e dei router MikroTik. Con la seconda strada ho “sistemato” i sensori custom, senza la necessità di doverli riprogrammare.

Ho quindi installato il broker mqtt usando “mosquitto”, in ambiente linux e modificato lo script PHP che processa i dati in ingresso al server. Questo è stato arricchito da una riga che, sfruttando mosquitto_pub, consente di pubblicare su un canale i dati ricevuti e metterli quindi a disposizione di tutti gli oggetti mqtt.
exec("mosquitto_pub -h localhost -p 1883 -t '/csensors/".escapeshellarg($name)."/temp"."'"." -m ".escapeshellarg($json_string_temp));

exec("mosquitto_pub -h localhost -p 1883 -t '/csensors/".escapeshellarg($name)."/humi"."'"." -m ".escapeshellarg($json_string_humi));

Queste due righe di codice consentono di replicare i dati di temperatura ed umidità ricevuti dai sensori remoti sul sistema MQTT.
La verifica del funzionamento è semplice, basta usare
mosquitto_sub -h localhost -p 1883 -t '#' -v
per mettersi in ascolto su tutti i canali e verificare il corretto scambio di messaggi:
/csensors/xxxx01/temp {"sensore"="xxxx01","value"="24.20"}
/csensors/xxxx01/humi {"sensore"="xxxx01","value"="49.00"}
/csensors/yyyy01/temp {"sensore"="yyyy01","value"="33.00"}
/csensors/yyyy01/humi {"sensore"="yyyy01","value"="31.50"}
/csensors/xxxx01/temp {"sensore"="xxxx01","value"="24.20"}
/csensors/xxxx01/humi {"sensore"="xxxx01","value"="49.00"}


Una volta che i dati sono disponibili sul sistema MQTT, occorre istruire HA per poterli leggere ed elaborare. Per questa operazione è necessario modificare la configurazione del sistema. Io mi sono trovato molto bene con il componente aggiuntivo “Studio Code Server“, che avevo già usato per integrare il NAS e modificare la configurazione dell’oggetto TV.

Ogni dispositivo MQTT deve essere creato appositamente, istruendo HA sul canale da sottoscrivere, il valore da leggere ed i suoi attributi. Il file ha sintassi YAML e particolare cura deve essere prestata alla indentazione.
mqtt:
sensor:
- name: "Temperatura yyyy"
state_topic: "/csensors/yyyy01/temp"
unit_of_measurement: "°C"
device_class: "temperature"
- name: "Umidita yyyy"
state_topic: "/csensors/yyyy01/humi"
unit_of_measurement: "%"
device_class: "humidity"


Terminata la redazione del file di configurazione è necessario riavviare HA per fare in modo che i dispositivi vengano integrati nelle “entità”. A questo punto è immediato aggiungerli ad uno dei tanti pannelli di controllo e visualizzazione che si possono creare.

Energy Meter

Finalmente, dopo solo 5 anni, sono riuscito a (quasi) finire il progetto dell’energy meter. Detta in poche parole, si tratta di un misuratore di energia Pzem-001 di provenienza Aliexpress (12 euro), collegato ad un ESP8266. Il microcontrollore, ogni 30 secondi circa, legge il valore di potenza, tenssione, corrente ed energia e li inserisce in un database.
Visto che c’era spazio, ho anche installato un sensore di tensione ed una sonda di umità e temperatura (DHT-22), in modo da rendere l’acquisizione dati il più completa possibile.Il sistema è alimentato con una batteria tampone, in modo da potere inviare allarmi in caso di mancanza dell’energia elettrica.

Allo stato attuale mancano una decina di saldature per finire tutto il lavoro, ma conto di finire quanto prima. I dati nel database sono poi processati da una serie di script PHP per generare grafici ed analizzare il consumo di energia elettrica nel tempo. Con questo “semplice” sistema mi sono reso conto che:
– l’investimento nei 5kW è stato necessario, spesso e volentieri “buchiamo” i 4kW di assorbimento, per periodi ben maggiori dei 3 minuti;
– la linea “contatore-quadro” è molto lunga e realizzata con cavi di sezione non adeguata. Questo comporta il fatto che quando l’assorbimento di corrente sale, la tensione scende (maledetto Ohm), fino a tensioni molto basse (sotto i 200V).
– l’andamento della tensione a parità di carico è interessante: il massimo di tensione è nelle ore diurne, quando la produzione dal solare è massima.

Progetti per il futuro:
– finire le 2o saldature che mi consentiranno di leggere la presenza di tensione in uscita dai sezionatori;
– implementare un po’ di “intelligenza” che invii allarmi in caso di mancanza di energia elettrica;
– implementare qualche algoritmo che sia in grado di capire se qualche cosa non va, ad esempio se abbiamo scordato il ferro da stiro o il forno acceso;
– implementare un allarme in caso di superamento di alcune soglie di assorbimento (sonoro, con un buzzer o su una APP).

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.

Esp8266 – No WiFi Connection

Dopo l’allagamento della mia stazione meteo, ho deciso di riprogettare tutto il sistema. Ho quindi realizzato un circuito stampato in modo da abbandonare per sempre la realizzazione filata su mille-fori. Il PCB lo ho disegnato con Eagle e realizzato presso Millennium Dataware, come sempre. Ho dovuto correggere qualche piccolo errore derivante dalla poca attenzione e massima fretta nello sbroglio delle piste, ma tutto ha funzionato bene. Almeno dal punto di vista elettrico.

Nel momento in cui sono andato a ricaricare il firmware sulla scheda mi aspettavo un funzionamento “alla prima botta”. Invece il dispositivo si è bloccato nella fase di connessione all’access point, restituendo codice di errore “6” da WiFi.Status(). In pratica: nessuna connessione. Malgrado questo io sul’AP ero in grado di vedere il modulo come “autorizzato” o connesso. Per sbrigliare meglio questa matassa ho deciso di utilizzare un AP realizzato con una RouterBoard Mikrotik, in modo da potere approfittare delle funzionalità di logging.

Il codice che gestisce la connessione verso l’AP è il seguente:

Serial.println("");
Serial.println("WIFI INIT");
Serial.println("");
WiFi.macAddress(MAC_array);
for (int i = 0; i < sizeof(MAC_array); ++i){
sprintf(MAC_char,"%s%02x:",MAC_char,MAC_array[i]);
}
Serial.print("Unit Mac Address is: ");
Serial.println(MAC_char);
Serial.println("");
Serial.print("Connecting to ");

Serial.println(ssid);

// IP,DNS,GATEWAY,SUBNET
WiFi.mode(WIFI_STA);
WiFi.begin(ssid, password); //Gestione della connessione ad un AP
WiFi.softAP(ssidSA, passwordSA, 1, 1); //Gestione del SoftAP e hidden SSID
WiFi.setOutputPower(0); // Impostazione della potenza di uscita

while (WiFi.status() != WL_CONNECTED) {
Serial.println(WiFi.status());
delay(1000);
Serial.print(".");
}

Serial.println("");
Serial.println("WiFi connected");
Serial.println("IP address: ");
Serial.println(WiFi.localIP());

Cercando una possibile soluzione in rete mi sono imbattuto in questo post, in cui si legge:

WL_CONNECTED is only returned if the wifi interface has connected an has IP address
in DHCP mode this means you got the IP form the DHCP server. in Static mode you have set the IP yourself.

Detto fatto: ho configurato la mia MikroTik per lavorare come dhcp server e per effettuare il NAT della rete WiFi verso la rete di casa e… funziona!

Nota bene, in caso l’assegnazione dell’IP sia statica, il codice deve essere modificato in questo modo:

IPAddress host(192,168,**,**); //used for socket,mysql,mqtt 
IPAddress ip_wifi(192,168,**,**);
IPAddress dns_wifi(192,168,**,**);
IPAddress gw_wifi(192,168,**,**);
IPAddress subnet_wifi(255,255,**,**);

void setup() {
  Serial.println("");
  Serial.println("WIFI INIT");
  Serial.println("");
  //WiFi Management
  Serial.print("Connecting to ");
  Serial.println(ssid);
   
   WiFi.mode(WIFI_STA);
   WiFi.config(ip_wifi,dns_wifi,gw_wifi,subnet_wifi);  
   WiFi.begin(ssid, password);     
   WiFi.softAP(ssidSA, passwordSA, 1, 1); 
   WiFi.setOutputPower(0);        
   
  while (WiFi.status() != WL_CONNECTED) {
    delay(1000);
    Serial.print(".");
  }

Un altro progettone!

Non sono un appassionato di meteorologia, sono semplicemente un “meteocurioso”. Mi piace conoscere la misura dei principali parametri meteorologici e poterne studiare la loro evoluzione nel tempo. Tanti anni fa avevo un quaderno in cui annotavo temperatura massima e minima del giorno. A dire il vero lo faceva mamma… io mi scordavo 2 volte su 3.

Ai tempi della tesi di dottorato avevo rispolverato un paio di componenti molto interessanti per la misura della temperatura ed umidità e pressione ed umidità. Si tratta di SHT21 della Sensirion e del MPL115A della NXP. Due prodotti molto interessanti, piccoli e facili da leggere, soprattutto con una raspberrypi. All’epoca avevo anche realizzato un mini-sito nella raspberry per potere analizzare l’andamento dei parametri meteo e poterlo confrontare con la variazione delle grandezze elettriche che erano oggetto del mio studio.

A distanza di alcuni anni, ho notato in commercio due oggetti che hanno riacceso il “fuoco sacro” della sperimentazione:

  • ESP8266, un chip Wi-Fi a basso costo con un microcontrollore Arduino-compatibile integrato;
  • BME 280, un sensore Bosch capace di rilevare temperatura, umidità e pressione.

Ho deciso quindi di realizzare una stazione meteo, che non pretende di entrare in competizione con prodotti commerciali ma che può soddisfare la mia curiosità meteorologica. Il progetto prevede l’integrazione di numerosi sensori e componenti aggiuntivi:

  • schermo solare, realizzato con i sottovasi ed il tornio;
  • sensore di temperatura umidità e pressione;
  • sensore di direzione del vento;
  • sensore di velocità del vento;
  • sensore di presenza pioggia.

 

I dispositivi sono stati acquistati tutti su Aliexpress, attendendo i canonici 30,40,50 giorni per la consegna. Particolarmente positivo è stato il giudizio nei confronti dei sensori di direzione e velocità del vento: ben costruiti, con ottimi cuscinetti e connessioni stagne. Considerato il prezzo di acquisto il prodotto è davvero interessante.

ESP8266 si occupa di raccogliere tutti i dati, impacchettarli e consegnarli via metodo http post al server per il loro immagazzinamento nel database. Il database è MySQL in esecuzione sulla solita Cubieboard. I dati sono presentati attraverso una interfaccia web “triviale” ed è possibile anche tracciare dei grafici relativi all’andamento delle grandezze nell’arco di 24,48 ore o una settimana. Nello screenshot seguente si vede la tabella riepilogativa dei sensori presenti in cui sono riportate le principali grandezze misurate. Il sensore pioggia è in errore a causa di un malfunzionamento.

Questa immagine mostra i dettagli del sensore. Una tabella riepiloga massimi, minimi e valori medi delle grandezze misurate.

I grafici mostrano l’andamento nel tempo delle grandezze, sono realizzati con la libreria JpGraph.

I problemi da risolvere sono stati tantissimi, molti dovuti alla mia proverbiale incapacità di programmatore. Malgrado le difficoltà, il sistema è attualmente in produzione e funziona in maniera piuttosto stabile. Ho notato una certa imprecisione del sensore di pioggia, che mi era stata segnalata anche da un collega. Non mi sorprende, considerando il prezzo di acquisto del dispositivo. La maggiore difficoltà la ho avuta nel gestire lo stato della connessione di ESP8266: nella prima stesura del codice effettuavo un controllo di connessione solo in fase di “setup” del dispositivo. Con questo approccio errato, in caso di caduta della connessione Wi-Fi, le funzioni che cercano di scrivere su un socket rallentano o bloccano l’esecuzione del codice. L’inserimento di controlli sullo stato della connessione ed eventuale riconnessione, ha reso il funzionamento del sistema molto più stabile.

Ho sviluppato il sistema con l’IDE di Arduino. Non amo particolarmente questo sistema ma lo ritengo comodissimo per questo tipo di applicazioni ludico-ricreative. Sviluppare il progetto con il PIC sarebbe stato un pianto (per me…) integrare una chip Wi-Fi con stack tcp/ip sarebbe stato oneroso e, forse, inutile. Ben vengano queste agevolazioni quindi, soprattutto se sono ben consolidate ed affidabili.

Il codice è a disposizione su richiesta, appena avrò tempo di epurarlo dai dati personali sarà pubblicato sul sito nella sezione download.