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