# LoRaWAN

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

El controlador LoRaWAN convierte a Ganter Lab en un pequeño **servidor de red LoRaWAN**. El sentido de la relación está invertido respecto a la mayoría de los controladores: la estación no sale a buscar un sensor, es la **pasarela la que se conecta a Ganter Lab**, y los sensores entregan sus lecturas como enlaces ascendentes a través de esa pasarela. Ganter Lab integra un servidor de red que habla el protocolo **LoRa Basics Station** de Semtech, así que cualquier pasarela con firmware Basics Station puede usar esta estación como su LNS.

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

Cada dispositivo bajo el controlador 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 pasarela), 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 **Añadir 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 mientras la conexión en sí parece sana. La respuesta se construye aquí a partir de la región elegida; no hay ningún texto de configuración que pegar.

## Preparar la pasarela {#prepare-the-gateway}

La pasarela 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 lleva la tarjeta **Preparar la pasarela** con lo que hay que introducir en los ajustes de Basics Station de la pasarela, escrito para esta estación:

| Qué configurar en la pasarela | 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 ordenador 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 pasarela 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 pasarela. Cada pasarela es un dispositivo concentrador propio. Mientras está vacío, la tarjeta dice que se introduzca en la tarjeta Conexión. |
| Certificado de cliente (`tc.crt`, con su clave en `tc.key`) | TLS mutuo: la pasarela presenta un certificado de cliente que lleva su EUI de la estación en el nombre común o en un nombre alternativo DNS (véase [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 pasarela no se ha conectado 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 pasarela. Una pasarela 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 pasarela 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 pasarelas de esta estación, y no cambia cuando cambian el nombre o las direcciones de la estación. Una pasarela con la configuración de fábrica de Basics Station acepta la estación: no hay que desactivar nada en su configuración.

**Toda pasarela 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 pasarelas 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 pasarela de una estación que ya tenía pasarelas, 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 pasarela | `wss://<station-address>: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 pasarela como última parte de la ruta del WebSocket |

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

## Certificados {#certificates}

La admisión es por TLS mutuo: el servidor demuestra quién es con su propio certificado, y toda pasarela 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 sitio.
- `GanterLabConnector-<station>.pem`, en `ua\pki\station`, el certificado raíz público. Este es el archivo que se instala en la pasarela 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 caduca**. Su mitad pública se instala una sola vez, a mano, en cada concentrador, así que una raíz que se agotara 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 caducidad 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 controlador, 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 ordenador mientras está vacío), `localhost` y cada dirección IPv4 de la estación, así que una pasarela que verifica el nombre del servidor lo acepta. Cambiar el nombre de la ordenador, 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 controlador 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 haga, no se pueden conectar.

**Certificado de cliente de la pasarela.** Toda pasarela tiene que presentar un certificado de cliente durante el apretón de manos TLS; un apretón de manos sin él se descarta antes de que circule ningún dato. El certificado tiene que:

1. Ser de confianza de una de dos maneras: construye 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 controlador (más abajo). En los dos casos tiene que estar dentro de sus fechas de validez. Una comprobación fallida rechaza la conexión, y el diario técnico anota qué comprobación falló.
2. Llevar el **EUI de la estación** de la pasarela en su nombre común de sujeto o en un nombre alternativo de sujeto 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 la misma estación.
3. Nombrar la **misma estación** que dice ser la conexión de datos: un certificado que nombra una pasarela distinta de la que va en la dirección de la conexión se rechaza.

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

Una pasarela 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 este ordenador. Su primera conexión se rechaza, y su certificado espera en **Acceso a los equipos**, al final de la página del controlador LoRaWAN, la misma tarjeta que lleva la página del controlador 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 pasarela. **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 pasarela y devuelve su certificado a la lista. **Importar certificado** aprueba el certificado público de una pasarela 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 pasarela del mismo fabricante espera su propia aprobación. Compare la huella digital con la que indica la pasarela antes de aprobarlo. Aprobar no cambia qué pasarela 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 las órdenes, y estas 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.

## 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 a esta estación. El panel muestra primero el selector de registro y después los campos que ese registro necesita.

| Campo | Qué es | Formato | Por defecto |
|---|---|---|---|
| Registrado como | Cuál de los dos registros es este dispositivo: **Sensor de campo** o **Concentrador de radio**. Cambiarlo vacía 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, pelados (`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ío |
| 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 escrituras de arriba. | vacío |
| Región de radio (concentrador) | Dónde está 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) | Segundos que este sensor puede quedarse callado antes de que sus valores guardados dejen de contar como lecturas. 0 apaga la caducidad. Véase más abajo. | 0 o más | 3600 |

Un dispositivo cuyo DevEUI (sensor) o EUI de la estación (concentrador) sigue vacío, como uno recién añadido, 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. Rellene 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 trata como tal. El panel la esconde tras unos puntos, con una casilla **Mostrar la contraseña** que la enseña mientras usted comprueba lo que ha escrito; la base de datos de configuración la guarda protegida bajo la cuenta de Windows que la introdujo; y no aparece ni en el diario técnico 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 vuelve vacío, diciendo "No se puede leer en esta cuenta de Windows: solo se abre en el ordenador y en la cuenta de Windows que lo introdujo. Vuelva a introducirlo aquí.", y el sensor deja de unirse hasta que usted vuelva a escribir la clave. 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 el aire a través del concentrador, y el servidor de red le contesta usando la AppKey configurada. Una petición de unión de un DevEUI que no lleva ningún dispositivo configurado se rechaza y se anota en el diario técnico. 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 oiga, y un concentrador que se cae o se retira no se lleva ningún sensor consigo.

Deshabilitar o eliminar un dispositivo lo retira del servidor de red de inmediato, sin esperar a ningún reinicio: su clave deja el registro, la sesión que tenía en esta estación se libera, y su siguiente unión se rechaza. Deshabilitar o eliminar un concentrador también cierra su conexión en el acto, 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 la cabecera 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 arranca por él, y la estación no vuelve a intentar el mismo registro: corregir el campo es lo que trae de vuelta el 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 de su fila en el árbol y la columna **Estado de salud** en la página del controlador, es si su pasarela 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 pasarela todavía sin conectar (su certificado aún esperando aprobación, por ejemplo) | **Sin conexión** |
| La pasarela conectada | **En línea** |
| La pasarela se cayó: parada, desenchufada o aislada de la red | **Sin conexión**, hasta que vuelva a conectarse |
| Deshabilitado | **Deshabilitado** |

Durante hasta diez segundos después de guardar un cambio en el concentrador, o de que arranque el Connector, se lee **Aún sin determinar**: registrarlo de nuevo cierra la conexión de la pasarela, y la pasarela 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 apretón de manos 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 por defecto 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 hay detrás llega a informar de un valor.

No hay campos de intervalo de sondeo. LoRaWAN funciona empujando: el sensor decide cuándo transmite hacia arriba, el servidor conserva 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.

Un sensor que todavía no ha transmitido hacia arriba no tiene, por tanto, **ninguna lectura**, y no una lectura fallida. Los tags se quedan vacíos, el dispositivo informa de que no se ha observado nada en lugar de irse sin conexión, y no se anota ningún fallo: esperar el primer enlace ascendente es el protocolo funcionando. Una dirección que no resuelve nada dentro de una carga útil que el sensor sí envió es otra cosa, y se informa como el fallo de lectura que es.

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

Como nada sondea a un sensor, la carga útil que envió por última vez se queda en esa caché hasta que envía otra. Si no se hiciera nada, un sensor cuya batería se agotó seguiría publicando el mismo número como lectura buena mientras la estación corriera, alimentando gráficos, histórico y alarmas con un valor que dejó de ser cierto.

Por eso todo sensor lleva un **tiempo máximo sin transmisión**, en segundos, en su propio panel. El valor por defecto es de **3600 segundos**, una hora, que cubre con holgura la cadencia de diez a treinta minutos de un sensor corriente; un sensor que informa más de tarde en tarde sube el suyo. Pasado ese plazo:

- Sus tags dejan de llevar 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 poder ver cuánto tiempo lleva callado.

Poner el campo a **0** apaga la caducidad de ese sensor: su último enlace ascendente se sigue leyendo como bueno indefinidamente. No cambia nada más, y no se descarta ninguna carga útil guardada.

## Direccionamiento del tag {#tag-addressing}

Un tag 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 | Por defecto |
|---|---|---|---|
| Direccionar por canal/tipo Cayenne LPP | Apagado: el campo de canal es un desplazamiento en bytes a secas. Encendido: la carga útil se recorre en busca de una pareja de canal y tipo Cayenne LPP. | encendido / apagado | apagado |
| Canal / desplazamiento en la carga útil | En modo de desplazamiento: el desplazamiento en bytes, contando desde 0, en el que empieza el valor. En modo LPP: el número de canal LPP que hay que buscar. | 0 o más | 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 de la pareja de canal y tipo que coincide, y cuando coinciden varias cargas útiles, gana la más nueva. | 0 o más | 0 |
| Longitud de lectura (bytes, en blanco = automático) | Cuántos bytes de la carga útil componen el valor. En blanco se deriva del tipo de dato: 1 en Boolean y Byte, 2 en Int16, 4 en Int32 y Float, 16 en String. | 1 o más, o en blanco | en blanco |
| Máscara de bits (hex, en blanco = ninguna) | Una máscara hexadecimal que se aplica con un Y lógico sobre los bytes brutos antes que cualquier otra cosa (por ejemplo `0x0FFF` para descartar 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 los mismos bytes que 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 casilla de orden de palabra: una carga útil de longitud arbitraria no tiene palabras de 16 bits que intercambiar. | encendido / apagado | apagado |
| Multiplicador (en blanco = ninguno) | Un factor del lado del bus que el servidor de red aplica 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 allí donde se escribe ("Un multiplicador de 0 pondría a cero todas las lecturas."), porque informaría de todas las lecturas del tag como 0 y 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 o desplazamiento `2`, longitud de lectura `2`, byte más significativo primero encendido.
- Modo LPP, con el mismo sensor hablando Cayenne LPP en el canal 1 con el tipo 103: marque la casilla LPP, canal `1`, código de tipo `103`, longitud de lectura `2`.

## 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 con signo de 16 bits |
| Int32 | 4 | Entero con signo de 32 bits |
| Float | 4 | Precisión simple IEEE 754 |
| String | 16 | Texto UTF-8 de la longitud de lectura |

## Escrituras y descubrimiento {#writes-and-discovery}

Los tags 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 con escritura, y el runtime rechaza una escritura en vez 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 en un tag.

El controlador no tiene ninguna exploración de descubrimiento. Añada 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 recorrido general para añadir un dispositivo se describe en la página [Connector](connector).