Stazione Meteo 3.0 su ESP8266-12e

meteo3

Era prevedibile che portassi il nodo relativo alla Stazione Meteo da Arduino a ESP8266. La possibilità che offre questo modulo di entrare direttamente nella LAN casalinga fa sì che possa andare a scrivere direttamente i dati in un server MySql senza ricorrere ad intermediari. L’unico particolare è che non avendo ancora disponibile (per ora e per quanto ne sappia) una libreria che dallo sketch sia in grado di effettuare direttamente le INSERT nel database (cosa che per gli Arduino esiste da tempo) necessita di spedire i dati con il protocollo  HTTP ad un web server attrezzato con un interprete PHP, che potrebbe risiedere ad esempio nello stesso Raspberry dove gira MySql. Niente di complicato insomma, specialmente per chi già ha almeno conoscenze di base di questi ambienti.

Devo dire che il mercato di queste piccole schede è molto agguerrito e in continua evoluzione: già sono in commercio cloni di Arduino Uno dotati di moduli wi-fi ESP, che mantenendo lo schema di connessioni tipico di Arduino (comprese le molte porte analogiche che mancano agli ESP) abbassano notevolmente il costo della connessione wi-fi da svariate decine di euro a 5-6 euro. Un chiaro messaggio a chi riteneva che si dovessero spendere 70 euro per mettere un singolo Arduino in rete via wi-fi, francamente un’esagerazione.

Risolti i problemi di stabilità di cui ho parlato in precedenza (ora i moduli sono stabilissimi) rimaneva il problema del consumo di corrente, che è notevolmente maggiore di un Arduino Nano e che mi creava molti problemi ad alimentare la stazione con un battery pack a celle solari di quelli che si usano per ricaricare i cellulari. Il modulo può essere facilmente messo in “sleep-mode” e riportato in vita solamente per effettuare le letture diciamo ogni 5 minuti, il che abbassa drasticamente il consumo di corrente che altrimenti si manterrebbe su diverse decine di mA. Colpa ovviamente del modulo wi-fi che per collegarsi alla LAN e per rimanerci collegato, specialmente in caso di segnale basso, consuma molta energia.

Un’altra cosa interessante da sottolineare è il buon comportamento di questo modulo nei confronti del segnale wi-fi. Per la cronaca quelli che sto utilizzando ora sono i 12e venduti da BangGood a circa 6 euro, interfacciati verso la porta USB da un chip CH340 (altri produttori usano l’FTDI). Nonostante l’antenna “stampata” sulla scheda stessa non possa dare le stesse prestazioni di una esterna in termini di sensibilità devo dire che anche con un segnale di -94 o -96 dB raramente il modulo perde la connessione, e se accade si riaggancia al primo colpo al mio router. Tutto questo è documentato dal mio logger dove registro in tempo reale anche questo tipo di attività.

Lo sketch che pubblico di seguito invia i suoi dati via HTTP ad uno script PHP situato nella DocumentRoot di un server Apache che una volta letti i dati si occuperà di inviarli ad un server MySql installato, nel mio caso, sulla stessa macchina, un Raspberry Pi2.

Ecco lo script:

Esiste quindi un database con dbname = domotica e una tabella dove vengono depositati, ogni 5 minuti, i dati inviati dalla Stazione.

La tabella MySql avrà questa struttura:

Ho preferito mantenere il timestamp di ricezione dei dati in UTC, ovvero un orario di riferimento con fuso orario 0 con ottima approssimazione assimilabile al Tempo Medio di Greenwich perché non genererà date ambigue nel momento in cui si passa dall’ora solare a quella estiva, MySql permette poi in fase di interrogazione di riferirsi al fuso locale italiano (definito CET, e poi CEST quando in vigore l’ora estiva) con una query del tipo:

Qui devo fare una annotazione di tipo sistemistico: la funzione CONVERT_TZ() richiede che siano popolate alcune tabelle di sistema che generalmente sia in MySql che in MariaDB NON sono inizializzate. Per evitare che la lettura delle date ritorni dei valori NULL bisogna, da shell Linux, lanciare una utility che prelevi le informazioni relative alle timezone (tipicamente in /usr/share/zoneinfo) e le depositi nelle tabelle in questione. Il comando è:

Di seguito verrà chiesta la password dell’utente root del database. A esecuzione avvenuta si potrà andare nello schema denominato “mysql” e controllare che le tabelle [timezone_*], credo siano 4 se non ricordo male, siano popolate.

In poche parole la tabella nella sua forma originale si presenta in questo modo:

Schermata 2016-01-22 alle 21.56.33

E letta dalla query che ho indicato con le conversioni delle date in quest’altro modo:

Schermata 2016-01-22 alle 21.56.48

Ma passiamo ai collegamenti fisici: ho sostituito il “vecchio” lettore di luce KY018 con un più preciso e flessibile TSL2561 di Adafruit, digitale, che mi ha permesso di non scontrarmi con la poca flessibilità delle schede ESP con i sensori analogici.

“Solita” resistenza di pull-up sul sensore DHT22 (4.7Kohm o 10Kohm) e, cosa fondamentale un “ponte” possibilmente interrompibile tra il pin GPIO16 (D0) e il pin RST per far sì che funzioni il codice di Deep-Sleep del modulo. Questo circuito va chiuso durante l’esecuzione dello sketch e va aperto quando c’è da fare l’upload di uno sketch modificato. Mi raccomando, poiché con i due PIN cortocircuitati l’upload del codice dà errore e non funziona. Il Deep-Sleep fa risparmiare molta corrente, l’ESP quando è “dormiente” consuma pochi micro ampère  e quando viene risvegliato riesegue da capo lo sketch comprensivo della funzione setup(). Il che significa ovviamente che si riconnetterà di nuovo al wi-fi dopo esserne uscito per “addormentarsi”.

La mia Stazione è ormai da circa 24 ore in questa condizione di funzionamento e non ho rilevato comportamenti anomali o scorretti da parte del modulo.

Per quanto riguarda le librerie esterne, sono le stesse che ho già indicato in post precedenti relative agli stessi sensori. Adafruit per quanto riguarda i sensori DHT22 e TSL2561 e la SFE_BMP180 per il sensore barometrico.

Ecco quindi lo sketch che pilota il tutto:

Sostituire i valori della propria LAN nelle rispettive righe:

const char* ssid = “**********************”;
const char* password = “******************”;

nonché l’indirizzo IP del server HTTP:

String url = “http://192.168.3.100/insert_meteo.php?”;

e il nome del file php che si occupa della ricezione, che io ho chiamato “inserti_meteo.php”

La gestione del modo Deep-Sleep avviene in pratica sostituendo la classica delay() con questo codice:

uint32_t sleepTimeSec = 300;  // 300 secondi, ovvero 5 minuti
uint32_t sleep = (sleepTimeSec * 1000000);

ESP.deepSleep(sleep, RF_DEFAULT);

Trascorso il tempo indicato il modulo effettuerà un wake-up, in pratica un SOFT RESET, che NON rimetterà in esecuzione il codice dal punto in cui lo abbiamo lasciato, ma procederà ad una riesecuzione da capo della funzione setup() e poi loop().

Stazione Meteo 2.0 – Invio automatico di un rapporto via e-mail

Vediamo come fare in modo che la nostra Stazione Meteo possa inviare in automatico con cadenza periodica un messaggio di posta elettronica contenente i dati raccolti sul database MySql. Prima di descrivere la procedura devo premettere che ho aggiunto alla tabella dati_meteo un paio di campi (rispettivamente data e ora) solamente per la comodità di averli già divisi, sia per le query che per il prelievo di informazioni, che non comportano nessuna modifica nel codice già scritto in quanto popolati da un trigger associato a questa tabella.

Ecco qui quindi le modifiche da apportare alla tabella in questione:

In grassetto ciò che mancava in precedenza.

Sostanzialmente si tratta di un semplice script in Python che va messo nel data collector, ovvero nel Raspberry (o chi per lui) che contiene il database MySql. Richiede un account di posta GMAIL da dove spedire la posta tramite il suo server SMTP ma può essere facilmente adattato per l’utilizzo di altri gestori. Ovviamente la macchina dove installeremo lo script deve avere accesso ad Internet, e mi raccomando di controllare che qualora ci sia un firewall attivo non venga bloccato il traffico in uscita sulla porta TCP 587.

Controllare anche che sia installato il modulo python-MySql per l’accesso al database. In caso contrario, a seconda della distribuzione in uso, usare il gestore di pacchetti per installarlo. Lo script prevede di utilizzare una lista di destinatari, in caso di invio ad un singolo indirizzo è sufficiente inserire una voce soltanto nella lista. La variabile GMAIL_USERNAME deve contenere invece un account Gmail già esistente con relativa password. Dal momento che questo script conterrà la password in chiaro di questo utente consiglio di installare lo script in una directory dell’utente root e dare permessi di tipo 700 a questo codice. Personalmente non amo affatto le distribuzioni basate sul “sudo” e preferisco creare anche nelle distro Debian-like un utente root e togliere qualsiasi accesso elevato (“sudo”, appunto) agli utenti normali.

Ecco qui il codice Python:

Veramente semplice. Per fare sì che venga spedita periodicamente una mail è sufficiente inserire nella crontab di root la riga con la chiamata periodica di questo script. Con il comando < crontab -e > entriamo nell’editor di crontab e inseriamo una riga come questa che provocherà il lancio dello script ogni ora.

Questo comando suppone che lo script sia stato salvato nella directory /root/python_code ovviamente. Cercando su Internet le regole sintattiche relative al comando < crontab > non sarà difficile capire come impostare altri tipi di periodicità.

A breve parlerò anche di una cosa ben più interessante: ovvero come richiedere queste (ed altre informazioni) da remoto utilizzando un BOT, ovvero un utente automatico creato tramite alcune API opensource messe a disposizione dal programma di chat Telegram. In questo caso non ci limiteremo a richiedere passivamente informazioni ma potremo interagire in modo attivo (accendere o spegnere apparecchi) da remoto con la nostra infrastruttura domotica. 🙂

Stazione Meteo – Software Upgrade v. 2.0

Ho provveduto ad effettuare due modifiche al software di gestione della Meteo Station. La prima comporta la lettura del voltaggio di lavoro (in teoria 5.0V) delle schede Arduino rispettivamente nella Stazione Trasmittente e nella Stazione Ricevente. Questo perché nel caso una od entrambe fossero alimentate da una batteria esterna si possa tenere sotto controllo la tensione di alimentazione, e alla eccessiva discesa di questo valore prevedere la ricarica e/o il cambio della batteria. Tali misure vengono riportate sulla tabella dati_meteo del database MySql per cui oltre al codice è cambiata la struttura di questa tabella.

La seconda modifica è senz’altro più importante. Avendo trovato una buona libreria per fare questo ho fatto in modo che sia la stessa Stazione Ricevente a scrivere i dati direttamente sul Database, rendendo in questo modo inutile la trasmissione UDP sul network e quindi il codice relativo al Server UDP da inserire nel data logger.

Cliccare QUI per scaricare la libreria di accesso a MySql per Arduino.

Consiglio caldamente di scaricare anche il file PDF contenente la documentazione della libreria, che offre una completa panoramica di come si usa e di tutti i comandi implementati. Ovviamente è richiesto uno shield Ethernet, o uno dei tanti shield o moduli wi-fi disponibili per Arduino. L’unica accortezza è che consuma molta memoria sia in termini di codice che di variabili, per cui in caso di sketch piuttosto complessi è necessario ricorrere ad un Arduino Mega o una di quelle schede che comunque hanno spazi dedicati alla programmazione superiori a quelli di una normale scheda Arduino Uno o Nano.

Nel caso del mio sketch siamo ancora nei limiti di gestione di un Arduino Uno, ad ogni modo ho inserito nel codice una funzione che in fase di debug sull’interfaccia seriale indica la memoria rimasta per le variabili. Bisogna cercare di evitare l’Out Of Memory del codice che porterebbe al blocco dello sketch o al reset continuo del codice.

Scaricata la libreria in formato .ZIP va inserita nella IDE di Arduino con la procedura solita. Io ho dovuto comunque spostare i file .cpp e .h nel path principale della libreria e rifare lo ZIP prima di inserirlo nella IDE, altrimenti le #include non funzionavano.

Attenzione poi al giusto dimensionamento dell’array char query[]. In caso di query piuttosto lunghe il valore consigliato negli esempi (128) porta l’esecuzione della query al blocco del codice. Ho dovuto infatti estenderne l’allocazione a 256 bytes per far funzionare lo sketch, tenendo sempre sotto controllo la memoria rimanente che si aggira circa sui 650 bytes durante il runtime.

Scompare quindi il codice Python relativo al Server UDP da far girare sul Server MySql e rimangono gli sketch relativi a Trasmettitore e Ricevitore che riporto qui sotto. Va notato che ora il timestamp di scrittura delle letture è dato dal database stesso, essendo il campo timestamp_cet dotato del default value CURRENT TIMESTAMP(6). Questo per ora è sufficiente ma sono in attesa che mi arrivino dei moduli DS3231 AT24C32 IIC, piccole schede contenenti un RTC, ovvero un orologio alimentato a batteria che finalmente potrò utilizzare per marcare le letture dei sensori con il loro tempo effettivo di prelievo.

 

TABELLA DATI_METEO MODIFICATA

SKETCH DELLA STAZIONE TRASMITTENTE

SKETCH DELLA STAZIONE RICEVENTE

 

Stazione Meteo – Il Data Collector

Ecco l’ultimo anello della catena, il server UDP che raccoglie i dati inviati dalla Stazione Ricevente e li scrive su un database Mysql, residente, ma non necessariamente, sulla stessa macchina. In questo caso non sto parlando di un hardware specifico, potrebbe trattarsi di un qualsiasi Pc, Mac, o Server Linux dove sia installato l’interprete Python 2 e un Server MySql o MariaDB. Certo, deve rimanere acceso H24 ed è conveniente che sia una scheda a basso consumo come un Raspberry se vogliamo ospitarla a casa nostra.

Non voglio entrare nei particolari di gestione di un server MySql, perché richiederebbe un tutorial apposito piuttosto lungo ed articolato, per cui darò per scontato che chi si appresta a completare un progetto simile sia già a conoscenza delle procedure necessarie a gestirlo. Comunque per ricevere i dati che la Stazione Ricevente sta attualmente inviando ho provveduto a creare un database chiamato meteodb, un utente meteo, dotato di password e accessibile dal localhost in questo caso e un paio di tabelle di cui la prima, dati_meteo per la ricezione dei dati veri e propri, e la seconda, stazioni, per gestire un eventuale elenco di stazioni di trasmissione, ognuna associata ad un codice.

Script delle tabelle:

Codice Python del Server Udp:

Questo codice va salvato in un file chiamato ad esempio data_logger.py a cui vanno dati i permessi di esecuzione (chmod +x).

Infine può essere lanciato in backgound con un comando del tipo nohup python data_logger.py > dlg_stdout.log 2>dlg_error.log &

in modo tale che anche chiudendo il terminale da cui si è lanciata l’esecuzione il processo rimanga attivo in background.

Ecco un esempio di scrittura di alcune righe di dati sul database:

Schermata 2015-10-29 alle 20.32.23

Questi sono dati scritti ogni minuto, ma agendo sullo sketch del trasmettitore si può scegliere la cadenza di lettura in base alle proprie esigenze.

Stazione Meteo – L’unità ricevente

20151024_200515

L’unità ricevente della Stazione Meteo è costituita da un Arduino Uno R3 con montato uno shield Ethernet collegato alla lan domestica attraverso uno switch. Il  suo scopo è ricevere via radio i valori letti dalla Stazione Trasmittente per ritrasmetterli poi, via UDP ad un server MySql che li inserirà nel database. In aggiunta a questo all’Arduino Uno è collegato localmente un sensore DHT11 per rilevare temperatura e umidità nella stanza in cui si trova la scheda stessa.

20151024_223655

Una piccola complicazione è nata dal fatto che lo shield Ethernet e il ricevitore NRF24L01 utilizzano entrambi l’interfaccia SPI per comunicare con Arduino. Andando infatti a leggere la documentazione ufficiale su questo shield leggeremo che i pin 10,11,12 e 13 (50,51 e 52 nel caso di un Mega) sono usati per il colloquio tra shield ed Arduino, il che impedisce a questi pin di essere usati per l’I/O e causa possibili conflitti con altri moduli che utilizzano la SPI. In un primo momento, infatti, mantenendo sull’UNO gli stessi collegamenti usati dall’NRF24 nell’Arduino Nano, questo non funzionava. Per fortuna ho dovuto spostare solo il pin CSN dal 10 all’8 per far funzionare il modulo ricevente.

Un’altra considerazione riguarda la scelta di usare il colloquio tramite protocollo UDP nella LAN domestica. Il protocollo UDP è molto semplice da utilizzare: il client spedisce i suoi pacchetti sulla rete indirizzandoli al server che se è in ascolto li riceve, se per qualche motivo non ha avuto occasione di farlo la trasmissione va persa, senza alcun tipo di controllo. Oltre a questo va detto che a differenza del protocollo TCP, non esiste alcuna garanzia che i pacchetti arrivino nell’ordine giusto. Non spaventiamoci, tutto questo succede molto raramente, ma può succedere. Inoltre lo shield ethernet di Arduino prevede solamente il colloquio di tipo Unicast, ovvero il client può inviare pacchetti solamente ad un destinatario per volta, di cui conosce l’indirizzo IP e non permette l’invio di pacchetti a più destinatari contemporaneamente, ovvero in modalità Multicast.

Detto questo non escludo che in un prossimo futuro farò in modo che il server che ospita MySql sia in ascolto da un socket server TCP, sicuramente più affidabile. Dalle prove sul campo per ora il colloquio UDP non mi ha dato particolari problemi, per cui considero questo passaggio come una miglioria del software per la futura versione 2.0.

Sia l’Ethernet Shield che il server MySql ovviamente devono avere un indirizzo IP nell’ambito della nostra rete domestica, che verrà definito di tipo Statico. Nel mio caso allo Shield ho assegnato un IP 192.168.3.120 mentre la scheda Banana Pro dove risiede MySql ha indirizzo IP 192.168.3.102. Una particolarità dell’Ethernet Shield è che il produttore non ha provveduto a “marcarlo” con un MAC address univoco, come di solito si fa con gli apparati di rete, per cui all’interno dello shield ne inseriremo noi uno di comodo, in quanto comunque ogni scheda di rete deve presentarsi su un network con un MAC address, oltretutto univoco.

Una considerazione sullo shield ethernet: dovendolo tenere acceso H24 per questo progetto mi sono accorto che il chip principale della

20151025_100705

scheda scalda molto. Poggiandoci con cautela il dito sopra scotta talmente che non si resiste per più di un paio di secondi. Secondo la misura del mio “ditometro” direi quindi che raggiunge una temperatura di non meno di 50-55 gradi durante il suo funzionamento. Ho previsto quindi di applicare sopra al chip uno di quei piccoli dissipatori passivi che in genere si acquistano per i Raspberry, al fine di allungare la vita operativa dello shield.

 

I collegamenti:

Stazione Ricevente

 

Per quanto riguarda lo sketch, questo oltre a provvedere ai vari settaggi di rete, riceve il payload dalla Stazione Trasmittente, legge i dati del sensore DHT11, li aggiunge al payload ricevuto e invia il tutto al server UDP in ascolto.

 

SKETCH :

 

 

 

 

 

Stazione Meteo – L’unità trasmittente

20150920_095055

L’unità incaricata di ospitare i sensori è attualmente funzionante anche se ancora ospitata su breadboard in attesa, alla fine del collaudo, di passare su scheda millefori. Ho scelto come scheda controller dei sensori l’Arduino Nano, piccolo, poco costoso (5-6 euro), dai bassi consumi e dotato di buone caratteristiche di connettività.

20151009_172728

La Stazione Trasmittente dovrà essere collocata all’aperto, e per quanto riguarda l’alimentazione a 5V del Nano sto testando con un certo successo alcuni Power Pack a ricarica solare generalmente dedicati ai telefoni cellulari e prodotti in Cina che, se tenuti costantemente alla luce solare durante il giorno, riescono a ricaricare ciò che il Nano e i sensori consumano in termini di corrente nell’arco delle 24 ore.

20151020_191748

Non sono richieste grosse capacità della batteria interna, anche una da 5000mA va più che bene, purché l’esposizione alla luce diurna della cella solare (in genere sono celle da 1.5W) riesca sempre a recuperare l’energia assorbita dalla Stazione Trasmittente.

Per la trasmissione dei dati letti dai sensori ho scelto un modulo molto economico ma piuttosto affidabile, l’NRF24L01. Si tratta di una trasmittente / ricevente a 2.4 GHz, funzionante tramite interfaccia SPI, capace di operare fino ad una velocità di 2 Mbps con un consumo estremamente basso. Il costo si aggira intorno ai 2 euro.

Schermata 2015-10-21 alle 15.00.45

Si trova in varie versioni, principalmente distinte dal fatto che abbia un antenna cablata sul circuito come pista di rame (vedi figura) o dotata di un’antenna esterna. Io ho utilizzato la prima versione e per distanze di svariati metri (anche con ostacoli del tipo pareti) non mi sta dando alcun problema. Qualora l’NRF24L01 desse qualche problema durante la trasmissione è consigliabile inserire un condensatore elettrolitico di capacità pari a 4.7 o 10 microfarad saldato tra i 2 pin di alimentazione del modulo, allo scopo di stabilizzare la linea dei 3.3 V dell’Arduino Nano che può presentare eccessivi residui di alternata (ripple) se alimentato con un alimentatore a 5V. Nel mio caso, usando un battery pack il problema non sussiste.

I componenti usati al momento quindi sono:

E questo è lo schema di collegamento:

Schermata 2015-09-20 alle 18.28.31

Come già accennato nel Post precedente, sto preventivando di aggiungere quantomeno un rilevatore di pioggia ai sensori esistenti, ma in futuro sarà possibile anche registrare dati su velocità e direzione del vento tramite un unità anemometrica esterna, collegata a questa o ad un’altra stazione trasmittente. La libreria standard del modulo NRF24L01 prevede fino a 6 trasmettitori su altrettanti canali diversi.

Infine lo sketch che si occupa di leggere i sensori e trasmettere il “payload” con il contenuto delle letture al ricevitore Arduino Uno. Utilizzo uno schema di trasmissione semplificato, senza controlli sull’avvenuta ricezione in quanto questi moduli NRF24L01 si sono dimostrati molto affidabili, ma è possibile gestire la trasmissione in maniera più sofisticata, se necessario.

Per il funzionamento dello sketch sono necessarie alcune librerie esterne da aggiungere alla IDE di Arduino.

 

Stazione Meteo – Il progetto

Stazione Meteo Finale.001

Ecco il mio progetto di Stazione Meteo nella sua prima attuale versione in corso di collaudo. E’ sostanzialmente costituita da un modulo trasmittente (ma possono essere più di uno, fino a sei) collocato all’aperto e utilizzante un Arduino Nano collegato ad una serie di sensori e ad una piccola scheda radio di tipo NRL24L01 in grado di trasmettere tutti i dati letti ad un Arduino Uno, dotato dello stesso modulo per la ricezione e con in più uno shield ethernet in grado di colloquiare con la rete domestica. Lo stesso Arduino è dotato di un altro sensore di temperatura e umidità che effettua una lettura dentro casa. Tutti questi dati vengono raccolti da un client UDP che li invia al corrispondente  server UDP che può essere collocato su un Raspberry (o altra macchina Linux) che provvederà a scrivere in tempo reale queste grandezze su di un database MySQL installato localmente.

Attualmente la stazione trasmittente legge informazioni all’esterno relative a Temperatura, Umidità, Pressione Atmosferica, Illuminazione. E’ possibile comunque aggiungere altri sensori per rilevare ad esempio la presenza di pioggia o neve, dati su velocità e direzione del vento ed eventualmente un pluviometro per la misurazione quantitativa della pioggia caduta. I margini di ampliamento sono piuttosto ampi (come prima aggiunta sto aspettando un sensore di pioggia) e il resto della catena andrà adeguata solamente in termini di software.

Senza contare che tutti i dati incamerati nel database presente all’interno del Raspberry possono a loro volta essere utilizzati da un sito web locale (realizzato in PHP ad esempio) o inviati ad un documento remoto del tipo Google Docs. Questa fase è ancora in corso di progettazione.

20150920_094948

Questo è il prototipo funzionante della Stazione Trasmittente, ancora su breadboard, che ho poi posto all’esterno (ben protetta) a raccogliere dati. Per l’alimentazione a 5V del circuito sto sperimentando uno di quei Power Pack a ricarica solare che si utilizzano per i telefoni cellulari (costo: 15 –  20 euro) che mi sembra ideale per questo tipo di situazione dal momento che sarà esposta alla luce del sole per tutta la giornata. Non appena terminata la fase di collaudo passerò tutti i componenti su di una scheda millefiori con cablaggi a saldare.

 

20150917_230641

Questo è il modulo ricevente interno costituito da un Arduino Uno + Ethernet Shield (entrambi SunFounder) che oltre ad occuparsi della ricezione dei segnali dalla Stazione Esterna ( o anche da più stazioni) mette a disposizione questi dati sulla rete domestica. Infine sulla scheda Raspberry o Banana Pro, come nel mio caso, dove sarà collocato il Server UDP in ascolto, gira il codice Python che si occupa anche della scrittura su database MySQL. Questa ultima macchina, se opportunamente configurata attraverso il router che accede all’esterno, potrebbe in teoria ricevere dati da altri collector dello stesso tipo situati geograficamente in qualsiasi locazione.

 

Schermata 2015-10-18 alle 14.23.06

Ed ecco come si presentano attualmente i dati su MySQL, letti in questa fase di collaudo ogni minuto per evidenziare qualsiasi tipo di problematica. Da sinistra verso destra ci sono il timestamp di deposito sul DB, temperatura e umidità interni, poi i dati esterni letti dal DHT22, dal BM180 e dal KY018.

Di seguito pubblicherò altri post con la descrizione dettagliata, schemi di collegamento e il codice per i vari moduli.