# 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 {#prepare-the-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:

| Che cosa configurare sul gateway | Che cosa dà la scheda |
|---|---|
| Indirizzo dell'LNS (il `tc.uri` di Basics Station) | `wss://<indirizzo>:5001`, prima con l'indirizzo dato dal nome di questa stazione (il « Nome di rete » della configurazione del server OPC UA integrato, o il nome del computer finché è vuoto), poi una volta per ogni indirizzo IPv4 che questa stazione ha su una rete, ciascuno con un pulsante di copia. Un gateway che verifica il nome del server, come fa Basics Station di default (`TLS_SNI`), ha bisogno dell'indirizzo dato dal nome; uno che non lo verifica accetta uno qualsiasi, e allora basta quello della sua rete. |
| EUI della stazione | L'EUI della stazione del concentratore, con un pulsante di copia: l'identità con cui questo dispositivo registra il gateway. Ogni gateway è un dispositivo concentratore a sé. Finché è vuoto, la scheda dice di inserirlo nella scheda Connessione. |
| Certificato client (`tc.crt`, con la sua chiave in `tc.key`) | TLS reciproco: il gateway presenta un certificato client che riporta il suo EUI della stazione nel nome comune o in un nome alternativo DNS (vedere [Certificati](#certificates)). |
| Certificato del server di cui fidarsi (`tc.trust`) | Il percorso completo di `GanterLabConnector-<station>.pem`, il certificato radice di questa stazione, con il pulsante **Apri la cartella**, che mostra il file in Esplora file di Windows. Il pulsante funziona nella finestra della stazione stessa; in un browser su un altro dispositivo resta in grigio e dice perché. Il file viene scritto al primo avvio del server di rete, e fino ad allora la scheda lo dice. |

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](#equipment-access). 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 {#network-server-and-ports}

| Che cosa | Valore |
|---|---|
| Protocollo | LoRa Basics Station (WebSocket, JSON) |
| Ascolto | Tutte le interfacce, porta TCP **5001**, solo TLS |
| Indirizzo del gateway | `wss://<station-address>:5001` |
| Endpoint di rilevamento | La richiesta `router-info` di Basics Station viene servita sullo stesso ascolto |
| Connessione dati | Indirizzata dall'EUI della stazione del gateway come ultima parte del percorso WebSocket |

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 {#certificates}

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 {#equipment-access}

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:

| Gruppo | Che cosa elenca | Che cosa si può fare |
|---|---|---|
| In attesa di approvazione | Ogni certificato rifiutato, sotto l'EUI della stazione che porta: la sua impronta SHA-256, l'ultimo tentativo e quanti tentativi, e i suoi dettagli (soggetto, emittente, nomi di dominio, date di validità). | **Approva** ammette il certificato dalla prossima connessione del gateway. **Blocca** continua a rifiutarlo senza elencarlo di nuovo qui. **Scarta tutti i certificati in attesa** svuota l'elenco senza approvare né bloccare nulla. |
| Apparecchiature approvate | I certificati approvati o importati, con chi ha deciso e quando. | **Ritira l'approvazione** chiude la connessione del gateway e riporta il suo certificato nell'elenco. **Importa certificato** approva il certificato pubblico di un gateway prima della sua prima connessione. |
| Apparecchiature bloccate | I certificati bloccati. Un certificato bloccato viene rifiutato anche se Windows lo considera attendibile. | **Sblocca** riporta il certificato nell'elenco, senza approvarlo. |

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 {#connection-fields}

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.

| Campo | Che cos'è | Formato | Predefinito |
|---|---|---|---|
| Registrato come | Quale delle due registrazioni è questo dispositivo: **Sensore** oppure **Concentratore radio**. Cambiarlo svuota il campo sottostante, perché una chiave applicativa e una regione non sono la stessa cosa. | Sensore / Concentratore radio | Sensore |
| DevEUI del sensore | Il DevEUI del sensore, l'identità che presenta nella sua richiesta di ingresso in rete. | 16 cifre esadecimali, nude (`8899AABBCCDDEEFF`), con i trattini (`88-99-AA-BB-CC-DD-EE-FF`) oppure con i due punti. | vuoto |
| Chiave applicativa (sensore) | La chiave applicativa OTAA del sensore (AppKey). Autentica l'ingresso in rete e ne deriva le chiavi di sessione. | Esattamente 32 cifre esadecimali, senza separatori. | vuoto |
| EUI della stazione (concentratore) | L'EUI della stazione del concentratore, lo stesso identificatore che il suo certificato client deve portare e quello che mette nel proprio indirizzo di connessione. | 16 cifre esadecimali, in una qualunque delle grafie qui sopra. | vuoto |
| Regione radio (concentratore) | Dove si trova il concentratore. Decide i canali, le velocità di trasmissione e le finestre di ricezione che questa stazione gli passa alla connessione. Si sceglie dall'elenco; non c'è testo libero. | Europa 868 MHz, Stati Uniti 915 MHz, Australia 915 MHz, Asia 923 MHz, Cina 470 MHz (revisione 1), Cina 470 MHz (revisione 2) | Europa 868 MHz |
| Tempo massimo senza trasmissione (sensore) | I secondi per cui questo sensore può restare muto prima che i suoi valori memorizzati smettano di contare come letture. 0 disattiva la scadenza. Vedi qui sotto. | 0 o più | 3600 |

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 {#the-concentrators-health}

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:

| Situazione | Stato di salute |
|---|---|
| EUI della stazione ancora vuoto | **Non ancora noto**: non è registrato nulla |
| Registrato, il gateway non ancora connesso (il suo certificato ancora in attesa di approvazione, per esempio) | **Non connesso** |
| Il gateway connesso | **Connesso** |
| Il gateway caduto: fermato, staccato o isolato dalla rete | **Non connesso**, finché non si riconnette |
| Disabilitato | **Disabilitato** |

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 {#what-the-concentrator-is-sent}

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 {#when-a-sensor-goes-quiet}

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 {#tag-addressing}

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**:

| Campo | Che cosa fa | Valori | Predefinito |
|---|---|---|---|
| Indirizza per canale/tipo Cayenne LPP | Disattivo: il campo del canale è un semplice scostamento in byte. Attivo: il payload viene esaminato in cerca di una coppia canale/tipo Cayenne LPP. | attivo / disattivo | disattivo |
| Canale / scostamento nel payload | Modo scostamento: lo scostamento in byte, in base 0, da cui il valore comincia. Modo LPP: il numero di canale LPP da cercare. | 0 o più | 0 |
| Codice di tipo LPP | Solo nel modo LPP: il byte di tipo di dato Cayenne LPP che segue il byte del canale (per esempio 103 per la temperatura). I byte del valore vengono letti subito dopo la coppia canale/tipo corrispondente, e quando corrispondono più payload vince il più recente. | 0 o più | 0 |
| Lunghezza di lettura (byte, vuoto = automatico) | Quanti byte del payload compongono il valore. Vuoto la ricava dal tipo di dato: 1 per Boolean e Byte, 2 per Int16, 4 per Int32 e Float, 16 per String. | 1 o più, oppure vuoto | vuoto |
| Maschera di bit (esadecimale, vuoto = nessuna) | Una maschera esadecimale messa in AND sui byte grezzi prima di ogni altra cosa (per esempio `0x0FFF` per far cadere i bit di stato). Il prefisso `0x` è facoltativo e una maschera di lunghezza dispari viene riempita a sinistra. La maschera deve coprire esattamente tanti byte quanti ne legge la lunghezza di lettura, altrimenti la lettura va in errore. | testo esadecimale oppure vuoto | vuoto |
| Byte più significativo per primo (MSB first, big-endian) | Dichiara che il payload porta il valore in big-endian; i byte letti vengono rovesciati prima della conversione. Qui non c'è alcuna casella per l'ordine delle parole: un payload di lunghezza arbitraria non ha parole a 16 bit da scambiare. | attivo / disattivo | disattivo |
| Moltiplicatore (vuoto = nessuno) | Un fattore lato bus applicato dal server di rete subito dopo la decodifica, prima che il valore entri nella catena di conversione propria del tag. Vale solo per i tipi numerici. Uno 0 viene rifiutato dove viene scritto (« Un moltiplicatore pari a 0 azzererebbe ogni lettura. »), perché riferirebbe ogni lettura del tag come 0 con qualità buona. | qualunque numero diverso da 0, oppure vuoto | vuoto |

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 {#supported-data-types}

| Tipo | Byte letti (automatico) | Come vengono interpretati i byte |
|---|---|---|
| Boolean | 1 | Zero è false, qualunque altra cosa true |
| Byte | 1 | Byte senza segno |
| Int16 | 2 | Intero con segno a 16 bit |
| Int32 | 4 | Intero con segno a 32 bit |
| Float | 4 | IEEE 754 a precisione singola |
| String | 16 | Testo UTF-8 della lunghezza di lettura |

## Scritture e rilevamento {#writes-and-discovery}

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](connector).