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.

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.

El servidor de red y los puertos

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

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.

El certificado del servidor. Se genera automáticamente en el primer arranque y se guarda en la carpeta de datos de la aplicación, bajo ua\pki\own\private:

• GanterLabOPCUAServer-with-san.pfx, 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.
• GanterLabOPCUAServer-with-san.pem, el certificado público. Este es el archivo que se instala en la puerta de enlace para que confíe en esta estación.

El certificado es autofirmado y no vence. Su mitad pública se instala una sola vez, a mano, en cada concentrador, así que un certificado que se venciera tumbaría toda la red de sensores en su aniversario, rechazado 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 página del driver muestra como lectura la fecha que lleva.

Se vuelve a escribir solo en dos casos, y los dos se dicen en el diario técnico:

• El archivo guardado ya no se puede abrir, por ejemplo porque lo escribió otra cuenta de Windows.
• Lo emitió una versión anterior de esta aplicación, que le daba 12 meses.

En cualquiera de los dos casos la página del driver dice, una vez, que hay que darle a cada concentrador el nuevo GanterLabOPCUAServer-with-san.pem. 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. Formar una cadena válida en esta máquina Windows (los errores de cadena, como una raíz sin confianza, rechazan la conexión, y el diario técnico registra qué verificación falló).
2. Llevar el EUI de 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.

Los campos de conexión

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.

Un identificador que se deja vacío cae en el nombre higienizado del dispositivo, que casi nunca es un EUI válido, así que llénelo.

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.

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 cualquier concentrador tuviera para él se libera, y su siguiente unión se rechaza. Un registro que el servidor no acepta, un DevEUI, una clave de aplicación, un EUI de estación o una región mal escritos, dejan al dispositivo leyéndose como no conectado, y el diario técnico nombra el campo que se rechazó.

Qué se le envía al concentrador

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

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

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

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

Las escrituras y el descubrimiento

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.