Nel precedente articolo sull’idroponica, ho tralasciato il fatto che l’esperimento 2 è stato dotato pure di un un sistema di monitoraggio della temperatura che ho progettato e realizzato, durante la scorsa estate.
La necessità di questo sistema è scaturito dalla necessità di un un approccio più “data-driven”, che ci consentisse di determinare se il sistema idroponico era effettivamente utilizzabile all’aperto, durante le torride giornate estive. Come dicevo nel precedente articolo, il fatto che la temperatura della soluzione nutritiva rimanga entro certi range è di fondamentale importanza, proprio perché è contatto con le radici della pianta. Quindi era importante sapere se l’acqua dentro a quei secchi stesse bollendo (d’estate) o congelando (d’inverno) ¯_(ツ)_/¯.
L’architettura di questo progetto è relativamente semplice. Si tratta di un ESP8266, un piccolo ed economico microprocessore a 32bit con connettività Wi-Fi, popolarissimo in ambito IoT, al quale ho collegato 2 sensori: un DHT22 ed un DS18B20. Il primo è in grado di monitorare la temperatura e l’umidità ambientale, il secondo era immerso nella soluzione nutritiva per monitorarne la temperatura.
La parte elettronica è resa molto facile, grazie alla standardizzazione verso cui siamo diretti da un po’ di anni, spinti da realtà commerciali come Arduino e Raspberry Pi. Per questo la maggior parte dei sensori che si trovano in giro funzionano a 5V e utilizzano protocolli digitali molto semplici come OneWire e I2C, per cui con un paio di fili dupont (quelli che si usano per i prototipi su breadboard) spesso siamo a posto.
Ho provato a disegnare il circuito che avevo in mente usando KiCad.
Un circuito più complicato di quel che effettivamente serviva… la ventola da PC che si vede nel disegno doveva servire per raffreddare la soluzione grazie all’evaporazione dell’acqua. E per qualche grado centigrado ha pure funzionato, solo che far evaporare direttamente la soluzione nutritiva era un po’ scomodo, quindi alla fine è rimasto solo un prototipo.
Visto che mi sono messo a parlare di raffreddamento dell’acqua, vi dico solo che abbiamo fatto anche un’altro esperimento usando alcune celle di Peltier, ma questo potrebbe andare benissimo in un futuro articolo.
Passiamo al lato software (≧▽≦). Inizio col fornirvi il codice da far girare sull’ESP8266, e un bel diagramma di dispiegamento UML 2.0. Spero che abbia senso e che aiuti la comprensione di come ho allestito il tutto.
Il mitico ESP8266, può essere programmato usando vari linguaggi e ambienti, come Arduino e MicroPython, ma la mia scelta è ricaduta su quello un po’ più particolare, ovvero il firmware NodeMCU.
NodeMCU è una piattaforma “open source” pensata per l’IoT, è programmabile con il linguaggio di programmazione Lua ed offre un ambiente orientato agli eventi, dove ogni funzione che scriviamo deve terminare in pochi millisecondi per lasciare di nuovo la CPU al firmware, pena un bel crash seguito da un reset. Le attese vengono gestite tramite chiamate di funzione asincrone e callback. Insomma, un po’ come javascript su una pagina web di qualche anno fa, che quando finiva in loop, si bloccava tutto il browser e l’unico modo di procedere era un bel SIGKILL.
NodeMCU è modulare, per cui a tempo di compilazione si possono scegliere i moduli necessari al nostro progetto. Abbiamo a disposizione anche numerose librerie Lua che estendono le capacità dei moduli scritti in C del firmware.
Per quanto riguarda il mio progetto ho usato il modulo DHT e OW(OneWire) per il sensore DHT22, e I2C con la libreria Lua ds18b20 per, appunto il sensore DS18B20. Ottimo, per leggere i sensori non c’è da sporcarsi le mani con indirizzi e registri vari!
A questo punto bisogna preoccuparsi di mandare i dati raccolti dai sensori al mio caro server casalingo (per leggere questo articolo, dove credete di esservi collegati? (^^)). Ho dovuto scegliere un protocollo e, dopo aver fatto diverse ricerche sul web, ho trovato la soluzione più adatta allo scopo e supportata da un modulo NodeMCU: il protocollo MQTT (Message Queue Telemetry Transport).
Il protocollo MQTT è un protocollo molto semplice creato da IBM, che trova molte applicazioni proprio nel campo IoT. Il protocollo prevede un server centrale detto broker MQTT, che ha una architettura publish-subscribe, ovvero i client che si collegano hanno 2 operazioni a disposizione: possono sottoscriversi ad un argomento, oppure pubblicare su di un argomento. Al momento in cui un client pubblica su di un argomento, tutti i client che si sono sottoscritti allo stesso argomento ricevono una copia dell’informazione pubblicata. Oltre a questa utile funzionalità di copia, per cui tutti gli interessati possono facilmente usufruire dei dati, il broker MQTT disaccoppia il sensore dal resto dell’architettura, per cui non ci sono problemi quando l’ESP8266 si scollega dal Wi-Fi, o nessuno è pronto a ricevere i nuovi dati.
Ricapitolando, i dati dei sensori raggiungono il broker tramite una pubblicazione MQTT e da qua raggiungono il componente successivo dell’architettura del progetto, ovvero lo stack TICK. TICK sta per Telegraf InfluxDB Chronograf Kapacitor, che sono 4 servizi che insieme cooperano per formare una soluzione completa per quanto riguarda l’estrazione, lo stoccaggio, l’analisi e la visualizzazione di serie temporali di dati.
Una serie temporale o serie storica o ancora time serie in inglese, non è altro che una serie di dati a cui è associata la data e l’ora di acquisizione. Pensandola come una base di dati relazionale ci si può immaginare una tabella per ogni sensore che contiene 2 colonne: una che contiene l’ora e l’altra che contiene la misurazione. Le basi di dati relazionali, in genere, non si sposano molto bene con questo tipo di dati, in primis perché non ci sono relazioni tra i dati e poi le prestazioni possono degradarsi col tempo molto rapidamente, man mano che vengono costruiti indici sempre più enormi.
Per ovviare a questi problemi sono stati ideati alcuni database specializzati. Uno di questi è proprio InfluxDB.
Tuttavia, i nostri dati sono ancora nella coda del broker MQTT e non è che magicamente si spostano di propria volontà nel database InfluxDB! Infatti, c’è Telegraf che estrae i dati periodicamente dal broker MQTT e li converte nel formato desiderato da InfluxDB, dove vengono memorizzati.
I dati così salvati possono essere recuperati in ogni momento e visualizzati tramite una comoda interfaccia web, usando grafici, indicatori e dashboard personalizzate utilizzando Chronograf. Parlando di dashboard posso condividere con voi, miei silenziosi lettori, un file JSON che potete importare su Chronograf per ottenere la stessa dashboard che ho utilizzato per questo progetto.
Non appena Telegraf estrae nuovi dati, informa anche Kapacitor che a sua volta processa i dati lanciando script scritti in TICKscript. Ciò consente a Kapacitor, tra le altre cose, di lanciare allarmi qualora determinati parametri siano fuori scala. Ho usato proprio quest’ultima funzionalità per ricevere notifiche (tramite XMPP) qualora i parametri di temperatura fossero al di fuori di valori accettabili.
Tutto questo lavoro mi ha consentito di ottenere questi risultati:
Questi software “open source” mi hanno consentito di registrare una notevole quantità di dati, spendendo pochi soldi (giusto il costo di un ESP8266 e un paio di sensori) e imparando un sacco di cose nel frattempo.
Semmai dovessi tornare su questo progetto, penso che proverei ad aggiungere anche i sensori di pH, conducibilità elettrica e livello dell’acqua. A quel punto si potrebbe pensare anche all’automazione tramite pompe peristaltiche che mantengono in equilibrio l’acidità della soluzione (probabilmente usando un “semplice” algoritmo PID (`･/д＼･)).
Alla prossima!