Creazione di un Gateway IoT con Antennino e Thingsboard

Una nuova applicazione della board Antennino che realizza un gateway utilizzando un software open source con cui realizzare un pannello di controllo (Dashboard) per i nostri dispositivi wireless.ย 

Vi abbiamo fatto conoscere, in questi post, la nostra Arduino in versione IoT dotata di connessione wireless, battezzata non a caso Antennino; questa scheda ha la particolaritร  di poter funzionare, in base alla configurazione hardware e firmware, da periferica o da gateway di piรน periferiche.

Ricordiamo, prima di entrare nel vivo di questo articolo, che Antennino รจ una scheda basata su architettura Arduino Uno e dotata nativamente di una serie di connessioni utilizzabili per lโ€™interfacciamento a sensori locali e un link radio UHF per comunicare con il mondo esterno; una delle sue caratteristiche salienti รจ che, a seconda del firmware che vi si va a caricare, puรฒ funzionare sia da unitร  remota o nodo periferico (edge-point) che si interfaccia direttamente ai sensori, sia da concentratore, che sarebbe il nodo deputato a raccogliere i messaggi inviati da piรน unitร  Antennino funzionanti da nodo periferico. Il concentratore รจ equipaggiato con un piccolo display OLED che funziona da interfaccia utente.

Ora andremo a implementare un Gateway vero e proprio, dove i dati delle Antennino periferiche non vengono semplicemente raccolti e visualizzati, ma anche interfacciati al web.

Per implementare tale applicazione non abbiamo potuto utilizzare lo stesso hardware di Antennino, ma progettare da zero e realizzare una nuova scheda, dove per la connettivitร  sfruttiamo un modulo ESP32 e quindi il link WiFi, che ci farร  da bridge verso il mondo di Internet.

Il progetto del gateway con Antennino

Utilizzeremo il modulo ESP32 come un classico Arduino e lo faremo comunicare con il modulo RFM69. Come certamente saprete lโ€™ESP32 supporta in modo nativo la connettivitร  TCP/IP (WiFi) e questo apre le porte alla comunicazione del nostro ecosistema di sensori verso la rete internet e quindi potremo realmente parlare di IoT.

Dopo una attenta valutazione delle possibili alternative per quanto riguarda la scelta del software per la Dashboard, lโ€™attenzione si รจ posata su un software open source (Licenza Apache) che viene rilasciato in due versioni: una versione Community Edition ed una versione Professional. Si scarica da https://thingsboard.io.

La versione Community Edition puรฒ essere installata su Raspberry Pi, su un PC Windows, su un server Linux (Ubuntu โ€“ CentOS), su Google Cloud, tramite Doker (Windows o Linux o MacOs) su piattaforma AWS e ciliegina sulla tortaโ€ฆ รจ disponibile una versione perfettamente funzionante tramite la quale potrete dedicarvi alle prime sperimentazioni senza impegnarvi in alcuna installazione e senza dover sborsare un solo euro.

Per i piรน esigenti esiste la versione Professional che puรฒ essere istanziata come servizi PaaS (Platform as a Service, ossia qualcosa che fornisce agli sviluppatori una piattaforma e un ambiente per realizzare applicazioni e servizi Internet) su Cloud Microsoft Azure o Amazon AWS. Inoltre รจ possibile attivare dei piani personalizzati per usufruire del supporto del team di sviluppo.

Esiste inoltre un software Gateway addizionale sempre Open Source che permette di interfacciarsi con dispositivi che supportano i protocolli OPC-UA, Sigfox, Modbus. Essendo Open รจ possibile modificare il software secondo le proprie esigenze ed estendere le possibilitร  di interfacciamento.

Il codice รจ sviluppato in Java รจ disponibile su Github come la versione Community di ThingsBoard. Noi non utilizzeremo questo software ma interfacceremo i nostri Antennino tramite protocollo MQTT direttamente verso ThingsBoard impiegando il nostro Gateway.

La piattaforma Thingsboard comunica in modo nativo tramite protocollo MQTT.

 

MQTT: conosciamolo meglio

Tutto nasce nel 1999 dallโ€™impegno di due ingegneri, Andy Stanford-Clark (IBM) e Arlen Nipper (Arcom, oggi Cirrus Link) concentrati nel trovare una soluzione per monitorare pozzi e asset remoti delle aziende petrolifere Texane. Idearono quello che viene indicato con lโ€™acronimo MQTT (Message Queuing Telemetry Transport) e nello stesso anno rilasciarono la prima versione.

Dopo tre anni dalla pubblicazione fu annunciato che lโ€™MQTT sarebbe stato standardizzato dalla OASIS e nellโ€™ottobre del 2014 MQTT ha finalmente ricevuto il suggello della standardizzazione e attualmente รจ disponibile la versione 3.1.1. MQTT si รจ subito affermato in ambito IoT.

Il protocollo oggi รจ open, disponibile con licenza royalty-free, dopo la donazione da parte dellโ€™IBM dal 2011 al progetto Eclipse Paho.

Il protocollo MQTT si presta in modo particolare per permettere la comunicazione di dispositivi embedded, con richiesta di impiego minimo di risorse energetiche e limitata capacitร  computazionale; รจ particolarmente indicato per questi vincoli e nei casi in cui la rete consenta larghezza di banda limitata.

MQTT viaggia su protocollo di rete TCP/IP e ha bassi overhead di trasporto, dato anche un formato di messaggio con header fissato a 2 byte, che รจ anche la dimensione minima di un pacchetto.

MQTT fornisce tre tipi di Quality of Service. I tre livelli di servizio sono:
โ€ข 0. At most once (al piรน una volta): i messaggi vengono consegnati in base al miglior effort di rete, per cui possono avvenire perdite o repliche di informazione;
โ€ข 1. At least once (almeno una volta): si assicura lโ€™arrivo del messaggio, ma possono avvenire repliche;
โ€ข 2. Exactly once (esattamente una volta): si assicura che i messaggi arrivino esattamente una volta.

Gli sviluppatori di Thingsboard hanno in un certo senso integrato un Broker MQTT nella loro piattaforma e quindi il Gateway che andremo a realizzare in questa puntata comunica con lo specifico Broker MQTT di Thingsboard il quale supporta solo i due livelli QoS 0 ed 1.

 

Come funziona MQTT

Il ruolo centrale dellโ€™architettura รจ il Broker (intermediario) MQTT (Fig. 1), il quale ha il compito di instradare tutti i messaggi tra i mittenti e i legittimi destinatari.

Ogni cliente (Client) che pubblica un messaggio sul broker, include un topic (argomento) nel corpo del messaggio. Lโ€™argomento รจ lโ€™informazione di instradamento per il broker.

Ogni cliente che desidera ricevere messaggi sottoscrive un determinato argomento e il Broker consegna tutti i messaggi con lโ€™argomento corrispondente ai vari client che lo hanno sottoscritto.

Fig. 1 Architettura MQTT.

 

Pertanto i clienti non devono conoscersi tra loro: comunicano solo sullโ€™argomento cui desiderano sottoscrivere aggiornamenti.

Questa architettura consente soluzioni altamente scalabili senza dipendenze tra i produttori di dati e i consumatori di dati, quindi si possono avere architetture completamente eterogenee.

La differenza con HTTP รจ che un client non deve eseguire un polling per ricevere le informazioni di cui ha bisogno, ma รจ il Broker che notifica gli aggiornamenti sui topics che il client ha sottoscritto, nel caso ci sia qualcosa di nuovo.

Pertanto ogni client MQTT ha una connessione TCP permanentemente aperta verso il Broker. Se questa connessione viene interrotta per qualche circostanza, il broker MQTT puรฒ bufferizzare tutti i messaggi e inviarli al client quando questi tornerร  in linea. Un client puรฒ essere allo stesso tempo un publisher che un subscriber chiaramente su topic diversi.

Il Gateway

Per quanto riguarda il Gateway abbiamo pensato di realizzare una basetta con il minimo di componenti presaldati a bordo per privilegiare la modularitร . Per quanto riguarda i moduli, sono facilmente reperibili su questo sito e li trovate qui a destra.

Nella prima stesura del progetto ci eravamo orientati sul modulo ESP8266, ma proseguendo nella realizzazione ci siamo resi conto che sarebbe stato meglio passare al fratello maggiore: lโ€™ESP32.
La Tabella 1 riassume in modo conciso le differenze tra i due moduli.

Quello che salta subito allโ€™occhio รจ la maggiore disponibilitร  di memoria RAM (quasi triplicata), la frequenza di clock raddoppiata, il maggior numero di GPIO, ma la cosa piรน importante รจ la presenza di due Core.
Un core รจ deputato alla gestione dello stack TCP-IP e lโ€™altro dedicato alla gestione del nostro Sketch; questo consente di avere maggiore stabilitร  del codice.

Mentre nel caso del chip ESP8266 lo stesso core deve gestire sia la connessione TCP-IP che lo sketch dellโ€™utente e non รจ raro il verificarsi di situazioni di stallo che portano al blocco del codice o a dei malfunzionamenti.

 

Tabella 1 Comparazione tra ESP8266 e ESP32.

 

Utilizzare lโ€™ESP32 nellโ€™IDE Arduino

Per poter utilizzare i moduli ESP32 รจ necessario installare quella che viene chiamata la Toolchain: un insieme di strumenti e librerie.

Per agevolare lโ€™utente รจ stato messo a punto uno script che permette di fare scaricare tutto quello che ci serve dalla interfaccia IDE di Arduino.

Assicuriamoci di avere lโ€™ultima versione dellโ€™IDE di Arduino, poi andiamo per prima cosa ad aggiungere il supporto al modulo ESP32. Per fare ciรฒ, dobbiamo aprire lโ€™IDE di Arduino selezionare dalla voce di menu File/Preferences ed aprire la scheda visibile nella Fig. 2.

Fig. 2 Impostazione dellโ€™IDE Arduino.

 

Inseriamo quindi il seguente URL https://dl.espressif.com/dl/package_esp32_index.json nel box โ€œAdditional Boards Manager URLโ€ e cliccare su โ€œOKโ€.

Riavviamo quindi Lโ€™IDE di Arduino e se tutto รจ filato liscio dovremmo trovare una serie di board aggiuntive che usano il modulo ESP32. Dal menu, selezioniamo la scheda desiderata come visibile nella Fig. 3.

Dovrete altresรฌ caricare le librerie utilizzate nel progetto. Per agevolarvi nel compito abbiamo inserito nella cartella lib del repository GihHub, un file .zip contenente tutte le librerie relative al Gateway: inserite solo quelle che non avete giร  nella vostra cartella delle librerie Arduino, perchรฉ alcune potrebbero essere giร  presenti perchรฉ avete giร  compilato uno sketch relativo ai moduli Antennino.

Riavviamo quindi Lโ€™IDE Arduino, cosicchรฉ siamo pronti ad aprire lo sketch del Gateway, compilarlo e caricarlo sul Gateway.

Fig. 3 Selezione della scheda

 

La memoria dell’ESP32 per lo sketch

Il chip ESP32 รจ dotato di una memoria Flash esterna, visibile in figura (Fig. 3). Tale chip Flash, viene impiegato per memorizzare software, dati, parametri di configurazione eccโ€ฆ
Questa memoria esterna viene collegata al chip via bus SPI e puรฒ avere una dimensione massima di 16Mb.

Il modulo ufficiale Espressif (ESP-WROOM-32) monta un chip da 4Mb. Normalmente non vediamo i chip ESP32 e il modulo Flash perchรฉ sono racchiusi allโ€™interno di una schermatura metallica che nella Fig. 4 รจ stata rimossa a scopo dimostrativo.

Fig. 4 La EEPROM sul modulo

 

Lo spazio di memoria complessivo del chip Flash viene partizionato in diverse parti, ognuna delle quali ha uno scopo specifico.Per vedere quali profili di partizione della Flash Memory esistono normalmente, apriamo il menu accessibile, dallโ€™IDE di Arduino selezioniamo, con i comandi Tools/Partition Scheme.

In esso possiamo vedere che sono presenti quattro opzioni, ognuna delle quali corrisponde ad altrettanti utilizzi particolari ed ognuna mette a disposizione un ammontare specifico di Memoria Flash per il nostro sketch (Fig. 5).

Fig. 5 Menu con le quattro opzioni di memoria.

 

Proviamo a selezionare lโ€™opzione โ€œdefaultโ€. Compilando lo sketch vedremo (Fig. 6) che saranno disponibili al massimo 1310720 Byte. Mentre in Fig. 7, selezionando lโ€™opzione โ€œNo OTA (large APP) avremo a disposizione 2097152 Byte. Scegliamo quindi questa opzione per il nostro progetto.

Le altre opzioni sono: la velocitร  in di comunicazione della porta seriale, la frequenza max del bus SPI del chip Flash, la modalitร  del funzionamento del chip Flash e la modalitร  di debug.
Come caricare lo sketch

Fig. 6 Massima memoria disponibile con lโ€™opzione di partizione โ€œDefaultโ€.

 

Fig. 7 Massima memoria disponibile con lโ€™opzione di partizione โ€œNo OTA (Large APP)โ€.

 

Per evitare problemi, prima di avviare il caricamento dello sketch dalla interfaccia IDE di Arduino รจ necessario tenere pigiato il pulsante โ€œBOOTโ€ che si trova alla destra del connettore microUSB, potremo poi rilasciarlo quando inizierร  ad apparire il messaggio di log presente in Fig. 8.

Se tutto procede in modo corretto al termine il modulo si resetterร  e potremo testarne il funzionamento aprendo la finestra della porta seriale per verificare i messaggi di LOG. Alcuni messaggi importanti vengono riportati anche sul display OLED.

Fig. 8 Il messaggio di log nella finestra dei report dellโ€™IDE.

Modulo GPRS

Il Gateway potrebbe essere impiegato anche in una installazione nella quale la connettivitร  Wi-Fi non sia presente e per ovviare a questo abbiamo previsto di fornire connettivitร  tramite un piccolo modulo GSM-GPRS.
Il modulo che utilizzeremo monta il chip SIM800 che lavora nella banda di frequenze 1.800 MHz, 1.900 MHz, 850 MHz, 900 MHz ed ha una velocitร  massima di trasferimento dati di 85,6 kbps.

Lโ€™impiego del protocollo MQTT non richiede grande larghezza di banda e quindi una connessione GPRS รจ piรน che sufficiente. Inoltre, attualmente sul mercato sono apparse numerose aziende che forniscono SIM specifiche per il mondo IOT ed i prezzi sono molto interessanti.

Per il momento lo abbiamo previsto a bordo della scheda, poi nei prossimi numeri tratteremo un articolo specifico per il suo impiego nel Gateway.

Il modulo GPRS necessita di tensione di alimentazione che deve essere nel range 3,4รท4,4V DC con una corrente massima di 2A (nella fase di trasmissione), quindi abbiamo la necessitร  di aggiungere un modulo di alimentazione switching e dovremo prevedere anche un adattatore di livelli logici per la comunicazione seriale tra il ESP32 ed il modulo GPRS in seguito alla discrepanza di tensione di alimentazione e al fatto che il modulo ESP32 non รจ 5V-tolerant.

Il traslatore di livelli logici lo abbiamo implementato con la coppia di Mosfet Nโˆ’Channel Q1, Q2 e i quattro resistori R1, R2, R3, R4.

Schema Elettrico

Diamo dunque uno sguardo allo schema elettrico del Gateway, che รจ sostanzialmente quello della board che ospita tutti i moduli.

La configurazione รจ molto semplice. La comunicazione tra il modulo ESP32 ed RFM69 avviane tramite il protocollo SPI utilizzando i pin preposti per questo protocollo sul modulo ESP32.

Tabella 2 Pin utilizzati per la comunicazione.

 

In Fig. 9 vediamo la pin-out del modulo ESP32 e nella Tabella 2 riportiamo un riepilogo dei pin utilizzati per la comunicazione SPI.

 

Tabella 3 Pin dellโ€™RTC utilizzati.

 

La comunicazione tra il modulo ESP32 ed il modulo RTC avviene tramite il protocollo IยฒC. In Tabella 3 abbiamo un riepilogo dei pin impiegati, anche in questo caso sono stati utilizzati dei pin configurati in modo predefinito per svolgere questa funzionalitร , ossia quelli dellโ€™RTC.

Fig. 9 Pin out del Modulo ESP32.

 

 

 

Lโ€™esigenza di impiegare un modulo RTC รจ dovuta alla necessitร  da parte del Gateway di inviare pacchetti telemetrici verso Thingsboard che contengano un Timestamp corretto.

Questo non รจ necessario per sensori che comunicano direttamente in MQTT con ThingsBoard. Sul sito si trovano diversi tutorial che spiegano come implementarli.

รˆ presente anche un piccolo display OLED che viene pilotato tramite protocollo IยฒC e che quindi condivide il Bus con il chip RTC DS3231. Particolare attenzione va posta alla pin-out del modulo OLED perchรฉ alcuni modelli che si trovano in commercio hanno i pin di alimentazione invertita.

Lโ€™alimentazione a 3,3V per il modulo RFM69 e per il modulo RTC viene ricavata dal regolatore a bordo del modulo ESP32 il quale a scopo di test puรฒ essere alimentato tramite il cavo USB impiegato per caricare lo sketch Arduino, mentre per lโ€™uso in produzione e soprattutto quando si impiega il modulo GPRS, sarร  necessario alimentarlo tramite un alimentatore esterno collegato al connettore CONN1 (Tabella 4).

Tabella 4 Pin dedicati al modulo GPRS

Per la connessione dellโ€™antenna del modulo RFM69 abbiamo previsto un connettore U.FL sulla scheda base, ovvero una piazzola alla quale saldare uno spezzone di filo. Per quanto riguarda il modulo ESP32, lโ€™antenna per il WiFi รจ integrata. รˆ stato previsto un connettore di servizio CONN2 che permette di accedere ai pin GPIO rimasti liberi e che quindi potrebbero essere utili per implementare delle funzionalitร  aggiuntive del Gateway.

Alimentare il modulo SIM800

Quando il gateway viene impiegato senza modulo GPRS lโ€™alimentazione puรฒ essere fornita anche tramite un buon alimentatore da 5V con cavo micro-usb che eroghi almeno 1A, da collegare direttamente al modulo ESP32. Il regolatore lineare AMS117 a bordo si occuperร  di convertire la tensione nei 3,3V necessari al funzionamento del Gateway.

Quando invece viene impiegato il modulo GPRS, dovremo utilizzare ad un alimentatore esterno di maggiore potenza da collegare al connettore CONN1. In tal caso รจ tassativo utilizzare un alimentatore di buona qualitร , stabilizzato che eroghi una tensione massima di uscita di 12V ed un corrente di almeno 2A.

Questo perchรฉ la tensione viene applicata al pin Vin del modulo ESP32 che ha a bordo un regolatore AMS117 che sopporta al massimo una tensione di 15 V, e perchรฉ il modulo SIM800 richiede dei picchi di corrente massima di 2A nelle fasi di trasmissione dati o aggancio alla cella.

Inoltre, particolare attenzione va posta nella regolazione della tensione del modulo Switching U2: il modulo SIM800 necessita di una tensione massima di 4,4V.

Lasciamo quindi sulla scheda il solo regolatore U2, ponticelliamo il Jumper JP1, apriamo il Jumper JP2, colleghiamo lโ€™alimentatore esterno (Max 12V) al connettore CONN1 e regoliamo il trimmer a bordo del modulo finchรฉ la tensione misurata con un multimetro digitale sui pin di test TP1 (GND) e TP2 sia pari a 4,4 V.

Per assicurarsi che non avvenga una modifica della regolazione potremmo anche sigillare il trimmer con una goccia di silicone o ceralacca. A questo punto rimuoviamo lโ€™alimentatore esterno, chiudiamo il Jumper JP2, colleghiamo il modulo GPRS e ricolleghiamo lโ€™alimentatore esterno.

 

Caricamento sketch e configurazione Gateway

I vari Sketch possono essere scaricati dal repository Github https://github.com/open-electronics/antennino/gateway_thingsboard, dove sarร  possibile scaricare anche le librerie utilizzate per il progetto.
Il codice del Gateway รจ stato suddiviso in tre file che devono trovarsi tutte nella stessa cartella.

Cโ€™รจ un file di configurazione User_config.h e due file contenente codice RFM69.ino e ThingsBoardGateway.ino
Nel file di configurazione ci sono solo due parametri che richiedono una modifica: NETWORKID e ENCRYPTKEY.

NETWORKID in questo momento รจ settato su 1. Normalmente รจ corretto cosรฌ, ma se avete lโ€™esigenza di avere piรน di 253 dispositivi Antennino, dovrete modificare questo parametro e suddividere la rete in piรน network, ognuna con un proprio gateway dedicato visto che una rete Antennino (RFM69) puรฒ supportare su uno stesso NETWORKID al massimo 253 dispositivi.

Lโ€™altro Parametro, ENCRYPTKEY deve invece essere assolutamente modificato perchรฉ รจ la chiave che serve a criptare la comunicazione tra i moduli Antennino ed il gateway. Attenzione, che deve essere di 16 caratteri e deve essere lo stesso su tutti i nodi della rete, Gateway compreso.

รˆ stata implementata inoltre la funzionalitร  di sincronizzazione del RTC (DS3231).

Per sincronizzare il chip RTC รจ stata realizzata una libreria che utilizza le API del servizio web https://timezonedb.com, questo รจ preferibile rispetto alla sincronizzazione effettuata tramite un server NTP, perchรฉ questโ€™ultimo richiede lโ€™apertura di porte UDP e il codice รจ di difficile portabilitร  nel caso di utilizzo del modulo GPRS. Per poter usufruire del servizio, che รจ gratuito per un uso normale, รจ necessario registrarsi ed ottenere una KEY.

Nella configurazione esiste un parametro che permette di specificare la frequenza di aggiornamento del RTC tramite il server TimezonedB.

Terminata la procedura di test รจ necessario settare la variabile DEBUG_MODE a false.

Il codice del Nostro Gateway contiene la gestione dei parametri di connessione WiFi e dei parametri di connessione al server ThingsBoard e la KEY per lโ€™utilizzo del timeserver TimeZonedB. Il tutto viene implementato tramite la personalizzazione del modulo WifiManager.

Il codice del Gateway si compone della solita procedura Setup che viene eseguita una sola volta in fase di Boot del dispositivo e di una procedura di Loop che viene ripetuta ciclicamente durante il funzionamento del Gateway. Nella procedura di Setup vengono inizializzate come di consueto la Porta Seriale, i Pin, ecc.

Viene inoltre intercetta la pressione del pulsante P1 che serve a resettare la configurazione del Gateway, viene inizializzato il RTC (DS3231) le librerie per la connessione con TimezonedB, MQTT, RFM69.

Una particolare attenzione va posta alla chiamata client.setCallback(MQTTtoRFM69); con la quale si istruisce il codice sulla procedura di CallBack relativa al Protocollo MQTT, in pratica quando il gateway riceve un pacchetto MQTT in seguito alla ricezione di dati relativi ad una sottoscrizione ad un certo topic, la gestione di questi dati viene delegata alla procedura MQTTtoRFM69() nella quale vengono estratte le informazioni contenute nel formato JSON e intraprese le azioni conseguenti.

Nella procedura di Loop una cosa molto utile in fase di debug รจ la gestione di un carattere ricevuto dalla seriale (Listato 1). In questo modo รจ possibile impartire un comando particolare (richiamare una particolare procedura mentre il Gateway sta funzionando a scopo di debug).

Nel Loop() viene verificato il fatto che il client MQTT sia connesso e nel caso in cui si perda la connessione viene richiamato il metodo reconnect(); mentre, ciclicamente se la connessione รจ attiva viene richiamato il metodo client.loop();.

Nella fase di loop viene anche intercettata la pressione del pulsante P1. Tenendo premuto questo pulsante viene resettata la configurazione WiFi del chip ESP32 e quindi รจ possibile modificare i parametri di connessione. Nel prossimo articolo vedremo nel dettaglio questa configurazione.

La funzione RFM69toMQTT inoltra i dati ricevuti dai nodi Antennino da parte del Gateway verso il server MQTT di Thingsboard. Degna di nota รจ anche la procedura PublishRPC_Response che permette il funzionamento delle chiamate RPC (Remote Procedure Call) con le quali รจ possibile inviare dei comandi dalle Dashboard di ThingsBoard verso un dispositivo Antennino e ricevere un Feedback sullโ€™avvenuta esecuzione del comando.

Questa particolaritร  รจ stata usata per controllare il LED di bordo di Antennino da una Dashboard. Vedremo in seguito come si implementa su ThingsBoard questa funzionalitร .

Sul sito web di ThingsBoard sono presenti degli esempi di controllo di Pin GPIO su semplici dispostivi che non fanno uso di Gateway. Vi invitiamo a sperimentare per capire in modo approfondito il funzionamento della tecnica quando non sia presente un Gateway, cosa che poi tornerร  utile per capire le modifiche che sono state necessarie nella implementazione quando esiste un intermediario (Gateway) tra il modulo da controllare ed ThingsBoard.

La pubblicazione di dati telemetrici verso ThingsBoard avviene tramite la funzione PublishTelemetryData. Da notare il formato particolare che deve avere il payload Json da inviare:

โ€œ{\โ€RFM69_1\โ€:[{\โ€ts\โ€:1483228800000,\โ€values\โ€:{\โ€BAT\โ€:2.51,\โ€T\โ€:26.38,\โ€L\โ€:876.00}}]}โ€

RFM69_1 rappresenta lโ€™identificativo del dispositivo che trasmette il dato, quindi si tratta del nodo RFM69 Nยฐ 1.
1483228800000 rappresenta il Timestamp ricavato dal RTC. BAT รจ lโ€™identificativo del parametro Batteria e 2.51 il suo valore letto tramite lettura analogia, T lโ€™identificativo del parametro Temperatura e 26.38 il suo valore letto tramite il sensore a DS18B20 bordo

Lโ€™identificativo del parametro Luminositร  e 876.00 il suo valore letto tramite il sensore LDR a bordo.

Allโ€™indirizzo Internet https://thingsboard.io/docs/reference/gateway-mqtt-api si trovano informazioni dettagliate sulle API da usare.

Codice Nodo Antennino โ€“ Attuatore

Come ricordato precedentemente abbiamo modificato il codice ai Antennino per gestire lโ€™invio dei dati telemetrici nel formato Json. Inoltre, per poter sfruttare la possibilitร  di controllare dei Pin (RPC) di Antennino tramite la Dashboard di ThingsBoard รจ necessario che il modulo Antennino non vada in modalitร  LowPower. Quindi abbiamo configurato il modulo per fare in modo che sia costantemente alimentato ed abbiamo modificato il codice per gestire le chiamate RCP.

In Fig. 10 riportiamo la disposizione dei jumper che consente di ottenere la configurazione dellโ€™alimentazione desiderata. In questo modulo usiamo la modalitร  di alimentazione tramite le due batterie AA a bordo di Antennino disabilitando il timer TPL5110. La maggior parte del codice รจ rimasta invariata rispetto al codice giร  presentato dei nodi Antennino.

Degno di nota รจ il blocco che si trova dentro il loop del Listato 2. In questo codice si intercettano i comandi ricevuti dal Gateway conseguenti a richieste originate dalla Dashboard e si prepara la costruzione della risposta da rigirare al Gateway che a sua volta le ridirigerร  a Thingsboard.

Fig. 10 Impostazione dei jumper.

Una cosa molto importante รจ il valore del parametro Request_Id il quale รจ inviato da ThingsBoard per mantenere traccia della identitร  di una sequenza di richieste e risposte tra il dispositivo ed ThingsBoard.

In pratica se ThingsBoard invia un comando per il quale richiede una risposta, viene inserito il codice Request_Id che deve essere restituito dal nodo Antennino nella risposta verso ThingsBoard. Tutto questo in conseguenza dellโ€™asincronia tra chiamate e risposte.

Codice Nodo Antennino โ€“ Lowpower

In questo caso, cioรจ utilizzando la modalitร  lowpower, il modulo puรฒ andare in modalitร  basso consumo e quindi non sarร  possibile inviare dei comandi remoti allo stesso tramite la Dashboard.

Riportiamo in Fig. 11 la disposizione dei jumper che consente di ottenere la configurazione per la modalitร  Low Power nativa del modulo Antennino (senza TPL5110).

Il codice รจ molto simile a quello del Nodo Actuator, a parte la gestione dei comandi RPC e la gestione della modalitร  Low Power. Per il resto, vengono inviati verso ThingsBoard gli stessi dati di telemetria.

Fig. 11 Impostazione jumper per la modalitร  Low Power.

Automatic Provisionig

Una cosa interessante che riguarda il nostro Gateway ed i nodi Antennino รจ quella che una volta aggiunto il dispositivo Gateway, per fare in modo che i vari moduli Antennino che andremo ad aggiungere alla nostra rete di sensori/attuatori appiano tra i dispositivi presenti su ThingsBoard, non รจ necessario compiere alcuna azione: รจ sufficiente mantenere alimentato il Gateway, alimentare i vari nodi Antennino che vogliamo partecipino alla rete e i nodi appariranno โ€œmagicamenteโ€ sotto la voce Dispositivi su ThingsBoard con la dicitura RFM69_1, RFM69_2 โ€ฆ RFM69_XXX.

Dove il numero XXX dopo il prefisso RFM69_ indica il numero del nodo che deve essere univoco un una rete Antennino.

Vi ricordiamo che la rete Antennino supporta la massimo 255 (253 considerando il gateway dati ed OTA) nodi possibili per ogni rete. Quindi beneficeremo di quella che viene indicata come Automatic Provisionig o Deployement.

Quindi appena uno dei nodi invierร  un pacchetto di dati al Gateway (perchรฉ ricordiamoci che i nodi parlano direttamente con il nostro Gateway) il Gateway provvederร  a ridirigere i dati con il protocollo MQTT verso ThingsBoard.

Conclusioni

Bene, per il momento concludiamo qui. Nellโ€™articolo successivo concluderemo affrontando lโ€™installazione e lโ€™utilizzo di ThingsBoard nella creazione della Dashboard.

Vi abbiamo introdotto la realizzazione del Gateway Antennino che ci permetterร  di collegare la nostra rete di dispositivi ad una Dashboard Thingsboard, abbiamo illustrato le particolaritร  del Gateway ed abbiamo introdotto il protocollo MQTT e la Dashboard IoT ThingsBoard.

Lascia un commento

Il tuo indirizzo email non sarร  pubblicato.

Menu