Arm Mbed and Pelion Device Management support forum

Mbed-client and UDP Queue for sleepy devices

My team is currently evaluating the Pelion platform on the free tier and we have a couple of questions on the udp queue mode in regards to device sleepy devices.

We are building a device that is the majority of the time asleep (~24h wake up interval times) thus we are looking to utilise the UDP_QUEUE mode to send updates to the device.

When a devices registers with Pelion I can see it receives any pending commands. This is great however we are unsure when the device has completed receiving all the messages. Our idea so far has been to use a timeout of x seconds and once the device has stopped receiving requests in this period it would assume it has processed all the pending commands. However I see a number of issues with this approach including network latency.

Is there a better approach ?

When sending commands to a device we are limited to queuing up-to twenty commands. This is fine however if a previously queued command is no longer relevant we would need to queue another command to update/correct that value. This can quickly fill the request queue.

I’m hesitant to suggest that we handle this in cloud by waiting for the device to register and then issue correction messages as this just doesn’t feel right.

Is there a service API to clear a devices UDP request queue, if not is this part of the lwm2m specification ?

mbed-cloud-client: 4.3.0
mbed-os: 5.15

Thanks,
Ash

Hi,
PDMC has an API that can be used to indicate to your application when the queued message transaction has been completed and it is safe for your application to go to “sleep” for next cycle.

Check this API,

Here is a code snippet on how you can use it.

void SimpleM2MClient::sleep_callback_function() {
        printf("Pelion client is going to sleep\r\n");
    } 
   
callback_handler cb(this, &SimpleM2MClient::sleep_callback_function);
        _cloud_client.set_queue_sleep_handler(cb);

Regards,
Yogesh

Hey Yogesh

Thanks very much, we must of not spotted this cb functionality, I can confirm it works. Can this callback also be used to tell if all resources have been published ?

Also any ideas on how to clear/reset/view the queue on the cloud side ?

Ash

Hi,
To reliably track the resource publishing , we have another similar API that you can set callback to each resource individually and follow the status

It is also demonstrated in public example

When the notification is successfully delivered to Pelion DM, your callback will receive status
case M2MBase::MESSAGE_STATUS_DELIVERED
based on which you can create your application logic.

As for the cloud side, I am not aware whether such functionality exists but will try to find answer for this.

Regards,
Yogesh

Thank you for the update, we currently use notification callbacks along with a counter to check the status of published resources, you have confirm this was the right approach.

As for the cloud side, I am not aware whether such functionality exists but will try to find answer for this.

Perfect will wait on this response. Without being able to at least look what is already on the queue, it will be difficult to prove what actions the device will perform once it wakes up, especially considering that multiple applications can queue messages.

Regards,
Ash

Hello,

About the server side question. There is no API to clear the queue (You are not the first one to ask this, so I will take a note about you requesting this as well), the approach has been that the web application would set ‘expiry-seconds’ to make the message to expire from the queue. You will get a response to your web application of delivery failing because it expired. This would of course mean that your web application would need to place the same command again if there is no newer value. I guess you know the documentation already https://www.pelion.com/docs/device-management/current/device-management/managing-device-resources.html

1 Like

Thank you very much for your response.

We will use the message expiry approach you mentioned to ensure messages are not for longer than device connection interval and less than the registration expiry time, and continue to manage device state on our web application.

Add a plus one from me in your internal jira for this feature request :+1:

I will mark this thread as solved.

Regards,
Ash