A downlink is a frame from the network to a device: for example, a new reporting interval for a sensor, or “open” for a valve. In Hermetry you send an application downlink as a command with the method lora.downlink. You provide the bytes yourself, as the device maker documents them; Hermetry does not build them from named commands.
The lora.downlink command
| Parameter | Required | Meaning |
|---|---|---|
fPort | Yes | The application port, 1–223, as the device maker specifies |
data | Yes | The payload as hexadecimal ("0100003C") or base64 ("AQAAPA=="); both give the same bytes. At most 1,024 characters. |
confirmed | No | true asks the device to acknowledge. Default false. |
{
"method": "lora.downlink",
"params": { "fPort": 10, "data": "0100003C", "confirmed": false }
}A command with missing or wrong parameters is not sent; it leaves the queue as expired.
Send it
lora.downlink is a command like any other, so the general rules of Sending commands to devices apply.
From the device page: add lora.downlink to the Commands catalog of the device’s LoRaWAN profile, with fixed or editable parameters and a tier that decides who may send it. Then send it from the device’s Commands tab. A catalog entry per action (for example “Report every 10 minutes” with its fixed bytes) is easier for your team than raw bytes.
As a raw method: without a catalog entry, only owners may send it.
Through the 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 }From a flow: the Send command block sends a catalog command to the message’s device.
Recommended options:
- One-way: a LoRaWAN device does not answer a command; a two-way command would wait for an answer that never comes and end as TIMEOUT.
- Persistent, with an expiry: a Class A device may not send for a while, and the command must wait in the queue.
When it goes out
| Class | Timing |
|---|---|
| A | At the device’s next uplink, in its RX1 or RX2 window. A device that reports hourly receives it up to an hour later. |
| C | At once, on the RX2 channel, through the gateway that heard the device last, as long as its last uplink is less than 15 minutes old. Otherwise at its next uplink. |
Only one application downlink is sent per uplink of a Class A device. When more are queued, the network server sets the “more data pending” flag, which asks many devices to send again soon. See Device classes A and C.
Size
The payload must fit the data rate of the window it goes out in, together with any MAC commands waiting for the device:
| Data rate | Max payload |
|---|---|
| DR0–DR2 | 51 bytes |
| DR3 | 115 bytes |
| DR4–DR7 | 222 bytes |
- Class A: if it does not fit this time, it waits for an uplink at a faster data rate. A payload larger than 222 bytes can never be sent and leaves the queue as expired (
payload_too_large). - Class C: sent at the RX2 data rate (DR0 by default), so at most 51 bytes. A larger one leaves the queue as expired.
Confirmed downlinks
With "confirmed": true the device acknowledges in its next uplink.
- Class A: the network server sends it again at the next uplinks until the acknowledgement arrives, up to 3 sends in total (profile setting
maxRetries). - Class C: it waits for the profile’s Confirmed downlink: wait for the acknowledgement (seconds) (60 s by default), then sends it again with a new frame counter, up to 3 sends in total.
- Without an acknowledgement after the last send, the command leaves the queue as expired (
no_ack).
Use confirmed downlinks only for actions that matter. Every send uses the gateway’s duty cycle.
Results
| What happened | Command state |
|---|---|
| A gateway transmitted the downlink | DELIVERED; a one-way command then ends SUCCESSFUL |
| The command’s expiry passed before it could be sent | EXPIRED |
| Wrong parameters or payload too large, before it was ever sent | EXPIRED |
For a confirmed downlink, the command’s state follows the first transmission. The acknowledgement itself, and any re-sends, show in the frames log.
The frames log shows each downlink as Downlink, Sent via gateway with its window (RX1, RX2 or RXC) and its FPort. A Basics Station gateway does not report failed transmissions; the gateway’s lora.gw.dn_unknown counter shows downlinks without a result.
Downlinks you do not send yourself
The network server also sends acknowledgements of confirmed uplinks, join accepts and MAC commands (ADR and radio settings). These do not appear as commands. See ADR, data rates and MAC commands.