DAY 4

CRONACA DI PROGETTO 

DAY 4

A cosa ci server?

Ogni viaggio giunge ad una conclusione, e se non lo fa siano beati o dannati i passeggeri. Il nostro termina oggi.

Entriamo nell'ufficio dopo un rapido caffè e come sempre ad aspettarci troviamo il nostro Virgilio del mondo informatico, Antonio Pintus. Finora siamo riusciti a connettere due Arduino attraverso dei server di prova già realizzati e pronti all'uso, ma l'ultimo giorno è sempre quello speciale.

L'obbiettivo di oggi è capire i principi che stanno alla base di un'applicazione server e successivamente di realizzarne una vera e propria per i nostri ipotetici usi nell'ambito IoT. Sappiamo però che molti dei nostri lettori, come noi, non sono certamente dei guru dell'informatica e perciò proveremo a spiegarvi a grandi linee quello di cui stiamo parlando.

Quando parliamo di applicazione server ci stiamo riferendo a un vero e proprio programma scritto e caricato su una macchina (PC, Arduino o server che sia) che sia in grado di accettare e rispondere a richieste che gli vengono fatte da un altro dispositivo. Nel nostro percorso del DAY 2 e del DAY 3 abbiamo già visto le richieste di tipo GET e POST, e sarà su queste che lavoreremo per lo più. L'intento è quello di realizzare un applicazione server a cui inviare dei dati rilevati da un sensore e che sia in grado di cederli sotto richiesta di un attuatore in modo da completare l'analisi delle parti dei sistemi IoT. Il nostro server non sarà certo al pari di quelli di google ma per i nostri scopi ci accontentiamo con molto piacere. 

Lavorare per la programmazione di alcuni piccoli server, sia locali che remoti, potrebbe rivelarsi un impresa più che ardua per quattro studenti che mai prima d'ora si erano cimentati in queste imprese ma per fortuna abbiamo la compagnia del nostro tutor che tanto basta ad addolcire le fredde linee di codice che ci si presentano davanti passo dopo passo.  Per realizzare i nostri scopi decidiamo di utilizzare come framework node.js. Una sorta di esecutore del linguaggio JavaScript che ci permette di realizzare applicazioni web anche di una certa complessità.

La sintassi di node.js è semplificata a tal punto che con sole quattro righe di testo è possibile creare un sever locale e, con qualche passo in più, anche uno in remoto. Il primo server che creiamo è elementare. Lo impostiamo per rispondere alle richieste GET con il messaggio "ecco la risorsa" e a quelle POST con un HTTP 201 dopo aver stampato sullo schermo il contenuto della richiesta del client.

Come ogni festa barbecue che si rispetti non ci limitiamo solo agli affettati ma decidiamo di mettere altra carne al fuoco e oltre alle due funzioni elementare di GET e POST e creiamo all'interno del server delle API che ipoteticamente ci permetterebbero di raccogliere i dati rilevati dai nostri sensori in una posizione specifica come ad esempio in un database. Nell'immagine sottostante è possibile distinguere le varie API create grazie al " / " che precede i loro nomi. 

Per verificare il tutto facciamo un tentativo di richiesta GET al server creato e grazie a un particolare terminale verifichiamo che il nostro sistema abbia ricevuto la richiesta. La conferma arriva dal codice a tre cifre di cui abbiamo parlato nel DAY 2 "304" che tradotto in linguaggio umano significa "not modified", ovvero, "Richiesta andata bene, la risorsa che hai chiesto è identica a com'era l'ultima volta che l'hai chiesta". 

La nostra esperienza si conclude qui, tra le righe di codice, gli Arduino i saluti e la consapevolezza di essere entrati in contatto con qualcosa di cui spesso ci si dimentica nell'uso quotidiano della tecnologia, quello che c'è dietro la tecnologia stessa.

Un grazie ad Antonio Pintus, alla coordinatrice di progetto Carol Salis e a tutto il CRS4.

DAY 3

CRONACA DI PROGETTO 

DAY 3

L’aiuto delle API

Durante la giornata precedente abbiamo avuto il piacere di iniziare ad esplorare degli strumenti essenziali per gli sviluppatori, le API.

In informatica le API sono delle librerie di funzioni che consentono,a sviluppatori o programmatori, di comunicare con un determinato software o piattaforma web che le mettono a disposizione. Sono fondamentali come per una cartolina l’indirizzo del destinatario, infatti, tutti possono spedire cartoline ma senza l’immissione dell’indirizzo non possono avvenire né spedizione né consegna.

Dunque , gli API consentono la comunicazione di sistemi remoti e stabiliscono come l’uno debba porre una richiesta e come chi ha ricevuto la richiesta debba dare la risposta.

Oggi abbiamo visto come avviene questa risposta e come il nostro microprocessore, Arduino, possa rielaborarla e ricavarne delle conclusioni comportandosi da attuatore.

Abbiamo incominciato la giornata con la stesura di uno sketch che ci ha permesso di contare tutte le ‘’a’’ presenti all’interno di una pagina web e dopo qualche problema di sorta nell’ottenere il dato (all’inizio ritrovavamo elencato tutto il conteggio del carattere) siamo venuti a conoscenza di un modo semplice e essenziale per la parte successiva, ottenere un dato specifico dalla piattaforma ‘’Paraimpu.com’’  

È la rete che c'illumina. 

Il pomeriggio avanza nel terzo giorno di corso e anche se il sole di giugno ci invita a metterci i costumi da bagno noi continuiamo incorruttibili sulla strada dell'IoT, come sempre nel nostro ufficio al terzo piano dell'edificio 1, immersi nella natura che circonda il Parco Tecnologico di Pula. 

Come avevamo già accennato nel DAY 2, alla base dell'IoT e più in particolare delle sue connessioni vi sono le due funzioni GET e POST; per chi avesse bisogno di un ripasso la prima chiede di ricevere dei contenuti da un server, la seconda di inviarceli, tutto secondo il protocollo HTTP, un tipo di comunicazione tra sistemi che consente solo dialoghi del tipo "request-response". Proviamo a immaginare un sistema che utilizza la tecnologia IoT. Abbiamo due dispositivi, un sensore e un attuatore. Dove il primo rileva una grandezza, il secondo agisce su qualcos'altro in funzione di questa stessa. Essi dovranno comunicare per trasmettersi le informazioni e perciò sarà necessario l'utilizzo di una rete che possa fungere da strada per i loro messaggi. 

Come già abbiamo fatto precedentemente ci affidiamo ad un semplice circuito che rende benissimo l'esempio, un termometro connesso ad un Arduino ma con una variante; questa volta, dato che l'Internet of Things prevede una comunicazione tra più dispositivi ci sarà anche un secondo Arduino che per comodità è connesso ad un semplice LED. L'intento è far illuminare il LED quando la temperatura della stanza supera i 20 gradi. 

Per comodità e mancanza di tempo scegliamo di utilizzare la piattaforma Paraimpu. Per chi non sapesse di che si tratta, immaginate di dover spedire un pacco ad un amico. In ogni paese civile ci sarà sempre un servizio di posta che prenderà il vostro pacco, ne indicizzerà l'indirizzo di destinazione, lo spedirà nei giusti hub e infine lo recapiterà al vostro amico. Una delle funzioni e potenzialità di Paraimpu è questa. La piattaforma rende disponibile a chiunque volesse degli API per immagazzinare dati prodotti dai vostri sensori e richiederli per far funzionare i vostri attuatori. Entriamo dunque sul sito e creiamo un sistema generico sensore-attuatore. Il primo sarà ovviamente il termometro e il secondo un LED. 

Utilizziamo gli API che il sito ci ha fornito e impostiamo le nostre schede Arduino per trasmettere i dati a quei precisi indirizzi. Nell'immagine sottostante potate infatti notare che la funzione POST del primo Arduino carica i dati nell'indirizzo in blu, (l'API del termometro)

Mentre il secondo Arduino esegue una richiesta GET dei dati caricati dal primo.

Ricordiamoci però che il nostro obbiettivo è far accendere un LED quando la temperatura della stanza supera i 15 gradi; per farlo impostiamo lo sketch del nostro secondo Arduino per illuminarci solo se il valore della temperatura letto (corrispondente qua sotto alla dicitura string) è maggiore di 20.

Calcolato il valore "string" lo poniamo come parametro del costrutto "if" che mette il nostro LED in stato alto con la funzione "digitalWrite(13,HIGH)", nel caso in cui la temperatura sia invece minore di 20 gradi la funzione "else" spegnerà il LED.

Il sistema è ora completo, il primo Arduino rileva la temperatura e invia il dato a un API fornitoci da un server, il secondo invece legge il valore caricato dal primo (sempre attraverso la chiamata di un API) e reagisce di conseguenza. La parte fisica del sistema termometro-LED è ora connessa grazie a una parte virtuale. Questa, cari lettori, è l'essenza dell'Internet delle cose.

DAY 2

CRONACA DI PROGETTO 

DAY 2 

About HTTP

La mattina del secondo giorno di corso si apre con una lezione dettagliata sul protocollo HTTP, tenuta come sempre dal nostro eccellente tutor, Antonio Pintus. Per capire meglio cosa rappresenti questo particolare nome proviamo a immaginare di dover scrivere una lettera formale ad una persona importante. Nella stesura della lettera si rivelerà opportuno l'utilizzo di una certa forma, ad esempio inserire oltre al messaggio la data, l'indirizzo del destinatario, la firma e così via. Allo stesso modo, quando due dispositivi comunicano attraverso il protocollo HTTP devono utilizzare delle particolari forme di "scrittura" del messaggio. E' importante sottolineare che la comunicazione con protocollo HTTP prevede solo l'interazione tra due dispositivi del tipo "request-response", ovvero richiesta e risposta. Di fatto, in un dialogo c'è sempre un dispositivo che chiede e l'altro che risponde. E sebbene le richieste e le risposte possano essere di vario tipo, la loro forma rimane sempre la stessa, e sarà questo ciò che vi illustreremo.

La strutta del protocollo HTTP è divisa in tre parti. La prima, detta "request-line"  indica il tipo richiesta che stiamo facendo. Nel caso in cui ricevessimo una risposta da un server questa prima parte prende il nome di "status line" poiché come suggerisce il nome stesso ci informa sullo stato della comunicazione. Se quest'ultima fosse il paziente di un dottore la status line sarebbe il suo referto medico. Grazie alla status line e ad un messaggio a tre cifre contenuto in essa siamo in grado di capire se il server destinatario della nostra richiesta l'abbia effettivamente ricevuta, accettata o ci abbia ad esempio negato i permessi per accedere a un contenuto che volevamo. Oltre alla status line il protocollo HTTP prevede anche una seconda parte, quella degli header. Così come ognuno di noi è in possesso del proprio documento d'identità dove vengono specificati indirizzo, data di nascita e altri dati personali, così gli header informano i dispositivi su molti dettagli aggiuntivi al semplice stato della comunicazione. Con gli header possiamo informarci sul tipo di messaggio che stiamo ricevendo, sulla dimensione suo contenuto o al contrario possiamo chiedere di ricevere solo un certo tipo di contenuti creati in una precisa data. Ci accingiamo ora ad arrivare all'ultima parte del protocollo HTTP, quella che trasporta il vero e proprio contenuto della richiesta e della risposta. Questa è detta anche "body" perché in essa è impacchettato il contenuto del messaggio, esattamente come quando scriviamo ciò che l'altra persona dovrà leggere nella parte sinistra di una cartolina.

Sebbene la struttura che abbiamo appena analizzato rimanga invariata per tutte le comunicazione che utilizzano il protocollo HTTP, i contenuti di queste ultime possono variare in tanti fattori. Diversi sono infatti i tipi di richieste che possiamo inviare; le due su cui ci concentriamo di più e che più hanno da aggiungere al nostro bagaglio IoT sono quelle di GET e di POST. La prima richiede un contenuto, la seconda chiede di postarlo sul server. Com'è facile intendere, in un ipotetico sistema "sensore-server-attuatore" le richieste GET e POST sono quelle che comporrebbero la fitta rete di messaggi, poiché dove il sensore chiede di inserire dati sul server, l'attuatore chiede di riceverli da esso.

GET e POST in Arduino

Dopo aver capito di più sulle comunicazioni HTTP arriva il momento di applicare gli insegnamenti del nostro tutor su qualcosa di tangibile. Decidiamo quindi di provare le due funzioni di GET e POST mediante il nostro Arduino Yùn. Come ogni comando che impartiamo alla scheda dev'essere prima programmato con uno sketch, anche le funzioni  sopracitate sono utilizzabili solo se prima programmate nella scheda. Per permettere al nostro processore di comunicare con un altro dispositivo è necessario impostarlo per connetterlo autonomamente a una rete. Per chi volesse cimentarsi nell'impresa le procedure (abbastanza elementari) sono descritte in questa guida
Ora che la nostra scheda è connessa alla rete tentiamo di fare una richiesta GET ad un indirizzo dato e ne analizziamo i risultati. Ancora una volta, per chiunque volesse ripetere la procedura le indicazioni possono essere trovate seguendo questo link noi invece vi riportiamo solo una parte "saliente" dello sketch dove è chiaramente visibile il tipo di richiesta "client.get" 

            

A seguito della richiesta riceveremo una risposta che Arduino stamperà sul monitor seriale e che potremo quindi visualizzare agevolmente.

Fatto ciò ci inoltriamo più in là nelle acque della comunicazione e proviamo la seconda delle due funzioni che vi abbiamo presentato, quella di POST. Per chiedere di caricare un contenuto dobbiamo ovviamente avere qualcosa da inviare e per questo decidiamo di rilevare la temperatura con il circuito sperimentato nel DAY 1 e di spedire i valori letti dal nostro Arduino a un server di prova (generato sul sito www.requestb.in). Come nel caso precedente vi riproponiamo solo la parte più "saliente" dello sketch, quella dove è visualizzato il comando POST e l'indirizzo del server a cui invieremo il nostro dato. 

Fatto ciò ci sarà possibile accedere al dato caricato ogni qualvolta vorremo, o in un contesto più concreto, ogni qualvolta il nostro attuatore avrà bisogno di un valore su cui basarsi.

DAY 1

CRONACA DI PROGETTO

DAY 1 

Introduzione internet e web

Per navigare in acque conosciute incominciamo il progetto IoT - Desir con una rapida ma importante lezione sul mondo della rete tenuta dal nostro Tutor nonché capo progetto Antonio Pintus. 

Dalle differenze tra web e internet alle basi del funzionamento del protocollo HTTP entriamo timidamente nel mondo della rete. È sorprendente scoprire quanti processi e richieste avvengono in quei 0,30 secondi di Google e quanto ci sia dietro una semplice ricerca, quando a noi basta premere pochi tasti, p, i, z, z, a, e abbiamo all'istante una pagina coi migliori link su uno dei piatti più amati al mondo. Ma la questione è un po' diversa, se osserviamo la ricerca dal punto di vista delle macchine: il browser effettua una "GET", o una "POST"; viene seguito un rigido protocollo e si ricevono indietro dei dati, poi riorganizzati per permetterci di accedere alle informazioni. Ma il bello è capire come tutto sia possibile, grazie ad HTTP.

Primi passi con Arduino

Dopo esserci rapidamente formati sul come funziona la rete, iniziamo a prendere confidenza con la scheda programmabile più amata della piazza, Arduino.

Essendo l'Internet of Things l'essenza del nostro progetto ci è necessario comprendere come questa piccola scheda riesce a comandare e comunicare con altri dispositivi. Il primo sketch che realizziamo è un semplice codice per rilevare la temperatura dell'ambiente con un sensore LM35. Nonostante il circuito in questione sia molto semplice il valore effettivo è ben più grande. Scopriamo infatti che Arduino può essere programmato per inviare e ricevere segnali, ma la vera skill è che 
decidiamo noi cosa fare del segnale una 
volta rilevato.