LwM2M (Lightweight M2M) adds full device management on top of CoAP/DTLS: standardized objects, lifecycle registration, server-initiated observe, and remote execute. Where plain CoAP just ingests telemetry, LwM2M lets CORE-M manage the device — read and write its resources, observe sensors, run firmware updates, and trigger actions — using the OMA object model.
| LwM2M (plain UDP) | 5683 |
| LwM2M over DTLS | 5684 |
Production uses DTLS on 5684. The same DTLS-PSK and certificate auth as
CoAP applies — identity is established by the handshake.
sequenceDiagram
participant Dev as LwM2M Client (device)
participant BS as Bootstrap server
participant SRV as CORE-M LwM2M adapter :5684
participant RP as Redpanda telemetry.raw.{tenant}
Dev->>BS: Bootstrap request
BS-->>Dev: Server + security config
Dev->>SRV: Register (endpoint name = urn:imei:123)
SRV->>SRV: Map endpoint name → device_id, mark online
SRV-->>Dev: 2.01 Created (registration id)
SRV->>Dev: Observe /3303/0/5700 (temperature)
Dev-->>SRV: Notify /3303/0/5700 = 22.5
SRV->>RP: Publish TelemetryPoint numeric_values.temperature=22.5
Note over SRV,Dev: Later: Execute /3/0/4 (reboot)<br/>delivered as a device RPC
SRV->>Dev: Execute /3/0/4
Dev-->>SRV: 2.04 Changed (RPC status updated)
Bootstrap — the device contacts the bootstrap server and receives its server connection and security configuration. (Devices pre-configured with the server can skip this and register directly.)
Register — the device registers with the CORE-M LwM2M adapter using its
endpoint name (for example urn:imei:123). The adapter maps that endpoint
name to the platform device_id, marks the device online, and records
last_seen.
Observe — the adapter observes the resources mapped to metrics. Each
notification is converted into a TelemetryPoint and published to
telemetry.raw.{tenant_id}.
Execute — server-initiated actions (reboot, firmware apply, custom commands) are delivered to the device as LwM2M Execute operations, driven by CORE-M’s device RPC mechanism.
A device registers with an endpoint name, not a CORE-M UUID. The adapter keeps the mapping so all telemetry, status, and commands resolve to the right device:
| LwM2M endpoint name | CORE-M device_id |
|---|---|
urn:imei:123 | d7b1c0e2-3f44-4a91-9b2e-2c5a1f0e9d33 |
The mapping is established at provisioning time. On register, the adapter looks up
the endpoint name, attaches the resolved device_id, and publishes a
device.status event marking the device online.
LwM2M exposes data as /objectID/instance/resourceID. The device profile maps
each resource path to a CORE-M metric name; observe notifications on those paths
become numeric_values (or string_values) on the telemetry point.
| Resource path | OMA object / resource | CORE-M metric |
|---|---|---|
/3303/0/5700 | IPSO Temperature → Sensor Value | temperature |
/3304/0/5700 | IPSO Humidity → Sensor Value | humidity |
/3323/0/5700 | IPSO Pressure → Sensor Value | pressure |
/3/0/9 | Device → Battery Level | battery_level |
For example, an observe notification carrying /3303/0/5700 = 22.5 produces a
TelemetryPoint with numeric_values.temperature = 22.5. Add or change mappings
in the device profile — no firmware change required.
A CORE-M server→device RPC maps onto an LwM2M Execute on a resource. The classic example is reboot:
| RPC method | LwM2M Execute path |
|---|---|
reboot | /3/0/4 (Device → Reboot) |
factory_reset | /3/0/5 (Device → Factory Reset) |
An operator (or rule) issues an RPC — method="reboot" — for the device.
The LwM2M adapter translates it to an Execute on the mapped resource (/3/0/4)
and sends it to the device.
The device’s response updates the RPC’s status, so the caller can see whether the action succeeded.
This is how device management actions stay protocol-agnostic at the API layer: the same RPC interface drives Execute on LwM2M, a command topic on MQTT, or an SSE downlink on HTTP.
Reach for LwM2M when…
For pure telemetry on constrained hardware without management, plain CoAP is lighter.