# LoRaWAN

> Referencia del driver LoRaWAN: el servidor de red Basics Station integrado, los certificados de la puerta de enlace, los registros de sensor y de concentrador, y el direccionamiento de la carga útil.

El driver LoRaWAN convierte a Ganter Lab en un pequeño **servidor de red LoRaWAN**. El
sentido de la relación es el contrario al de casi todos los drivers: la estación no sale a
buscar un sensor, sino que **la puerta de enlace se conecta a Ganter Lab**, y los sensores
entregan sus lecturas como enlaces ascendentes a través de esa puerta de enlace. Ganter Lab
integra un servidor de red que habla el protocolo **LoRa Basics Station** de Semtech, así
que cualquier puerta de enlace con firmware Basics Station puede usar esta estación como su
LNS.

El servidor integrado arranca cuando el primer dispositivo LoRaWAN activado se carga en el
connector en marcha, no al arrancar la aplicación, y se detiene cuando se quita o se
desactiva el último: sin ningún sensor y sin ningún concentrador configurados, no hay nada
escuchando en el puerto. Agregar uno lo trae de vuelta, sin reiniciar la aplicación.

Cada dispositivo bajo el driver es uno de **dos registros**, elegido en su panel:

- Un **sensor de campo**, identificado por su DevEUI y admitido con su clave de aplicación.
  Sus tags descodifican la carga útil del enlace ascendente.
- Un **concentrador de radio** (la puerta de enlace), identificado por su EUI de estación y
  registrado en una **región de radio** elegida de una lista. No lleva tags propios: su página mantiene **Agregar tag** en gris, con el motivo, hasta que el dispositivo se registre como sensor de campo.

Registre el concentrador además de los sensores. Un concentrador Basics Station pide su
configuración de radio en cuanto se conecta y no retransmite absolutamente nada hasta que
se le contesta, así que una estación que nunca ha visto su EUI de estación deja sin valor a
todos los sensores que hay detrás de él mientras la conexión misma se ve sana. La respuesta
se arma aquí a partir de la región que usted eligió; no hay ningún texto de configuración
que pegar.

## Preparar la puerta de enlace {#prepare-the-gateway}

La puerta de enlace es quien llama a esta estación, mediante LoRa Basics Station, y de
fábrica no sabe dónde está. La página de cada dispositivo registrado como
concentrador de radio trae la tarjeta **Preparar la puerta de enlace** con lo que hay que
indicar en la configuración de Basics Station de la puerta de enlace, escrito para esta
estación:

| Qué configurar en la puerta de enlace | Qué da la tarjeta |
|---|---|
| Dirección del LNS (el `tc.uri` de Basics Station) | `wss://<dirección>:5001`, primero con la dirección por el nombre de esta estación (el "Nombre de red" de la configuración del servidor OPC UA integrado, o el nombre de la computadora mientras está vacío), luego una vez por cada dirección IPv4 que esta estación tiene en una red, cada una con un botón de copiar. Una puerta de enlace que verifica el nombre del servidor, como hace Basics Station de fábrica (`TLS_SNI`), necesita la dirección por el nombre; una que no lo verifica acepta cualquiera de ellas, y entonces basta la de su propia red. |
| EUI de la estación | El EUI de la estación del concentrador, con un botón de copiar: la identidad con la que este dispositivo registra la puerta de enlace. Cada puerta de enlace es un dispositivo concentrador propio. Mientras está vacío, la tarjeta dice que se indique en la tarjeta Conexión. |
| Certificado de cliente (`tc.crt`, con su clave en `tc.key`) | TLS mutuo: la puerta de enlace presenta un certificado de cliente que lleva su EUI de la estación en el nombre común o en un nombre alternativo DNS (consulte [Los certificados](#certificates)). |
| Certificado del servidor en el que confiar (`tc.trust`) | La ruta completa de `GanterLabConnector-<station>.pem`, el certificado raíz de esta estación, con el botón **Abrir la carpeta**, que muestra el archivo en el explorador de archivos de Windows. El botón funciona en la ventana de la propia estación; en un navegador de otro equipo queda en gris y dice por qué. El archivo se escribe la primera vez que arranca el servidor de red, y hasta entonces la tarjeta lo dice. |

La tarjeta está abierta mientras la puerta de enlace no se conecta desde que se abrió la
estación, y se pliega cuando se conecta: se queda en la página para la próxima vez
que se configure la puerta de enlace. Una puerta de enlace cuyo certificado no avala ninguna raíz
instalada en Windows se rechaza en su primera conexión y espera en
[Acceso a los equipos](#equipment-access). Una puerta de enlace que solo habla el protocolo
Semtech UDP packet forwarder no puede conectarse: necesita un firmware Basics Station.

El archivo es el mismo para todas las puertas de enlace de esta estación, y no cambia cuando
cambian el nombre o las direcciones de la estación. Una puerta de enlace con la configuración
de fábrica de Basics Station acepta la estación: no hay que desactivar nada en su
configuración.

**Toda puerta de enlace que recibió un archivo de una versión anterior necesita este,
instalado una vez como `tc.trust`.** En el primer arranque de esta versión, una estación
cuyas puertas de enlace pueden tener un archivo anterior muestra en la tarjeta un aviso,
**El archivo de esta estación cambió**, solo en esa ejecución. El aviso es un recordatorio,
no la instrucción: instale el archivo nuevo una vez en cada puerta de enlace de una estación
que ya tenía puertas de enlace, muestre o no la tarjeta el aviso.

## El servidor de red y los puertos {#network-server-and-ports}

| Qué | Valor |
|---|---|
| Protocolo | LoRa Basics Station (WebSocket, JSON) |
| Escucha | Todas las interfaces, puerto TCP **5001**, solo TLS |
| Dirección de la puerta de enlace | `wss://<dirección-de-la-estación>:5001` |
| Endpoint de descubrimiento | La petición `router-info` de Basics Station se sirve en la misma escucha |
| Conexión de datos | Direccionada por el EUI de estación de la puerta de enlace, como última parte de la ruta del WebSocket |

La escucha siempre es TLS. No hay ningún ajuste que apague el cifrado: una escucha por HTTP
sin cifrar se rechaza en cualquier lugar que no sea loopback, que es inalcanzable desde la
red de planta y existe solo para las pruebas dentro del proceso.

## Los certificados {#certificates}

La admisión es por TLS mutuo: el servidor demuestra quién es con su propio certificado, y
cada puerta de enlace tiene que demostrar quién es con un certificado de cliente.

**Certificado del servidor.** El servidor de red presenta un certificado firmado por la raíz
propia de esta estación, la misma de la que depende el sistema central OCPP. La raíz se crea
una vez por perfil, la primera vez que arranca cualquiera de los dos servidores, y se guarda
en la carpeta de datos de la aplicación:

- `GanterLabConnector.pfx`, en `ua\pki\own\private`, la clave privada, cifrada con una
  contraseña aleatoria que a su vez está protegida por usuario de Windows (DPAPI), así que el
  par de archivos no se abre para nadie cuando se copia a otro lado.
- `GanterLabConnector-<station>.pem`, en `ua\pki\station`, el certificado raíz público. Este es
  el archivo que se instala en la puerta de enlace como `tc.trust` para que confíe en esta
  estación.

El sujeto de la raíz es `Ganter Lab Connector (<station>)`, donde `<station>` es el nombre de
red el día en que se creó, y **no vence**. Su mitad pública se instala una sola vez, a
mano, en cada concentrador, así que una raíz que se venciera tumbaría toda la red de
sensores en su aniversario, rechazada en el concentrador, donde esta estación no ve nada, y
costaría una visita a cada concentrador para recuperarla. No hay ningún aviso de
vencimiento ni ningún comando de renovación, porque no hay nada que renovar; la tarjeta
**Certificado raíz de la estación**, en la página del driver, muestra como lectura la fecha
que lleva (**Válido hasta**), con la ruta completa del archivo público y el botón **Abrir la
carpeta**, que lo muestra en el explorador de archivos de Windows (en la ventana de la propia
estación; en un navegador de otro equipo el botón queda en gris y dice por qué).

El certificado que el servidor de red presenta bajo esa raíz nombra el nombre de red de la
estación (el "Nombre de red" de la configuración del servidor OPC UA integrado; el nombre de
la computadora mientras está vacío), `localhost` y cada dirección IPv4 de la estación, así que
una puerta de enlace que verifica el nombre del servidor lo acepta. Cambiar el nombre de la
computadora, el nombre de red o las direcciones de la estación no reemplaza la raíz: solo se
emite de nuevo el certificado que está debajo, por sí solo, sin nada que hacer en los
concentradores.

La raíz se crea de nuevo solo cuando la guardada ya no se puede abrir, por ejemplo porque la
escribió otra cuenta de Windows. En ese caso, y en el primer arranque de esta versión en una
estación que ya pudo haber dado un archivo anterior a los concentradores, la página del driver
dice, una vez, bajo **Los concentradores necesitan el nuevo archivo de certificado**, que hay
que darle a cada concentrador el nuevo `GanterLabConnector-<station>.pem` como `tc.trust`.
Hasta que se les dé, no se pueden conectar.

**El certificado de cliente de la puerta de enlace.** Cada puerta de enlace tiene que
presentar un certificado de cliente durante el saludo TLS; un saludo sin él se tira antes
de que fluya ningún dato. El certificado tiene que:

1. Ser de confianza de una de dos maneras: forma una cadena válida en esta máquina
   Windows, hasta una raíz instalada en ella; o usted aprobó este mismo certificado en
   **Acceso a los equipos** en la página de este driver (más abajo). En los dos casos tiene
   que estar dentro de sus fechas de validez. Una verificación fallida rechaza la conexión,
   y el diario técnico registra qué verificación falló.
2. Llevar el **EUI de la estación** de la puerta de enlace en el nombre común de su sujeto o
   en un nombre alternativo de sujeto de tipo DNS. El identificador se lee como un valor,
   así que `AABBCCDDEEFF0011`, `AA-BB-CC-DD-EE-FF-00-11` y `AA:BB:CC:DD:EE:FF:00:11`
   nombran todos a la misma estación.
3. Nombrar a la **misma estación** que dice ser la conexión de datos: un certificado que
   nombre a otra puerta de enlace distinta de la que va en la dirección de conexión se
   rechaza.

### Acceso a los equipos {#equipment-access}

Una puerta de enlace cuyo certificado no avala ninguna raíz instalada en Windows, porque es
autofirmado o lo emitió la autoridad del propio fabricante, no necesita que esa raíz se
instale en esta computadora. Su primera conexión se rechaza, y su certificado espera en
**Acceso a los equipos**, al final de la página del driver LoRaWAN, la misma tarjeta que
lleva la página del driver OPC UA, hasta que usted decida:

| Grupo | Qué muestra | Qué puede hacer |
|---|---|---|
| A la espera de aprobación | Cada certificado rechazado, bajo el EUI de la estación que lleva: su huella digital SHA-256, cuándo lo intentó por última vez y cuántas veces, y sus detalles (sujeto, emisor, nombres de dominio, fechas de validez). | **Aprobar** admite el certificado a partir de la próxima conexión de la puerta de enlace. **Bloquear** lo sigue rechazando sin volver a listarlo aquí. **Descartar todos los certificados pendientes** vacía la lista sin aprobar ni bloquear nada. |
| Equipos aprobados | Los certificados que usted aprobó o importó, con quién decidió y cuándo. | **Retirar la aprobación** cierra la conexión de la puerta de enlace y devuelve su certificado a la lista. **Importar certificado** aprueba el certificado público de una puerta de enlace antes de su primera conexión. |
| Equipos bloqueados | Los certificados que usted bloqueó. Un certificado bloqueado se rechaza aunque Windows confíe en él. | **Desbloquear** devuelve el certificado a la lista, sin aprobarlo. |

Cada certificado se aprueba por sí mismo, nunca la autoridad que lo firmó, así que una
segunda puerta de enlace del mismo fabricante espera su propia aprobación. Compare la huella
digital con la que indica la puerta de enlace antes de aprobarlo. Aprobar no cambia qué
puerta de enlace es el certificado: se sigue admitiendo solo bajo el EUI de la estación que
lleva, y solo dentro de sus fechas de validez. Un certificado en el que Windows ya confía se
admite como antes y nunca aparece aquí; nada se aprueba de forma automática.

Las decisiones se guardan en la carpeta de datos de la estación, en `ua\pki\lorawan`, y
sobreviven a un reinicio. Solo a un rol que puede configurar el Connector se le dibujan los
comandos, y estos actúan solo en la ventana de la propia estación: un navegador en otro
dispositivo lee la tarjeta sin cambiarla, y ninguna herramienta de un agente aprueba un
certificado. La lista guarda hasta 100 certificados a la espera de aprobación; cuando está
llena, uno nuevo se sigue rechazando pero no se lista, y la tarjeta lo dice.

## Los campos de conexión {#connection-fields}

Un dispositivo LoRaWAN no tiene host ni puerto propios: a un sensor se llega por el
concentrador que lleve su tráfico de radio, y un concentrador llega hasta esta estación. El
panel muestra primero el selector de registro, y luego los campos que ese registro necesita.

| Campo | Qué es | Formato | Valor inicial |
|---|---|---|---|
| Registrado como | Cuál de los dos registros es este dispositivo: **Sensor de campo** o **Concentrador de radio**. Cambiarlo borra el campo de abajo, porque una clave de aplicación y una región no son lo mismo. | Sensor de campo / Concentrador de radio | Sensor de campo |
| Identificador DevEUI (sensor) | El DevEUI del sensor, la identidad que presenta en su petición de unión. | 16 dígitos hexadecimales, simples (`8899AABBCCDDEEFF`), con guiones (`88-99-AA-BB-CC-DD-EE-FF`) o con dos puntos. | vacío |
| Clave de aplicación (sensor) | La clave de aplicación OTAA del sensor (AppKey). Autentica la unión y deriva las claves de sesión. | Exactamente 32 dígitos hexadecimales, sin separadores. | vacía |
| EUI de la estación (concentrador) | El EUI de estación del concentrador, el mismo identificador que tiene que llevar su certificado de cliente y el que pone en su dirección de conexión. | 16 dígitos hexadecimales, en cualquiera de las grafías de arriba. | vacío |
| Región de radio (concentrador) | Dónde está parado el concentrador. Decide los canales, las tasas de datos y las ventanas de recepción que esta estación le entrega al conectarse. Se elige de la lista; no hay texto libre. | Europa 868 MHz, Estados Unidos 915 MHz, Australia 915 MHz, Asia 923 MHz, China 470 MHz (revisión 1), China 470 MHz (revisión 2) | Europa 868 MHz |
| Tiempo máximo sin transmisión (sensor) | Los segundos que este sensor puede quedarse callado antes de que sus valores guardados dejen de contar como lecturas. 0 desactiva el vencimiento. Vea más abajo. | 0 o mayor | 3600 |

Un dispositivo cuyo DevEUI (sensor) o EUI de la estación (concentrador) sigue vacío, como
uno recién agregado, lo espera. La estación no lo registra en el servidor de red y no se
intenta ninguna conexión, su fila en el árbol y el aviso de lo alto de su página dicen
"DevEUI aún sin indicar" o "EUI de la estación aún sin indicar" en lugar de mostrar un
error, **Reconectar** no tiene nada que reabrir, y su estado de salud sigue en Aún sin
determinar. Llene el identificador en la tarjeta Conexión y la estación registra el
dispositivo. Un dispositivo guardado con el identificador vacío y llamado con su EUI
(dieciséis dígitos hexadecimales, sin separadores) no espera: se registra con su nombre,
como siempre lo ha hecho.

La clave de aplicación es un secreto y la estación la maneja como tal. El panel la
oculta detrás de puntos, con una casilla **Mostrar la contraseña** que la muestra
mientras usted revisa lo que escribió; la base de datos de configuración la guarda
protegida bajo la cuenta de Windows que la ingresó; y no aparece ni en el diario ni en la
dirección que lee el controlador, que solo lleva el DevEUI. Abra la misma configuración
con otra cuenta de Windows y la clave no se abre con ella: el campo regresa vacío,
diciendo "No se puede leer en esta cuenta de Windows: solo se abre en la computadora y en
la cuenta de Windows que lo ingresó. Vuelva a ingresarlo aquí.", y el sensor deja de
unirse hasta que usted teclee la clave otra vez. Una configuración que se lleva en una
copia de seguridad la conserva, porque la copia va sellada con la contraseña que usted le
pone.

La unión es **solo OTAA**: el sensor hace una unión por aire a través del concentrador,
y el servidor de red se la contesta con la AppKey configurada. Una petición de unión de
un DevEUI que ningún dispositivo configurado lleva se rechaza y se registra. La
activación por personalización (ABP, con claves de sesión preaprovisionadas) no se
admite. La sesión de un sensor pertenece a esta estación, no al concentrador que
retransmitió su unión: con más de un concentrador al alcance, sus enlaces ascendentes
llegan por el que los escuche, y un concentrador que se cae o se quita no se lleva
ningún sensor con él.

Desactivar o eliminar un dispositivo lo saca del servidor de red de inmediato, sin
esperar a un reinicio: su clave sale del registro, la sesión que tenía en esta estación
se libera, y su siguiente unión se rechaza. Desactivar o eliminar un concentrador
también cierra su conexión de inmediato, y los sensores que retransmitía conservan sus
sesiones.

Un registro que el servidor no acepta no llega a hacerse: un DevEUI o un EUI de estación
que está indicado y no tiene 16 dígitos hexadecimales, una clave de aplicación que falta o que no tiene
32 dígitos hexadecimales, o una región que esta estación no sabe configurar. El
dispositivo se lee como no conectado, su fila en el árbol y el texto rojo bajo el
encabezado de su página nombran el campo que se rechazó y lo que tiene que contener, y
el diario técnico guarda la misma línea. El servidor de red no se inicia por él, y la
estación no vuelve a intentar el mismo registro: corregir el campo es lo que trae de
regreso al dispositivo, y **Reconectar** responde con el mismo rechazo.

### El estado de salud del concentrador {#the-concentrators-health}

Un concentrador no lleva tags, así que ninguna lectura puede decir si está ahí. Su estado de
salud, el punto en su fila del árbol y la columna **Estado de salud** en la página del
driver, es si su puerta de enlace está conectada a esta estación:

| Situación | Estado de salud |
|---|---|
| EUI de la estación todavía vacío | **Aún sin determinar**: no hay nada registrado |
| Registrado, la puerta de enlace todavía sin conectarse (su certificado aún esperando aprobación, por ejemplo) | **Sin conexión** |
| La puerta de enlace conectada | **En línea** |
| La puerta de enlace se cayó: detenida, desenchufada o aislada de la red | **Sin conexión**, hasta que vuelva a conectarse |
| Desactivado | **Desactivado** |

Durante hasta diez segundos después de guardar un cambio en el concentrador, o de que el
Connector arranque, se lee **Aún sin determinar**: registrarlo de nuevo cierra la conexión
de la puerta de enlace, y la puerta de enlace tarda un momento en volver a conectarse. Los
sensores conservan su propio estado de salud, por sus lecturas, sea cual sea el del
concentrador: con más de un concentrador al alcance, uno que se cae deja a los demás
entregando.

### Qué se le envía al concentrador {#what-the-concentrator-is-sent}

Cuando un concentrador registrado termina su saludo de versión, esta estación le contesta
con la configuración de radio de su región: el rango de frecuencias, las tasas de datos y
cuáles de ellas son solo de bajada, y el plan de canales predeterminado de la región. Si el
EUI de estación no está registrado aquí, no se envía nada, y el diario técnico dice qué
estación preguntó y que no está registrada. Esa es la entrada que hay que buscar cuando un
concentrador se conecta y ningún sensor de los que están detrás reporta jamás un valor.

No hay campos de intervalo de sondeo. LoRaWAN es de empuje: el sensor decide cuándo hace su
enlace ascendente, el servidor guarda las cargas útiles descodificadas más recientes de cada
dispositivo, y los valores de los tags se refrescan desde esa caché en un ciclo fijo de un
segundo.

Por eso un sensor que todavía no ha hecho ningún enlace ascendente **no tiene lectura**, no
tiene una lectura fallida. Los tags se quedan vacíos, el dispositivo reporta que no se ha
observado nada en lugar de irse sin conexión, y no se registra ninguna falla: esperar el
primer enlace ascendente es el protocolo funcionando. Una dirección que no resuelve a nada
dentro de una carga útil que el sensor sí mandó es otra cosa, y se reporta como la lectura
fallida que es.

### Cuando un sensor se queda callado {#when-a-sensor-goes-quiet}

Como nada sondea a un sensor, la carga útil que mandó por última vez se queda en esa caché
hasta que mande otra. Si se le deja solo, un sensor cuya batería se murió seguiría
publicando el mismo número como una lectura buena mientras la estación corra, alimentando
gráficas, histórico y alarmas con un valor que dejó de ser cierto.

Por eso cada sensor lleva un **tiempo máximo sin transmisión**, en segundos, en su propio
panel. El valor inicial son **3600 segundos**, una hora, que cubre con holgura la cadencia
de diez a treinta minutos de un sensor común; un sensor que reporta con menos frecuencia
sube el suyo. Pasado ese plazo:

- Sus tags dejan de llevar un valor y publican mala calidad, en lugar de repetir el último
  enlace ascendente.
- El panel del dispositivo dice cuándo transmitió el sensor por última vez, para que usted
  vea cuánto lleva callado.

Poner el campo en **0** desactiva el vencimiento de ese sensor: su último enlace ascendente
se sigue leyendo como bueno indefinidamente. Nada más cambia, y no se descarta ninguna carga
útil guardada.

## El direccionamiento del tag {#tag-addressing}

Un tag de LoRaWAN direcciona **bytes dentro de la carga útil descodificada del enlace
ascendente**. No hay dirección de texto libre; la tarjeta Fuente ofrece campos tipados en dos
modos, conmutados por la casilla **Direccionar por canal/tipo Cayenne LPP**:

| Campo | Qué hace | Valores | Valor inicial |
|---|---|---|---|
| Direccionar por canal/tipo Cayenne LPP | Apagada: el campo de canal es un desplazamiento simple en bytes. Encendida: la carga útil se recorre buscando un par canal/tipo de Cayenne LPP. | encendida / apagada | apagada |
| Canal / desplazamiento en la carga útil | En modo de desplazamiento: el desplazamiento en bytes, desde 0, en el que empieza el valor. En modo LPP: el número de canal LPP que se busca. | 0 o mayor | 0 |
| Código de tipo LPP | Solo en modo LPP: el byte de tipo de dato de Cayenne LPP que sigue al byte de canal (por ejemplo, 103 para temperatura). Los bytes del valor se leen justo después del par canal/tipo que coincida, y cuando coinciden varias cargas útiles gana la más nueva. | 0 o mayor | 0 |
| Longitud de lectura (bytes, en blanco = automático) | Cuántos bytes de la carga útil forman el valor. En blanco se deriva del tipo de dato: 1 para Boolean y Byte, 2 para Int16, 4 para Int32 y Float, 16 para String. | 1 o mayor, o en blanco | en blanco |
| Máscara de bits (hex, en blanco = ninguna) | Una máscara hexadecimal que se aplica con Y lógica sobre los bytes crudos antes que cualquier otra cosa (por ejemplo `0x0FFF` para tirar los bits de estado). El prefijo `0x` es opcional y una máscara de longitud impar se rellena por la izquierda. La máscara tiene que cubrir exactamente tantos bytes como la longitud de lectura; si no, la lectura da error. | texto hexadecimal o en blanco | en blanco |
| Byte más significativo primero (MSB first, big-endian) | Declara que la carga útil lleva el valor en big-endian; los bytes leídos se invierten antes de convertirlos. Aquí no hay caja de orden de palabras: una carga útil de longitud arbitraria no tiene palabras de 16 bits que intercambiar. | encendida / apagada | apagada |
| Multiplicador (en blanco = ninguno) | Un factor del lado del bus, aplicado por el servidor de red justo después de descodificar, antes de que el valor entre en la cadena de conversión propia del tag. Se aplica solo a los tipos numéricos. Un 0 se rechaza ahí mismo donde se escribe ("Un multiplicador de 0 pondría a cero todas las lecturas."), porque reportaría todas las lecturas del tag como 0 con buena calidad. | cualquier número distinto de 0, o en blanco | en blanco |

El orden de las operaciones en una lectura es: tomar los bytes direccionados → aplicar la
máscara de bits → invertir si el byte más significativo va primero → convertir al tipo de
dato del tag → aplicar el multiplicador (en los tipos numéricos).

Ejemplos, para un sensor cuya carga útil de 11 bytes lleva una temperatura Int16 en
big-endian en el desplazamiento 2:

- Modo de desplazamiento: canal/desplazamiento `2`, longitud de lectura `2`, byte más
  significativo primero encendido.
- Modo LPP, con ese mismo sensor hablando Cayenne LPP en el canal 1 con el tipo 103: marque
  la casilla de LPP, canal `1`, código de tipo `103`, longitud de lectura `2`.

## Los tipos de dato admitidos {#supported-data-types}

| Tipo | Bytes leídos (automático) | Cómo se interpretan los bytes |
|---|---|---|
| Boolean | 1 | Cero es falso, cualquier otra cosa verdadero |
| Byte | 1 | Byte sin signo |
| Int16 | 2 | Entero de 16 bits con signo |
| Int32 | 4 | Entero de 32 bits con signo |
| Float | 4 | IEEE 754 de precisión simple |
| String | 16 | Texto UTF-8 de la longitud de lectura |

## Las escrituras y el descubrimiento {#writes-and-discovery}

Los tags de LoRaWAN son de **solo lectura**: los valores vienen únicamente de los enlaces
ascendentes de los sensores, el campo de acceso no ofrece ninguna opción escribible, y el
runtime rechaza una escritura en lugar de fingir que salió bien. Los enlaces descendentes
existen en el protocolo como tráfico de red (aceptaciones de unión, comandos MAC), nunca
como escrituras de valor de un tag.

El driver no tiene escaneo de descubrimiento. Agregue el concentrador a mano con su EUI de
estación y su región, y cada sensor a mano con su DevEUI y su AppKey; el flujo general para
agregar un dispositivo se describe en la página del [Connector](connector).