Guides

Add your devices

Create devices, bind them to networks, and let the Center provision them.

A message can only be decoded if the Center recognises the device it came from. That means creating the device with the identifier its network uses.

Create one

Devices → New device. Pick the project, give it a reference you will recognise, then Add technology and fill in the network's identifiers.

For Sigfox that is the Device ID, the PAC, and the device type ID. For LoRaWAN, the DevEUI and an Activation choice: OTAA — the usual case — takes the JoinEUI and AppKey (plus NwkKey on LoRaWAN 1.1); ABP takes the DevAddr, NwkSKey and AppSKey of a session the device already holds. Above those, the LoRaWAN row asks Where does this device come from? — Register a new device (type the identifiers) or Adopt one already on the LNS (pick it from the project's application; see LoRaWAN provisioning).

The identifier must match exactly

This is how an arriving message finds its device. A wrong identifier does not raise an error — the message simply arrives unmatched and undecoded, which looks like a decoder problem and is not.

Attach a profile

Set the device's profile to say what model it is. The profile brings the decoder and the field schema with it, so a device without one delivers raw payloads.

The profile also decides which fields are required. Miss one and saving fails with the exact field named — attributes.pac, secrets.encryptionKey — rather than succeeding into something that never works.

See Devices & profiles.

Inherited defaults

Fields you leave blank can be filled from the project's provider defaults — the Sigfox device type, the LoRaWAN application. Set those on the project and new devices stop needing them typed in.

Anything you do enter on the device wins over the inherited value.

Editing secrets

Secrets are encrypted and never shown again. When editing a binding, leave a secret field blank to keep what is stored — you only type a value to replace it.

So you can correct a device's reference or device type without needing to know its encryption key.

Sigfox provisioning

For Sigfox the Center can create things on the backend for you rather than you doing it in the Sigfox console.

Every provisioning action comes in two halves:

Plan

A dry run. Shows the exact requests that would be sent, and changes nothing. Always safe.

Apply

Sends them for real. Gated by an environment switch, so a Center configured for read-only cannot write to Sigfox even by accident.

Run Plan first and read it. It tells you what would be created, what would be updated, and what is already correct.

Apply is idempotent — running it twice does not duplicate anything, it reconciles. That is what makes it the supported fix after an ingest URL changes: re-apply the callbacks and they are rewritten to the current endpoint.

The contract decides what is possible

On Sigfox, a device type's contract governs which callback variables are authorised, and the contract cannot be changed after the device type is created. A device type with no contract has no authorised variables at all. If callbacks register but arrive empty, this is usually why.

Adopt a device the Backend already has

When the device already exists on Sigfox — a meter provisioned from the Sigfox console, or one moving over from another application — switch the Sigfox row of the form to Already on Sigfox — pick it. The list shows the devices under the project's group (sub-groups included), narrowable to one device type, and picking one fills the ID, PAC, name and device type from Sigfox. The provisioning step then only recognises it: nothing is created twice.

Register, recognise, or transfer

Creating a device ends on a Sigfox step; the same panel is on the device page. It shows what the Backend has for the device ID — not there yet, or on which device type and group, with the last message time — beside the Center's own record, and offers one of two actions:

Register, or recognise — creates the device on the target device type when Sigfox does not have it, and records it when it is already there. A device that sits on another device type is reported, not moved.
Transfer to the target device type — moves such a device, using the Backend's transfer job (the only way a device changes device type). Choose whether its message history comes along.

The target device type defaults to the device's own, then the project's default, then the device type the project's Sigfox source created — so a project set up through the source wizard needs no extra choice. Preview always shows the exact requests; Apply is gated like every other write. Remove from Sigfox deletes the device on the Backend and keeps the Center device.

LoRaWAN provisioning

On The Things Stack the Center goes one step further than Plan → Apply. Once the project is linked to the LNS, a LoRaWAN device is kept in step automatically:

Creating a device with a LoRaWAN binding registers it on the LNS — or recognises it when the application already has that DevEUI. Nothing is created twice.
Editing follows. A changed key re-sends the keys; a changed class, frequency plan or MAC setting updates the Network Server; a new name is pushed; a changed DevEUI removes the old registration and makes a new one.
Deleting the device (or its LoRaWAN binding) removes it from the LNS too. The delete dialog has Also remove it from The Things Stack, ticked by default — untick it to keep the registration.

Every one of these is fail-open: the Center saves your change even when the LNS refuses, and the refusal shows up on the device page instead. Sigfox stays Plan → Apply.

Adopt a device the LNS already has

When the device already exists in the project's application — registered from the LNS console, or by someone else — switch the LoRaWAN row of the form to Adopt one already on the LNS. The picker lists the application's end devices (one already in the Center is shown but not offered) and fills the DevEUI and JoinEUI; its keys stay on the LNS. The Center then recognises it rather than registering it again.

Register, move, or re-key

Creating a device ends on a The Things Stack step; the same card is on the device page. It shows the Center's record beside what the LNS has for the DevEUI — Registered on the LNS or Not on the LNS yet — and what the last apply did: registered, recognised — already on the LNS, moved from its previous application, keys updated, radio settings updated, renamed. When an apply failed, the card says at which step and quotes the LNS's reason.

Preview → Register on LNS is a retry or repair now that the hooks do the routine work: run it after a refused change, for a device created while live writes were off, or to finish a half-registered one.
Move appears when the device is registered in another application — the project was re-linked since. It removes the old registration with the tenant's key, then registers the device here.
Re-send keys re-sends only the keys of a registered device — the OTAA root keys, or the ABP session.
Remove from LNS deletes the registration and keeps the Center device.

On the devices list, select several devices and use Register on the LNS or Remove from the LNS on the selection.

Many devices at once

Bulk creation goes through the API rather than the UI. The endpoints are the same ones the app uses, documented in the API reference — create the device, then add its technology binding.

The field schema is enforced identically there, so a script gets the same clear errors as the form.

Check it worked

Send an uplink and open Analytics. If Received went up but your sink got raw hex, the device matched and the decoder is the next thing to look at. If nothing was received at all, the problem is upstream in the source.

Decode the payload

Bytes into readings.

Check coverage

Whether the network reaches where the device is going.

Edit this page

Tune LoRaWAN receive windows

Make a LoRaWAN device answer in the same exchange, like Sigfox — and own the rest of its MAC settings from the Center.

Decode the payload

Turn raw bytes into named readings your rules and sinks can use.