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 ?