A LoRaWAN device’s class decides when it can receive. Hermetry supports Class A and Class C. Class B (scheduled receive slots with gateway beacons) is not supported.
Class A
Every LoRaWAN device supports Class A. After each uplink the device opens two short receive windows, then sleeps until its next uplink:
| Window | When | Frequency and data rate |
|---|---|---|
| RX1 | RX1 delay after the uplink (5 s by default on Hermetry; 1 to 15 s) | The uplink’s channel; the data rate is the uplink’s minus the RX1 data-rate offset (0 by default) |
| RX2 | One second after RX1 | 869.525 MHz at DR0 by default |
What this means for you:
- A downlink to a Class A device waits until the device’s next uplink. A sensor that reports every hour receives a queued command up to an hour later.
- Only one application downlink fits in each pair of windows.
- The network server gives the gateway both windows in one message; the gateway tries RX1 first and RX2 if RX1 cannot be used.
How the gateway and window are chosen
For each uplink that needs an answer, the network server ranks the gateways that heard it:
- Directly connected gateways before relayed ones.
- The better signal: the SNR margin above what the data rate needs, then RSSI.
- The lighter downlink load in the last hour.
- The shorter round trip.
A gateway is used only when it is online, active, in cloud mode, and can still hand over the answer in time. RX1 is used when the answer can reach the gateway before the window, counting processing time, the gateway’s round trip and a 100 ms radio margin; otherwise RX2 if it still fits; otherwise the next gateway. The gateway must also have duty-cycle budget left on the window’s frequency. The frames log shows the gateway and window of each downlink, for example Sent via Roof north (RX1).
Class C
A Class C device keeps its receiver on all the time when it is not sending. It is usually mains powered: actuators, valves, relays, street lights.
| Item | Behaviour on Hermetry |
|---|---|
| When a downlink goes out | At once, without waiting for an uplink |
| Frequency and data rate | The device’s RX2 settings (869.525 MHz, DR0 by default) |
| Which gateway | The best gateway of the device’s latest uplink, with RX2 duty-cycle budget |
| How long the device is reachable this way | Up to 15 minutes after its last uplink (900 s, profile setting classCMaxAgeS, 60 to 86,400 s). After that a downlink waits for the next uplink. |
| Never inside the uplink’s own windows | A Class C downlink waits until the uplink’s RX2 window has passed (plus 0.5 s), so it never collides with the answer to that uplink. |
The device tab says it in one line: Class C devices listen all the time: their downlinks go out at once on the RX2 channel, through the gateway that heard them last.
Answers to a Class C device’s uplinks (acknowledgements, MAC commands) still use the Class A windows. Application downlinks go only the Class C way. In the frames log a Class C downlink shows the window RXC.
Confirmed downlinks to Class C devices
A confirmed downlink asks the device to acknowledge it in its next uplink. For a Class C device, Hermetry waits for the acknowledgement for the profile’s Confirmed downlink: wait for the acknowledgement (seconds) (60 s by default, 5 to 3,600 s). Without it, the downlink is sent again with a new frame counter, up to 3 sends in total (profile setting maxRetries). After that it leaves the queue as expired (no_ack).
Keep the device sending regular uplinks: the acknowledgement travels in an uplink, and the device can be reached directly only within 15 minutes of its last one.
Set the class
- When you add a device: choose A (battery, answers after each uplink) or C (mains powered, always listening) in the form.
- Later: on the device’s LoRaWAN tab, change Class and select Save class.
- Devices added by pairing mode get the class of their profile.
Set the class the device really runs. A Class A device marked as C misses downlinks sent at once; a Class C device marked as A receives them only after uplinks.