Data Flow¶
This page describes how device data moves through the N-Hub platform from device to dashboard.
Message Lifecycle¶
graph LR
A[Device transmits] --> B[Network delivers]
B --> C[Platform ingests]
C --> D[Deduplicate]
D --> E[Decode payload]
E --> F[Store readings]
F --> G[Available via API / Portal / MQTT]1. Device Transmission¶
An IoT device (sensor, meter, tracker) transmits a data message. For LoRaWAN devices, this is received by one or more base stations and forwarded to the network server.
2. Network Delivery¶
The network server (e.g., ThingPark Wireless) delivers the message to N-Hub via an HTTP webhook. For MQTT-connected devices, data arrives directly at the MQTT bridge. The message payload typically includes:
- Device identifier (e.g., DevEUI for LoRaWAN)
- Raw payload (hex-encoded binary data)
- Network metadata (signal strength, timestamp, gateway info)
3. Ingestion¶
The platform receives the message and queues it for asynchronous processing. The ingestion endpoint returns immediately — no processing happens in the request path, ensuring the upstream system is never blocked.
4. Processing¶
The processing pipeline handles each message through these stages:
| Stage | Description |
|---|---|
| Deduplication | Checks if this exact message was already processed (prevents duplicates from network retries) |
| Device resolution | Looks up the device in the registry by its identifier |
| Payload decoding | Runs the active parser (JavaScript) to convert raw bytes into structured readings |
| Validation | Verifies the decoded data meets expected formats before storage |
5. Data Available¶
Once stored, data is immediately available through:
- REST API — query readings by device, time range, or enterprise
- Web Portal — view device status, latest readings, and trends
- MQTT Streaming — receive readings in real time as they are processed
Error Handling¶
| Scenario | Behavior |
|---|---|
| Duplicate message | Silently dropped (deduplication) |
| Unknown device | Logged and retried — unresolved messages are dropped after retry limit |
| Parser error | Logged with device and payload details for investigation |
| Temporary processing failure | Automatic retry with backoff |
Retry behavior
Messages that fail processing are automatically retried with increasing delays. If a message cannot be processed after all retries, it is logged with full diagnostic details for investigation.