Differenze tra le versioni di "Gruppo Meteo/StimaOverview"
(→TCP/IP) |
|||
(32 versioni intermedie di 2 utenti non mostrate) | |||
Riga 3: | Riga 3: | ||
== Premesse == | == Premesse == | ||
− | * | + | * Aderisce alla Rete di Monitoraggio Ambientale Partecipativo (R-MAP) |
* Open hardware e open software | * Open hardware e open software | ||
* al momento vengono gestiti parametri meteorologici | * al momento vengono gestiti parametri meteorologici | ||
+ | |||
+ | == Funzionalità == | ||
+ | |||
+ | === Sensori === | ||
+ | |||
+ | ==== Collegamento su bus I2C ==== | ||
+ | I sersori devono essere compatibili con il bus I2C. Quando sensori I2C non siano disponibili il problema viene risolto con un microcontrollore che adatta le letture (analogiche o digitali) e le elaborazioni (contatori, medie etc.) rendendole disponibili su registri interrogabili tramite I2C. | ||
+ | |||
+ | Il protocollo I2C prevede l’utilizzo di un bus formato da due linee bidirezionali. Le due linee, chiamate “scl” e “sda” | ||
+ | rispettivamente, trasportano la tempistica di sincronizzazione (chiamata anche “clock”) e i dati. | ||
+ | Abbiamo scelto il bus I2C in quanto: | ||
+ | * È diventato lo standard di fatto per una serie di integrati tra cui i sensori | ||
+ | * Si possono collegare fino a 127 dispositivi | ||
+ | * La comunicazione è bidirezionale (read e write) con velocità assolutamente sufficienti per i nostri scopi | ||
+ | * la lunghezza operativa dei cavi è adeguata al nostro utilizzo (anche alcune decine di metri) | ||
+ | |||
+ | ==== Interrogazione dei sensori ==== | ||
+ | I sensori possono venire interrogati a richiesta tramite remote call procedure oppure ad intervalli regolari. | ||
+ | Quando interrogati a intervalli regolari tutti i sensori vengono interrogati "in parallelo" ossia tutti i sensori vengono impostati e configurati all'accensione poi periodicamente vengono attivati e impartita la richiesta di lettura; il driver del sensore torna il tempo di attesa necessario per avere la misura disponibile; si attente il tempo necessario per il sensore più lento; si effettuano tutte le letture. | ||
+ | In questo modo si riescono a campionare tutti i sensori solitamente entro i 3 secondi e considerando i tempi per la loro pubblicazione sul server generalmente viene utilizzata una frequenza di campionamneto pari a una ogni 5 secondi. | ||
+ | Tenendo i sensori normalmente in sleep si riducono anche i consumi. | ||
+ | |||
+ | Ogni sensore può restituire volori multipli (ad esempio temperatura e umidità). | ||
+ | |||
+ | === Operazioni di mantenimento === | ||
+ | Il software effettua periodicamente tutte le funzioni di mantenimento necessarie a un corretto funzionamento quali quelle relative al DHCP o alla sincronizzazione dell'orologio interno con una sorgente esterna. | ||
+ | Tutti i firmware hanno attivo un watchdog hardware che evita blocchi permanenti dovuti a malfunzionamenti su eventi improbabili. | ||
+ | |||
+ | === Orologio di riferimento === | ||
+ | Una base dei tempi precisa è richiesta nel caso in cui sia necessario salvare i dati localmente (su SD) nel caso la connessione utilizzata per pubblicare i dati sul server (broker) non sia considerata stabile. Se invece la connessione (trasporto) viene considerata stabile (o non sia necessario recuperare i dati in caso di fault) un preciso orologio di riferimento non è necessario e il tempo di riferimento verrà aggiunto automaticamente dal server alla pubblicazione in tempo reale del dato. Ci sono diversi sistemi per avere un orologio di riferimento preciso sui moduli Stima. | ||
+ | |||
+ | === Stazioni fisse o mobili === | ||
+ | È possibile installare sia stazioni fisse, la cui posizione non cambia nel tempo, sia stazioni mobili, sia terrestri che marine. Per aggiornare la posizioni delle stazioni mobili viene utilizzato un GPS che può essere o a bordo del modulo Stima o a bordo di un dispositivo android. | ||
+ | |||
+ | === Attenzione ai consumi energetici === | ||
+ | Attenzione è stata posta alla limitazione dei consumi. Quando possibile i microcontrollori e i sensori vengono messi in sleep e sono alcuni interrupt a risvegliare il sistema. Questo agevola l'utilizzo con batterie dei sistemi a basso consumo quali il modulo satellite che funziona con un modulo radio. | ||
+ | |||
+ | === Differenti tipologie di rete === | ||
+ | La configurazione della rete può essee differente a seconda delle esigenze; oltre alla classica configurazione a stella (moduli master e base) con un broker al centro è disponibile la configurazione ad albero sia via cavo (modulo master + base) che via radio: con la possibilità di utilizzare moduli radio di maggiore potenza (~1Km in aria libera) è possibile prevedere coperture di un terriotorio con ampia superficie. | ||
+ | |||
+ | === Software utente multipiattaforma === | ||
+ | Il software che l'utente può utlizzare per la pubblicazione e visualizzazione dei dati è multipiattaforma. | ||
+ | Fatti salvi i moduli basati su microcontrollore e vincolati all'ambiente Atmel e alcune funzioni sul server di raccolta dei dati sviluppati in ambiente Linux (distribuzioni CentOS e Fedora) la visulizzazione e il monitoraggio sono multipiattaforma. Anche l'interfaccia utente grafica che permette la geolocalizzazione, autenticazione e pubblicazione dei dati sia automatica che manuale anche di dati rilevati manualmente e a vista è multipiattaforma (attualmente testata su Linux, Android, ma portabile su Windows, OS X, iOS | ||
+ | |||
+ | === Salvataggio locale dei dati === | ||
+ | |||
+ | I dati possono essere pubblicati in real time e/o salvati localmente. | ||
+ | È previsto un meccanismo di salvataggio dei dati su SD formattata FAT; i file | ||
+ | vengono frammentati a una dimensione prefissata per farne circa uno al | ||
+ | giorno e numerati da 000 a 999; i dati salvati hanno un flag che indica | ||
+ | se i dati sono stati già pubblicati correttamente su MQTT; i file che | ||
+ | devono essere controllati per possibili reinvii hanno postfisso .que e | ||
+ | quelli che hanno tutti i dati già inviati hanno postfisso .don | ||
+ | |||
+ | In questo modo si ottengono queste funzionalità: | ||
+ | * salvataggio dati su SD almeno per due anni con campionamenti ogni 5s | ||
+ | * reinvio automatico al server dei dati salvati ma non pubblicati correttamente sul server | ||
+ | * ottimizzazione dei tempi in quanto solo i file che contengono dati da inviare vengono letti per selezionare i dati da reinviare | ||
+ | * i dati possono essere riletti su un normale PC estraendo la SD | ||
+ | |||
+ | === Messagistica di diagnostica === | ||
+ | C'è la possibilità di ottenere una ampia messaggistica di diagnostica per la soluzione dei problemi | ||
+ | |||
+ | === Configurazione === | ||
+ | Le versioni delle configurazioni vengono verificate e quando il firmware non è retrocompatibile il modulo resta in attesa di una nuova configurazione. | ||
+ | Le configurazioni vengono subito verificate: non è possibile configurare un modulo con dei sensori non corretti o non funzionanti. | ||
+ | |||
+ | === Modularità hardware e software === | ||
+ | Le configurazioni hardware sono molteplici e possono essere utilizzate differenti board; sono compatibili i moduli hardware maggiormente diffusi e conosciuti dai makers oltre ad essere generalmente a basso costo. | ||
+ | |||
+ | === Crittografia === | ||
+ | Qualora il trasporto non sia considerato sicuro (via radio) viene utilizzata la crittografia per garantire riservatezza e autenticità. | ||
+ | |||
+ | === Integrazione con la domotica === | ||
+ | Per quello che è stato possibile si è cercato di integrarsi con gli standard della domotica (MQTT). Tutti i moduli possono essere utilizzati anche da attuatori on/off (fino a 4 relay) ma è molto semplice aggiungere altre funzionalità tramite remote procedure in formato json su tutti i trasporti o tramite MQTT. | ||
== Concetti base == | == Concetti base == | ||
Riga 12: | Riga 87: | ||
=== Trasporti === | === Trasporti === | ||
Il concetto di trasporto in Stima è simile ma non rigidamente aderente ai concetti del modello ISO-OSI. Nel caso dei trasporti passivi il suo compito è fornire un canale logico-affidabile di comunicazione end-to-end per fornire servizi al soprastante livello che in Stima è JsonRPC. | Il concetto di trasporto in Stima è simile ma non rigidamente aderente ai concetti del modello ISO-OSI. Nel caso dei trasporti passivi il suo compito è fornire un canale logico-affidabile di comunicazione end-to-end per fornire servizi al soprastante livello che in Stima è JsonRPC. | ||
− | Nel caso dei trasporti attivi | + | Nel caso dei trasporti attivi corrisponde al protocollo (Session Layer) per la pubblicazione dei dati su un server (broker). |
=== Passivi o attivi === | === Passivi o attivi === | ||
Riga 20: | Riga 95: | ||
===== Seriale ===== | ===== Seriale ===== | ||
Collegamento punto a punto tramite porta seriale. | Collegamento punto a punto tramite porta seriale. | ||
+ | * Principalmente per configurazione e debug | ||
+ | * Piccole distanze via cavo | ||
caratterizzato da: | caratterizzato da: | ||
Riga 26: | Riga 103: | ||
===== TCP/IP ===== | ===== TCP/IP ===== | ||
− | Trasporto che utilizza il | + | Trasporto che utilizza il TCP/IP; i supporti fisici supportati sono: |
+ | * ethernet: collegamenti tramite cavo ethernet a breve e media distanza | ||
+ | * GSM/GPRS: installazioni con problemi per le cablature di alimentazione e collegamento di rete | ||
caratterizzato da: | caratterizzato da: | ||
* Name (Nome risolto dal DNS) | * Name (Nome risolto dal DNS) | ||
− | * | + | * NTPserver |
===== Bluetooth ===== | ===== Bluetooth ===== | ||
Riga 37: | Riga 116: | ||
===== NRF24 ===== | ===== NRF24 ===== | ||
+ | |||
+ | * OSI Network Layer using nRF24L01(+) radios 2.4GHz ISM 50/150m in aria libera | ||
+ | * Host Addressing. Each node has a logical address on the local network. | ||
+ | * Message Forwarding. Messages can be sent from one node to any other, and this layer will get them there no matter how many hops it takes. | ||
+ | * Ad-hoc Joining. A node can join a network without any changes to any existing nodes. | ||
+ | |||
+ | RF24Network Addressing and Topology | ||
+ | |||
+ | Each node must be assigned an 15-bit address by the administrator. This address exactly describes the position of | ||
+ | the node within the tree. The address is an octal number. Each digit in the address represents a position in the tree further from the base. | ||
+ | * Node 00 is the base node. | ||
+ | * Nodes 01-05 are nodes whose parent is the base. | ||
+ | * Node 021 is the second child of node 01. | ||
+ | * Node 0321 is the third child of node 021, an so on. | ||
+ | * The largest node address is 05555, so 3,125 nodes are allowed on a single channel. | ||
+ | |||
+ | Alla libreria distributia è stata aggiunta la crittografia e | ||
+ | frammentazione e ricomposizione del payload | ||
+ | |||
caratterizzato da: | caratterizzato da: | ||
* Node (Node ID for RF24 Network) | * Node (Node ID for RF24 Network) | ||
Riga 45: | Riga 143: | ||
==== Attivi ==== | ==== Attivi ==== | ||
===== MQTT ===== | ===== MQTT ===== | ||
+ | MQTT (Message Queue Telemetry Transport) è un protocollo | ||
+ | publish/subscribe particolarmente leggero, adatto per la | ||
+ | comunicazione M2M tra dispositivi con poca memoria o | ||
+ | potenza di calcolo e server o message broker. | ||
+ | |||
caratterizzato da: | caratterizzato da: | ||
* Mqttsampletime (intervallo in secondi per la pubblicazione) | * Mqttsampletime (intervallo in secondi per la pubblicazione) | ||
Riga 52: | Riga 155: | ||
===== AMQP ===== | ===== AMQP ===== | ||
+ | AMQP (Advanced Message Queuing Protocol) è protocollo per | ||
+ | comunicazioni attraverso code di messaggi. Sono garantite | ||
+ | l'interoperabilità, la sicurezza, l'affidabilità, la persistenza. | ||
+ | |||
caratterizzato da: | caratterizzato da: | ||
* Amqpserver (Server AMQP) | * Amqpserver (Server AMQP) | ||
Riga 57: | Riga 164: | ||
* Queue (Nome della coda locale AMQP ) | * Queue (Nome della coda locale AMQP ) | ||
* Amqpuser (User AMQP) | * Amqpuser (User AMQP) | ||
− | * Amqppassword | + | * Amqppassword |
=== JsonRPC === | === JsonRPC === | ||
Riga 66: | Riga 173: | ||
==== JsonRPC over different transports ==== | ==== JsonRPC over different transports ==== | ||
− | + | È possibile fare richiesta di una procedura remota che a sua volta richiede una procedura remota; in questo modo è possibile utilizzare due trasporti differenti e usare un modulo come gateway. | |
Ad esempio il modulo base non dispone al momento del trasporto radio RF24 ma puo' richiedere a un modulo master tramite trasporto seriale o TCP/IP di eseguire una procedura remota su un modulo satellite raggiungibile tramite trasporto RF24. | Ad esempio il modulo base non dispone al momento del trasporto radio RF24 ma puo' richiedere a un modulo master tramite trasporto seriale o TCP/IP di eseguire una procedura remota su un modulo satellite raggiungibile tramite trasporto RF24. | ||
Queste funzionalità sono ampiamente da testare. | Queste funzionalità sono ampiamente da testare. | ||
− | == | + | == Elementi hardware == |
+ | |||
+ | === board microcontroller === | ||
+ | ==== atmel 328p ==== | ||
+ | Il più piccolo della serie può essere utilizzato per: | ||
+ | * modulo i2c-gps | ||
+ | * modulo i2c-wind | ||
+ | * modulo i2c-rain | ||
+ | |||
+ | implementazioni on board: | ||
+ | * arduino uno | ||
+ | * arduino nano | ||
+ | * microduino core | ||
+ | |||
+ | ==== atmel 644p ==== | ||
+ | Il medio della serie può essere utilizzato per: | ||
+ | * modulo satellite | ||
+ | * modulo bluetooth | ||
+ | * tutti i moduli relativi al 328p | ||
+ | |||
+ | implementazioni on board: | ||
+ | * microduino core+ 644p | ||
+ | |||
+ | ==== altmel mega 2560/1284p ==== | ||
+ | Il grande della serie può essere utilizzato per: | ||
+ | * modulo master | ||
+ | * modulo GPS/GPRS | ||
+ | * tutti i moduli relativi al 644p | ||
+ | |||
+ | implementazioni on board: | ||
+ | * arduino mega2560 | ||
+ | * microduino core+ 1284p | ||
+ | |||
+ | === board RTC === | ||
+ | Il real time clock deve utilizzato quando non è possibile avere un'altra sorgente affidabile per il tempo di riferimento e al tempo stesso la pubblicazione dei dati può avvenire con tempo differito ad esempio tramite la memorizzazione su scheda SD. | ||
+ | |||
+ | === board radio RF24 === | ||
+ | È necessaria per supportare il trasporto NRF24 | ||
+ | |||
+ | === board ft232 === | ||
+ | È necessaria per programmare, debuggare, a volte configurare il modulo e per supportare il trasporto seriale. | ||
+ | |||
+ | === board ENC28J60 === | ||
+ | Ethernet module a basso costo; è necessario lo stack tcp/ip software su microcontrollore. | ||
+ | Serve per supportare il trasporto TCP/IP. | ||
+ | Alternativa alla board wiznet | ||
+ | |||
+ | === board wiznet W5500 === | ||
+ | Ethernet module completa dello stack tcp/ip. | ||
+ | Serve per supportare il trasporto TCP/IP. | ||
+ | Alternativa alla board ENC28j60 | ||
+ | |||
+ | === board display I2C LCD 4 linee 20 caratteri === | ||
+ | Utilizzabile per visualizzare messaggistica di diagnostica e alcune misure quando non è disponibile un PC per debug e altre visualizzazioni. | ||
+ | |||
+ | implementazioni on board: | ||
+ | * YwRobot Arduino LCM1602 IIC V1 | ||
+ | |||
+ | === board 5V relay === | ||
+ | 5V 4/2-Channel Relay interface board; Equipped with high-current relay, AC 250V 10A / DC 30V 10A | ||
+ | Opticalcoupler Protection | ||
+ | Utilizzabile per aggiungere a un modulo la funzionalità di attuatore. Ogni relay può essere attivato singolarmente. | ||
+ | |||
+ | |||
+ | === board SD === | ||
+ | Microduino-SD aims to read and write data of a memory card. | ||
+ | Utilizzata per memorizzare i dati in loco; necessaria quando non ci siano trasporti utili o la stabilità dei trasporti utilizzati è messa in dubbio e i dati hanno valore anche in tempo differito. | ||
+ | |||
+ | === board GSM/GPRS sim800/sim900 === | ||
+ | Adopt SIM800L module to support four-band GSM/GPRS, whose working band is:GSM850, EGSM900, DCS1800 and PCS1900MHz. | ||
+ | Utilizzabile per avere il trasporto TCP/IP quando non è disponibile una connessione ethernet. | ||
+ | Questo modulo può funzionare sul trasporto TCP/IP in due modalità: una con delle get http tramutate dal server in publish MQTT e l'altra in una vera connessione MQTT. | ||
+ | E' possibile utilizzare questo modulo anche cone Real Time Clock per ottenere una tempo di riferimento stabile. | ||
+ | Si può quindi ottenere dal server rmap il tempo di riferimento e impostarlo nell'RTC di questo modulo per poi rileggerlo al bisogno in caso di non disponibilità del trasporto TCP/IP; tutto questo a scapito di stabilità e continuità di servizio. | ||
+ | Nel caso sia importante avere un RTC affidabile si consiglia l'aggiunta di un modulo RTC o ancora meglio del modulo GPS. | ||
+ | |||
+ | === board GPS Neo 6M === | ||
+ | Questa board insieme a una board microcontrollore possono creare un modulo i2c-gps. | ||
+ | Il modulo i2c-gps fornisce a richiesta la posizione (lat, lon, altezza) e il tempo di riferimento. | ||
+ | Serve per istallazioni mobili o che necessitano di un tempo di riferimento particolarmente stabile. | ||
+ | |||
+ | == Guida per la composizione di un modulo Stima == | ||
+ | TODO |
Versione attuale delle 09:08, 17 giu 2015
Stima Overview
Stazione modulare per la misura di parametri ambientali.
Premesse
- Aderisce alla Rete di Monitoraggio Ambientale Partecipativo (R-MAP)
- Open hardware e open software
- al momento vengono gestiti parametri meteorologici
Funzionalità
Sensori
Collegamento su bus I2C
I sersori devono essere compatibili con il bus I2C. Quando sensori I2C non siano disponibili il problema viene risolto con un microcontrollore che adatta le letture (analogiche o digitali) e le elaborazioni (contatori, medie etc.) rendendole disponibili su registri interrogabili tramite I2C.
Il protocollo I2C prevede l’utilizzo di un bus formato da due linee bidirezionali. Le due linee, chiamate “scl” e “sda” rispettivamente, trasportano la tempistica di sincronizzazione (chiamata anche “clock”) e i dati. Abbiamo scelto il bus I2C in quanto:
- È diventato lo standard di fatto per una serie di integrati tra cui i sensori
- Si possono collegare fino a 127 dispositivi
- La comunicazione è bidirezionale (read e write) con velocità assolutamente sufficienti per i nostri scopi
- la lunghezza operativa dei cavi è adeguata al nostro utilizzo (anche alcune decine di metri)
Interrogazione dei sensori
I sensori possono venire interrogati a richiesta tramite remote call procedure oppure ad intervalli regolari. Quando interrogati a intervalli regolari tutti i sensori vengono interrogati "in parallelo" ossia tutti i sensori vengono impostati e configurati all'accensione poi periodicamente vengono attivati e impartita la richiesta di lettura; il driver del sensore torna il tempo di attesa necessario per avere la misura disponibile; si attente il tempo necessario per il sensore più lento; si effettuano tutte le letture. In questo modo si riescono a campionare tutti i sensori solitamente entro i 3 secondi e considerando i tempi per la loro pubblicazione sul server generalmente viene utilizzata una frequenza di campionamneto pari a una ogni 5 secondi. Tenendo i sensori normalmente in sleep si riducono anche i consumi.
Ogni sensore può restituire volori multipli (ad esempio temperatura e umidità).
Operazioni di mantenimento
Il software effettua periodicamente tutte le funzioni di mantenimento necessarie a un corretto funzionamento quali quelle relative al DHCP o alla sincronizzazione dell'orologio interno con una sorgente esterna. Tutti i firmware hanno attivo un watchdog hardware che evita blocchi permanenti dovuti a malfunzionamenti su eventi improbabili.
Orologio di riferimento
Una base dei tempi precisa è richiesta nel caso in cui sia necessario salvare i dati localmente (su SD) nel caso la connessione utilizzata per pubblicare i dati sul server (broker) non sia considerata stabile. Se invece la connessione (trasporto) viene considerata stabile (o non sia necessario recuperare i dati in caso di fault) un preciso orologio di riferimento non è necessario e il tempo di riferimento verrà aggiunto automaticamente dal server alla pubblicazione in tempo reale del dato. Ci sono diversi sistemi per avere un orologio di riferimento preciso sui moduli Stima.
Stazioni fisse o mobili
È possibile installare sia stazioni fisse, la cui posizione non cambia nel tempo, sia stazioni mobili, sia terrestri che marine. Per aggiornare la posizioni delle stazioni mobili viene utilizzato un GPS che può essere o a bordo del modulo Stima o a bordo di un dispositivo android.
Attenzione ai consumi energetici
Attenzione è stata posta alla limitazione dei consumi. Quando possibile i microcontrollori e i sensori vengono messi in sleep e sono alcuni interrupt a risvegliare il sistema. Questo agevola l'utilizzo con batterie dei sistemi a basso consumo quali il modulo satellite che funziona con un modulo radio.
Differenti tipologie di rete
La configurazione della rete può essee differente a seconda delle esigenze; oltre alla classica configurazione a stella (moduli master e base) con un broker al centro è disponibile la configurazione ad albero sia via cavo (modulo master + base) che via radio: con la possibilità di utilizzare moduli radio di maggiore potenza (~1Km in aria libera) è possibile prevedere coperture di un terriotorio con ampia superficie.
Software utente multipiattaforma
Il software che l'utente può utlizzare per la pubblicazione e visualizzazione dei dati è multipiattaforma. Fatti salvi i moduli basati su microcontrollore e vincolati all'ambiente Atmel e alcune funzioni sul server di raccolta dei dati sviluppati in ambiente Linux (distribuzioni CentOS e Fedora) la visulizzazione e il monitoraggio sono multipiattaforma. Anche l'interfaccia utente grafica che permette la geolocalizzazione, autenticazione e pubblicazione dei dati sia automatica che manuale anche di dati rilevati manualmente e a vista è multipiattaforma (attualmente testata su Linux, Android, ma portabile su Windows, OS X, iOS
Salvataggio locale dei dati
I dati possono essere pubblicati in real time e/o salvati localmente. È previsto un meccanismo di salvataggio dei dati su SD formattata FAT; i file vengono frammentati a una dimensione prefissata per farne circa uno al giorno e numerati da 000 a 999; i dati salvati hanno un flag che indica se i dati sono stati già pubblicati correttamente su MQTT; i file che devono essere controllati per possibili reinvii hanno postfisso .que e quelli che hanno tutti i dati già inviati hanno postfisso .don
In questo modo si ottengono queste funzionalità:
- salvataggio dati su SD almeno per due anni con campionamenti ogni 5s
- reinvio automatico al server dei dati salvati ma non pubblicati correttamente sul server
- ottimizzazione dei tempi in quanto solo i file che contengono dati da inviare vengono letti per selezionare i dati da reinviare
- i dati possono essere riletti su un normale PC estraendo la SD
Messagistica di diagnostica
C'è la possibilità di ottenere una ampia messaggistica di diagnostica per la soluzione dei problemi
Configurazione
Le versioni delle configurazioni vengono verificate e quando il firmware non è retrocompatibile il modulo resta in attesa di una nuova configurazione. Le configurazioni vengono subito verificate: non è possibile configurare un modulo con dei sensori non corretti o non funzionanti.
Modularità hardware e software
Le configurazioni hardware sono molteplici e possono essere utilizzate differenti board; sono compatibili i moduli hardware maggiormente diffusi e conosciuti dai makers oltre ad essere generalmente a basso costo.
Crittografia
Qualora il trasporto non sia considerato sicuro (via radio) viene utilizzata la crittografia per garantire riservatezza e autenticità.
Integrazione con la domotica
Per quello che è stato possibile si è cercato di integrarsi con gli standard della domotica (MQTT). Tutti i moduli possono essere utilizzati anche da attuatori on/off (fino a 4 relay) ma è molto semplice aggiungere altre funzionalità tramite remote procedure in formato json su tutti i trasporti o tramite MQTT.
Concetti base
La modularità della stazione è stata ottenuta astraendo alcuni concetti e funzioni e implementandoli nei differenti moduli hardware e software.
Trasporti
Il concetto di trasporto in Stima è simile ma non rigidamente aderente ai concetti del modello ISO-OSI. Nel caso dei trasporti passivi il suo compito è fornire un canale logico-affidabile di comunicazione end-to-end per fornire servizi al soprastante livello che in Stima è JsonRPC. Nel caso dei trasporti attivi corrisponde al protocollo (Session Layer) per la pubblicazione dei dati su un server (broker).
Passivi o attivi
In pratica i trasporti "passivi" permettono di eseguire procedure remote codificate in formato json specifiche dell'implementazione Stima; quelli attivi permettono la pubblicazione su server (broker) dei messaggi aderenti allo standard R-MAP.
Passivi
Seriale
Collegamento punto a punto tramite porta seriale.
- Principalmente per configurazione e debug
- Piccole distanze via cavo
caratterizzato da:
- Baud rate
- Device
TCP/IP
Trasporto che utilizza il TCP/IP; i supporti fisici supportati sono:
- ethernet: collegamenti tramite cavo ethernet a breve e media distanza
- GSM/GPRS: installazioni con problemi per le cablature di alimentazione e collegamento di rete
caratterizzato da:
- Name (Nome risolto dal DNS)
- NTPserver
Bluetooth
caratterizzato da:
- Bluetooth Name
NRF24
- OSI Network Layer using nRF24L01(+) radios 2.4GHz ISM 50/150m in aria libera
- Host Addressing. Each node has a logical address on the local network.
- Message Forwarding. Messages can be sent from one node to any other, and this layer will get them there no matter how many hops it takes.
- Ad-hoc Joining. A node can join a network without any changes to any existing nodes.
RF24Network Addressing and Topology
Each node must be assigned an 15-bit address by the administrator. This address exactly describes the position of the node within the tree. The address is an octal number. Each digit in the address represents a position in the tree further from the base.
- Node 00 is the base node.
- Nodes 01-05 are nodes whose parent is the base.
- Node 021 is the second child of node 01.
- Node 0321 is the third child of node 021, an so on.
- The largest node address is 05555, so 3,125 nodes are allowed on a single channel.
Alla libreria distributia è stata aggiunta la crittografia e frammentazione e ricomposizione del payload
caratterizzato da:
- Node (Node ID for RF24 Network)
- Channel (Numero canale per RF24)
- Key (AES key)
- Iv
Attivi
MQTT
MQTT (Message Queue Telemetry Transport) è un protocollo publish/subscribe particolarmente leggero, adatto per la comunicazione M2M tra dispositivi con poca memoria o potenza di calcolo e server o message broker.
caratterizzato da:
- Mqttsampletime (intervallo in secondi per la pubblicazione)
- Mqttserver (MQTT server)
- Mqttuser (MQTT user)
- Mqttpassword (MQTT password)
AMQP
AMQP (Advanced Message Queuing Protocol) è protocollo per comunicazioni attraverso code di messaggi. Sono garantite l'interoperabilità, la sicurezza, l'affidabilità, la persistenza.
caratterizzato da:
- Amqpserver (Server AMQP)
- Exchange (Nome dell'exchange remoto AMQP)
- Queue (Nome della coda locale AMQP )
- Amqpuser (User AMQP)
- Amqppassword
JsonRPC
La chiamata di procedure remote in formato json è l'unico metodo per poter eseguire funzioni su un modulo dalla configurazione al campionamento dei sensori.
La documentazione delle procedure remote è disponibile qui Gruppo_Meteo/RemoteProcedure
JsonRPC over different transports
È possibile fare richiesta di una procedura remota che a sua volta richiede una procedura remota; in questo modo è possibile utilizzare due trasporti differenti e usare un modulo come gateway. Ad esempio il modulo base non dispone al momento del trasporto radio RF24 ma puo' richiedere a un modulo master tramite trasporto seriale o TCP/IP di eseguire una procedura remota su un modulo satellite raggiungibile tramite trasporto RF24. Queste funzionalità sono ampiamente da testare.
Elementi hardware
board microcontroller
atmel 328p
Il più piccolo della serie può essere utilizzato per:
- modulo i2c-gps
- modulo i2c-wind
- modulo i2c-rain
implementazioni on board:
- arduino uno
- arduino nano
- microduino core
atmel 644p
Il medio della serie può essere utilizzato per:
- modulo satellite
- modulo bluetooth
- tutti i moduli relativi al 328p
implementazioni on board:
- microduino core+ 644p
altmel mega 2560/1284p
Il grande della serie può essere utilizzato per:
- modulo master
- modulo GPS/GPRS
- tutti i moduli relativi al 644p
implementazioni on board:
- arduino mega2560
- microduino core+ 1284p
board RTC
Il real time clock deve utilizzato quando non è possibile avere un'altra sorgente affidabile per il tempo di riferimento e al tempo stesso la pubblicazione dei dati può avvenire con tempo differito ad esempio tramite la memorizzazione su scheda SD.
board radio RF24
È necessaria per supportare il trasporto NRF24
board ft232
È necessaria per programmare, debuggare, a volte configurare il modulo e per supportare il trasporto seriale.
board ENC28J60
Ethernet module a basso costo; è necessario lo stack tcp/ip software su microcontrollore. Serve per supportare il trasporto TCP/IP. Alternativa alla board wiznet
board wiznet W5500
Ethernet module completa dello stack tcp/ip. Serve per supportare il trasporto TCP/IP. Alternativa alla board ENC28j60
board display I2C LCD 4 linee 20 caratteri
Utilizzabile per visualizzare messaggistica di diagnostica e alcune misure quando non è disponibile un PC per debug e altre visualizzazioni.
implementazioni on board:
- YwRobot Arduino LCM1602 IIC V1
board 5V relay
5V 4/2-Channel Relay interface board; Equipped with high-current relay, AC 250V 10A / DC 30V 10A Opticalcoupler Protection Utilizzabile per aggiungere a un modulo la funzionalità di attuatore. Ogni relay può essere attivato singolarmente.
board SD
Microduino-SD aims to read and write data of a memory card. Utilizzata per memorizzare i dati in loco; necessaria quando non ci siano trasporti utili o la stabilità dei trasporti utilizzati è messa in dubbio e i dati hanno valore anche in tempo differito.
board GSM/GPRS sim800/sim900
Adopt SIM800L module to support four-band GSM/GPRS, whose working band is:GSM850, EGSM900, DCS1800 and PCS1900MHz. Utilizzabile per avere il trasporto TCP/IP quando non è disponibile una connessione ethernet. Questo modulo può funzionare sul trasporto TCP/IP in due modalità: una con delle get http tramutate dal server in publish MQTT e l'altra in una vera connessione MQTT. E' possibile utilizzare questo modulo anche cone Real Time Clock per ottenere una tempo di riferimento stabile. Si può quindi ottenere dal server rmap il tempo di riferimento e impostarlo nell'RTC di questo modulo per poi rileggerlo al bisogno in caso di non disponibilità del trasporto TCP/IP; tutto questo a scapito di stabilità e continuità di servizio. Nel caso sia importante avere un RTC affidabile si consiglia l'aggiunta di un modulo RTC o ancora meglio del modulo GPS.
board GPS Neo 6M
Questa board insieme a una board microcontrollore possono creare un modulo i2c-gps. Il modulo i2c-gps fornisce a richiesta la posizione (lat, lon, altezza) e il tempo di riferimento. Serve per istallazioni mobili o che necessitano di un tempo di riferimento particolarmente stabile.
Guida per la composizione di un modulo Stima
TODO