Productos/ EMU Professional II/ LoRa

Interfaz · EMU Professional II

LoRa en el EMU Professional II: LoRaWAN, TTN y decodificador de payload

Radio en la banda EU868 sin licencia, alcance en lugar de velocidad de datos, contadores que transmiten por sí mismos. Esta página explica cómo encajan LoRa y LoRaWAN, por qué el duty cycle marca el ritmo y cómo la plantilla TTN y nuestro decodificador le dan valores legibles sin programar nada.

El principio

¿Cómo funciona LoRa?


Dos términos se confunden constantemente. LoRa es la técnica de radio – una modulación de espectro ensanchado que extiende una señal estrecha tanto que todavía se detecta por debajo del ruido. Eso aporta alcance a costa de velocidad de datos. LoRaWAN es el protocolo de red que va encima: pasarelas, servidor de red, cifrado, procedimiento de alta.

La lógica es distinta a la de M-Bus o Modbus: ningún maestro consulta al contador. El contador envía por sí mismo un pequeño paquete con un ritmo fijo, y una pasarela dentro del alcance de radio lo recibe y lo reenvía al servidor de red. Tras cada envío, el equipo abre brevemente dos ventanas de recepción: es la clase A, el modo de funcionamiento más ahorrador.

En Europa esto funciona en la banda EU868 sin licencia. Sin licencia no significa sin normas: rige un límite de duty cycle que restringe el tiempo de emisión por equipo y hora. Por eso LoRa está pensado para valores cuartohorarios u horarios, no para valores por segundo.

Conceptos

LoRa

La técnica de radio. Modulación de espectro ensanchado, alcance a costa de velocidad de datos.

LoRaWAN

El protocolo de red: pasarelas, servidor de red, claves, alta.

Spreading factor

SF7 a SF12. Más alto significa más lejos y más robusto, pero más lento y con más tiempo de emisión.

Duty cycle

Limitación legal del tiempo de emisión por equipo en la banda sin licencia.

clase A

El equipo emite y después abre dos breves ventanas de recepción. El modo más ahorrador.

OTAA

Alta por radio con DevEUI, JoinEUI y AppKey. La vía recomendada.

ABP

Claves de sesión programadas de forma fija. Más sencillo, pero menos seguro.

Payload

Los datos útiles del paquete – bytes empaquetados de forma compacta, no texto legible.

Ruta de los datos

¿Cómo llegan de forma segura las lecturas de un contador LoRa al sistema de destino?


Con un servidor de red propio o directamente en Joulio-Web: el contador se une a la red mediante OTAA y todas las lecturas viajan cifradas de extremo a extremo. Esto vale tanto para el EMU Professional II LoRa como para los contadores Helvatron H2O y DELTA III. Los gateways solo reenvían.

Caso de uso 1: servidor de red externo con API

Radio EU868BackhaulAPIDuplicado descartadoProfessional II LoRaEnergía · EMUHelvatron H2OAguaHelvatron DELTA IIICalorGateway 1Módem SIM (LTE)Gateway 2LANServidor de redLNS + join serverDecodificadorSist. de controlFacturaciónNube / BIEn el contadorDevEUIJoinEUIAppKeyDevAddrNwkSKeyAppSKeyClaves de sesión tras el joinEn los gatewayssin clavessolo reenvían paquetesEn el servidor de redDevEUIJoinEUIAppKeyDevAddrNwkSKeyAppSKeyClaves de sesión tras el join
  1. Claves en su sitioCada contador conoce su DevEUI, su JoinEUI y la AppKey secreta. Los mismos tres valores están registrados en el servidor de red. La AppKey nunca se transmite por radio.
  2. Join requestEl contador solicita unirse a la red con DevEUI, JoinEUI y un número aleatorio. El mensaje va firmado con la AppKey. Lo recibe cada gateway que está al alcance, aquí los dos.
  3. Reenvío por LTE y LANEl gateway 1 transmite por su módem SIM integrado, el gateway 2 por LAN. Los gateways no abren nada. El servidor de red reconoce el paquete recibido dos veces y descarta el duplicado.
  4. Join acceptEl servidor de red comprueba la firma, asigna una dirección de red (DevAddr) y responde, cifrado con la AppKey, a través del gateway con mejor recepción.
  5. Claves de sesiónEl contador y el servidor de red calculan por separado las mismas claves de sesión: NwkSKey para la integridad y AppSKey para las lecturas. Ninguna de las dos se transmite.
  6. Envío de lecturasLos contadores de electricidad, agua y calor envían sus valores a intervalos fijos, cifrados con la AppSKey. Los gateways no pueden leer el contenido.
  7. Comprobar y decodificarEl servidor de red comprueba la firma, descarta duplicados, descifra con la AppSKey y convierte los bytes en kWh, m³ y energía térmica mediante el decodificador de payload.
  8. Reenvío por APILos valores decodificados llegan a través de la API del servidor de red, por ejemplo REST, webhook o MQTT, al sistema de control, a la facturación o a la nube.

Caso de uso 2: Joulio-Web con servidor de red integrado

Radio EU868BackhaulUsoDuplicado descartadoProfessional II LoRaEnergía · EMUHelvatron H2OAguaHelvatron DELTA IIICalorGateway 1Módem SIM (LTE)Gateway 2LANJoulio-WebLNS integradoDecodif. + análisisPanelesFacturaciónAPI (opcional)En el contadorDevEUIJoinEUIAppKeyDevAddrNwkSKeyAppSKeyClaves de sesión tras el joinEn los gatewayssin clavessolo reenvían paquetesEn Joulio-WebDevEUIJoinEUIAppKeyDevAddrNwkSKeyAppSKeyClaves de sesión tras el join
  1. Claves en su sitioCada contador conoce su DevEUI, su JoinEUI y la AppKey secreta. Los mismos tres valores están registrados en Joulio-Web. La AppKey nunca se transmite por radio.
  2. Join requestEl contador solicita unirse a la red con DevEUI, JoinEUI y un número aleatorio. El mensaje va firmado con la AppKey. Lo recibe cada gateway que está al alcance, aquí los dos.
  3. Reenvío por LTE y LANEl gateway 1 transmite por su módem SIM integrado, el gateway 2 por LAN. Los gateways no abren nada. Joulio-Web reconoce el paquete recibido dos veces y descarta el duplicado.
  4. Join acceptJoulio-Web comprueba la firma, asigna una dirección de red (DevAddr) y responde, cifrado con la AppKey, a través del gateway con mejor recepción.
  5. Claves de sesiónEl contador y Joulio-Web calculan por separado las mismas claves de sesión: NwkSKey para la integridad y AppSKey para las lecturas. Ninguna de las dos se transmite.
  6. Envío de lecturasLos contadores de electricidad, agua y calor envían sus valores a intervalos fijos, cifrados con la AppSKey. Los gateways no pueden leer el contenido.
  7. Comprobar y decodificarJoulio-Web comprueba la firma, descarta duplicados, descifra con la AppSKey y convierte los bytes en kWh, m³ y energía térmica mediante el decodificador de payload.
  8. Directamente en Joulio-WebJoulio-Web gestiona las claves por sí mismo y utiliza los valores directamente para paneles, curva de carga y reparto de gastos. Los sistemas de terceros se conectan a través de la API de Joulio-Web.

Integración

¿Cómo decodifico el payload LoRa de un contador de energía?


Lo que llega al servidor de red es primero un breve bloque de bytes. Para convertirlo en «energía activa consumida, tarifa 1, 128.431 kWh» se necesita un decodificador de payload: un pequeño fragmento de código que descompone los bytes según la estructura de payload del equipo.

Justo aquí fracasan con más frecuencia los proyectos LoRa – no en el enlace de radio, sino porque el decodificador se escribió a mano y nunca se documentó. Por eso lo suministramos listo.

The Things Network

En la red TTN, el EMU Professional II LoRa está disponible directamente como plantilla. Crear el equipo, elegir la plantilla, introducir las claves – el decodificador viene incluido. Para el caso más habitual, el asunto queda así totalmente resuelto.

Otros servidores de red

Para la integración en otros sistemas, el decodificador está en GitHub. Le acompañan dos herramientas que funcionan directamente en el navegador: un decodificador de payload para comprobar un paquete recibido y un generador de payload para crear paquetes de prueba antes de instalar el primer contador. Ambas ahorran búsqueda de errores in situ.

Probar antes de montar

Con el generador de payload se puede construir y comprobar toda la cadena, del servidor de red al sistema de destino, antes de que cuelgue un solo contador en el patinillo. Así, la búsqueda de errores pasa del sótano al escritorio.

Planificación de radio

¿Qué alcance logra LoRa dentro de edificios?


Spreading factor

Un spreading factor más alto aporta alcance y robustez, pero alarga el tiempo de emisión y consume así más del duty cycle permitido. Los contadores del sótano suelen acabar en SF11 o SF12; los que tienen visión directa, en SF7.

Situación constructiva

El hormigón armado, la tierra y las puertas metálicas de los cuadros cuestan más nivel de señal de lo que sugiere cualquier distancia. Un contador a 30 m en el sótano es más difícil que uno a 2 km con visión de la pasarela.

Medir antes

Un equipo de prueba en el punto de instalación previsto dice más que cualquier cálculo. En inmuebles dispersos compensa un recorrido con mediciones antes de montar las pasarelas de forma definitiva.

Cuándo encaja

¿Cuándo es LoRa la interfaz adecuada?


A favor

  • Puntos de medición sin recorrido de cable, por ejemplo en edificios existentes
  • Inmuebles dispersos con una pasarela común
  • Ampliaciones donde ya no se puede tender cable
  • Valores cuartohorarios u horarios como resolución objetivo
  • Plantilla TTN disponible, decodificador público en GitHub

En contra

  • Valores por segundo o tareas de regulación – el duty cycle lo impide
  • Grandes volúmenes de datos por lectura
  • Entrega garantizada en un momento fijo
  • Puntos de medición profundos sin camino de radio hacia fuera
  • Instalaciones donde ya hay M-Bus o Ethernet

Ver M-Bus · Ver TCP/IP

Documentos

Manuales y fichas técnicas para descargar


Esta página explica el principio. Las listas de registros, la estructura de telegramas, la asignación de bornes y los parámetros exactos de cada versión están en el manual de la interfaz.

PDFManual de la interfaz LoRa1490 · estructura de payload · inglés GITLoRa decoderemuag/professional_II_lora GITPayload generatorCódigo fuente en GitHub WEBDecodificadorFunciona en el navegador WEBPayload generatorFunciona en el navegador PDFFicha técnica Professional II1441 · inglés

Preguntas frecuentes

Preguntas frecuentes sobre la interfaz


¿Cuál es la diferencia entre LoRa y LoRaWAN?

LoRa es la técnica de radio – una modulación de espectro ensanchado que cambia velocidad de datos por alcance. LoRaWAN es el protocolo de red que va encima, con pasarelas, servidor de red, cifrado y procedimiento de alta. En la práctica se necesitan ambos.

¿Hay una plantilla lista para The Things Network?

Sí. En la red TTN, el EMU Professional II LoRa está disponible directamente como plantilla. Crear el equipo, elegir la plantilla, introducir las claves – el decodificador de payload viene incluido.

¿Cómo integro el contador en otro servidor de red?

Mediante el decodificador que ofrecemos en GitHub. Además hay un decodificador y un generador de payload como herramientas web: con el decodificador comprueba un paquete recibido, con el generador crea paquetes de prueba para montar la cadena antes de instalar el primer contador.

¿Con qué frecuencia transmite un contador LoRa?

Con un ritmo fijo, no bajo demanda. El ritmo sigue el duty cycle de la banda EU868 sin licencia, que limita el tiempo de emisión por equipo y hora. Por eso LoRa es adecuado para valores cuartohorarios y horarios, no para valores por segundo ni tareas de regulación.

¿Qué alcance conseguiré?

Depende del lugar, no de una cifra en una ficha técnica. El hormigón armado, la tierra y las puertas metálicas cuestan bastante más nivel de señal que la distancia. Un contador a 30 m en el sótano puede ser más difícil que uno a 2 km con visión directa. Una medición en el punto previsto supera a cualquier cálculo.

OTAA or ABP?

OTAA, el alta por radio con DevEUI, JoinEUI y AppKey, es la vía recomendada: las claves de sesión se negocian en el alta. ABP trabaja con claves programadas de forma fija – más sencillo de configurar, pero menos seguro y más engorroso al sustituir un contador.

¿No está seguro de si LoRa encaja?


Envíenos el número de puntos de medición, las distancias y el sistema de destino. Le diremos qué versión tiene sentido – y cuándo otra interfaz sería la mejor opción.

Teléfono
+41 (0)41 545 03 00

Soporte técnico
helpdesk@emuag.ch

Pedidos Suiza
orders@emuag.ch