¶ LWM2M Server
This page contains detailed information about the LWM2M service in the Tartabit IoT Bridge. The embedded LWM2M server is fully compliant with the LWM2M 1.0 specification, and partially compliant with the LWM2M 1.1 specification.
¶ Features
- Protocols
- CoAP
- CoAP via UDP on port 5683
- CoAP via DTLS on port 5684
- Supports blockwise transfer, both BLOCK1 and BLOCK2 are supported from both the client and server.
- Block transfer originating from the server defaults to 1024 byte blocks, but can be overriden in the service configuration.
- Custom configuration of ACK_TIMEOUT, ACK_RETRIES, NSTART, and ACK_RANDOM_FACTOR.
- CoAP
- Encodings
- TLV (fully supported)
- Plain text (fully supported)
- JSON (not supported)
- Opaque (fully supported)
- SenML CBOR (fully supported, 1.1 only)
- LWM2M 1.1
- Composite-read
- Composite-write
- Composite-observe
- Send
- DTLS
The LWM2M server supports DTLS with the following features. If your device requires a different cipher or feature, please contact support.- Supported cipher suites:
- TLS_PSK_WITH_AES_128_CCM_8 (preferred)
- TLS_PSK_WITH_AES_128_CBC_SHA256
- TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8
- Session resumption via session_id
- Certificate based authentication
- Certificate
thumbprint basedauthentication is supported where each endpoint has the thumbprint for the certificate that the device will present. This allows fine control, at the expense of having to manage individual certificates for each endpoint. - Certificate
CA basedauthentication is also supported where a CA certificate is uploaded to the server and all clients connecting must use a certificate signed by the CA to be authenticated.
- Certificate
- Support for RFC-9146 (Connection ID)
- Server has a default CID length of 8 bytes, and cannot be changed at this time.
- CID sessions are persisted through maintenance cycles, and will be saved for up to 24 hours of inactivity by devices.
- Support for final RFC-9146 as well as RFC-9146-Draft-05 (Nov-2019) to accomodate devices deployed with older versions of the specification
- Note that future support for devices using the draft specification is not guaranteed and may change in the future.
- Supported cipher suites:
- Bootstrapping
Devices can bootstrap to the IoT Bridge using the same URL as registration. - By default, bootstrapping is enabled for all devices, and if a device bootstraps, it will be bootstrapped to connect to the same server using DTLS with a one time use pre-shared key.
- Custom bootstrap configurations can be configured using triggers supporting:
- NoSec and PSK security configurations.
- Single or multiple server configurations.
- Full control over ACL definitions.
- Queue Mode
Devices that register with "UQ" binding are enabled for queue mode operation. If any read, write, observe, or execute operation are attempted and reach their maximum CoAP retries, the request will be queued for the next available opportunity to communicate with the device.- Attempts to flush the queue occur after a registration or update message are received by the server.
- Read, Write, Observe, and Execute operations are elidgible to be queued, Discover requests are not.
- Queued messages are stored in persistent storage on the server ensuring that they can be safely managed for long durations.
- Bootstrap
- Supports Client-Initiated bootstrap.
- Automatically bootstraps the client to the Tartabit IoT Bridge application servers.
- Does NOT currently allow custom ACLs to be defined.
- Does NOT currently allow additional appliaction servers to be defined.
- Custom Objects
- Users can upload custom object definition XML files to support custom objects, or to override default objects provided by the system.
- LWM2M Browser
- Can read, write, and execute resources on connected endpoints.
- Can read instances on connected endpoints.
- Can change the encoding used for the operation between text, TLV, opaque, and SenML CBOR.
- Standard objects are all based on the LWM2M 1.1 object definitions, if using a LWM2M 1.0 client, you may see resources that are not implemented for your device.
- Limitations
- Cannot create or delete instances or resources
- Auto-creation of endpoints
- If using CA based authentication, the system can automatically create endpoints for new clients as they register.
- Optional saving of certificate thumbprint for additional security.
- Note: thumbprints only work if each device is issued a unique certificate.
¶ Service
The LWM2M service serves as an anchor for defined endpoints. It contains common information related to settings such as bootstrap and CoAP timeouts. You must have a LWM2M service defined before you can connect any LWM2M devices.
¶ Service Parameters
¶ Bootstrap
- Bootstrap Lifetime - The lifetime (in seconds) for the application server configuration that is sent to the device during bootstrap if no trigger defines a custom bootstrap configuration.
- Force Queue Mode - Force the device to be considered to support queue mode so the server will store messages for the device.
¶ CoAP
- CoAP Block Size - The block size to use for server-originated messages.
- CoAP Max Retransmit - The number of retries that the server will attempt if a request times out.
- CoAP Ack Timeout - The duration (in seconds) to wait for a reply from the client before initiating the next retry.
- CoAP Ack Random Factor - The random factor used to scale the timeout to avoid message synchronization.
- CoAP Max In-Flight Messages - The maximum number of messages allowed to be in-flight at any given time.
¶ DTLS
- DTLS CA Certificate - The PEM encoded CA certificate used to sign all client certificates. CA certificates require a unique Distinguished Name (DN) within the IoT Bridge. The certificate must start with -----BEGIN CERTIFICATE----- and end with -----END CERTIFICATE-----.
¶ Auto-Generate Endpoints
- Auto-generation enabled - Enable or disable autogeneration of endpoints, if enabled, and a device connects with a certificate that is signed by the CA in the service definition and the endpoint is not already defined, a new endpoint will be defined in the IoT Bridge.
- Auto-generation save thumpprint - Optionally, the IoT Bridge can save the thumbprint of the certificate in the endpoint definition. To use this feature, all devices must register with unique certificates signed by the CA specified in the service.
- Auto-generation time until missing - Optionally, the IoT Bridge can set the
Time before declared missingfield in the endpoint at the time the endpoint is created.
¶ Endpoint
The LWM2M endpoint contains information about the specific client that is connecting. Most importantly it holds the endpoint name, identity, and pre-shared key used for authentication. It is important to note that clients can bootstrap or register with the Tartabit IoT Bridge using the defined credentials, if the client bootstraps, it will be provided unique credentials to use during its subsequent registration.
¶ Endpoint Parameters
- LWM2M Endpoint - The endpoint (UTF-8 string) that the client will use to connect. (required)
- DTLS Identity or Certificate Thumbprint - If using PSK based authentication, this value should be the identity (UTF-8 string) that the client will use to authenticate. If using certificates, this value should be the thumbprint of the certificate. Thumbprints are the sha256 checksum of the raw DER encoded certificate represented as a hexedecimal string.
- DTLS Pre-shared key - The pre-shared key (hex encoded string) that the client will use for encryption.
¶ Trigger Events
¶ lwm2m.register
This event fires any time a LWM2M device successfully registers to the platform.
{
"binding": "U",
"credentials": "primary",
"remoteAddr": "1.2.3.4:34221",
"version": "1.1",
"discovery": {
"children": {
"1": {
"children": {
"0": {}
}
},
"2": {},
"3": {
"children": {
"0": {}
}
},
"5": {
"children": {
"0": {}
}
},
"6": {
"children": {
"0": {}
}
},
}
}
}
- version: The version of LWM2M implemented by the client, if the client does not provide a value, "1.0" will be returned.
- binding: The binding for the connection, such as
UorUQ. - credentials: Which set of DTLS credentials were used, could be
primary,alternate, ornone - remoteAddr: The IP/port of the device.
- discovery: An object that reports the available objects and instances available in the device.
¶ lwm2m.update
This event fires any time a LWM2M device update is received by the platform.
same as lwm2m.register
¶ lwm2m.bootstrap
This event fires when a LWM2M device bootstraps to the platform. If no bootstrap trigger is executed, then the device will be automatically bootstrapped. To use this event, you must reply with a bootstrap configuration using the trigger.reply() function.
{
"version":"1.1"
}
Below is a sample trigger showing the bootstrap configuration:
var bootstrap = {
clearSecurityObjects: true,
clearServerObjects: true,
clearAclObjects: true,
servers: [
{
shortServerId: 99,
bootstrap: false,
self: true,
//secMode: 'nosec',
secMode: 'psk',
lifetime: 60,
disableTimeout: 86400,
binding: 'UQ',
}
],
acls: [
{
objectId: 4,
instanceId: 0,
rules: {
'99': 'rwe'
},
owner: 65535
}
],
objects: {
"3441": {"1": null},
"3441": {"10": { "105": "bootstrap value"}}
}
}
trigger.reply(bootstrap)
- clearSecurityObjects - Deletes all security (0) objects during bootstrap.
- clearServerObjects - Deletes all server (1) objects during bootstrap.
- clearAclObjects - Deletes all ACL objects (2) during bootstrap.
- discoverSecurityObjects - Try to discover (read) all security objects during bootstrap.
- servers - Array of servers to send to the device, must have at least one.
- shortServerId - Short Server ID for the server record.
- bootstrap - Defines if the server entry should be treated as a bootstrap server by the client. NOTE Do not combine
bootstrap: trueandself: true. - self - If true, the IoT Bridge will generate an identity and pre-shared key for the device automatically, if false, they must be manually specified.
- secMode -
nosecandpskare supported. - identityString - DTLS identity as a string (mutually exclusive with identityHex, required if secMode is
dtls). - identityHex - DTLS identity as a hex encoded binary value (mutually exclusive with identityString, required if secMode is
dtls). - pskHex - DTLS pre-shared key as a hex encodied binary value (required if secMode is
dtls). - lifetime - The lifetime of the connection in seconds.
- disableTimeout - The disable timeout for the connection in seconds.
- binding - The binding for the connection in seconds.
- acls - Array of ACL entries, optional.
- objectId - Object ID to be protected.
- instanceId - Instance ID to be protected.
- rules - List of rules, must have at least one rule.
- <shortServerId> - Combination of flags
r,w,e,c,dto allow specific functionality.
- <shortServerId> - Combination of flags
- owner - Owner of the rule, use 65535 to allow modification only during bootstrap.
- objects - List of object instances to be created during bootstrap phase
- To create an empty instance, specify "objId": {"instId": null}.
- To create an instance with initial values, specify "objId": {"instId": {"resId": "value"}}.
¶ lwm2m.data
This event fires any time data is received from the LWM2M device, data is received as a result of a "notify" packet sent as part of an observation, or a reply to an asynchronous read request.
{
"source": "read",
"data": {
"device": {
"0": {
"battery_level": 0,
"battery_status": "normal",
"current_time": "2020-12-10T00:58:18Z",
"device_type": "Device",
"error_code": {
"0": "no error"
},
"firmware_version": "1.0.5.111",
"hardware_version": "Rev 0",
"manufacturer": "Tartabit",
"memory_free": 12459472,
"memory_total": 12864892,
"model_number": "Not Set",
"serial_number": "Not Set",
"software_version": "1.2.2",
"supported_binding_and_modes": "UQ",
"timezone": "EST",
"utc_offset": "-04:00"
}
}
},
"context": {
"requestId":"12345678"
}
}
- source: The source can either be "read", "notify", or "send" depending on the origin of the data.
- data: Data contains the values in a map of object -> instance -> resource heirarchy.
- Multiple objects can be returned in a single lwm2m.data event.
- When issuing the read or observe, setting the translateIds option will convert the object and resource ID numbers to strings to improve readability. This is enabled by default and can be disabled via the options on the lwm2m.read() or lwm2m.observe() calls.
- context: Context is an opaque object that can be passed into a lwm2m.read() request through the options variable and will be returned on the associated lwm2m.data event.
¶ lwm2m.fota_complete
This event fires when the firmware update process completes (whether a success or failure) for a client.
{
"success": true,
"result": "Firmware updated successfully",
"dateStarted": "2021-02-16T12:21:25.7839634Z",
"dateDownloading": "2021-02-16T12:21:25.8329683Z",
"dateDownloaded": "2021-02-16T12:21:25.8329683Z",
"dateUpdating": "2021-02-16T12:21:25.8329683Z",
"dateComplete": "2021-02-16T12:21:35.8363563Z",
"duration: 10.0343,
"context": {
"replyId": "INRXVhm76rhB9o6Z"
}
}
- success: True/false if the firmware udpate was a success.
- result: The result from 5/0/5 with information about any potential errors.
- dateStarted: The date the firmware update was started.
- dateDownlading: The date the firmware started downloading.
- dateDownloaded: The date the firmware update was downloaded.
- dateUpdating: The date the firmware update started updating.
- dateComplete: The date the firmware update completed.
- duration: The duration of the update from start to finish in seconds.
- context: Context is an opaque object that was passed through the lwm2m.firmwareUpdate() function.
¶ lwm2m.result
This event fires when an asynchronous function is called, and a context was specified.
// synchronous, so will not generate an event
var obj = lwm2m.read('mydevice',['3/0'],{async: false})
// asynchronous, but no context defined. Will not generate an event
lwm2m.read('mydevice',['3/0'])
// will generate an event
lwm2m.read('mydevice',['3/0'], {context: {op: 'read', msgId: '1234'}})
// successful example
{
"context": {
"op": "read",
"msgId": "1234"
},
"path": "3/0/14,3441/0/110",
"source": "observe-composite",
"success": true
}
// failed example
{
"context": {
"op": "read",
"msgId": "1234"
},
"error": "tlv: resource definition not found",
"path": "3/0/100",
"source": "write",
"success": false
}
// partial failure
{
"context": {
"op": "read",
"msgId": "1234"
},
"error": "partial success",
"partialErrors": {
"3/0/100": "coap: not found"
},
"path": "3/0/14,3/0/100",
"source": "read",
"success": false
}
- success: True if the operation was a success, false if it failed.
- queued: True if the operation was executed when flushing the queue, false if it was sent in real-time.
- intermediate: Only present if queued is
true, will betrueif the result is an intermediate result (like putting an item on the queue), and will not be present otherwise. - source: The source indicates what operation failed,
read.write,writeMulti,exec,create, etc. - error: Error message describing the problem.
- partialErrors: Some operations can have partial failures, such as reading multiple objects, or writeMulti when not using composites. The errors will be returned in a map of path:error values.
- path: The resource path being accessed. If the operation is a composite operation, the path will be a comma separated list of path entities.
- context: Context is an opaque object that can be passed into a lwm2m.read() request through the options variable and will be returned on the associated lwm2m.data event.
- data: Data will be present if the request was a read operation and returns data.
¶ lwm2m.error (deprecated)
This event fires any time a lwm2m.read() call fails.
{
"source": "read",
"error": "device did not respond to the request"
"context": {
"requestId":"12345678"
}
}
- source: The source indicates what operation failed,
read.write,writeMulti,exec,create - error: Error message describing the problem.
- context: Context is an opaque object that can be passed into a lwm2m.read() request through the options variable and will be returned on the associated lwm2m.data event.
¶ Trigger Actions
¶ Common input parameters
- endpoint: The platform endpoint key to find the client to communicate with. Note that this is the platform endpoint, not the LWM2M endpoint key.
- path: The path is a string representing the object, instance, and resource to access in URI form, ie 3/0, 3/0/14, etc.
- options: Options object allows optional fields to be specified for many calls.
{
"encoding":"tlv",
"composite": false,
"context": {},
"async": true
}
- encoding: (read, write, observe) Can be 'tlv', 'text', 'senml_cbor', or 'opaque', default is 'tlv'.
- composite: (read, write, observe) Defaults to false, when true, the request will be issued using the LWM2M 1.1 composite operations. When composite it true, the encoding will default to 'senml_cbor'.
- context: (read) The context object will be returned on a subsequent 'lwm2m.data' or 'lwm2m.error' event when the operation is complete, it is useful for passing context required to complete the original request.
- async: Whether the operation is completed asynchronously or blocks until the command returns, default is true (does not wait).
¶ lwm2m.create(endpoint, path, data[, options])
Create an instance of an object.
// Create instance 0 of object 19 with resource 0 set to 5 and resource 1 set to 'ABC'
lwm2m.create('mydevice','19/0', {'0':5, '1':'ABC'})
- data: Data should be an object that represents the instance to be created.
¶ lwm2m.exec(endpoint, path[, options])
Execute a resource of an object.
// Execute resource 3/0/4 to reboot the device.
lwm2m.exec('mydevice','3/0/4')
¶ lwm2m.execWithArgs(endpoint, path, args)
Execute a resource of an object and pass arguments with the execution.
// Execute resource 3/0/4 to reboot the device.
lwm2m.execWithArgs('mydevice','3/0/4', {'0': 'abc123'})
- args: an object that will be encoded using the text/plain encoding described in the LWM2M specification. The above example will be encoded as
0='abc123'.
¶ lwm2m.firmwareUpdate(endpoint, uriOrFile[, options])
Execute a firmware update using object 5 on a client. Updates regarding the progress of a firmware update are available in the log viewer. When an update is complete, whether successful or failed, a LWM2M FOTA Complete event will be generated. It is possible to initiate a firmware update on a non-standard instance by specifying instance: "1" in the options configuration.
// Initiate a firmware update on 'mydevice' with a firmware file hosted externally.
lwm2m.firmwareUpdate('mydevice','https://<your url here>/fwv102.bin')
// Initiate a firmware update on 'mydevice' with a firmware file hosted in the inventory. URI will be written assuming an HTTPS download.
lwm2m.firmwareUpdate('mydevice','fwv102.bin')
// Initiate a firmware update on 'mydevice' with a firmware file hosted in the inventory. The download will occur using COAP over UDP.
lwm2m.firmwareUpdate('mydevice','fwv102.bin', {protocol:'coap'})
// Initiate a firmware update on 'mydevice', and supply a context that will be available in the 'LWM2M FOTA Complete' event for matching the result.
lwm2m.firmwareUpdate('mydevice','fwv102.bin', {context: {a:1, b:2})
// Initiate a firmware update on 'mydevice' with a firmware file hosted in the inventory. The file will be pushed to the device by writing to the 5/0/0 resource.
lwm2m.firmwareUpdate('mydevice','fwv102.bin', {delivery:'push'})
- uriOrFile: Can be either a valid URI for an externally hosted file (must begin with http://, https://, coap://, or coaps://), or the name of a file uploaded to the
LWM2M Inventory. If a file from the inventory is specified, then the URI will be automatically set based on the options. - options: In addition to the standard options, the following options are additionally available:
- protocol: Can be either
http,https,coap, orcoapsdepending on your desired transfer method. Default ishttp. - watchMethod: Currenlty only
observeis supported, meaning that an observation will be placed on 5/0/3 to monitor the state of the firmware update. In the futurepollwill be supported for devices that do not support observations. - delivery: Currently defaults to
pullis supported, set topushto send the file by writing 5/0/0. - noEpid: By default, when using the
httporhttpsprotocols, a query parameterepid=<endpointid>will be added to the URL to allow the server to track when the device actually starts downloading the firmware file. SettingnoEpidto true will suppress this query parameter from the URL. - resetUri: Can be
trueorfalse, and defaults tofalse. When set, prior to initiating a firmware update a blank string will be written to5/0/1to reset the device's state machine. - resetEncoding: Defaults to
text, can betext, ortlvto control the encoding used to write the blank string to reset the firmware state machine ifresetUriis set to true. - instance: Specify a non-standard instance for the firmware update, default is
0.
- protocol: Can be either
¶ lwm2m.firmwareCancel(endpoint)
Cancels a firmware update in process, the state machine will be set to cancelled. If a firmware update is not in process, no action will be performed.
// Cancel a firmware update in progress.
lwm2m.firmwareCancel('mydevice')
¶ lwm2m.lastKnown(endpoint, [, options])
Retrieve the last known values of all resources for a given endpoint. The return matches the same formatting as the result of a lwm2m.read() call. The time that each resource was last updated is presented in a set of additional objects prefixed by ~, this allows you to know when each value was populated.
// Retrieve the last known data for a device.
var data = lwm2m.lastKnown('mydevice')
var manufacturer = data['3']['0']['0']
var manufacturerUpdatedTimestamp = data['~3']['0']['0']
// Retrieve the last known data for a device, and don't include the ~ objects with the timestamps.
var data = lwm2m.lastKnown('mydevice',{includeUpdateTimes: false})
var data = lwm2m.lastKnown('mydevice', {translateIds:'strings'})
var manufacturer = data['device']['0']['manufacturer']
¶ lwm2m.observe(endpoint, path[, options])
Observe an instance, or resource. Typically this function should by called from the lwm2m.register event to setup observations when the device connects. After a successful observation, device notifications will be received and generate lwm2m.data events that can be captured and processed. If used with {async: false} then an object will be returned with an object called tokens containing the observation tokens for each observed instance or resource so that they can be cancelled in the future.
// Observe resource 3/0/13 to get notifications on the current time of the device.
lwm2m.observe('mydevice','3/0/13')
// Observe instance 3/0 to get notifications anytime the device object changes.
lwm2m.observe('mydevice','3/0')
// Observe multiple resources using a composite observation.
lwm2m.observe('mydevice',['3/0/11','6/0'],{composite:true})
// Observe synchronously and retreive the token
var rslt = lwm2m.observe('mydevice',['3/0/11','6/0'],{async: false})
// rslt.tokens will be a map such as { '3/0/11': 'abdz9sdf23', '6/0': 'd0xa930xa'} containing the tokens for each
// observation, if the observation is a composite, it will have a single key named composite { 'composite': '190s9xzdfa0'}
- paths: An array of strings with the instances and/or resources to be observed.
¶ lwm2m.observeCancel(endpoint, token[, options])
Cancel an existing observation by its token. You must have saved the token from a previous call to lwm2m.observe() to be able to cancel it. This function is always asynchronous.
// observe two resources and save the tokens to the cache
var rslt = lwm2m.observe('mydevice',['3/0/11','6/0'],{async: false})
cache.set('observes-mydevice',JSON.stringify(rslt.tokens))
// get the tokens and cancel them (presumably in another trigger)
var tokens = JSON.parse(cache.get('observes-mydevice'))
lwm2m.observeCancel('mydevice', tokens['3/0/11'])
lwm2m.observeCancel('mydevice', tokens['6/0'])
¶ lwm2m.read(endpoint, paths[, options])
Read one or more instances or resources. You can read multiple instances or resources by specifying an array of paths. The reads are asynchronous because there could be a long delay between the request and the response for the device. As such, the replies come in the form of a lwm2m.data event with the results of the read request. If the device uses LWM2M 1.0, then each instance or resource will be issued as a separate read packet, if using LWM2M 1.1 then the server will attempt to use composite reads.
// Read instance 3/0, reply will be returned via the lwm2m.data event.
lwm2m.read('mydevice',['3/0'])
// Read multiple instances.
lwm2m.read('mydevice',['3/0','6/0/0','6/0/1'])
// Read resource with text encoding
lwm2m.read('mydevice',['3/0/14'],{encoding: 'text'})
// Read instance and pass context to lwm2m.data event.
lwm2m.read('mydevice',['3/0'], {context:{reply: 'abc123'})
// read multiple resources using a composite read.
lwm2m.read('myevice',['3/0/11','6/0'],{composite:true})
- paths: An array of strings with the instances and/or resources to be read.
¶ lwm2m.write(endpoint, path, data[, options])
Write a single instance or resource. This function is convenient as the data field is a simple value or object, whereas the writeMulti() call requires a more complex object. Note that this function does not support composite operations, for composite write, use writeMulti().
// Write resource 3/0/15 (timezone) to the value 'UTC'.
lwm2m.write('mydevice','3/0/15','UTC')
// Write instance 3/0 with two values.
lwm2m.write('mydevice','3/0',{'14':'+4:00', '15':'EDT'})
// Write resource 3/0/15 (timezone) to the value 'UTC' with text encoding.
lwm2m.write('mydevice','3/0/15','UTC', {encoding: 'text'})
- data: Data can either be a primitive for writing a resource, or an object with properties as the resource IDs to write.
¶ lwm2m.writeMulti(endpoint, data[, options])
Write multiple instances or resources. If the client supports LWM2M 1.1, then this function will attempt to perform a composite write of all data, if the client supports LWM2M 1.0, then each instance or resource will be written individually. If you write a single resource in an instance, it will be sent as a instance write, if you write more than one resource, and utilize an encoding that supports multi-resource operations (ie TLV or SENML_CBOR) it will be sent as an instance write, otherwise each individual resource will be written.
// Write resource 3/0/15 (timezone) to the value 'UTC'.
lwm2m.writeMulti('mydevice',{'3':{'0':{'15':'UTC'}}})
// Write multiple resource on different instances.
lwm2m.writeMulti('mydevice',{'3':{'0':{'15':'UTC'}}, '1':{'0':{'7': 86400}}})
// Write multiple resource on different instances using a composite write.
lwm2m.writeMulti('mydevice',{'3':{'0':{'15':'UTC'}}, '1':{'0':{'7': 86400}}},{composite:true})
¶ Synchronous vs Asynchronous actions
All actions can either be invoked asyncrhonously or synchronously, the difference can have significant impact on your application, so care must be taken.
¶ Usage
By default, all actions are asynchronous, meaning they return immeditely, and any error or data is published via another event. In the options for an action, you can specify "async: false" to force the action to act synchronously.
¶ Asynchronous
- Fast to execute
- Failed operations will queue for future delivery to the device
- Errors are reported to the event log
- Errors are published as
LWM2M Errorevents.
¶ Synchronous
- Blocks trigger execution waiting for acknowledgement from the client.
lwm2m.read()returns the data from the read, and throws an exception on failure.- All other actions return nothing, but throw an exception upon failure.
¶ Examples
var data = lwm2m.read('mydevice', ['3/0'], {async: false})
// data contains the same object that is generated in the LWM2M Data event.
try {
lwm2m.write('mydevice', '5/0/2', {async: false})
} catch(e) {
//handle error
}
¶ Custom Objects
Custom objects can be managed by navigating to Advanced -> LWM2M Objects in the Control Center. From here you can easily upload new objects and delete objects that are no longer needed. Note that objects must be valid XML definitions as specified by OMA. Objects defined in an account will override the default objects provided by the system, as such, if you have a device that needs a custom implementation of a standard object it can be imported here.
¶ Inventory
The LWM2M Inventory allows you to upload files that can be distributed through firmware updates (and software updates in the future). Files that are uploaded can be accessed by PULL mode FOTA requests via HTTP, HTTPS, COAP, and COAPS. For COAPS you must use the same DTLS credentials as you use for your application server connection.
The files uploaded to the LWM2M Inventory must be smaller than 16MB. Larger files must be hosted externally.
¶ LWM2M Browser
The LWM2M Browser can be found by clicking the browser icon on an endpoint in the endpoint list. The browser works for any connected device to enable simple interactions with instances and resources in your client.
¶ Billable events
The following events are considered billable:
- Client registration
- Client update
- Client bootstrap
- Server initiated read (each call to action lwm2m.read() regardless of how many objects, instances, or resources are read is considered a single event)
- Server initiated write (same as read, each invokation of lwm2m.write() or writeMulti() is counted as a single event.
- Server initiated exec
- Server initiated observation
- Notification received from client
- Send received from client
The following events are NOT considered billable:
- Retransmissions
- Sending of queued messages
¶ Notes
Endpoints will show connected if the client is registered to the server, this does not mean that the client is reachable. If the device is connecting on the public internet, then it is highly possible that it is behind a NAT. In general UDP NATs expire after 1-3 minutes, meaning there is only a 60-180 second window after each update for the server to initiate communications with the client.
To debug the firmware state machine edit your LWM2M Service and add a tag
_trace_. Additional messages will be logged to the log viewer.
Due to the inconsistent implementation of LWM2M 1.1 in clients, features such as composites are not enabled by default, you must use the {composite:true} flag in the options of the request to initiate a composite operation. This is subject to change in the future as consistent implementation improves.