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, if the Center will provision it, the AppKey.

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.

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

Connect a source

Give a device network somewhere to post, and make sure only it can.

Decode the payload

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