Internet Of Green

di Dan Pejeroni [Infosphere]

Utilizzare l’agrometeorologia con le tecnologie Internet of Thing e Machine Learning per la gestione degli impianti di irrigazione è stata la sfida che mi sono posto progettando e sviluppando questo prototipo. Lo scopo di questo primo articolo è presentare l’abstract del progetto, mentre nei seguenti fornirò i dettagli tecnici degli aspetti funzionali, hardware e software.

Le comuni centraline degli impianti di irrigazione sono in grado di controllare l’erogazione idrica alle diverse zone in cui è suddivisa l’area verde, fornendo quantità d’acqua predefinite (in base al tempo di attivazione dei vari gruppi di erogatori). I cicli di irrigazione sono quindi subordinati a calendari settimanali programmabili. 

L’aspetto critico di questo approccio è rappresentato però dall’ottimizzazione del consumo d’acqua, spesso prelevata dalla rete idrica che impone stringenti limiti a queste forme di utilizzo. Se, per esempio, il nostro programma di irrigazione prevedesse 5 cicli settimanali dalle 3:00 alle 5:00, avremmo un consumo di oltre 2 mq giornalieri e, tenere conto del fattore pioggia per risparmiare cicli, diventerebbe assolutamente prioritario. Purtroppo l’unico strumento spesso disponibile su questi impianti è rappresentato da rudimentali sensori pioggia che quando si bagnano interrompono l’irrigazione fino a quando non si asciugano. Se la precipitazione arrivasse successivamente all’ora di attivazione prestabilita, avremmo sprecato 2000 litri di preziosa acqua potabile. 

Partendo da queste considerazioni ho deciso di creare Internet Of Green, un micro controller basato sulla scheda Arduino MKR 1010, che sfrutta diverse strategie per minimizzare il consumo idrico e garantisce un’erogazione ottimale alle varie zone verdi. Il sistema scambia dati con il cloud Internet Of Things Blink, per il controllo remoto da PC e smartphone.

 

La MKR WIFI 1010 è la versione migliorata della MKR 1000 WIFI. E’ equipaggiata con il modulo ESP32 della U-BLOX. Questa scheda mira a velocizzare e semplificare la prototi-pazione di applicazioni IoT basate su WiFi grazie alla flessibilità del modulo ESP32 ed il suo basso consumo.

La scheda è formata da tre blocchi principali: il processore SAMD21 Cortex-M0+ 32bit Low Power ARM MCU; il modulo WiFi U-BLOX NINA-W10 Series Low Power 2.4GHz IEEE® 802.11 b/g/n; ed il chip ECC508 Crypto Authentication.

 

Per ottenere questi risultati Internet Of Green utilizza congiuntamente diverse strategie:

  • monitoraggio e analisi dell’umidità del terreno delle singole zone;
  • analisi parametri ambientali rilevati dalle sonde;
  • previsioni meteorologiche (ottenute da API OpenWeatherMap);
  • machine learning sulla pluviometria effettiva.

Il micro controllore riceve una serie di dati in tempo reale da una rete di sensori ambientali e mantiene uno storico, successivamente utilizzato dagli algoritmi di machine learning per prendere le decisioni operative sui criteri di irrigazione:

  • temperatura e umidità dell’aria;
  • pressione atmosferica;
  • velocità del vento;
  • radiazione solare;
  • pluviometria;
  • umidità del terreno.

Monitoraggio dell’umidità del terreno

L’umidità del terreno è rilevata da sonde capacitive a minima corrosione che la trasmettono (ogni 10′) al controller che, comparando i valori ottenuti con i trigger impostati, fornisce o inibisce il consenso all’irrigazione. Durante il periodo estivo su terreno argilloso e prato di Festuca arundinacea, valori di umidità compresi tra il 25 e il 30% hanno dato risultati soddisfacenti. Se da un lato questa modalità di gestione dell’irrigazione può

 
 

garantire un livello minimo di umidità del terreno, dall’altro, come metodo consuntivo, non garantisce la minimizzazione del consumo idrico. Non è inoltre in grado di modulare la quantità d’acqua da erogare per ogni ciclo irriguo, non essendo in grado di prevedere il fattore di evapotraspirazione, legato a parametri ambientali quali temperatura, umidità dell’aria, vento e livello di irraggiamento.

Previsioni meteorologiche OpenWeatherMap

La strategia più idonea per un efficace contenimento dei consumi idrici è quella di consultare le previsioni meteo prima di avviare ogni ciclo di irrigazione. Per essere utilizzata praticamente una previsione deve essere però interpretata, poiché é necessario decidere se un determinato scenario di previsione può essere preso con sufficiente sicurezza come segnale di sospensione del normale ciclo irriguo. Trattandosi in ogni caso di una previsione di natura generale, questa decisione deve essere adattata alle caratteristiche orografiche del territorio specifico.

Internet Of Green, immediatamente dopo la mezzanotte, attiva la seguente serie di processi per attuare la strategia predittiva:

  • Utilizza le API messe a disposizione dal network OpenWeaterMap per scaricare la più recente previsione (suddivisa in otto intervalli di tre ore) che copre le successive 24 ore;
  • Traduce la previsione in un indice che rappresenta la probabilità che nelle successive 24 ore si verifichi un evento piovoso significativo e lo salva nella knowledge base;
  • Consolida il valore di pioggia effettiva (ricavata del pluviometro) nelle trascorse 24 ore, lo salva nella knowledge base e conferma o meno la previsione;
  • Attiva il processo di apprendimento (decision tree) sull’intera knowledge base ottenendo un benchmark aggiornato con cui paragonare la previsione ottenuta;
  • Abilita o disabilita l’irrigazione;

Questa strategia, con la crescita della base dati storica, aumenta nel tempo l’attendibilità della previsione effettuata dagli algoritmi di machine learning, adattandola alle condizioni locali e alle specifiche finalità di controllo dei cicli irrigui. Affiancata al monitoraggio dell’umidità del terreno, permette notevoli risparmi idrici evitando inutili irrigazioni.

Evapotraspirazione e bilancio idrico

L’evapotraspirazione (ET) rappresenta la quantità d’acqua che effettivamente evapora dalla superficie del terreno e traspira attraverso gli apparati fogliari delle piante, in determinate condizioni di temperatura, vento, umidità e irraggiamento solare. In estrema sintesi, possiamo affermare che Il nostro bilancio idrico è dato dalla differenza tra la precipitazione (mm di pioggia)

e l’evapotraspirazione. Questa differenza deve essere compensata dall’irrigazione. L’evapotraspirazione aumenta per effetto dell’irraggiamento, del vento e della temperatura, ma dipende anche dalle caratteristiche morfologiche del terreno e ecofisiologiche della coltura.

Internet Of Green, attraverso una rete di sensori ambientali, rileva nel corso delle 24 ore queste grandezze, consolidandole a fine giornata e calcolando quindi l’evapotraspirazione (mm/day). Poiché questo valore anticipa ciò verrà rilevato a consuntivo dalle sonde di umidità del terreno, possiamo utilizzarlo per modulare la quantità d’acqua da fornire alle varie zone, agendo sul tempo di erogazione degli irrigatori.

Una gestione multilivello

Internet Of Green, per realizzare una gestione ottimale dell’impianto d’irrigazione, può quindi avvalersi di tre distinte metodologie che possono essere utilizzare in modo indipendente o combinato. Per un gestione di base, è possibile avvalersi del solo monitoraggio dell’umidità del terreno, che disabilita l’irrigazione quando questo parametro supera la soglia di trigger impostata (per esempio 30%), oppure affidarsi alle sole previsioni meteorologiche, in modo che in previsione pioggia l’irrigazione venga sospesa. Anche utilizzando il solo controllo dell’evaporazione e del bilancio idrico è possibile gestire l’irrigazione, ma è dalla combinazione delle tre strategie che si ottengono

i migliori risultati garantendo un corretto livello di umidità al terreno minimizzando nel contempo i consumi idrici.

Il prototipo Internet Of Green è in fase di beta testing da agosto 2019 offrendo risultati molto positivi. Per la gestione WiFi dei sensori sul campo, è stata sperimentata l’adozione del protocollo MQTT e del cloud ThingSpeak. Nell’ultimo periodo è corso di valutazione anche l’utilizzo della nuova scheda Arduino MKR1310 a basso consumo che implementa la comunicazione LoRa (Long Range) e il cloud The Things Network.

Domus – Internet of Things per la domotica (parte 1)

Un (altro) progetto IoT basato su Arduino che implementa funzioni di telecontrollo, automazione, data logging e allarmi.


Per la realizzazione di un sistema di automazione e telecontrollo per la casa, si può contare oggi sui molti componenti disponibili nel mercato home automation che, nonostante la mancanza di standard definitivi, si avvia alla maturità. Dall’altra parte abbiamo tecnologie open source che, anche in questo campo, rappresentano una valida alternativa al buy.

Per comprendere meglio il fenomeno ho deciso di rispolverare le mie competenze di elettronica e realizzare un prototipo funzionante per il telecontrollo di una ambiente domestico basato su Arduino Uno: Domus.

Diapositiva1

Domus prevede una sezione attuatori per il comando dei sistemi di riscaldamento, irrigazione e illuminazione giardino e una sezione sensori che raccoglie e gestisce le varie sonde sul campo (tensione, corrente, flusso acqua, temperatura, umidità terreno, luce, pioggia) e allarmi (blocco caldaia, intrusione, incendio, allagamento, gas).

Screenshot_2015-02-19-12-07-16

Il telecontrollo del sistema è basato su un’applicazione Android (per il comando remoto degli attuatori), sviluppata con Tasker e su un PLC controller (basato su un Asus EEE-Box con Windows 7) che svolge funzioni di data logger, reporting e automazione di processo.

Negli articoli seguenti illustrerò le componenti del sistema hardware, software e le configurazioni di rete.

Domus parte2: Arduino

Domus Parte3: Networking

Domus parte4: App Android

Domus parte5: PLC Controller

Domus – Internet of Things per la domotica (parte 2)

La seconda parte dell’articolo illustra la scheda Arduino, lo sketch principale e le librerie utilizzate, gli shield Ethernet, Relè, i sensori e la board di adattamento.


Hardware

Il prototipo Domus si basa sui seguenti componenti:

  • Scheda Arduino Uno
  • Ethernet Shield W5100
  • Board a 4 Relay 250v – 10A
  • Scheda di adattamento realizzata con basetta millefori

Lo schema seguente rappresenta la scheda di adattamento. Nella parte superiore sono elencati i collegamenti agli ingressi analogici e digitali della scheda Arduino, mentre nella parte inferiore i collegamenti ai vari sensori. La basetta è stata dotata di due morsettiere saldate. Gli ingressi digitali 10-13 sono impegnati dall’Ethernet Shield W5100, mentre i 4-7 dalla scheda relè.

Diapositiva2

I sensori utilizzati sono facilmente reperibili a prezzi contenuti su eBay e Amazon:

  • Sonda di corrente (non invasiva) SCT-013-030
  • Alimentatore 220/9v AC/AC (corrente alternata in uscita)
  • Sonda liquidi FS-200°
  • Due sonde digitali di temperatura DS18820 (collegate in bus)
  • Una sonda Soil (umidità terreno)
  • Una sonda pioggia
  • Una fotoresistenza VT90N3
  • Il contatto digitale costituito da un relè presente nella caldaia a condensazione e programmabile per chiudersi quando è in blocco

Software

Lo sketch caricato su Arduino è il seguente:

Arduino Sketch

Il loop principale dello sketch Domus risponde a comandi REST sulla porta 85 del web server creato dalla libreria Ethernet. I comandi HTTP Get vanno lanciati da un browser o, come nel nostro caso, dall’app Android e restituiscono tipicamente il valore di risposta (esempio: 192.168.2.177:85/Lux).

I comandi supportati sono i seguenti:

Comando            Risposta

  • /Emon                  : tensione (V); corrente (A); potenza (W)
  • /Water                 : flusso acqua (L/Hour)
  • /Temp0               : Temperatura Zona Giorno (°C)
  • /Temp1               : Temperatura Zona Notte (°C)
  • /Soil                      : Umidità terreno (val)
  • /Rain                     : Pioggia (0=pioggia, 1=asciutto)
  • /Lux                      : Luminosità (Lux) aprox
  • /Alarm                 : Allarme blocco caldaia (0=blocco, 1=ok)
  • /01_on                 : Attiva relè01 e restiruisce stato di tutti (1000)
  • /01_off                : Disattiva relè01 e restiruisce stato di tutti (0000)

(vale per i relè 01-04)

Dopo l’inclusione delle librerie è necessario configurare i parametri: indirizzo ip, default gateway (il vostro router o, come vedremo più avanti l’indirizzo del gateway OpenVPN) e porta. Seguono le definizioni relative al BUS OneWire (per le sonde di temperatura DS18D20) e agli altri sensori e relè.

Le librerie utilizzate (che quindi devono essere installate nel vostro IDE Arduino) sono le seguenti:

  • Dallas Temperature Control
  • Emon Lib Master
  • OneWire
  • Webserver.h

Per informazioni su come installare le librerie consultate : http://arduino.cc/en/Guide/Libraries

Vai a Domus parte 3: Networking

Domus – Internet of Things per la domotica (parte 3)

La terza parte dell’articolo illustra le soluzioni di rete adottate per superare le limitazioni degli operatori di telefonia mobile italiani, che da qualche tempo forniscono solo IP privati.


Dopo aver realizzato e testato positivamente il prototipo Arduino sulla mia LAN, è venuto il momento di provare l’accesso via WAN, che rappresenta le normali condizioni di utilizzo. Con ADSL Alice, l’accesso remoto non costituisce un problema, in quanto registrando un account gratuito ad un servizio DNS dinamico (NO-IP, Dyndns, ecc.) si ottiene facilmente l’equivalente di un indirizzo statico.

I problemi sono iniziati quando ho provato l’accesso tramite un router connesso ad una chiavetta Vodafone. Questo scenario di utilizzo è tutt’altro che remoto: spesso la casa da controllare non dispone di connettività ADSL e l’unica soluzione è questa.

Ho eseguito la prova con un router TP-Link TL-MR3420 (Morgana) dopo aver inserito una vecchia chiavetta Huawei nella sua porta USB 3G/4G con sim dati Vodafone ed aver associato l’end point ad un account dyndns.  Niente. Nessuna risposta. Un trace con WireShark mi ha confermato quello che già la classe di indirizzi avrebbe dovuto suggerirmi: 10.128.224.10, indirizzo IP privato. NAT. Niente da fare.

Sembrava che TIM fornisse ancora IP “alti”, ma qualcuno lo smentiva. Sono andato allora a comprare una sim TIM per provare.  Risultato: 10.239.31.157. Anche da TIM un indirizzo privato.

E se stabilissi una VPN tra la LAN di casa (servita da ADSL) e la LAN di Arduino (servita da chiavetta TIM)?  Sarebbe come fossero sulla stessa LAN.

Camelot Net

Non essendo i miei router in grado di attivare autonomamente le VPN, ho ripiegato su una soluzione basata su OpenVPN, riciclando ancora una volta i miei due vecchi e fidati Asus EEE-Box, Excalibur e Dragonet. Saranno loro a sostenere la VPN, il primo come server, il secondo come client. Dopo qualche tentativo (occhio al famigerato firewall di windows), con questa configurazione sui due end point ho ottenuto i primi risultati.

Generare una chiave simmetrica key.txt, tramite l’apposita utility e copiarla nelle cartelle “config” di OpenVPN di entrambi gli host. Quindi scegliere una subnet diversa da entrambe quelle degli host coinvolti (es. 10.3.0), aggiungere sul default gateway della rete del server (il router) una rotta statica che inoltri tutto il traffico destinato alla rete 10.3.0 verso l’IP privato del server (10.3.0.2).

Registrare su DynDNS e creareun hostname per il server (es: mioserver.dyndns.net). Installare sul server il client DynDNS e configurarlo per usare l’hostname appena creato.  Accertarsi che il relativo servizio parta automaticamente.

Installare OpenVPN su entrambi gli host, e inserire nelle cartelle “config” di OpenVPN i ripettivi file di configurazione, con estensione “ovpn”:

Dragonet Client.ovpn

Excalibur Server.ovpn

Sul server avviare il servizio “OpenVPN Server” e impostarne l’avvio automatico. Sul client, collegato ad internet con la connessione 3G,  eseguire “OpenVPN GUI” in modalità amministratore, cliccare col tasto destro sull’icona nella systray e scegliere “connect”.

Effettuare dei test di connettività. In caso di problemi, i log di OpenVPN sono molto esplicativi già a verb 3.

Il keep-alive ping garantisce la pronta connessione automatica della VPN ogni qualvolta le due macchine sono attive.

Rimane ancora da risolvere un problemino:  la creazione di una rotta statica verso la subnet  192.168.2.0 e l’inibizione del naturale percorso di ritorno di Morgana tramite Internet.

Per risolverlo, installare su Excalibur la comoda utility Passport per Windows, che permette il  forwarding di tutte le porte IP di Excalibur 192.168.0.200 su Dragonet  102.168.2.200 e configurare sul router  Taliesyn la rotta statica verso 192.168.2.0 tramite Excalibur 192.168.0.200.

Il risultato finale è la piena raggiungibilità di Arduino (mioserver.dyndns.net:85/cmd) da Internet (via Taliesyn, Excalibur, Dragonet ed infine Arduino 192.168.2.177:85).

Vai a Domus parte4: App Android 

Domus – Internet of Things per la domotica (parte 4)

La quarta parte dell’articolo illustra l’app Android per il telecontrollo di Domus.


Tasker è un’applicazione Android che permette la completa automazione dello smartphone. Per conoscere cosa fa, vi rimando direttamente a Google Play Store – Tasker.

Per lo sviluppo dell’app Android per Domus, mi sono basato sulla funzionalità “Editor di Scene”.

Screenshot_2015-02-19-12-07-16Una scena è una interfaccia grafica costituita da un insieme di elementi a cui possono essere collegati dei task in modo da essere eseguiti quando l’utente interagisce con essi, ad esempio toccandoli.

Tasker utilizza le scene per  le finestre di dialogo, i menu e per ottenere un input da parte dell’utente. Più in generale le scene possono essere visualizzate per  la creazione di semplici applicazioni o mostrando controlli aggiuntivi nella parte superiore delle applicazioni esistenti.

Le scene sono completamente personalizzabili dall’utente tramite un editor grafico drag-and-drop.

La funzione di export delle applicazioni, pur permettendone il salvataggio in formato XML, non fornisce un listato comprensibile, quindi non mi è possibile fornire, in questo articolo, il codice dell’app Domus. Tenete presente che, pur non essendo un programmatore, ho sviluppato senza difficoltà questa applicazione in poche ore di lavoro.

Il risultato si presenta a tutti gli effetti come una normale app Android che, utilizzando i servizi REST predisposti su Arduino, permette di effettuare il completo telecontrollo dei relè e l’elaborazione degli stati di ritorno, in modo da accendere i bottoni e rappresentare la condizione di ogni contatto. Inoltre il display superiore permette la visualizzazione dei valori dei sensori (temperatura, umidità, luce, corrente, flusso, condizioni di allarme, ecc.).

Vai a: Domus parte5: PLC Controller

Domus – Internet of Things per la domotica (parte 5)

La quinta e ultima parte dell’articolo, illustra le funzioni del PLC Controller, a supporto di Arduino, realizzato con l’EEE-Box.


Sebbene Arduino permetta la realizzazione di web servers e l’esecuzione di task complessi, per la mia sperimentazione ho deciso di limitarne l’uso a quello di attuatore relè e data-logger. Ho invece delegato le funzioni di raccolta, campionamento, storicizzazione e reporting dei dati, provenienti della rete di sensori, ad un piccolo server basato su EEE-Box con sistema operativo Windows 7.

Le componenti software utilizzate sono le seguenti:

Python 3.4.3 for Windows

EasyPHP for Windows

La libreria PHP pChart per I grafici

La piccola utility Tail

Le funzioni di raccolta, campionamento e storicizzazione sono affidate ad uno script Python che viene attivato ogni 15’ dallo scheduler di windows (l’intervallo di tempo può essere adattato alle effettive esigenze di controllo). Lo script invoca le chiamate REST, relative ai vari sensori, su Arduino e memorizza i dati raccolti in un set di file in formato csv nella directory c:\Domus.

Questo è lo script: Domus.py

Per farlo girare è necessario installare le librerie: smtplib, httplib2, datetime e os. La prima parte dello script interroga le sonde di temperatura, corrente, tensione, potenza, luminosità e condizione di allarme caldaia (sostituite gli indirizzi: mioserver.miodominio.net:85 con quelli a cui avete associato Arduino).

Alla fine, lanciando i file di comandi: Tail-Temp.batTail-Temp1.batTail-Emon.bat vengono regolate (a max 100 elementi nel mio caso) le lunghezze dei file dati csv, in modo da favorirne una comoda rappresentazione in forma di grafico.

La condizione di blocco caldaia è rilevato da Arduino mediante lettura di un ingresso digitale a cui è collegato un contatto della caldaia a condensazione, che viene chiuso in questo caso. Nell’ultima parte dello script Domus.py viene inviata una mail con soggetto ‘Caldaia in blocco!’, grazie alla libreria smtplib.

Il PLC è controllabile mediante il web server Apache messo a disposizione dal WAMP EasyPHP. Con l’aggiunta della comoda libreria PHP pChart sono riuscito a produrre facilmente grafici a partire dai file dati csv (opportunamente accorciati).

Temperature

Dopo aver installato e configurato pChart, provate ad eseguire da un browser lo script PHP: Temperature.php

Conclusioni

Tre mesi di test hanno dimostrato una discreta stabilità ed affidabilità del prototipo Domus. In particolare la soluzione scelta per ovviare all’indisponibilità di indirizzi ip privati, da parte dei provider di connettività mobile HSPA, si è rivelata solida e implicitamente sicura, grazie all’uso di VPN. Spero possa essere d’aiuto in generale a chiunque necessiti di un accesso remoto a siti non serviti da connettività ADSL.

La scheda Arduino Uno si è rivelata straordinariamente solida, perdonando le saldature fredde che non ho potuto evitare, nella realizzazione della Board di Adattamento con la basetta millefori. Anche i sensori, economici e facilmente reperibili, si sono risultati molto stabili e precisi.

Per lo sviluppo dello sketch, ho utilizzato alcune librerie, integrando porzioni di codice reperiti in rete da progetti open-source diversi, come Emon (Open Energy Monitor). Talvolta, considerato il carattere prototipale della realizzazione, mi sono concesso qualche approssimazione, come nel caso della trasformazione in Lux dei valori di output (assolutamente non lineari e difficilmente linearizzabili) della fotoresistenza VT90N3. Per la finalità di rilevare se c’è poca o tanta luce, mi è stato sufficiente così.

La scelta di relegare Arduino al ruolo di data-logger e di attuatore, è stata inizialmente dovuta alla mia scarsa conoscenza dell’ambiente di sviluppo della scheda, ma alla fine si è rivelata razionale e coerente con le limitate caratteristiche hardware di Arduino Uno. Ho considerato una possibile evoluzione del prototipo con l’adozione della scheda Arduino  Yún (che, grazie al sistema operativo Linux, permetterebbe di evitare il PLC).

Naturalmente qualunque suggerimento sarà ben accetto.

Dan

#IoT Domus: una Goccia nell’Oceano dei Big Data

di Dan Pejeroni [Infosphere]

 L’evoluzione del progetto IoT Domus su hardware Arduino Uno, per utilizzare ora il cloud Blynk.

Temperature

Il progetto Domus prevede una sezione attuatori per il comando dei sistemi di riscaldamento, irrigazione e illuminazione giardino e una sezione sensori che raccoglie e gestisce le varie sonde sul campo (tensione, corrente, flusso acqua, temperatura, umidità terreno, luce, pioggia) e allarmi (blocco caldaia, intrusione, incendio, allagamento, gas).

Nella prima serie di articoli avevo descritto un prototipo di telecontrollo affidato ad un PLC controller (basato su un Asus EEE-Box con Windows 7) che svolgeva funzioni di data logger, reporting e automazione di processo e ad un’applicazione Android (per il comando remoto degli attuatori), sviluppata con Tasker.

Questa nuova versione si basa sul Cloud IoT Blynk.

cwqpfohwiaaj6xg-jpg-large

Blynk è una piattaforma per iOS e Android che permette il controllo di schede Arduino, Raspberry Pi e altre, collegate a Internet tramite Wi-Fi, Ethernet o mediante il nuovo chip ESP8266. Si tratta di un cruscotto digitale dove è possibile costruire una interfaccia grafica per progetti IoT, semplicemente trascinando e rilasciando widget.

Blynk è stato finanziato su Kickstarter da 2.321 sostenitori che hanno creduto nell’idea. È possibile visitare la loro pagina della campagna e sapere di più.

Il Cloud Blynk è in grado di acquisire e memorizzare i dati rilevati dai sensori, collegati ad una scheda tra le molte supportate.

La piattaforma è costituita da tre componenti principali:

Blynk App – che permette di creare interfacce grafiche per i progetti IoT, semplicemente utilizzando vari widget forniti.

Blynk Server – che è responsabile di tutte le comunicazioni tra lo smartphone e l’hardware. È possibile utilizzare il Cloud Blynk o installare un server Blynk localmente. E completamente open-source e può facilmente gestire migliaia di dispositivi in comunicazione con il server (o il Cloud) elaborando tutti i comandi in entrata e in uscita

architecture

Ogni volta che un sensore rileva una nuova misura, oppure viene premuto un pulsante sull’app Blynk, i messaggi di controllo vengono trasferiti verso/dal Cloud Blynk, che acquisisce i dati oppure attiva un attuatore sulla scheda.

cwpaxetwiaqlmcq

Per iniziare con Blynk è necessario scaricare l’app Android o IOS, registrarsi sul sito per ottenere un Auth Token (che dovrà essere utilizzato sia nell’app che nello sketch della scheda), installare la libreria fornita da Blynk e scrivere il codice specifico da installare sulla scheda.

La versione 4.2 Cloud di Domus è disponibile su GitHub.

schermata-2016-11-24-alle-14-27-59