Connecting devices

Getting a device onto CORE-M is a four-step path. Every device — a battery sensor on HTTP, a fleet of meters behind an MQTT gateway, an SNMP switch — follows the same shape:

1. Provision the device. Create its identity in your tenant. Do this in the field with a provisioning key, one at a time from the dashboard, or in batches with a bulk CSV import.

2. Get credentials. Provisioning returns a device identity and a credential — typically an API key, but a device can also present a PSK or an X.509 client certificate. See Device identity & credentials.

3. Pick a protocol. Choose the transport that fits the hardware and network. CORE-M ingests over HTTP, MQTT, CoAP/DTLS, LwM2M, and SNMP. The decision table below helps you pick.

4. Send telemetry. Authenticate with the credential from step 2 and start publishing data points. Each accepted point flows through validation, dual storage, and blockchain anchoring.

Note

A device profile can carry defaults for every step — protocol config, telemetry schema, anchoring policy, and more — so a device inherits a consistent setup the moment it is created. Attach a profile at provisioning time and you skip most of the per-device configuration.

Choosing a protocol

All five transports terminate at the device-link service and converge on the same ingest pipeline, so your choice of protocol does not change how telemetry is validated, stored, or anchored. Pick based on the device, the network, and how much you control the firmware.

Protocol	Best for	Transport	Auth	Payload
HTTP	Simple devices, scripts, gateways, anything that can make a request	TCP / TLS	API key (Authorization: Bearer or X-API-Key)	JSON
MQTT	Always-on devices, fleets, low-overhead pub/sub, bidirectional commands	TCP / TLS	API key as MQTT password, or X.509 client cert (mTLS)	JSON
CoAP	Constrained/low-power devices, lossy or low-bandwidth networks	UDP / DTLS	PSK (DTLS) or X.509 client cert	JSON / CBOR
LwM2M	Managed device fleets needing standardized objects and remote management	UDP / DTLS (over CoAP)	PSK or X.509 client cert	LwM2M objects / TLV / CBOR
SNMP	Existing network gear (switches, routers, UPS, PDUs) you cannot reflash	UDP	SNMP community / USM credentials	SNMP OIDs (polled)

Tip

If you control the firmware and the device is always powered, MQTT is the default recommendation: low overhead, persistent connection, and a clean path for server→device commands. Reach for HTTP when you just want to fire off a request, and CoAP/DTLS or LwM2M when power and bandwidth are tight.

Decision flow

flowchart TD
  start([New device to connect]) --> ctrl{Can you run<br/>custom firmware?}
  ctrl -- No --> snmp["Use **SNMP**<br/>(poll existing network gear)"]
  ctrl -- Yes --> power{Battery / low-power<br/>or lossy network?}
  power -- Yes --> managed{Need standardized<br/>remote management?}
  managed -- Yes --> lwm2m["Use **LwM2M**<br/>(over CoAP/DTLS)"]
  managed -- No --> coap["Use **CoAP/DTLS**<br/>(PSK or client cert)"]
  power -- No --> conn{Always-on connection<br/>and/or server commands?}
  conn -- Yes --> mqtt["Use **MQTT**<br/>(API key or mTLS)"]
  conn -- No --> http["Use **HTTP**<br/>(API key)"]

Where to go next

First-device walkthrough End-to-end: provision a device, grab its key, and send your first HTTP telemetry point.

Device identity & credentials device_id vs hardware_id, and how API keys, PSKs, and client certs are issued and presented.

Provisioning by key claim Factory self-provisioning: devices claim their identity with a pre-shared key.

Manual registration Register a single device from the dashboard or API as a tenant admin.

Bulk import Import a factory batch from CSV and hand out provisioning keys.

Device profiles Reusable defaults and policies devices inherit at provisioning time.