In questa quinta e ultima puntata realizzeremo una classica applicazione IoT. Si tratta di un contenitore per le uova fresche dal funzionamento intelligente e del tutto automatico. Quando esse stanno per terminare ed essere consumate, il sistema emette una segnalazione luminosa e, contemporaneamente, viene inoltrato un ordine immediato al negoziante. L'operatore, quindi, si deve preoccupare solo di riporre le nuove uova recapitate dal venditore nell'apposito contenitore e poi... mangiarle.
La scorta di uova si sta esaurendo ma l'ordine viene automaticamente inoltrato al negoziante con una email
In questo ultimo articolo del corso abbiamo pensato bene di realizzare una utile e simpatica applicazione da utilizzare nella cucina della propria casa. Nei prossimi mesi il luogo più importante della nostra abitazione sarà sempre più corredato da tanti dispositivi di controllo degli alimenti. La casalinga non avrà più il bisogno di fare l'inventario di ciò che manca in frigorifero o nella dispensa ma, grazie all'IoT vedrà ricevere a domicilio la merce, a sua completa insaputa. In questo modo ella potrà dedicarsi ad altro e può stare pienamente tranquilla consapevole che l'informatica lavora al suo posto, senza mai commettere alcun errore. In particolare, il nostro prototipo ospita delle uova fresche. Non appena il loro numero scende al di sotto di un certo limite, programmato a priori dall'operatore, l'oggetto "si sveglia" e comincia a dare ordini e avvertimenti. Prima di tutto emette un lampeggio luminoso continuato per ricevere le attenzioni dei componenti della famiglia. Ma, cosa ancor più importante, prende automaticamente l'iniziativa di spedire subito una email al negoziante, che provvederà al più presto a rifornire la merce richiesta. Un apposito controllo provvede ad inoltrare una volta sola il messaggio di posta elettronica, anche se la mancanza di uova continua a perdurare, ovviamente, fino al successivo approvvigionamento di esse.
Le uova si mettono in frigo?
Il dispositivo che andiamo a presentare prevede un dislocamento e un funzionamento fuori dal frigorifero. L'importante, infatti, è non far prendere shock termici alle uova. Ma se avete la possibilità di passare qualche filo elettrico, il circuito può essere anche collocato all'interno. Il dilemma che colpisce i consumatori, infatti, è sempre lo stesso: "Uova in frigo oppure no?". Le scuole di pensiero, al riguardo, sono numerose: consultate la Rete per trovare una risposta, forse...
Schema di concetto
La figura 1 mostra un diagramma a blocchi con tutti i componenti coinvolti nel progetto. Il portauova intelligente espleta la funzione di sensore. Esso è collegato al Raspberry Pi 3 che coordina tutte le fasi decisionali ed elettroniche. Tramite il modulo WiFi le informazioni raggiungono il router che, grazie ad una connessione ad Internet, possono essere inviate attraverso la posta elettronica e ricevute dal negoziante.
Figura 1: il diagramma a blocchi del sistema
Il portauova intelligente
L'oggetto protagonista di questo articolo è un portauova intelligente che dispone di una "vita propria" ed è capace di prendere delle decisioni importanti. E' realizzato con il Raspberry Pi 3 e contiene tutto ciò che serve per la completa realizzazione di un dispositivo IoT: un microprocessore, un file system, un sistema operativo, un modulo WiFi per il collegamento ad Internet e, soprattutto, delle porte digitali di I/O con cui acquisire le informazioni da controllare e gestire, attraverso opportuni sensori.
Il nostro portauova è dotato di sei alloggiamenti ma se ne possono prevederne di più. Tale numero è altamente influenzato dalla quantità di porte digitali presenti nell'embedded. Esso sfrutta, appunto, alcuni sensibili pulsanti come sensori di presenza delle uova e sono dislocati proprio al di sotto dei rispettivi alloggiamenti. Si capisce bene che il peso dell'alimento innesca il pulsante, chiudendo un circuito elettrico. L'assenza di pressione, invece, causerà l'apertura della stessa linea definendo, di fatto, un livello logico differente.
La figura 2 mostra una possibile soluzione costruttiva del portauova. Si noti la presenza dei pulsanti nel ventre degli alloggiamenti e del diodo Led di segnalazione che avverte l'operatore che le uova stanno terminando. All'interno dell'alloggiamento è presente il Raspberry Pi 3, totalmente invisibile all'occhio umano. Si distingue solo il filo elettrico di alimentazione, ma esso può essere facilmente nascosto.
Nel caso si decidesse di collocare il portauova in frigo, si consiglia di separarlo dall'embedded. Il Raspberry, infatti, potrebbe non sopportare bene il freddo. I diversi componenti lavorano bene entro un intervallo ben definito di temperature. Si sconsiglia, quindi, di scendere al di sotto di 0°C. Si possono, al contrario, mettere tranquillamente in frigo il solo portauovo con i relativi pulsanti e collegarli al sistema tramite un elegante o invisibile cablaggio.
[...]
ATTENZIONE: quello che hai appena letto è solo un estratto, l'Articolo Tecnico completo è composto da ben 2587 parole ed è riservato agli ABBONATI. Con l'Abbonamento avrai anche accesso a tutti gli altri Articoli Tecnici che potrai leggere in formato PDF per un anno. ABBONATI ORA, è semplice e sicuro.
Ti potrebbe interessare anche:
HackRF One una guida pratica: dalla decodifica dei segnali al Penetration Testing – Prima parte
Material handling nella fabbrica intelligente
Memorizziamo i dati in maniera sicura con il confidential computing
Controllare i dispositivi con Telegram
Stazione meteo interattiva per centraline domotiche
Mettiamocelo in testa, il futuro ci riserva proprio questa tipologia di Applicazioni. TUTTO sarà collegato a Internet, pillole, pannolini, televisori, lampadine, forni, automobili, possibilmente anche parti del nostro corpo, per un monitoraggio medico e un eventuale intervento tempestivo.
Applicazione davvero molto utile per chi come me spesso non ricorda mai quando è il momento di fare un po’ di spesa 🙂 e da cui prendere spunto per tante altre applicazioni! Credo che uno degli obiettivi fondamentali sarà sempre più quello di avvicinare la tecnologia alle persone: mondo fisico e mondo virtuale sempre più vicini e connessi per la nostra comodità e sicurezza.
Gent. mo Giovanni,
le faccio i miei complimenti, ho trovato l’articolo molto interessante e ricco di spunti.
Sicuramente l’IoT rappresenta una nuova rivoluzione informatica ma se è vero che avrà molti risvolti positivi nelle nostre vite è anche vero che, aumentando il numero di oggetti IoT, aumenterà la quantità di rifiuti tossici per l’ambiente. Lei cosa ne pensa?
Salve e grazie dei complimenti.
Mah, sui rifiuti tossici non penso che ci sia un aumento significativo, del resto i dispositivi esisteranno sempre, con o senza connessione ad Internet. In altre parole, non penso che l’IoT possa influire negativamente sul piano dei rifiuti.
Semmai vedo un potenziale problema nell’utilizzo: pensate se dovesse mancare la linea Internet durante il funzionamento, oppure l’intrusione di Hacker che potrebbe far saltare il sistema.
Sono questi, secondo me, i punti da sviluppare alla perfezione, specialmente per l’IoT medico e militare.
Grazie
In realtà il discorso è interessante, nel wearable per esempio sempre IoT abbiamo le batterie e li nasce il problema. Così come aumentando la vendita di smartphone nasce il problema dello smaltimento…Come in ogni nuova tecnologia/sviluppo c’è sempre un problema che necessita di piena considerazione.
Ciao Maurizio,
hai proprio ragione ed è per questo che un buon progettista moderno è veramente “buono” se
in fase di progettazione considera anche il ciclo di vita dei singoli componenti e cerca di prevederne i possibili riutilizzi (o almeno tenta di farlo con il massimo impegno). Certo che a questo punto si apre tutto il discorso inerente l’obsolescenza programmata…
Perchè non fare un cellulare che si ricarichi attraverso l’energy harvesting, abbiamo trattato qui molto bene l’energy harvesting con uno speciale…Risolveremmo problemi (non del tutto, ma è un inizio) con le batterie per esempio…
Bellissima applicazione, un giorno sarà nelle case di tutti noi. Nei frigoriferi o nelle dispense, avremmo tutto sottocontrollo. Per le uova risulta alquanto facile, ma se volessimo monitorare qualcosa che acquistiamo in peso come la farina o la frutta? Dovremmo utilizzare un sensore di peso analogico o un sensore di livello per i liquidi?
Per unirmi alla conversazione degli sprechi e dell’inquinamento, penso che si debba intervenire anche sui cicli di smaltimento. Purtroppo tutto prima o poi va cestinato, ma con un buon processo di smaltimento e riutilizzo si possono recuperare la maggior parte dei materiali dalle schede e dai componenti.
SI, questi sono i sensori canonici.
Potrbbero esserci sensori più sofisticati, come ad esempio, sensore ad ultrasuoni che misura il rimbalzo del suono variabile alla quantità di prodotto. La tecnologia, in questi ultimi anni, sta aumentando in modo più che logaritmico.
Articolo molto interessante, con un’ottima applicazione IoT. Ormai le tecnologie hardware e software sono mature, bisogna solo avere un pò di iniziativa e molte applicazioni “connesse” posso prendere forma.
Il mondo dell’embedded sta migrando dai sistemi composti dal solo microcontrollore che tutt’al più usa un FreeRTOS, a sistemi che sono a tutti gli effetti dei mini computer come la Raspberry.
Si arriverà un giorno (forse non troppo lontano) a scrivere l’applicativo embedded usando linguaggi di alto livello come JavaScript per la parte funzionale e HTML per la grafica? Io penso di sì…
PS: ovviamente lo sviluppo in C/C++ esisterà sempre e comunque per lo sviluppo di tutti gli strati sopra i quali funzionerà tutto il resto.
Veramente un articolo interessante Giovanni e concordo con te che saremo sempre piu’ connessi, a partire dal wearable etc (e te lo dice uno che, per scelta, e’ rimasto al Nokia N70 in mezzo a un mondo ormai da 5″ in su :-)).
Ho lavorato negli anni passati su applicativi di demotica, ma poi e’ arrivata la crisi e sono sopravvissuti solo i piu’ “grandi” e soprattutto chi seguiva gli standard (KNX etc etc).
Ma qui siamo decisamente oltre alla demotica e sicuramente le implicazione etiche, oltre che tecnologiche, saranno molto interessanti.
Esporre un web server come da te citato sarebbe molto bello (qualche lettore, leggendo i miei commenti dire’: “che noia questo, ma sa fare solo webserver?” 🙂 ), in modo da poter monitorare il contenuto del frigo dallo smartphone (certo, con l’N70 rimarrebbe difficile 🙂 ).
Complimenti ancora.
Grazie Riccardo!!!!
Secondo me invece l’idea di avere un web server su ogni elettrodomestico è vincente: si sfruttano i vantaggi del protocollo TCP/IP e si usufruisce di una rete che oramai tutte le abitazioni hanno (e se non ce l’hanno è facile da realizzare).
Spoiler: Stay tuned sui prossimi articoli 😉
Concordo con te Luca. Essendo il futuro basato sulla connettività’, che si appoggia ovunque sul TCP/IP, non vedo altra possibilità per i dispositivi che esporre le loro funzionalità’ tramite il web. Mi pare cosi’ fisiologico e intrinseco che non ho dubbi su questo. Ecco perche’ cerco anch’io di basare le mie applicazioni su web server il piu’ possibile. I vantaggi sono enormi, non ultimo avere la multi utenza gestita in maniera nativa dal web server. Ovviamente questo poi si traduce nel gestire correttamente gli accessi nel codice (protezione di aree con critical sections/mutex) e renderlo flessibile con multithread (chiaramente se sotto si ha un OS che lo supporta).
Si esatto e oramai il mondo dell’embedded si sta spostando verso dispositivi che hanno a bordo un OS, vedi Raspberry o NanoPI.
Secondo me è una strada percorribile, solo un dubbio: parlando di domotica ogni singolo punto di interazione dovrà essere un web server (pulsanti, interruttori, prese, attuatori, elettrodomestici…); in questo modo non so se i classici 255 indirizzi IP siano sufficienti.
Il tuo dubbio e’ piu’ che lecito. Infatti nel passato ho lavorato su una soluzione proprietaria per una ditta, dove avevamo realizzato una rete domotica dove erano previsti dei “Master”, collegati su una dorsale su Ethernet. Da ogni master partiva poi una sottorete di “Slave” che parlavano su rete CAN Bus. Ogni nodo, compresi i master, era caratterizzato da una coppia di indirizzi, dove il primo era un normale indirizzo IP della dorsale primaria, e il secondo da un ID che si rendeva univoco all’interno di ogni sottorete. Questo garantiva circa 255 indirizzi X gli altri disponibili del CAN. Ogni master fungeva quindi da router interno e avevo sviluppato del firmware (erano tutti basati su processori LPCXXX) che smistava il tutto. Questo chiaramente indica che, senza dover passare da un altro tipo di Bus come si era scelto a suo tempo, che si dovrebbero creare delle sottoreti su TCP/IP, facendo in modo che ogni “Master” funga anche da gateway della sottorete. Non sono un sistemista di rete (e li ho sempre invidiati) ma credo sia fattibile, almeno in linea di principio.
Si infatti, bella idea usare dei dispositivi “master” che fungono da gateway! Io comunque utilizzerei sempre la rete TCP/IP: più comoda e molto spesso già disponibile.
Lanciamo un nuovo standard? 😀
Fantastico Giovanni!! ?
È un articolo molto interessante e soprattutto prospetta la creazione di un dispositivo di uso ordinario e quotidiano …. quasi Triviale oserei dire! ..ed è questa la vera rivoluzione che ci si auspica dall’IoT, entrare nel quotidiano e rendere possibili tutte le applicazioni nell’uso comune!!
Well done!!
Grazie Massimo.
Il listato in linguaggio C
Il listato non è per nulla complicato ed è scritto in linguaggio C. Per il pilotaggio delle porte digitali o per l’acquisizione del loro stato logico abbiamo utilizzato il componente wiringPi, esaminato anche nella precedente puntata del corso Purtroppo non si apre la PRECEDENTE PUNTATA che ricordo parlava della gestione degli ingressi uscite GPIO .. cosa posso fare per poterla rivedere e salvare?
Nella ricerca in alto a destrra scrivi:
“raspberry iot realizziamo” (senza virgolette)
Se il tuo abbonamento è valido li devi poter leggere.
questa è la puntata precedente https://it.emcelettronica.com/realizziamo-applicazioni-iot-con-il-raspberry-pi-3-gestione-del-personale