LoRaWAN

Riferimento del driver LoRaWAN - il server di rete Basics Station integrato, i certificati dei gateway, le registrazioni di sensore e di concentratore, e l'indirizzamento del payload.

Il driver LoRaWAN fa di Ganter Lab un piccolo server di rete LoRaWAN. La direzione del rapporto è rovesciata rispetto alla maggior parte dei driver: la stazione non va a cercare un sensore, è il gateway a collegarsi a Ganter Lab, e i sensori consegnano le loro letture come uplink attraverso quel gateway. Ganter Lab incorpora un server di rete che parla il protocollo LoRa Basics Station di Semtech, quindi qualunque gateway con firmware Basics Station può usare questa stazione come proprio LNS.

Il server integrato parte quando il primo dispositivo LoRaWAN abilitato viene caricato nel connector in funzione, non all'avvio dell'applicazione, e si ferma quando l'ultimo viene rimosso o disabilitato: senza alcun sensore e alcun concentratore configurato, sulla porta non ascolta proprio nulla. Aggiungerne uno lo fa tornare, senza riavviare l'applicazione.

Ogni dispositivo sotto il driver è una di due registrazioni, scelta nel suo pannello:

• Un sensore, identificato dal suo DevEUI e ammesso con la sua chiave applicativa. I suoi tag decodificano il payload dell'uplink.
• Un concentratore radio (il gateway), identificato dal suo EUI della stazione e registrato in una regione radio scelta da un elenco. Non porta tag propri: la sua pagina tiene Aggiungi tag disattivato, con il motivo, finché il dispositivo non è registrato come sensore.

Registra il concentratore oltre ai sensori. Un concentratore Basics Station chiede la propria configurazione radio appena si collega e non ritrasmette proprio nulla finché non gli si risponde, quindi una stazione che non ha mai visto il suo EUI della stazione lascia senza valore ogni sensore che gli sta dietro mentre la connessione stessa sembra sana. La risposta viene costruita qui a partire dalla regione scelta; non c'è alcun testo di configurazione da incollare.

Preparare il gateway

È il gateway a chiamare questa stazione, tramite LoRa Basics Station, e di fabbrica non sa dove si trovi. La pagina di ogni dispositivo registrato come concentratore radio porta la scheda Preparare il gateway, con quello che va inserito nelle impostazioni Basics Station del gateway, scritto per questa stazione:

La scheda è aperta finché il gateway non si è collegato dall'apertura della stazione, e si richiude una volta collegato: resta nella pagina per la prossima volta che il gateway verrà configurato. Un gateway il cui certificato non è garantito da nessuna radice installata in Windows viene rifiutato alla prima connessione e attende in Accesso delle apparecchiature. Un gateway che parla solo il protocollo Semtech UDP packet forwarder non può collegarsi: gli serve un firmware Basics Station.

Il file è lo stesso per tutti i gateway di questa stazione, e non cambia quando cambiano il nome o gli indirizzi della stazione. Un gateway con le impostazioni predefinite di Basics Station accetta la stazione: nella sua configurazione non occorre disattivare nulla.

Ogni gateway che ha ricevuto un file da una versione precedente ha bisogno di questo, installato una volta come tc.trust. Al primo avvio di questa versione, una stazione i cui gateway possono avere un file precedente mostra sulla scheda un avviso, Il file di questa stazione è cambiato, solo in quell'esecuzione. L'avviso è un promemoria, non l'istruzione: installare il nuovo file una volta su ogni gateway di una stazione che aveva già gateway, che la scheda mostri l'avviso o no.

Server di rete e porte

L'ascolto è sempre in TLS. Non esiste alcuna impostazione che spenga la cifratura: un ascolto in HTTP semplice viene rifiutato ovunque tranne che in loopback, che dalla rete di stabilimento è irraggiungibile ed esiste solo per le prove interne al processo.

Certificati

L'ammissione avviene con TLS reciproco: il server dimostra chi è con il proprio certificato, e ogni gateway deve dimostrare chi è con un certificato client.

Certificato del server. Il server di rete presenta un certificato firmato dalla radice propria di questa stazione, la stessa su cui si appoggia il sistema centrale OCPP. La radice viene creata una volta per profilo, al primo avvio di uno dei due server, e conservata nella cartella dati dell'applicazione:

• GanterLabConnector.pfx, sotto ua\pki\own\private: la chiave privata, cifrata con una password casuale a sua volta protetta per utente Windows (DPAPI), così la coppia di file non si apre per nessuno se copiata altrove.
• GanterLabConnector-<station>.pem, sotto ua\pki\station: il certificato radice pubblico. È il file che si installa sul gateway come tc.trust perché si fidi di questa stazione.

Il soggetto della radice è Ganter Lab Connector (<station>), dove <station> è il nome di rete nel giorno in cui è stata creata, e non scade. La sua metà pubblica si installa su ogni concentratore una volta, a mano, quindi una radice che scadesse metterebbe fuori uso l'intera rete di sensori nel giorno del suo anniversario, rifiutata al concentratore dove questa stazione non vede nulla, e costerebbe una visita a ogni concentratore per rimetterla in funzione. Non c'è alcun avviso di scadenza né comando di rinnovo, perché non c'è nulla da rinnovare; la scheda Certificato radice della stazione, nella pagina del driver, mostra la data che porta come sola lettura (Valido fino al), con il percorso completo del file pubblico e un pulsante Apri la cartella che lo mostra in Esplora file di Windows (nella finestra della stazione stessa; in un browser su un altro dispositivo il pulsante resta in grigio e dice perché).

Il certificato che il server di rete presenta sotto quella radice riporta il nome di rete della stazione (il « Nome di rete » della configurazione del server OPC UA integrato; il nome del computer finché è vuoto), localhost e ogni indirizzo IPv4 della stazione, perciò un gateway che verifica il nome del server lo accetta. Rinominare il computer, cambiare il nome di rete o cambiare gli indirizzi della stazione non sostituisce la radice: viene emesso di nuovo, da solo, soltanto il certificato sotto di essa, senza nulla da fare sui concentratori.

La radice viene creata di nuovo solo quando quella memorizzata non si può più aprire, per esempio perché è stata scritta da un altro account Windows. In quel caso, e al primo avvio di questa versione su una stazione che può aver già dato un file precedente ai concentratori, la pagina del driver dice, una volta, sotto I concentratori hanno bisogno del nuovo file di certificato, che a ogni concentratore va consegnato il nuovo GanterLabConnector-<station>.pem come tc.trust. Finché non lo si fa, non riescono a connettersi.

Certificato client del gateway. Ogni gateway deve presentare un certificato client durante l'handshake TLS; un handshake senza viene lasciato cadere prima che passi alcun dato. Il certificato deve:

1. Essere attendibile in uno di due modi: costruisce una catena valida su questa macchina Windows, fino a una radice installata lì; oppure proprio questo certificato è stato approvato in Accesso delle apparecchiature sulla pagina di questo driver (più sotto). In entrambi i casi deve essere entro le sue date di validità. Un controllo fallito rifiuta la connessione, e il diario registra quale controllo è fallito.
2. Portare l'EUI della stazione del gateway nel proprio common name di soggetto oppure in un nome alternativo di soggetto DNS. L'identificatore viene letto come valore, quindi AABBCCDDEEFF0011, AA-BB-CC-DD-EE-FF-00-11 e AA:BB:CC:DD:EE:FF:00:11 nominano tutti la stessa stazione.
3. Nominare la stessa stazione che la connessione dati dichiara di essere: un certificato che nomina un gateway diverso da quello dell'indirizzo di connessione viene rifiutato.

Accesso delle apparecchiature

Un gateway il cui certificato non è garantito da nessuna radice installata in Windows, perché è autofirmato o emesso dall'autorità del produttore stesso, non ha bisogno che quella radice sia installata su questo computer. La sua prima connessione viene rifiutata, e il suo certificato attende in Accesso delle apparecchiature, in fondo alla pagina del driver LoRaWAN, la stessa scheda della pagina del driver OPC UA, fino a una decisione:

Ogni certificato viene approvato a sé, mai l'autorità che lo ha firmato: un secondo gateway dello stesso produttore attende quindi la propria approvazione. Confrontare l'impronta con quella indicata dal gateway prima di approvarlo. L'approvazione non cambia quale gateway sia il certificato: resta ammesso solo sotto l'EUI della stazione che porta, e solo entro le sue date di validità. Un certificato che Windows considera già attendibile viene ammesso come prima e non compare mai qui; nulla viene approvato automaticamente.

Le decisioni sono conservate nella cartella dei dati della stazione, in ua\pki\lorawan, e sopravvivono a un riavvio. I comandi vengono disegnati solo per un ruolo che può configurare il Connector, e agiscono solo nella finestra della stazione stessa: un browser su un altro dispositivo legge la scheda senza modificarla, e nessuno strumento di un agente approva un certificato. L'elenco tiene fino a 100 certificati in attesa di approvazione; quando è pieno, uno nuovo resta rifiutato ma non viene elencato, e la scheda lo dice.

Campi di connessione

Un dispositivo LoRaWAN non ha un host o una porta propri: un sensore si raggiunge attraverso qualunque concentratore porti il suo traffico radio, e un concentratore raggiunge questa stazione. Il pannello mostra prima il selettore della registrazione, poi i campi di cui quella registrazione ha bisogno.

Un dispositivo il cui DevEUI (sensore) o EUI della stazione (concentratore) è ancora vuoto, come uno appena aggiunto, lo aspetta. La stazione non lo registra sul server di rete e non tenta alcuna connessione, la sua riga nell'albero e l'avviso in cima alla sua pagina dicono « DevEUI non ancora inserito » o « EUI della stazione non ancora inserito » invece di mostrare un errore, Riconnetti non ha nulla da riaprire, e il suo stato di salute resta Non ancora noto. Inserisci l'identificatore nella scheda Connessione e la stazione registra il dispositivo. Un dispositivo salvato con l'identificatore vuoto e chiamato con il suo EUI (sedici cifre esadecimali, senza separatori) non aspetta: si registra con il suo nome, come ha sempre fatto.

La chiave applicativa è un segreto e la stazione la tratta come tale. Il pannello la nasconde dietro i pallini, con una casella Mostra la password che la scopre mentre si controlla quello che è stato scritto; il database di configurazione la conserva protetta sotto l'account Windows che l'ha inserita; e non compare né nel diario né nell'indirizzo che il driver legge, il quale porta soltanto il DevEUI. Apri la stessa configurazione sotto un altro account Windows e la chiave non si apre con essa: il campo torna vuoto, dicendo "Non è leggibile su questo account Windows: si apre solo sulla macchina e sull'account Windows che l'hanno inserito. Reinserirlo qui.", e il sensore smette di entrare in rete finché non reinserisci la chiave. Una configurazione portata via in un backup la mantiene, perché il backup è sigillato con la password che gli dai.

L'ingresso in rete è solo OTAA: il sensore compie un ingresso via radio attraverso il concentratore, e il server di rete gli risponde usando l'AppKey configurata. Una richiesta di ingresso da un DevEUI che nessun dispositivo configurato porta viene rifiutata e registrata nel diario. L'attivazione per personalizzazione (ABP, con chiavi di sessione preimpostate) non è supportata. La sessione di un sensore appartiene a questa stazione, non al concentratore che ne ha inoltrato l'ingresso in rete: con più di un concentratore a portata, i suoi uplink arrivano attraverso quello che li sente, e un concentratore che cade o viene tolto non si porta via nessun sensore.

Disabilitare o eliminare un dispositivo lo toglie subito dal server di rete, senza aspettare un riavvio: la sua chiave lascia il registro, la sessione che teneva su questa stazione viene rilasciata, e il suo ingresso successivo viene rifiutato. Disabilitare o eliminare un concentratore chiude anche subito la sua connessione, e i sensori che inoltrava mantengono le loro sessioni.

Una registrazione che il server non accetta non viene fatta affatto: un DevEUI o un EUI della stazione che è inserito e non è di 16 cifre esadecimali, una chiave applicativa che manca o che non è di 32 cifre esadecimali, oppure una regione che questa stazione non sa configurare. Il dispositivo si legge come non connesso, la sua riga nell'albero e il testo rosso sotto l'intestazione della sua pagina nominano il campo rifiutato e ciò che deve contenere, e il diario tecnico conserva la stessa riga. Il server di rete non viene avviato per lui, e la stazione non ritenta la stessa registrazione: è la correzione del campo a riportare il dispositivo, e Riconnetti risponde con lo stesso rifiuto.

Lo stato di salute del concentratore

Un concentratore non porta tag, quindi nessuna lettura può dire se c'è. Il suo stato di salute, il punto sulla sua riga nell'albero e la colonna Stato di salute nella pagina del driver, è se il suo gateway è connesso a questa stazione:

Per al massimo dieci secondi dopo che una modifica al concentratore viene salvata, o che il Connector si avvia, si legge Non ancora noto: registrarlo di nuovo chiude la connessione del gateway, e il gateway impiega un momento a riconnettersi. I sensori conservano il proprio stato di salute, dalle loro letture, qualunque sia quello del concentratore: con più di un concentratore a portata, quello che cade lascia gli altri a consegnare.

Che cosa viene inviato al concentratore

Quando un concentratore registrato termina il proprio handshake di versione, questa stazione risponde con la configurazione radio della sua regione: l'intervallo di frequenza, le velocità di trasmissione e quali di esse sono solo in discesa, e il piano di canali predefinito della regione. Se l'EUI della stazione non è registrato qui, non viene inviato nulla, e il diario dice quale stazione ha chiesto e che non è registrata. È questa la voce da cercare quando un concentratore si collega e nessun sensore dietro di lui riferisce mai un valore.

Non ci sono campi per l'intervallo di interrogazione. LoRaWAN funziona a spinta: è il sensore a decidere quando fa un uplink, il server conserva i payload decodificati più recenti per ogni dispositivo, e i valori dei tag si aggiornano da quella cache su un ciclo fisso di un secondo.

Un sensore che non ha ancora fatto un uplink non ha quindi alcuna lettura, non una lettura fallita. I tag restano vuoti, il dispositivo riferisce che non è stato osservato nulla invece di andare non connesso, e nel diario non viene registrato alcun fallimento: aspettare il primo uplink è il protocollo che funziona. Un indirizzo che non risolve nulla dentro un payload che il sensore ha invece inviato è un'altra cosa, e viene riferito per la lettura fallita che è.

Quando un sensore ammutolisce

Poiché nulla interroga un sensore, il payload che ha inviato per ultimo resta in quella cache finché non ne invia un altro. Lasciato a sé, un sensore la cui batteria si è esaurita continuerebbe a pubblicare lo stesso numero come lettura buona per tutto il tempo in cui la stazione gira, alimentando grafici, storici e allarmi con un valore che ha smesso di essere vero.

Ogni sensore porta quindi un tempo massimo senza trasmissione, in secondi, nel proprio pannello. Il valore predefinito è 3600 secondi, un'ora, che copre con margine la cadenza da dieci a trenta minuti di un sensore comune; un sensore che riferisce più di rado alza il proprio. Superata quella scadenza:

• I suoi tag smettono di portare un valore e pubblicano cattiva qualità, invece di ripetere l'ultimo uplink.
• Il pannello del dispositivo dice quando il sensore ha trasmesso l'ultima volta, così si vede da quanto tempo è muto.

Mettere il campo a 0 disattiva la scadenza per quel sensore: il suo ultimo uplink continua a valere come buono a tempo indeterminato. Nient'altro cambia, e nessun payload memorizzato viene scartato.

Indirizzamento dei tag

Un tag LoRaWAN indirizza byte dentro il payload decodificato dell'uplink. Non c'è alcun indirizzo a testo libero; la scheda Sorgente offre campi tipizzati in due modi, commutati dalla casella di spunta Indirizza per canale/tipo Cayenne LPP:

L'ordine delle operazioni a ogni lettura è: prendere i byte indirizzati → applicare la maschera di bit → rovesciare se il byte più significativo viene per primo → convertire nel tipo di dato del tag → applicare il moltiplicatore (tipi numerici).

Esempi, per un sensore il cui payload di 11 byte porta una temperatura Int16 big-endian allo scostamento 2:

• Modo scostamento: canale/scostamento 2, lunghezza di lettura 2, byte più significativo per primo attivo.
• Modo LPP, stesso sensore che parla Cayenne LPP sul canale 1 con il tipo 103: spunta la casella LPP, canale 1, codice di tipo 103, lunghezza di lettura 2.

Tipi di dato supportati

Scritture e rilevamento

I tag LoRaWAN sono di sola lettura: i valori arrivano solo dagli uplink dei sensori, il campo dell'accesso non offre alcuna scelta scrivibile, e il runtime rifiuta una scrittura invece di fingere che sia riuscita. I downlink esistono nel protocollo come traffico di rete (accettazioni di ingresso, comandi MAC), mai come scritture di valore su un tag.

Il driver non ha alcuna scansione di rilevamento. Aggiungi a mano il concentratore con il suo EUI della stazione e la sua regione, e ogni sensore a mano con il suo DevEUI e la sua AppKey; il flusso generale per aggiungere un dispositivo è descritto nella pagina Connector.