(le scritte in verde permettono di attivare un link di contesto se vi si clikka sopra)        19 febbraio 2023
Pagina ecologica no pubblicità no scherzetti no virus no messaggi subliminali

Da dei progetti realizzati nelle grandi città metropolitane e nato questo monitoraggio per sopperire ai dati ufficiali che nel nostro
territorio romagnolo sono scarsi, una solo centralina su un'estensione lineare di oltre 40 Km, con dati che vengono pubblicati, se
va bene, solo il giorno dopo quando la gente ha già usufruito in modo incosciente dell'aria disponibile.


Le linee generali di questo progetto sono spiegate nel dettaglio nella mia pagina Alternativa_a_Blynk, su questa ci addentreremo
a spiegare nel dettaglio l'Hardware e il Software.

Ecco lo schema elettrico del progetto:

Si utilizza:
- una scheda Wemos D1 revisione R1;
- modulo RTC DS1307;
- alimentatore 9 volt per Arduino;
- resistenza da 10k e 4.7k ohm 1/4 wat;
- transistor BC337;
- diodo 1n4007;
- condensatori poliestere da 100 nanoFarad;
- scatolina di plastica per proteggere il tutto;
- sensore SDS011;
- sensore BME680;
- convertitore CJMCU 4 canali bidirezionali di livelli logici 3,3<->5volt;
- basetta millefori;
- connettori a striscia maschi;
- connettori a striscia femmina.

Il sensore SDS011 fornisce i valori del PM10 e PM2.5 garantendo 8000 ore di funzionamento del laser interno. Pertanto serve
mettere a riposo il sensore quando non viene utilizzato. Nel mio progetto viene eseguito una serie di 59 letture ogni 15 minuti, e le
prime 25 vengono scartate al fine di misurare solo aria nuova e non quella rimasta all'interno e nei tubi. L'uscita del segnale è
ascincrona, UART TTL con bit/rate a 9600 e frequenza tra le nuove letture di 1Hz. Il valore letto è affidabile sino a valori di
umidità del 70% poi la condensa delle goccioline si somma alle polveri, in particolar modo per il PM10, meno per il PM2.5,
pertanto è bene calcolare il punto di rugiada al fine di limitare i valori troppo elevati del PM10. Per il nostro scopo serve solo
stare in ascolto della linea tx del sensore che trasmette ad ogni secondo il treno di dati di PM10 e PM2.5 e non diamo alcun
comando sulla linea rx del sensore.
Mi sono costruito un banco di misura per testare la curva di risposta del SDS011 e poter comparare la curva con altri sensori.

Ho utilizzato un contenitore, sufficientemente alto per evitare che si sfondi col calore della fiamma, che viene chiuso
ermeticamente appoggiandolo su un piatto pieno di acqua, al fine di spegnere un lumino per mancanza di ossigeno. Viene
sviluppato del fumo, poi si fa entrare l'aria appoggiando il contenitore su due legnetti e si attende di arrivare alle 500 letture.

L'orologio per indicare l'orario di acquisizione dei dati deve lavorare con un'alimentazione di 5volt, per permettere la ricarica della
batteria a bottone da 3,3 volt, mentre gli ingressi della scheda Wemos accettano solo 3,3 volt, pertanto la linea I2C del orologio
sono adattate ai livelli tramite il convertitore di livelli bidirezionale CJMCU. Una terza uscita, di questo convertitore è dedicata
alla linea Tx del sensore di Polveri Sottili per adattare anche questi livelli, mentre il sensore BME680 non ne ha bisogno in
quanto alimentato a 3,3Volt.
Leggendo il manuale del sensore BME680 si apprende che i tempi di risposta sono dell'ordine di 8 secondi pertanto tra ogni
lettura attendo 10 secondi. L'umidità % massima è limitata al 85% pertanto serve apportare delle correzioni software per
dichiarare un'umidità del 100% (formazione di nebbia) calcolando quindi il punto di rugiada. Per la temperatura deve essere
tenuto conto una correzione per il surriscaldamento del sensore in esercizio e del fattore contenitore.


 

Dopo aver realizzato il cablaggio, e aver rivisto e verificato la corrispondenza con lo schematico iniziale, possiamo iniziare a
configurare la parte Software.
Premessa indispensabile è aver testato e verificato il perfetto funzionamento della piattaforma del sistema di sviluppo IDE con
una scheda Wemos compatibile ESP8266.
Ora carichiamo sulla scheda Arduino il software FTP_PM_htm.ino che potete scaricare da questo link.
Scompattate il file .rar e la directory compressa che ha lo stesso nome e dal menù File-apri selezionate il file FTP_PM_htm.ino poi
date invio sulla freccia della seconda riga per caricare il programma sulla scheda.
Il programma consta di 1000 righe di comandi pertanto commenterò solo le parti principali del programma.

Le informazioni di testata generali:

Lettura sensore per PM10 tipo SDS011 media su 34 letture ogni 15
minuti previo svuotamento dell'aria nel tubo per 25 secondi
oltre PM10 si leggono i PM2.5 e la media giornaliera
versione FTP per server su ARUBA del 14 gennaio 2023
Tarati tutti i strumenti in postazione di casa con dati meteo
Osservatorio Torricelli e compensato PM10 in presenza di superamento
punto di rugiada limitando il PM10 a PM2.5 * 2
In cso di disconnessione wifi si riconnette anche in caso di
caduta del collegamento internet si ripistina in automatico
Previsto invio mail in caso di superamento soglia
Listato adattato da originale pubblicato da JOY-IT
inserito RTC per invio orario
Sostituite i campi con xyxyxyxy coi dati vostri personali

Il programma ha il compito di raccogliere, ogni 15 minuti:
- la media dei valori delle polveri sottili PM10 e PM2.5;
- calcolare la media giornaliera dei PM10 e PM2.5;
-  mandare una email di allarme se vi è un incremento del valore del PM10 maggiore di 100;
- acquisisce la media della temperatura;
- acquisire la media della pressione;
- acquisire la media dell'umidità percentuale;
- acquisire la media del COV, Composti Organici Volatili (componente puzza);
- mandare una email di allarme per decremento del COV.
L'umidità viene incrementata del 20% per poter raggiungere la saturazione, in quanto il sensore fatica a superare il valore di 85% di umidità e la saturazione ci serve per il calcolo del punto di rugiada e quindi della formazione della nebbia che falsa con i valori
il PM10 essendo le particelle di umidità delle dimensione dei PM10. Quando si raggiunge la saturazione dell'umidità o il punto di
rugiada si limita il PM10 in modo da non superare il doppio del valore PM2.5. Se si è nelle vicinanze dei camini di fabbriche con
termo valorizzatori, in presenza di aria satura di umidità e assenza di vento, le ricadute dei fumi seguono il suolo e prima che si
dissolvano possono percorrere anche diverse centinaia di metri mandando in allarme le centraline. Tutti i dati sono inviati al
proprio server di Aruba, tramite protocollo FTP ad ingrassare un record per ogni dato acquisito, preceduto dall'orario di invio
necessario per realizzare i grafici temporali di ogni parametro, grafici che verranno eseguiti da un apposito software da un pc
appositamente dedicato. Terminato l'invio dei dati, il programma prima di mettersi a riposo per i prossimi 13 minuti, genera una
pagina in HTML con il riassunto testuale di tutti i valori, anch'essa inviata al proprio server di Aruba, pagina che verrà poi
pubblicata in una finestra che precede i vari grafici.
Le credenziali per la connessione FTP ve le rilascia ARUBA quando acquistate lo spazio HOSTING o potete richiederle in
seguito, comunque per utilizzare l'applicazione che vi descriverò sono necessarie.
La mia cartella principale su ARUBA si chiama "httpdocs" pertanto ho creato tramite il programma Filezilla come descritto nella
mia pagina "Alternativa a Blynk", una sottodirectory dal nome download dove verranno caricati i record nuovi sui vari file con i
dati vecchi.
Ecco la centralina cablata. Nel contenitore viene posizionato da un lato il naso con il sensore BME680 protetto da un filtro di
stoffa per evitare l'ingresso degli insetti e da un lato il tubicino per l'ingresso dell'aria da monitorare per i PM. Da prove effettuate
risulta che un tubicino di oltre un metro impedisce una misura ottimale, consiglio di non superare i 15 cm e di posizionarlo con la
punta in basso per evitare l'effetto imbuto in caso di poggia o condensa.

Torniamo al listato.
Per quanto riguarda le librerie usate:
#include <Arduino.h> // aggiunto per la gestione mail
#include <ESP8266WiFi.h>
#include <Wire.h>
#include <SPI.h>
#include "SoftwareSerial.h"
#include "RTClib.h"
#include <Adafruit_Sensor.h>
#include "Adafruit_BME680.h"
#include <SDS011.h>
#include <ESP_Mail_Client.h>
Per le librerie da usare, Arduino.h, Wire.h, SPI.h, SoftwareSerial.h e ESP8266WiFi sono già preinstallate dopo il caricamento della scheda Wemos, serve solo installare le librerie:
- RTClib-master puoi scaricarla da questo link:.
- Adafruit_Sensor.h e Adafruit_BME680.h poi scaricarle da questo link;
- ESP_Mail_Client.h puoi scaricarla da questo link;
- SdS011.h puoi scaricarla da questo link.
Le password da inserire e modificare sono:
#define WIFI_SSID "xyxyxyxyxy" // nome wifi per email
#define WIFI_PASSWORD "xyxyxyxyxyxy" // password wifi per email
#define sender_email "xyxyxyxyxyxy@gmail.com" // email inviante
#define sender_password "xyxyxyxyxyxyxyxy" // password inviante
#define Recipient_email "xyxyxyxyxyxy@gmail.com" // email destintario
const char* ssid = "xyxyxyxyxyxy"; // nome wifi per FTP
const char* password = "xyxyxyxyxyxy"; // password wifi per FTP
const char* server = "xyxyxyxyxyxyxy.it"; // dominio su Aruba
char user[] = "xyxyxyxyxyxyxy_"; // user per FTP su Aruba
char pasw[] = "xyxyxyxyxyxyxy"; // Password per FTP su Aruba
Per quanto riguarda l'invio di email consigliano di crearsi un account specifico su gmail e attivare tutte le procedure per sbloccare
l'invio di email non sicure, procedure che gmail cambia spesso l'ultima che uso e ho bypassato è descritta in questo link.
Queste le note sul setup:
my_sds.begin(D6, D8); //Si definisce il pin da usare per la ricezione RX, TX D8 non usata
Serial.begin(9600); // SDS011 funziona solo a con bitrate a 9600
rtc.adjust(DateTime(F(__DATE__), F(__TIME__))); // Comando per settare l'orologio con la data e orario del PC al momento di iniziare la compilazione
// una volta settato l'orologio, ai riavvii si controlla se già settato l'orologio così non viene più modificato
pinMode(D7, OUTPUT); //Usa pin 7 per dare alimentazione al Sensore PM
Il progetto da me realizzato utilizza tre centraline, ognuna è indipendente ed inviano i dati sulla stessa cartella del sever di aruba su
file diversi per poi essere elaborati e visualizzati su questa mia pagina. Il sistema attualmente lavora con ben 64 file. L'obiettivo è
dimostrare che all'interno del mio comune di 60000 abitanti, a distanza di pochi km ci possono essere differenze enormi di qualità dell'aria a causa di assenza o presenza di attività industriali inquinanti.

Le routine utilizate sono:
- void leggiPM() // restituisce i valori medi dei PM10 e PM2.5
- void leggiVCO() // restituisce i valori meteorologici e il valore della puzza
- void creaorario() // restituisce l'orario
- byte doFTP() // realizza la funzione FTP
- byte eRcv() // controlla la risposta ricevuta dopo la funzione FTP
- void efail() // gestione degli errori
- void connectWifi() // funzione di connessione Wifi
- void allarme() // verifica l'allarme per i PM e invia la email
- void leggigiorno() // verifica se la giornata è finita per inviare la media dei PM della giornata
- void allarmeVCO() // verifica l'allarme per i VCO e invia la email
- void creaHTM() // crea la pagina HTML con il riassunto dei valori in forma testuale
Infine la funzione:
- void loop()
ordina in sequenza le varie acquisizioni e invii, tramite la funzione FTP e mette in pausa la centralina sino ai prossimi 15 minuti.
Nella routine LeggiPM(), si acquisisce solo la media centrale delle letture dei PM, si memorizza il dato letto per fare una media
giornaliera, si tara in maniera software il valore letto rispetto ad un campione, e si evitano valori abnormi in caso di nebbia,
limitando i PM10 a non più del doppio dei PM2.5 in caso di arrivo al punto di rugiada.
Nella routine leggiVCO(), si acquisiscono i valori meteorologici e si tarano i valori rispetto ad un campione, per la pressione si
moltiplica per circa un 20% in più per compensare il fatto che il sensore non va oltre ad un 85% di umiità.
In Creaorario() ci restituisce una variabile con i dati di calendario e ora da far precedere ai dati da inviare al sever separati da una
virgola.
 

La routine byte doFTP() realizza due livelli diversi di connessione client e dclient, la prima client serve a fare i convenevoli col
server la seconda dclient invia i dati. Non sono riuscito ad usare delle variabili per fare i cambi di directory e indicare i nomi dei
file, pertanto devono essere dichiarati al momento. Si usano due comandi fondamentali FTP:
- STOR per scrivere o sovrascrivere un file;
- APPE per creare e aggiungere, quindi appendere dei dati in fondo ad un file.
Quando si apre la connessione FTP, la prima parte è uguale per tutti i file, poi tramite il comando switch(n) case n ... break; si
decide l'azione specifica da fare in base alla variabile numerica n (che file gestire, le variabili da inviare ecc). Poi vi è la parte
finale uguale a tutti per i saluti.
La routine creaHTM() provvede a creare una pagina in formato classico HTML inserendo le variabili dei dati acquisiti in
posizioni specifiche, tale lavoro permette di non dover far ricorso a linguaggi evoluti che si prestano ad aggiornamenti e plugin proprietari che spesso necessitano di manutenzione. Il risultato è una pagina inserita in un FRAME per una pubblicazione che
può essere inserito in qualsiasi punto di una pagina classica, con la possibilità di colorare e indicare il livello di qualità dell'aria in
base ad una scala cromatica. Di seguito i tre frame dei tre miei strumenti:

Ora ci resta di vedere come le informazioni inviate al server possono essere gestite per realizzare la nostra pagina su Aruba con i
grafici e il riassunto testuale con le indicazioni di allarme nei frame.

Nella mia pagina Alternativa a Blynk, spiego nel dettaglio come acquisire i file conservati su Aruba con i dati dei sensori,
elaborarli su un pc e rinviarli su Aruba per la visualizzazione.
Il processo è gestito da un file eseguibile, residente su un vecchio pc XP di casa mia, che scarica un file alla volta, lancia
l'applicativo per generare la foto del grafico e manda la foto aggiornata per la visualizzazione.
Vi resta un lavoro manuale da fare ogni settimana, scorporare tramite un programma di editing, come LibreOffice Write, i record
più vecchi, al fine di mantenere i grafici intellegibili, ma anche questa operazione può essere svolta in automatico, ma ogni
settimana è bene controllare che tutto funzioni a dovere e queste operazioni manuali vi permettono di farlo.
Per realizzare la vostra pagina WEB potete prendere spunto dalla mia, potete catturarla ed editarla semplicemente con un programma di editing WEB come Microsoft FrontPage o altri più evoluti.
Non mi resta che augurarvi buona sperimentazione e se avete qualche problema nella realizzazione e gestione sono disponibile
a darvi una mano.

Questo è  il link per vedere online le mie centraline.


Per contatti: