The Things Stack + Lumra

Lumra for The Things Stack

When a shipment is held or a sensor alert is disputed, a dashboard screenshot is rarely enough. Lumra preserves selected TTN uplinks as tamper-evident records and portable ProofPacks that another party can check.

Discuss a controlled pilotSee the connection path

Controlled pilot preparation. Not generally available or an official TTN Console tile.

The expensive part is explaining what happened later.

The first alert is only the start. A quality team may spend hours comparing exports, checking whether expected readings are missing, and explaining why two systems show different times. Lumra is for the small set of readings where those questions can delay a decision or turn into a dispute.

01 / Preserve

Keep what arrived

The complete JSON uplink delivered to Lumra is retained as the source body. TTN's claimed time and Lumra's receipt record remain distinct.

02 / Seal

Make changes detectable

Accepted records are signed and linked in a tenant-scoped history. Exact repeats of a TTN body can resolve to the same event within that tenant.

03 / Review

Export the evidence

A ProofPack gives a reviewer protected records and the material needed for an independent verification, without access to a Lumra account.

How an approved pilot connects

We first agree on one TTN application, the devices and reporting pattern, what counts as a missing reading, retention, and the pilot's success checks. No customer feed is enabled when someone asks about a pilot.

  1. Apply and receive a tenant-specific key.

    PriviNet checks the production release and delivery path before issuing credentials. Keep the key out of URLs, screenshots, and public samples.

  2. Add a custom webhook in The Things Stack Console.

    Under your application, choose Integrations, Webhooks, then Custom webhook. Use JSON, uplink messages only, and the approved Lumra host with path /v1/ingest/raw. Put the issued key in a secret X-API-Key header. Do not add a downlink key or filter out fields.

  3. Prove the route with synthetic data first.

    Confirm authentication, one event after an exact replay, tenant isolation, response time, and a retrievable package. Connect approved live devices only after those checks pass.

  4. Export and independently review.

    Agree on batch and export cadence. Run the standalone verifier with an appropriate trust root obtained separately from the package. Record any unresolved timing or completeness limits.

A proposed Lumra template is in TTN pull request #115. It is not available as an official Console tile unless TTN merges and releases it. An approved pilot can use a custom webhook in the meantime.

What the record can answer

Was a protected reading changed?

The verifier checks protected content and signatures against the supplied trust material.

Were readings missing?

Only when the pilot defines its device roster and expected intervals in advance. Event-driven sources need different expectations.

When did it happen?

The package separates source-claimed observation time, Lumra receipt, and any later external batch timestamp. A batch timestamp does not prove the sensor's observation time.

Can a reviewer inspect a sample?

Yes. The synthetic cold-chain example and verifier instructions illustrate the evidence format. They are demonstrations, not TTN customer records.

The record cannot certify that a sensor was accurate, recover uplinks that never arrived, or guarantee a legal outcome or EU-qualified status.

Start with one question worth answering.

Tell us the TTN application, the devices and cadence, and the incident or audit question you need to resolve. We will scope a controlled pilot with written success criteria before live traffic is connected.

Discuss a controlled pilot