Optimizing device settings

Device Management Connect and Device Management Client are designed for constrained devices, and therefore support methods that get the most out of the device's resources and battery life.

Selecting a server queue mode

IoT devices can work with Device Management Connect server in one of two modes:

• In normal mode, the device actively listens for incoming packets from the server. This allows the server to forward requests from a web application to the device as soon as the web application sends the original request to the server. This mode is not suitable for devices that are inactive most of the time.
• In queue mode, the server queues all requests from a web application. It only forwards these requests to the device when the device sends a registration update.

For energy efficiency reasons, many IoT devices are inactive most of the time; therefore, they need to work in queue mode. Device Management Client defines the mode in the registration phase, by setting the LwM2M binding mode to Q.

Regardless of the device operation mode, any messages sent to the device are held in server queue until delivered.

For more details, see Request delivery modes.

Note: Queue mode is only supported with UDP (MBED_CLOUD_CLIENT_TRANSPORT_MODE_UDP_QUEUE).

Resource cache

To minimize unnecessary traffic to Device Management Client, you can cache Resource values in the LwM2M server for a specified time. You can then use the cache to answer requests from third-party customer applications.

To configure the cache lifetime, set the max-age parameter (in seconds) on Device Management Client (at the Resource level).

Device Management Client includes the max-age information in responses related to Resources. For example, if you have a value that you want to cache for ten minutes:

1. The device notifies Device Management Connect of the Resource value change, adding max-age of 600 seconds.
2. Device Management Connect caches the resource value for 600 seconds.
3. Device Management Connect notifies the web application of the new value.
4. Less than 600 seconds later, the web application requests the same resource value.
5. Device Management Connect provides the response from the cache, without contacting the device.

The LwM2M server will cache the Resource value only after receiving a response or an observation. It will be cached for up to number of seconds defined in the max-age option header. However, the server may reduce the time defined. The caching is not automatically triggered, so if no one has read the Resource or subscribed to it, the cache of the LwM2M server is not populated.

Note: The max-age is limited to 72 hours by the server side. The caching is also bound to device registration and all cached resources will be removed if the registration is deleted or expires.

Tip: For more information on the max-age configuration, see Working with the server cache.

Guidelines for memory usage

• Minimize tracing for production releases. It can have a significant effect on RAM/ROM and performance.
• Avoid dynamic memory use in applications whenever possible. In particular, any Resource that you do not need to change should be set as static.
• Minimize eMMC usage to avoid the flash memory wearing out.
• The firmware update feature requires a lot of space to fully load a new binary to the device. More information about memory considerations for firmware updates is available in the Porting section.
  • For Device Management Client 3.2 and later, you can build a delta image that requires less space.

Power consumption

Use resource caching and queue mode as much as possible.

Auto-observation

The auto-observation feature reduces traffic between Device Management Client and Device Management Connect at the registration phase. You can use it on all levels: Resource, Object instance and Object. Your web application will still need to presubscribe to the Resources to start receiving the Resource change events.

An example on how to use the auto-observation method:

M2MResource* resource = object_instance->create_dynamic_resource(“5700", “IntegerType“, M2MResourceInstance::INTEGER, true);
resource->set_value(10);
resource->set_auto_observable(true);

Note: Currently, Device Management Client can have a maximum of 1023 auto-observable Resources. You must set the method before starting the registration process.

Tip: For more information on this API, see the following API descriptions M2MBase::set_auto_observable.

Auto-observation and sleepy devices without RAM retention

Note: This information is valid for both Device Management Client and Client Lite for devices that sleep without RAM retention, but not for Edge.

One of the challenges of working with battery-powered, resource constrained devices is the power consumption. If a device sleeps with RAM retention on, it consumes more power. If it sleeps without RAM retention, you need to deal with other complications, such as storing the context and dealing with wear leveling.

Auto-observation was created primarily to decrease the amount of network traffic between the device and Device Management. Normal subscriptions require subscription tokens to be sent from Device Management to device in every full registration, while auto-observation removes this traffic completely. It also offers a solution, with some limitations, to observe devices without RAM retention.

Getting data from a device without RAM retention

This is how to get data from a device without RAM retention.

1. The web application presubscribes the Resources.
2. In your device application, set the Resources auto-observable (resource->set_auto_observable(true);).
3. The device application requests Device Management Client to register (Client.register_and_connect();).
4. Device Management Client registers.
5. The device application reads the sensor value.
6. The device application updates the value to the Resource (resource->set_value)
7. Device sends observation of the value change to Device Management.
8. Device Management notifies the web application.

After wake-up or interrupt, start over from step 2.

Steps for deep sleep

Deep sleeping devices without RAM retention lose all of the RAM contents when they enter sleep, which means that every wake-up is very near a cold reboot. To drive the connectivity stack down in a controlled manner, use the pause and resume functionality.

Limitations caused by deep sleep

Losing the RAM contents limits the operation of the device as follows:

Normal observations cannot be used

• Subscription tokens are only in RAM. You lose them and cannot use subscriptions.
• Set everything that you want to observe auto-observable. The information gets sent to Device Management every time the device wakes up.

Observation rules are lost

• Subscription rules, such as PMIN and PMAX, are lost because they are stored only in RAM.
• When the device wakes up, the previous values are no longer available and there is nothing to compare with.
• Update the auto-observable resource values only when you want a notification to be sent. In other words, you need to make sure that your application logic handles this.