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.

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 che hai scelto; non c'è alcun testo di configurazione da incollare.

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. Generato automaticamente al primo avvio e memorizzato nella cartella dei dati dell'applicazione sotto ua\pki\own\private:

• GanterLabOPCUAServer-with-san.pfx: la chiave privata, cifrata con una password casuale che è a sua volta protetta per utente di Windows (DPAPI), così la coppia di file non si apre per nessuno se viene copiata altrove.
• GanterLabOPCUAServer-with-san.pem: il certificato pubblico. È il file che si installa sul gateway perché si fidi di questa stazione.

Il certificato è autofirmato e non scade. La sua metà pubblica si installa a mano su ogni concentratore una volta sola, quindi un certificato scaduto porterebbe giù tutta la rete di sensori nel suo anniversario, rifiutato al concentratore dove questa stazione non vede nulla, e costerebbe una visita a ogni concentratore per rimetterla in piedi. Non c'è alcun avviso di scadenza e alcun comando di rinnovo, perché non c'è nulla da rinnovare; la pagina del driver mostra come lettura la data che porta.

Viene riscritto solo in due casi, ed entrambi lo dicono nel diario:

• Il file memorizzato non si riesce più ad aprire, per esempio perché è stato scritto da un altro account Windows.
• È stato emesso da una versione precedente di questa applicazione, che gli dava 12 mesi.

In entrambi i casi la pagina del driver dice, una volta, che a ogni concentratore va consegnato il nuovo GanterLabOPCUAServer-with-san.pem. 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. Costruire una catena valida su questa macchina Windows (gli errori di catena, come una radice non attendibile, rifiutano 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.

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 identificatore lasciato vuoto ricade sul nome ripulito del dispositivo, che non è quasi mai un EUI valido: compilalo.

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 controlli quello che hai 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.

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 un qualunque concentratore teneva per lui viene rilasciata, e il suo ingresso successivo viene rifiutato. Una registrazione che il server non accetta, un DevEUI, una chiave applicativa, un EUI della stazione o una regione scritti male, lasciano il dispositivo che si legge come non connesso, e il diario nomina il campo che è stato rifiutato.

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 Origine 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.