Overview

LoRaGuard Overview

Getting Started

Learn how to start with LoRaGuard and set up your first application:

Getting Started

Application Overview

Organization Dashboard

The organization dashboard provides a high-level summary of the entire LoRaWAN fleet across all applications. It shows active versus inactive devices and gateways, alert configuration status, and a quick breakdown of application-level health. From here, administrators can validate network status, track fleet size, and identify operational gaps.

Application Overview

Each application dashboard aggregates all devices and gateways linked to that integration token. It surfaces core RF quality metrics (RSSI, SNR), missed-frame counts, duty-cycle behavior, and sending intervals. Energy and signal scores provide fast insight into battery efficiency and RF reliability across the application.

Historical Trends

The trends view visualizes 24-hour performance to highlight deterioration or improvement. Device activity separates active from offline units, KPI scoring shows energy and signal drift, and signal-quality charts track RSSI and SNR stability. Hourly event histograms reveal outage waves or localized RF problems.

Energy Monitor

The energy monitor focuses on battery-efficiency analytics. It breaks down the distribution of energy scoring across devices, flags excessive frame loss or long airtime that drains power, and recommends practical optimizations such as expanding gateway coverage or addressing retransmission hotspots.

Gateway Overview

The gateway dashboard tracks LoRaWAN backhaul performance at scale. It ranks gateways by connected device count, highlights weak-signal nodes, and isolates offline infrastructure. The view helps determine RF coverage strength, regional capacity limits, and infrastructure failures.

How it works

LoRaGuard passively ingests LoRaWAN uplinks via a read-only webhook. There is no downlink path, no write-access to a Network Server, and no modification of payloads or device configurations. All communication is one-directional:

Uplink Ingestion and Resource Discovery

Every uplink contains metadata such as DevEUI, gateway identifiers, RSSI/SNR values, timing, frame counters, and protocol settings. When an uplink arrives:

  • Devices are looked up by DevEUI. If a device does not exist, it is created and linked to the Application based on the associated integration token.

  • Gateways are looked up by gateway ID. Unknown gateways are created automatically and assigned to the same organization.

  • Last-seen timestamps are updated along the way.

  • Version-1 ignores PacketBroker gateways to avoid duplication.

This enables zero-touch onboarding: once uplinks flow, inventory builds itself.

Time-Series Storage

Each uplink writes a snapshot of radio data and KPIs into TimescaleDB:

  • RSSI, SNR

  • Spreading factor and bandwidth

  • Frequency

  • Frame counters

  • Payload size and airtime

  • Energy score and signal score

Gateways store their own time-series records separately.

Device-Level KPIs

Uplinks are compared against prior device statistics to compute rolling behavioral metrics:

  • Sending interval

  • Airtime efficiency

  • Frame counter progression and missed frames

  • Duty-cycle behavior

  • Device energy score (1=excellent, 5=critical)

  • Device signal score (1=excellent, 5=critical)

As uplinks accumulate, these KPI fields converge toward trend values.

Gateway Tracking

Each gateway/device pairing is registered once and updated efficiently. This enables:

  • Unique gateway counts per device

  • Gateway-level device-counts

  • Gateway last-seen tracking

Everything is handled via inserts and upserts to avoid full table scans.

Online/Offline State

Device and gateway online state is inferred from uplink history. A scheduled process runs every few minutes:

  • If a device has not been seen within its per-application offline threshold, it transitions to offline and emits a DEVICE_OFFLINE event.

  • Gateways follow a similar rule with per-gateway or organization defaults.

No polling is required from the user side.

Anomaly Detection

Threshold-based anomaly rules examine trend breaks. Examples:

  • RSSI degradation beyond threshold triggers a SIGNAL_DROP event.

  • Frame counter jumps trigger missed-frame detection.

  • Very low SNR signals degraded demodulation conditions.

  • Abnormal energy score changes mark behavioral drift.

  • Duty-cycle exceedance detects regulatory breaches.

Redis-backed cooldown prevents repeated anomalies from spamming the event system.

Application-Level Aggregation

Every five minutes, scheduled jobs aggregate all device statistics into application-level KPIs:

  • Rolling RSSI/SNR

  • Average energy and signal scoring

  • Duty-cycle percentage

  • Missed-frame rate

  • Sending interval trends

  • Active/offline device counts

  • Unique gateway counts

These aggregated values feed dashboards and serve as the basis for anomaly scoring at application scope.

Event Logging

All anomalies, offline transitions, and degradations are logged append-only into a time-series event table. No updates, no rewrites. The system favors durability over retrospective mutation.

Alert Aggregation

Once per minute, recent events are grouped by application and organization. This prevents issuing one email per device and instead produces a single alert:

Organization-level settings control:

  • Enabled alert types

  • Severity thresholds

  • Deduplication timing

  • Muting windows

Scoring Visibility

Because statistics are computed in batches, dashboards require a short warm-up period. Metrics typically appear within five minutes of initial data ingestion.

NextGetting Started

Last updated