Topics

LWM2M batch uploading data


Benjamin Lindqvist
 

Hi,

We have a use-case which I deem to be pretty normal: uplinks are really expensive and should be kept to a minimum (in fact, we want the radio completely powered off 99.99% of the time). But we have N sensors which we want to observe from the cloud, at different intervals. Looking briefly through the specification, one gets the impression that OBSERVE at some interval implies that the device uploads data at this observation interval. 

What we'd like to do is to sample the data at the observation interval and batch upload it at some different, longer, interval. It's not clear to me if the specification allows this - and if it does, does the Zephyr implementation allow it?

Grateful for clarifications.


Benjamin Lindqvist
 

To be honest, it sort of seems as if the implementation assumes it has a perpetually open socket connection to cloud at all times. Perhaps this is an exaggeration, but I'd kind of like to know how (if?) the implementation handles downed interfaces and broken pipes...


On Mon, Sep 23, 2019 at 5:34 PM Benjamin Lindqvist via Lists.Zephyrproject.Org <benjamin.lindqvist=endian.se@...> wrote:
Hi,

We have a use-case which I deem to be pretty normal: uplinks are really expensive and should be kept to a minimum (in fact, we want the radio completely powered off 99.99% of the time). But we have N sensors which we want to observe from the cloud, at different intervals. Looking briefly through the specification, one gets the impression that OBSERVE at some interval implies that the device uploads data at this observation interval. 

What we'd like to do is to sample the data at the observation interval and batch upload it at some different, longer, interval. It's not clear to me if the specification allows this - and if it does, does the Zephyr implementation allow it?

Grateful for clarifications.


Michael Scott
 

Hello Benjamin,

On Mon, Sep 23, 2019, 9:11 AM Benjamin Lindqvist <benjamin.lindqvist@...> wrote:
To be honest, it sort of seems as if the implementation assumes it has a perpetually open socket connection to cloud at all times. Perhaps this is an exaggeration, but I'd kind of like to know how (if?) the implementation handles downed interfaces and broken pipes...

You are correct.  The missing piece is LwM2M queue mode support.  This mode is registered during the initial client / server connection.  It means there is a mutual agreement that the client will (in general) not be available for instantaneous queries, but prior to the agreed upon connection "lifetime", the client will re-establish communication with the server and answer requests.  There is a set period of time where the client will remain connected afterward and then it can go back offline.

Over the last few months, queue mode in Zephyr has gotten more attention (mainly due to expanding modem support).  Unfortunately, due to my current work load, I haven't had the time to implement and test it.

Here is the Zephyr issue which tracks the addition of LwM2M queue mode support:

Michael Scott
Embedded Software Engineer
Foundries.io


On Mon, Sep 23, 2019 at 5:34 PM Benjamin Lindqvist via Lists.Zephyrproject.Org <benjamin.lindqvist=endian.se@...> wrote:
Hi,

We have a use-case which I deem to be pretty normal: uplinks are really expensive and should be kept to a minimum (in fact, we want the radio completely powered off 99.99% of the time). But we have N sensors which we want to observe from the cloud, at different intervals. Looking briefly through the specification, one gets the impression that OBSERVE at some interval implies that the device uploads data at this observation interval. 

What we'd like to do is to sample the data at the observation interval and batch upload it at some different, longer, interval. It's not clear to me if the specification allows this - and if it does, does the Zephyr implementation allow it?

Grateful for clarifications.


Benjamin Lindqvist
 

Thanks for the info Mike. Queueing mode seems like it would resolve some worries, but would you mind clarifying one thing? From the issue:
 
  • Wake up before lifetime or observation (if any) expires

Seems like this can be interpreted as "an observation always implies an uplink", i.e. buffering and batching many observations in a single uplink is not really possible. Is this correct?


On Tue, Sep 24, 2019 at 12:02 AM Michael Scott <mike@...> wrote:
Hello Benjamin,

On Mon, Sep 23, 2019, 9:11 AM Benjamin Lindqvist <benjamin.lindqvist@...> wrote:
To be honest, it sort of seems as if the implementation assumes it has a perpetually open socket connection to cloud at all times. Perhaps this is an exaggeration, but I'd kind of like to know how (if?) the implementation handles downed interfaces and broken pipes...

You are correct.  The missing piece is LwM2M queue mode support.  This mode is registered during the initial client / server connection.  It means there is a mutual agreement that the client will (in general) not be available for instantaneous queries, but prior to the agreed upon connection "lifetime", the client will re-establish communication with the server and answer requests.  There is a set period of time where the client will remain connected afterward and then it can go back offline.

Over the last few months, queue mode in Zephyr has gotten more attention (mainly due to expanding modem support).  Unfortunately, due to my current work load, I haven't had the time to implement and test it.

Here is the Zephyr issue which tracks the addition of LwM2M queue mode support:

Michael Scott
Embedded Software Engineer
Foundries.io


On Mon, Sep 23, 2019 at 5:34 PM Benjamin Lindqvist via Lists.Zephyrproject.Org <benjamin.lindqvist=endian.se@...> wrote:
Hi,

We have a use-case which I deem to be pretty normal: uplinks are really expensive and should be kept to a minimum (in fact, we want the radio completely powered off 99.99% of the time). But we have N sensors which we want to observe from the cloud, at different intervals. Looking briefly through the specification, one gets the impression that OBSERVE at some interval implies that the device uploads data at this observation interval. 

What we'd like to do is to sample the data at the observation interval and batch upload it at some different, longer, interval. It's not clear to me if the specification allows this - and if it does, does the Zephyr implementation allow it?

Grateful for clarifications.