LoRa Monitor 3DFAB — LoRa Helios

01Context

LoRa Helios is the sensor monitoring platform developed for 3DFAB. It turns LoRaWAN transmissions received through The Things Network (TTN) into information operators and users can consult. Each reading is associated with a device and timestamp, supporting both latest readings and historical views.

The operator, users and I used the main system with physical sensors to check reception on September 19, 2026. The core system is deployed and operational in production. Mobile GPS tracking is a separate, non-operational experiment.

02Problem

Receiving a message is not enough to analyze it. Sensors and decoders may use different field names, omit optional values and supply different timestamp formats. Repeated submissions and device-specific user permissions add further requirements.

The software needed a common model and a clear workflow: find a node, check the age of its readings, inspect its history and compare it with others without manually interpreting every payload.

03My role

I designed and implemented the full-stack software: TTN webhook integration, validation and normalization, Express API, MongoDB models and indexes, auxiliary caching, authentication and device access. I also developed the React dashboard, history queries, node comparison, exports and user administration.

I prepared container configuration and architecture/deployment documentation and checked reception with the operator and users. The mobile device trial was a team effort; this account attributes the software and integration work to me.

04Constraints

Design documentation assumes typical sensor transmissions every 10–30 minutes; this review did not measure that frequency in production. The dashboard polls the API every 30 seconds. Refreshing shows received data without increasing measurement frequency or creating continuous tracking.

Payloads depend on the sensor and decoder. Radio, TTN, the backend connection and the database are separate delivery dependencies. The model configures a 90-day TTL retention period. There is no durable ingestion queue or guarantee of recovering readings lost during an API restart. The portable GPS trial remains separate from core operation.

05Solution

The operator locates devices using search and filters, checks the latest reading and opens a node for investigation. They select variables and a date range, explore charts and export CSV history. A view of 2–10 devices supports comparisons. Export selects dates and a variable independently of the chart’s quick reading-count limit.

Administrators manage users and device assignments, while clients query authorized nodes. Cards adapt to available fields. Coordinate and speed support exists in the software, but operation of the mobile GPS device remains experimental.

06Architecture

The write path is LoRaWAN node → gateway → TTN → authenticated webhook → Express API → MongoDB. TTN supplies decoded payloads; the backend validates the envelope, normalizes fields and stores the reading. Ingestion works independently of an open dashboard.

React and Vite power the interface and Recharts displays histories. The dashboard summary polls the API every 30 seconds; history details reload when filters change or an update is requested. Redis caches device summaries; MongoDB is the primary store. Redis also receives internal Pub/Sub events, but no consumer turns them into browser push updates.

07Data pipeline

1. TTN submits device identification and decoded_payload. The API checks webhook credentials, limits requests and validates the envelope with Joi.

2. Normalization resolves aliases for up to 11 available variables: particulate matter, temperature, humidity, battery, coordinates, speed and radio quality. RF metadata comes from the first reported gateway, with payload fallbacks. The original input is retained for diagnostics.

3. The reading is stored, the device is created or updated, and summary cache invalidation is attempted. Success is returned after processing; there is no queue acknowledging before persistence. Reconstructed local dates receive a UTC suffix, so the firmware must use a compatible time convention.

08Concurrency and packet loss

A unique MongoDB index on deviceId and receivedAt prevents two readings with the same key from being stored, including competing inserts. The application treats a duplicate-key error as a successful repeat. An additional test sent 20 identical requests simultaneously, retaining one reading and one device with 19 duplicate responses. This protects that measurement identity; it does not recover radio packet loss.

Retries need a stable timestamp. If it is missing, normalization may assign receipt time and produce different keys. Saving a measurement and updating a device are separate operations, without a transaction covering the entire workflow. Fault injection reproduced a persisted reading with HTTP 500 and no device record.

When no Redis cache entry is available, the summary query reads MongoDB. This preserves a read path without making cache the main store. Ingestion has no durable queue or backend-owned retry mechanism; capacity and recovery must be evaluated per scenario.

09Decisions

MongoDB versus PostgreSQL: optional document fields and device/date indexes fit the decoders and Mongoose model. PostgreSQL with JSONB was also a valid alternative. The implementation uses a conventional indexed collection with TTL, not a native time-series collection.

Polling versus WebSockets: a 30-second query interval suits infrequent transmissions and simplifies connection and proxy handling. The trade-off is that the screen does not receive every event instantly.

Auxiliary caching: Redis reduces repeated summary queries while history stays in MongoDB. Uncached reads can have a different cost.

Bearer versus HMAC: the integration uses TTN-supported credentials and timing-safe comparison. This authenticates the call rather than individually signing its content. Three ADRs document these decisions.

10Security

JWT authentication and role/device assignment checks restrict clients to their nodes and user management to administrators.

The webhook has separate credentials, timing-safe comparison, Joi envelope validation and request limiting. Request records aid diagnostics, but the available tests do not establish complete traceability for every event. Envelope validation does not establish the physical validity of sensor measurements.

Key configuration, TLS, proxy behavior, allowed origins and service exposure are deployment concerns. The tests in this case study provide bounded functional evidence, not certification or a complete security audit.

11Testing

On October 3, 2026, the original suite was rerun against reviewed local code with Node.js 22.23.2, Jest, Supertest and temporary MongoDB: 98/98 cases across 7 test files. Line coverage was 79.45%, and all four metrics exceeded the configured 70% threshold. The frontend built successfully; Vite warned that the JavaScript bundle exceeds 500 kB. These checks did not test TTN, physical sensors or production.

The 10 separate checks of concurrency, normalization, uncached reads and partial persistence failure belong to the isolated September 19 review; they were not rerun on October 3. The five public-example cases were run again. The original suite does not establish persistence of every audit event. Redis client behavior is mocked; this does not represent an actual Redis server outage. The table separates dates and scope.

12Deployment

Docker Compose separates the Express backend, compiled frontend served by Nginx and Redis, with restart policies and health checks. Documentation describes Coolify deployment and MongoDB Atlas as external storage.

I prepared that configuration and deployment documentation. The core system is deployed in production. The technical review ran locally without exposing the production application server; configured health checks are not presented as a measured availability history.

13Outcome

The result is a shared workflow for reviewing reception and exploring measurements: latest readings, device/date histories, multi-node comparison and CSV export. The core system operates in production with verified field sensor reception by the operator and end users.

The functional benefit is a common representation of data and permissions in one interface. No percentage time saving or measured uptime is claimed. Mobile GPS remains a separate experimental extension.

14Evidence

This case combines reviewed local code, three documented architecture decisions, local test verification and active field deployment. An isolated September 19, 2026 review added 10 checks; on October 3, the 98 original tests were rerun, the frontend was built and the public sample was verified.

Tests used synthetic data and temporary MongoDB. They did not access operational databases or the application server. The core deployment is active in production, while production uptime, latency and radio delivery were not formally measured.

The video shows the interface and the final section presents the five-case normalization example. Real sensor data and infrastructure access details are not published.

15Software quality and UX

The interface emphasizes finding readings and understanding their age. The activity indicator means the latest reading is less than 30 minutes old, not that sensor connectivity was directly tested. Search, filters and detail views shorten navigation to a specific node.

Charts support date ranges and different scales; comparison displays multiple device series on a common time axis without physically correcting their clocks. CSV export supports analysis outside the dashboard.

Resolving aliases with ?? preserves valid zeros. Distinguishing zero from a missing value prevents the UI from hiding a real reading. The following example isolates and tests that decision.

16Code sample and engineering test

A self-contained public adaptation of the normalization rule: three environmental variables, equivalent aliases, canonical-name precedence and null for missing data. It excludes authentication, persistence and private data.

The test runs five inputs and checks that the original payload is unchanged. It demonstrates this normalization contract; backend concurrency is checked separately in the testing section.

1
// Isolated adaptation: decoded sensor fields only.
2
function normalizeSensorPayload(rawPayload) {
3
  const data = rawPayload.uplink_message?.decoded_payload ?? {};
4
  return {
5
    temperature: data.temperature ?? data.temp ?? data.t ?? data.temperatura ?? null,
6
    humidity: data.humidity ?? data.hum ?? data.h ?? data.humedad ?? null,
7
    battery: data.battery ?? data.batt ?? data.v_bat ?? null,
8
  };
9
}

1
import assert from 'node:assert/strict';
2
// Run together with the sample using Node.js.
3
const cases = [
4
  [{ temperature: 0, humidity: 0, battery: 0 },
5
    { temperature: 0, humidity: 0, battery: 0 }],
6
  [{ temp: 21, hum: 45, batt: 3.7 },
7
    { temperature: 21, humidity: 45, battery: 3.7 }],
8
  [{ temperatura: 18, humedad: 60, v_bat: 3.5 },
9
    { temperature: 18, humidity: 60, battery: 3.5 }],
10
  [{ temperature: 0, temp: 99, humidity: null, hum: 40 },
11
    { temperature: 0, humidity: 40, battery: null }],
12
  [{}, { temperature: null, humidity: null, battery: null }],
13
];
14
15
for (const [input, expected] of cases) {
16
  const raw = { uplink_message: { decoded_payload: input } };
17
  const before = JSON.stringify(raw);
18
  assert.deepEqual(normalizeSensorPayload(raw), expected);
19
  assert.equal(JSON.stringify(raw), before);
20
}
21
// 5 cases: zeros, aliases, precedence, missing fields, no input mutation.

5 cases executed: zeros, abbreviated aliases, Spanish aliases, precedence and missing fields; all original inputs preserved.