Revisione 0.6
I dispositivi IoT si appoggiano a server e servizi IoT attraverso internet, che in breve denominiamo Centro Servizi IoT.
Le proposte strutturali per allestire Centri Servizi IoT sono molteplici.
Spesso troviamo proposte di comunicare con il protocollo REST2, sostanzialmente HTTP .
Molti progetti prevedono l’utilizzo di schede Arduino connesse a Raspberry Pi come dispositivo IoT che comunica con il Centro Servizi IoT.
Arduino non nasce per lavorare in rete. Lo shield ethernet ha delle grandi limitazioni e non offre tutte le risorse del dispositivo ethernet gestito da Linux come in ambiente Raspberry Pi.
Conviene appoggiare Arduino, o più schede Arduino, su una scheda Raspberry Pi, con la funzione di wrapper verso il Centro Servizi IoT .
Ma come collegare Arduino/i al Raspberry Pi ?
Ci sono varie possibilità, quali utilizzare ethernet, RS 232, RS422, RS485, oppure seriale TTL con un adattatore di livelli 3.3 e 5V.
Forse la miglior scelta è utilizzare la porta seriale verso USB sempre prevista da Arduino. Si ricordi che la lunghezza massima del cavo è di 5m.
Le schede Arduino più diffuse hanno una sola UART connessa alla porta USB, usata anche per caricare il firmware.
Se si utilizza un firmware di base per Arduino, che realizza il server in ascolto attraverso la seriale – USB, allora serve un client lato Raspberry. I comandi che proponiamo sono stringhe intellegibili come riportate nel blog.
Il Raspberry Pi deve gestire le varie porte /dev/ttyUSBx o /dev/ttyACMx.
La libreria Linux utilizzata per gestire il /dev/tty è termios.c. Anche Python usa questa libreria. Per una questione di velocità conviene usare direttamente GCC.
Servono due servizi:
- un primo servizio con un client in poll verso la porta USB ed un altro client verso il Centro Servizi IoT
- un secondo servizio che gestisca ed aggiorni la tabella devices connessi attraverso le porte USB
La tabella devices di appoggio può appartenere ad un RDBMS, nel nostro caso PostgreSQL, oppure tabella piatta locale quale SQLite. La prima soluzione pemette la centralizzazione rispetto connessioni in rete o intranet, la seconda pemette la concorrenza nello stersso host.
Se, per esempio, vogliamo gestire un LCD 16×2 (16 colonne e 2 righe) compatibile con i driver Hitachi HD44780, per visualizzare avvisi ed errori di un host utilizzato come server, allora possiamo utilizzare una scheda Mega che ha una buona dotazione di pin. Quindi potremmo concepire di creare servizi in esecuzione permanente o al cron nel host da controllare. Supponiamo che tutto sia in locale compreso la scheda Mega connessa ad una porta USB. Un unico servizio deve prendersi in carico la porta USB connessa alla Mega. Ma più di un servizio dovranno inviare una stringa al LCD. La soluzione è aprire una tabella locale in modo concorrente.
Stiamo realizzando una soluzione in in C/C++, ovvero o mediante cron con frequenze multiple del minuto oppure come servizio, che controlla le porte USB attraverso il kernel. Nel caso di variazione dello stato di una porta USB, viene automaticamente determinato se è stato connesso o sconnesso un device USB e se questo è del tipo Arduino. Nel caso sia del tipo Arduino viene controllato se il seriale del dispositivo è riportato nella tabelle devices e, in tal caso, aggiornato lo stato. Se il dispositivo è del tipo Arduino e passa allo stato connesso allora viene eseguito come processo il servizio con il client verso Arduino via USB e il client verso il Centro Servizi IoT.
La connessione verso Arduino serial/USB è stabile, mentre verso il Centro Servizi IoT non lo è.
In caso di interruzione di una comunicazione, il servizio aggiorna la tabella database di interruzione avvenuta e termina.
Il Centro Servizi IoT ha vari servizi middleware che realizzano varie modalità di comunicazione con la parte centrale del Centro stesso. Tra le varie possibilità, alcune in ambiente Docker, ci sono il protocollo tcp row e telnet per i dispositivi più semplici. Altri servizi utilizzano un RDBMS in SSL, SSH oppure HTTP.
La parte centrale del Centro Servizi è costituita da RDBMS esclusivamente PostgreSQL che, in genere, sfrutta PL/Py3u. Sostanzialmente trigger con, spesso, subprocess verso programmi specifici.
Per esempio al comando file corrispondono vari programmi in Python che sviluppano quanto richiesto. Il risultato è di rendere disponibile la struttura dati file a dispositivi IoT spesso molto semplici.
le librerie comprendono moltissime possibilità: inviare una email, creare un file PDF o XLSX o ODS o TSV o CSV, da utilizzare anche come allegato email. Il file può essere generato da JasperReport, ReportLab, GNUPlot, Libreoffice anche con staroffice o altri servizi.
Il caso terminale richiede particolare attenzione per la sicurezza perché in chiaro. Il sistema è blindato mediante Docker, la porta è alta ed è sotto monitoraggio.
Comunque servizi e server sono scritti in Linguaggio per ambiente Linux con hardware i386, amd64 ed ARM, quindi server, desktop, portatili e schede Raspberry Pi, Banana Pi, …
Nel Sistema IoT i comandi si muovono in entrambi i versi: dai devices IoT al Centro Servizi IoT, e viceversa.
I passaggi successivi sono l’integrazione con Crestron e Modbus.
Consideriamo alcuni dati pratici: se la scheda Arduino è in linea, allora il poll verso Arduino può raggiungere e tenere senza problemi la velocità data dal poll con ritardo di 100ms.
Il poll che si connette via internet e comunica al Centro Servizi IoT ha un ritardo nel ciclo di base non inferiore ai 10s, ideale a 60 s, meglio se con tempi più lunghi.
Sono previsti buffer per archiviare temporaneamente i dati in assenza di connettività.