This page explains what happens between a LoRaWAN sensor sending a frame and a reading appearing on its device in Hermetry. Read it once before you add gateways and devices; most troubleshooting starts from this picture.
The parts
| Part | What it does |
|---|---|
| End device (sensor) | Sends short radio frames (uplinks) and listens briefly for answers (downlinks). |
| Gateway | Receives every LoRaWAN frame in range and forwards it to the network server over the internet. It also transmits downlinks. A gateway does not know which devices are yours. |
| Network server | Hermetry’s built-in server. It checks each frame, merges copies heard by several gateways, keeps the device’s session and counters, runs the MAC layer (ADR and other radio settings) and plans downlinks. |
| Join server | Part of the network server. It answers join requests of OTAA devices and creates their session keys. |
| Codec | Turns the bytes of a frame into named values, for example temperature and humidity. |
| Flows | Your device messages pass through the root flow, which stores the values and runs alarm rules. |
Gateways and end devices are both devices in Hermetry. A gateway lives on the built-in LoRaWAN gateway profile; an end device you add by hand lives on the built-in LoRaWAN EU868 Class A OTAA (1.0.3) profile. Both are created the first time you need them.
From a sensor to a reading
- The sensor sends an uplink. Every gateway in range hears it.
- Each gateway forwards its copy, with the signal strength (RSSI) and quality (SNR) it measured, to your organisation’s network server address.
- The network server collects the copies of the same frame for a short window (200 ms by default) and merges them into one uplink. Copies are merged only within one organisation: a frame heard by another customer’s gateway is never mixed with yours.
- It checks the frame: the device address (DevAddr) must belong to one of your devices’ sessions, the integrity check (MIC) must pass with that session’s key, and the frame counter must move forward. A frame that fails is dropped and shown in the frames log with its reason.
- It processes MAC commands the device sent and decides whether an answer is needed (an acknowledgement, a MAC request, or a queued downlink).
- It decodes the application payload with the device’s codec. Without a codec, or when decoding fails, the raw payload is passed on as hex under the key
raw. - It writes one device message for the uplink. When the profile setting Add the radio values (lora.rssi, lora.snr, …) to every message is on, the message also carries
lora.rssi,lora.snr,lora.gw_count,lora.dr,lora.freqandlora.fcnt_up. - The message runs through your root flow like any device message. The root flow stores the values.
One uplink is one device message, however many gateways heard it. Frames on FPort 0 (MAC commands only) write no device message.
De-duplication
Several gateways often hear the same uplink. The network server keys each copy by your organisation and the exact frame bytes. The first copy opens a group; copies that arrive within the window join it; when the window closes the uplink is processed once, with the list of every gateway that heard it. A copy that arrives after the window closed is counted as late and ignored.
The best gateway (highest SNR, then RSSI) is used for the radio values in the message and is the first choice for an answer.
Joins
An OTAA device must join before it can send data. Its join request goes through the same gateways and de-duplication. The join server checks the device’s DevEUI, JoinEUI, AppKey and DevNonce, creates a session, and sends a join accept back through the best gateway that can still reach the device in time. See How a device joins.
An ABP device does not join. Its session (address and keys) is entered when you add it.
Answers and downlinks
A Class A device listens only in two short windows after each uplink (RX1 and RX2). The network server picks the gateway and window that can still make it, given the gateway’s round trip and its duty-cycle budget. A Class C device listens all the time, so its queued downlinks go out at once. See Device classes and Sending downlinks.
Isolation between organisations
Every DevEUI and every gateway EUI can be registered only once on the whole platform. When you try to register one that another organisation holds, Hermetry says it is taken and never says who holds it. Frames of another organisation’s devices that your gateways hear are dropped as “A device of another network” and nothing about that device is shown to you.
What is not stored
The network server keeps only a short frames log (the last day, at most 1,000 frames per organisation) and the latest reception of each device. Reception history is stored only when your flow saves the lora.* keys with the other values, which the default root flow does when the profile adds them to the message.