Zigbee y LoRaWAN resuelven problemas de radio distintos. Zigbee transporta lecturas frecuentes de muchos dispositivos agrupados en un edificio. LoRaWAN transporta unas pocas lecturas pequeñas por hora desde dispositivos dispersos en una zona amplia. Muchas instalaciones energéticas necesitan ambos: submedición densa en los cuadros de distribución y unos pocos contadores de gas, agua o depósitos lejos de la alimentación eléctrica y de la red.
En un sistema EpiSensor, los dispositivos Zigbee se unen a la red mallada de la Gateway ZGW-20 y Edge almacena sus lecturas en la Gateway. Los dispositivos LoRaWAN informan a una pasarela LoRaWAN y a un servidor de red. Ese servidor decodifica cada mensaje ascendente y entrega las lecturas a Edge por MQTT o HTTPS. Edge reúne después ambos conjuntos en un mismo modelo de datos. No sustituye al servidor de red.
Elegir según los requisitos
| Requisito del proyecto | Punto de partida | Qué verificar |
|---|---|---|
| Lecturas cada pocos segundos o minutos desde muchos puntos de un edificio | Red mallada Zigbee | Ubicación de routers, planificación de canales Wi-Fi, número de dispositivos por Gateway |
| Pocas lecturas por hora desde dispositivos de batería dispersos | LoRaWAN | Cobertura medida, factor de dispersión en la posición real del contador, tiempo en el aire y presupuesto de batería |
| Ambos casos en una instalación | Ambas redes | Quién gestiona el servidor de red, qué marca temporal conserva cada lectura y cómo se alinean las dos resoluciones |
| Control de equipos con un plazo de respuesta | Ninguna por defecto | Latencia de extremo a extremo, estado tras perderse un mensaje y protecciones propias del equipo |
Un protocolo inalámbrico no es una función de seguridad. Defina con el proveedor del equipo el estado seguro de los equipos controlados, independientemente de la radio que transporte la orden.
Zigbee en la instalación
Zigbee funciona sobre IEEE 802.15.4 a 2,4 GHz. La banda tiene 16 canales, numerados del 11 al 26, con centros separados 5 MHz entre 2405 y 2480 MHz. La velocidad por radio es de 250 kbit/s y cada trama admite como máximo 127 bytes, incluidas las cabeceras.
La red tiene un coordinador, que en un sistema EpiSensor es la ZGW-20. Los routers retransmiten tramas de otros dispositivos. Los dispositivos finales solo envían y reciben a través de un router padre. Un dispositivo final en reposo despierta, consulta si su padre guarda mensajes para él y vuelve a dormir. Un equipo alimentado de la red eléctrica no siempre es router: compruebe el tipo de nodo en la ficha técnica (véanse las definiciones de tipos de nodo de Silicon Labs). Todos los dispositivos EpiSensor alimentados de la red eléctrica retransmiten. Cada uno alcanza hasta 50 m en interiores y 300 m en exteriores y añade, por término medio, unos 1.000 m² de cobertura en superficies comerciales. Una ZGW-20 admite hasta 250 dispositivos y 1.000 sensores.
Cada salto retransmite la trama por el mismo canal. Una lectura situada a tres saltos de la Gateway utiliza por tanto el canal tres veces. Una cadena profunda de routers a lo largo de un pasillo ocupa el canal más deprisa que una malla plana con varias rutas hacia la Gateway.
Planificar canales frente a Wi-Fi
Un canal Wi-Fi de 20 MHz cubre ±10 MHz alrededor de su centro. Los canales Wi-Fi 1, 6 y 11 se centran en 2412, 2437 y 2462 MHz. Cubren de 2402 a 2422, de 2427 a 2447 y de 2452 a 2472 MHz, y se solapan con los canales Zigbee 11 a 14, 16 a 19 y 21 a 24. Los canales Zigbee 15 (2425 MHz), 20 (2450 MHz), 25 (2475 MHz) y 26 (2480 MHz) quedan en los huecos. Silicon Labs midió que sus radios 802.15.4 toleran una señal Wi-Fi hasta 20 dB más potente cuando ambas están alejadas en frecuencia que cuando son adyacentes.
Hay dos casos que invalidan ese plan. En Europa, el canal Wi-Fi 13 (2472 MHz) está permitido y cubre los canales Zigbee 25 y 26. Un canal Wi-Fi de 40 MHz ocupa el doble de ancho que uno de 20 MHz. Mida los canales Wi-Fi usados antes de elegir el de Zigbee y vuelva a medirlos cuando la instalación añada puntos de acceso.
Modos de fallo de Zigbee
- Se apaga, aísla para mantenimiento o retira un router. Sus dispositivos finales deben encontrar otro padre. Si no hay otro router al alcance, dejan de informar hasta que regrese el primero.
- Un dispositivo está dentro de un armario de acero o una sala de máquinas con puerta de acero. El enlace con el router más cercano cae por debajo de un nivel utilizable. Sitúe un router fuera del armario o mueva la antena.
- Un punto de acceso Wi-Fi nuevo empieza a usar un canal que se solapa con Zigbee. Los informes desde el extremo lejano de la malla llegan tarde o no llegan.
Los tres casos se manifiestan del mismo modo en los datos: la última lectura del dispositivo tiene más de dos intervalos de antigüedad. Configure una alerta por esa condición para cada dispositivo desde la puesta en servicio.
LoRaWAN en la instalación
LoRaWAN usa la modulación LoRa en bandas inferiores a 1 GHz: de 863 a 870 MHz en Europa (EU868) y de 902 a 928 MHz en Norteamérica (US915). Los dispositivos no retransmiten los mensajes de otros. Cada mensaje ascendente llega directamente a todas las pasarelas LoRaWAN al alcance, que lo remiten a un servidor de red. El servidor elimina duplicados, comprueba la trama y la entrega a la aplicación.
La velocidad de datos depende del factor de dispersión (SF). Un SF mayor llega más lejos y soporta más atenuación, pero cada paso prácticamente duplica el tiempo en el aire. Los parámetros regionales EU868 establecen estos límites para canales de 125 kHz:
| Velocidad de datos | Factor de dispersión | Velocidad de bits | Carga útil máxima de aplicación |
|---|---|---|---|
| DR0 | SF12 | 250 bit/s | 51 bytes |
| DR1 | SF11 | 440 bit/s | 51 bytes |
| DR2 | SF10 | 980 bit/s | 51 bytes |
| DR3 | SF9 | 1.760 bit/s | 115 bytes |
| DR4 | SF8 | 3.125 bit/s | 222 bytes |
| DR5 | SF7 | 5.470 bit/s | 222 bytes |
Todo dispositivo EU868 debe utilizar 868,1, 868,3 y 868,5 MHz. Los tres canales pertenecen a la subbanda de 868,0 a 868,6 MHz, a la que ETSI aplica un ciclo de trabajo del 1 % a 25 mW ERP. La Sandbox pública de The Things Network añade un límite de uso justo de 30 s diarios de tiempo en el aire de mensajes ascendentes y 10 mensajes descendentes por dispositivo y día. Un servidor de red privado no tiene ese límite de uso justo, pero el ciclo de trabajo sigue siendo obligatorio.
El alcance depende de la altura de la antena, el terreno, los edificios y el SF. Una pasarela en un mástil puede llegar a dispositivos situados a varios kilómetros en campo abierto. Dentro de edificios y sótanos, cuente con cientos de metros. Modele la cobertura y después pruébela con un dispositivo en la posición real del contador.
Ejemplo de tiempo en el aire
Un contador envía una carga útil de aplicación de 20 bytes. LoRaWAN añade 13 bytes de cabecera y comprobación de integridad, así que la radio transmite 33 bytes. Con un preámbulo de 8 símbolos, tasa de codificación 4/5 y CRC activado, el tiempo en el aire es:
| Factor de dispersión | Tiempo en el aire | Pausa mínima con ciclo de trabajo del 1 % | Mensajes diarios dentro de 30 s | Intervalo mínimo dentro de 30 s diarios |
|---|---|---|---|---|
| SF7 | 72 ms | 7 s | 417 | 3,5 minutos |
| SF9 | 247 ms | 24 s | 121 | 12 minutos |
| SF10 | 453 ms | 45 s | 66 | 22 minutos |
| SF12 | 1.810 ms | 179 s | 16 | 90 minutos |
Un intervalo de 15 minutos supone 96 mensajes ascendentes al día. Cumple el límite de uso justo de Sandbox de SF7 a SF9, pero no en SF10 ni superiores. Un contador en una cámara de sótano que solo enlaza a SF12 puede enviar aproximadamente una vez cada 90 minutos en Sandbox. Además, consume por lectura unas 25 veces la energía de transmisión que gastaría a SF7, así que la estimación de batería debe usar el SF realmente alcanzado.
Explore el cálculo de duración del paquete con la carga de radio completa de 33 bytes de este ejemplo. Cambiar el factor de dispersión cambia el tiempo en el aire; el resultado no demuestra el cumplimiento de una norma regional de acceso al canal ni de una política de uso justo de la red.
Clases de dispositivos y órdenes
Las tres clases de dispositivos pueden recibir mensajes descendentes. Un dispositivo de clase A solo escucha en dos ventanas breves de recepción después de cada mensaje ascendente propio. Una orden a un contador de clase A que informa cada hora puede esperar, por tanto, hasta una hora. La clase B añade ventanas de recepción programadas mediante balizas de la pasarela. La clase C escucha continuamente salvo mientras transmite; conviene a actuadores alimentados de la red eléctrica y consume demasiado para la mayoría de los equipos de batería. Ninguna clase garantiza un tiempo de entrega de extremo a extremo (véanse las clases de dispositivos LoRaWAN).
Modos de fallo de LoRaWAN
- Un mensaje ascendente no confirmado no recibe acuse de recibo, pero puede repetirse según NbTrans. LoRaWAN L2 1.0.4 establece NbTrans transmisiones para mensajes ascendentes confirmados y no confirmados; las repeticiones no confirmadas se detienen cuando llega un mensaje descendente válido en una ventana de recepción de clase A. Si ninguna pasarela recibe ninguna transmisión, la lectura se pierde. Incluya las repeticiones configuradas en los presupuestos de tiempo en el aire y batería. Elija dispositivos que envíen un registro acumulativo, como kWh o m³ totales, en cada mensaje. Así, la pérdida de uno reduce la resolución temporal, no la energía contabilizada.
- Los mensajes ascendentes confirmados hacen que el servidor de red envíe una confirmación descendente por cada uno. Un dispositivo que confirma cada lectura de 15 minutos necesita 96 mensajes descendentes al día, muy por encima del límite de 10 de Sandbox. Además, cada mensaje descendente impide a la pasarela recibir mientras transmite. Use confirmación solo cuando perder una lectura importe más que el tiempo en el aire.
- La velocidad de datos adaptativa (ADR) reduce el SF cuando el margen del enlace es bueno. Cuando empeora el enlace, el dispositivo vuelve a subir hacia SF12. Un dispositivo que se mueve, o que está detrás de una puerta casi siempre abierta, puede pasar a SF12 y agotar la batería mucho antes de lo previsto. Vigile el SF que informa cada dispositivo al servidor de red.
- Un dispositivo activado por personalización (ABP) conserva claves de sesión fijas. Si tras apagarlo y encenderlo reinicia su contador de tramas a 0, el servidor de red ignora cada mensaje con un contador inferior al último visto. El dispositivo transmite aparentemente con normalidad, pero no llega nada. Use activación por aire (OTAA), que establece nuevas claves y contadores de sesión en cada incorporación.
- Una pasarela LoRaWAN pierde su enlace de salida. Pregunte si almacena los mensajes ascendentes durante la interrupción. Si solo los reenvía en tiempo real, se pierden las lecturas de ese periodo.
Ejemplos de instalaciones híbridas
Campus con contadores remotos
Un campus universitario tiene 20 edificios. Dentro de cada uno, los monitores eléctricos de los cuadros de distribución informan cada minuto o con mayor frecuencia. Esa tarea corresponde a Zigbee. Cada edificio con más de 250 dispositivos, o sin ruta de radio hacia sus vecinos, recibe su propia Gateway.
En el campus también hay contadores de agua en arquetas, contadores de gas en el perímetro y estaciones meteorológicas en cubiertas. Informan cada 15 a 60 minutos y no tienen alimentación ni Ethernet cerca. LoRaWAN les conviene. Sitúe las pasarelas LoRaWAN a partir de un estudio de cobertura, con un dispositivo de prueba bajado a la arqueta más profunda, en vez de suponer que una sola pasarela en una azotea cubre todo el campus.
Cartera de varias instalaciones
El propietario de 50 edificios comerciales los monitoriza. Cada edificio grande tiene una Gateway y una malla Zigbee para medir circuitos. Los emplazamientos pequeños, como aparcamientos y salas de máquinas sin personal, solo necesitan la lectura del contador principal y una temperatura. Allí, un dispositivo LoRaWAN de impulsos o temperatura alimentado por batería, que informe a un servidor de red existente, evita instalar una Gateway en cada emplazamiento. Compruebe primero el presupuesto de tiempo en el aire si el servidor es público.
Fábrica con servicios exteriores
Una fábrica alimentaria utiliza Zigbee para monitorizar la potencia de cada línea de producción. En el exterior, dispositivos LoRaWAN leen el contador de gas, el contador del pozo de agua y el nivel de un depósito de fueloil. Con ambos conjuntos en Edge, gas, agua y electricidad por turno comparten una misma línea temporal y la fábrica puede calcular energía por tonelada de producto.
Arquitectura de integración
Ruta Zigbee. Dispositivo Zigbee, coordinador ZGW-20, Edge en la Gateway. Edge almacena las lecturas localmente y sigue funcionando cuando se interrumpe el enlace aguas arriba.
Ruta LoRaWAN. Dispositivo LoRaWAN, pasarela LoRaWAN, servidor de red con el decodificador de carga útil del dispositivo, integración MQTT o HTTPS, Edge. El servidor de red puede ser privado o público y pertenecer a la instalación o a otro equipo. Acuerde quién controla la cuenta del servidor de red, las claves de los dispositivos y la versión del decodificador antes de conectarlo. La lista de dispositivos LoRaWAN y la lista de dispositivos Zigbee del Directorio de dispositivos muestran cómo se conecta cada modelo de terceros y qué lecturas documenta.
Una instalación también puede omitir Edge para LoRaWAN y enviar ambos flujos directamente a su plataforma: las lecturas Zigbee desde la Gateway y las LoRaWAN desde el servidor de red. Las mismas reglas de tiempo y resolución se aplican entonces en la plataforma.
Marcas temporales
Un informe de atributo Zigbee y un mensaje ascendente LoRaWAN no contienen la hora de la medición en la capa de protocolo, salvo que el dispositivo la incluya en su carga útil. El receptor marca la hora de cada lectura. En Zigbee lo hace la Gateway, a uno o unos pocos saltos del dispositivo. En LoRaWAN, el servidor de red registra cuándo recibió el mensaje, que la integración puede entregar segundos o, tras una interrupción, horas más tarde. Asocie a la lectura la hora de recepción del servidor de red, no la hora a la que el mensaje llegó a Edge. De otro modo, un lote pendiente reproducido aparecerá como una ráfaga de lecturas en el momento de restablecerse el enlace.
Actualizaciones de firmware
Ambas redes pueden actualizar por radio el firmware de los dispositivos, pero a velocidades muy distintas. La guía de actualizaciones OTA compara el clúster Zigbee OTA con LoRaWAN FUOTA y explica cómo planificar una campaña.
Resoluciones mixtas
Las lecturas Zigbee cada minuto y LoRaWAN cada 30 minutos no coinciden por defecto. Para el consumo, calcule la diferencia del registro acumulativo entre los límites del intervalo. No sume valores puntuales de potencia. Para un informe con un intervalo común, por ejemplo de 30 minutos, compare los contadores solo a ese intervalo. Muestre la antigüedad de la lectura junto a cada valor, para que una lectura LoRaWAN de hace una hora no parezca tan actual como una Zigbee de hace un minuto.
Seguridad
Zigbee cifra el tráfico de red con una clave de red AES de 128 bits compartida por todos los dispositivos de la red. El coordinador actúa como centro de confianza y entrega la clave de red a cada dispositivo cuando se incorpora. Los dispositivos Zigbee 3.0 deben admitir códigos de instalación. Cada código proporciona al dispositivo una clave de enlace única que protege la clave de red durante la incorporación. Sin ella, la clave de red se envía bajo una clave de enlace predeterminada y conocida públicamente; cualquiera que escuche durante la ventana de incorporación puede capturarla. Abra la red para incorporaciones solo durante la puesta en servicio y use códigos de instalación cuando los dispositivos los admitan.
LoRaWAN 1.0.x usa una AppKey raíz por dispositivo para OTAA. En cada incorporación se derivan de ella una clave de sesión de red (NwkSKey), con la que el servidor comprueba la integridad del mensaje, y una clave de sesión de aplicación (AppSKey), que cifra la carga útil entre dispositivo y servidor de aplicaciones. LoRaWAN 1.1 separa la clave raíz en NwkKey y AppKey y emplea claves de sesión de red independientes. En un servidor de red público, el operador puede custodiar todas estas claves. Registre quién posee cada una y cómo se renuevan las claves al trasladar un dispositivo a otro servidor de red.
Proteja el enlace del servidor de red a Edge con TLS y credenciales, como cualquier integración MQTT o HTTPS. Consulte MQTTS: MQTT sobre TLS para las pruebas de puesta en servicio.
Qué comprobar antes del despliegue
Haga un piloto que incluya las posiciones más difíciles de los contadores, no solo los puntos próximos a una pasarela. Acuerde estas pruebas de aceptación con el instalador y el equipo de la plataforma:
- Registre la identidad, el firmware, las unidades, el escalado y el intervalo de informes de cada punto. En dispositivos LoRaWAN, registre también el SF al que se estabiliza cada uno.
- Compare los valores recibidos con la pantalla del contador o un instrumento de referencia. Guarde los registros acumulativos separados del consumo calculado.
- Compruebe que la plataforma muestra una lectura ausente como ausente, no como cero.
- Interrumpa por separado el enlace de radio, la alimentación de la Gateway y la conexión aguas arriba. Anote qué componente conserva los datos y qué huecos no pueden recuperarse.
- Para las órdenes, compruebe el estado medido del equipo, no solo el acuse de recibo de la aplicación.
- Entregue la responsabilidad de las claves, cuentas del servidor de red, dispositivos de repuesto y contactos de asistencia antes de replicar el diseño en más instalaciones.
Para decidir el siguiente paso, lea sobre almacenamiento y arquitectura de datos IoT y plataformas de gestión energética. Si tiene un plano de la instalación y una lista de puntos, contacte con EpiSensor para revisar los requisitos de sensores y conectividad.