Un downlink es una trama que va de la red a un dispositivo: por ejemplo, un nuevo intervalo de envío para un sensor, o «open» para una válvula. En Hermetry envías un downlink de aplicación como un comando con el método lora.downlink. Tú proporcionas los bytes, tal como los documenta el fabricante del dispositivo; Hermetry no los construye a partir de comandos con nombre.
El comando lora.downlink
| Parámetro | Obligatorio | Significado |
|---|---|---|
fPort | Sí | El puerto de aplicación, 1–223, según lo especifique el fabricante del dispositivo |
data | Sí | La carga útil en hexadecimal ("0100003C") o en base64 ("AQAAPA=="); ambas dan los mismos bytes. Como máximo 1.024 caracteres. |
confirmed | No | true pide al dispositivo que confirme la recepción. Por defecto, false. |
{
"method": "lora.downlink",
"params": { "fPort": 10, "data": "0100003C", "confirmed": false }
}Un comando con parámetros ausentes o incorrectos no se envía; pasa a la cola como caducado.
Enviarlo
lora.downlink es un comando como cualquier otro, así que se aplican las reglas generales de Envío de comandos a dispositivos.
Desde la página del dispositivo: añade lora.downlink al catálogo de Comandos del perfil LoRaWAN del dispositivo, con parámetros fijos o editables y un nivel que decide quién puede enviarlo. Después envíalo desde la pestaña Comandos del dispositivo. Una entrada del catálogo por acción (por ejemplo, «Informar cada 10 minutos» con sus bytes fijos) es más fácil para tu equipo que los bytes en bruto.
Como método directo: sin una entrada en el catálogo, solo los propietarios pueden enviarlo.
A través de la API:
POST /tenant/<tenantId>/api/iot/devices/<deviceId>/rpc
Content-Type: application/json
{ "method": "lora.downlink", "params": { "fPort": 10, "data": "0100003C" }, "oneway": true, "persistent": true, "expiresInS": 86400 }Desde un flujo: el bloque Enviar comando envía un comando del catálogo al dispositivo del mensaje.
Opciones recomendadas:
- Unidireccional: un dispositivo LoRaWAN no responde a un comando; un comando bidireccional esperaría una respuesta que nunca llega y terminaría como TIMEOUT.
- Persistente, con caducidad: un dispositivo Clase A puede no transmitir durante un tiempo, y el comando debe esperar en la cola.
Cuándo se envía
| Clase | Momento |
|---|---|
| A | En el siguiente uplink del dispositivo, en su ventana RX1 o RX2. Un dispositivo que informa cada hora lo recibe hasta una hora después. |
| C | De inmediato, en el canal RX2, a través de la pasarela que escuchó al dispositivo por última vez, siempre que su último uplink tenga menos de 15 minutos. En caso contrario, en su siguiente uplink. |
Solo se envía un downlink de aplicación por cada uplink de un dispositivo Clase A. Cuando hay más en cola, el servidor de red activa el indicador «more data pending», que pide a muchos dispositivos que vuelvan a transmitir pronto. Consulta Clases de dispositivo A y C.
Tamaño
La carga útil debe caber en la velocidad de datos de la ventana por la que sale, junto con los comandos MAC que esperen al dispositivo:
| Velocidad de datos | Carga útil máxima |
|---|---|
| DR0–DR2 | 51 bytes |
| DR3 | 115 bytes |
| DR4–DR7 | 222 bytes |
- Clase A: si no cabe esta vez, espera a un uplink con una velocidad de datos más alta. Una carga útil mayor de 222 bytes nunca se podrá enviar y pasa a la cola como caducada (
payload_too_large). - Clase C: se envía a la velocidad de datos de RX2 (DR0 por defecto), por tanto como máximo 51 bytes. Una mayor pasa a la cola como caducada.
Downlinks confirmados
Con "confirmed": true el dispositivo confirma la recepción en su siguiente uplink.
- Clase A: el servidor de red lo reenvía en los siguientes uplinks hasta que llega la confirmación, hasta 3 envíos en total (ajuste del perfil
maxRetries). - Clase C: espera los Downlink confirmado: esperar la confirmación (segundos) del perfil (60 s por defecto) y después lo reenvía con un nuevo contador de trama, hasta 3 envíos en total.
- Sin confirmación tras el último envío, el comando pasa a la cola como caducado (
no_ack).
Usa los downlinks confirmados solo para acciones importantes. Cada envío consume el ciclo de trabajo (duty cycle) de la pasarela.
Resultados
| Qué ocurrió | Estado del comando |
|---|---|
| Una pasarela transmitió el downlink | DELIVERED; un comando unidireccional termina entonces como SUCCESSFUL |
| Pasó la caducidad del comando antes de poder enviarlo | EXPIRED |
| Parámetros incorrectos o carga útil demasiado grande, antes de enviarse | EXPIRED |
En un downlink confirmado, el estado del comando sigue a la primera transmisión. La confirmación en sí y los reenvíos aparecen en el registro de tramas.
El registro de tramas muestra cada downlink como Downlink, Enviado vía pasarela con su ventana (RX1, RX2 o RXC) y su FPort. Una pasarela Basics Station no informa de las transmisiones fallidas; el contador lora.gw.dn_unknown de la pasarela muestra los downlinks sin resultado.
Downlinks que no envías tú
El servidor de red también envía las confirmaciones de los uplinks confirmados, los join accept y los comandos MAC (ADR y ajustes de radio). Estos no aparecen como comandos. Consulta ADR, velocidades de datos y comandos MAC.