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).

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.

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.

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

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 ).

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.

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