Implement stored notification at client side.

[sbernard31]

Leshan server is able to handle stored notification as described here.

But we don't have support of this as client side.

[JaroslawLegierski]

What is your opinion about idea of implementation Notification RW Storing When Disabled or Offline in Leshan client ?

From what I see, to implement this feature is needed:

1) Implementation Observe with timestamped value in leshan client 2) Add support Observe-Composite with timestamped value in leshan client 3) Add support of timestamped data for Observe-Composite on server side (Issue 1089) 4) Implement storage, enable support for /1/0/4 and /1/0/5 in leshan-client-demo

Is that all or I miss something?

[sbernard31]

What is your opinion about idea of implementation Notification RW Storing When Disabled or Offline in Leshan client ?

I still think that Observation is worst LWM2M feature but this is in the project scope and so this is something we can try to add if this is really needed.

Could I ask if you need it (or it's just for sake of completeness) and why ?

Is that all or I miss something?

I think it missed the most problematic parts : 1- Currently Leshan client doesn't really support to go offline, I guess this will be related to implementing the queue mode or something like this ?

2. This means that CoAP notification should be intercepted/blocked, stored then sent later. This looks like similar needs than the ones from #1514

enable support for /1/0/4 and /1/0/5 in leshan-client-demo

I don't get how this resource are related to stored notification :thinking:

[sbernard31]

I read 1/0/6 again and I understand why you are talking about 1/0/4 and 1/0/5 :

If true, the LwM2M Client stores “Notify” operations to the LwM2M Server while the LwM2M Server account is disabled or the LwM2M Client is offline.

(source : LWM2M-v1.1.1@core§Table: E.2-2 LwM2M Object: LwM2M Server Resource definitions)

But I think there is an issue in the specification about that I will open a ticket.

[sbernard31]

The corresponding issue : https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/572

[sbernard31]

My opinion about working on this, you could try to experiment about this feature, play a bit with it. But this will conflict/reuse a lot of #1514, so this will not be integrated before we get something about write attributes.

Better to push effort on :

• define a minimal viable feature for write attributes.
• Code it and test it properly.
• Then decide if we need to enlarge the scope of write attributes.
• If yes then do one more iteration.
• Then once we do what we want for write attribute, we can consider to the same for this feature.

(If you want to talk about write attributes plan, please use #1514)

[JaroslawLegierski]

Could I ask if you need it (or it's just for sake of completeness) and why ?

In fact we need feature observe-composite with timestamped data on server site. However at the moment we do not have ready lwm2m client supporting this function and we thought about use of modified leshan-client-demo as very good starting point.

I read 1/0/6 again and I understand why you are talking about 1/0/4 and 1/0/5 :

If true, the LwM2M Client stores “Notify” operations to the LwM2M Server while the LwM2M Server account is disabled or the LwM2M Client is offline.

(source : LWM2M-v1.1.1@core§Table: E.2-2 LwM2M Object: LwM2M Server Resource definitions)

But I think there is an issue in the specification about that I will open a ticket.

Yes we had in mind following scenario:

• Run the client. Client is sending Single notifications according to standard rules (pmin,pmax,epmin,epmax,gt,lt,step)
• From the Server, do a WRITE /1/0/5 to configure the “shut-up” period for, for instance, 1 hour
• From the Server, do a WRITE /1/0/6 to “true” to be sure that the client will “Store” notifications during this “shut-up” period
• From the Server, do an EXE on /1/0/4 to inform the client that it should shut-up, for a duration that has been configured on /1/0/5
• On the client, while it is in the “disabled” period, the client stores all the Notification that should have occured, with their timestamp.
• On the client, when the “disabled” period is over, then the client must send ALL the previously stored notifications with their timestamp, using multi-timestamped senml.

Does the lwm2m client really have to send a deregistration request before disabling ?

[sbernard31]

Does the lwm2m client really have to send a deregistration request before disabling ?

At least this is what the specification says : "LwM2M Client MUST send response of the operation and perform de-registration process" That's why I think there is an issue here : https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/572

In fact we need feature observe-composite with timestamped data on server site.

Probably largely easier to implement this at server side than as client side. (and implementing it at server side can probably be done concurrently with implementing "write attributes" supports at client side without too much issue)

[JaroslawLegierski]

My opinion about working on this, you could try to experiment about this feature, play a bit with it. But this will conflict/reuse a lot of #1514, so this will not be integrated before we get something about write attributes.

Better to push effort on :

* define a minimal viable feature for write attributes.

* Code it and test it properly.

* Then decide if we need to enlarge the scope of write attributes.

* If yes then do one more iteration.

* Then once we do what we want for write attribute, we can consider to the same for this feature.

(If you want to talk about write attributes plan, please use #1514)

I fully agree with You - Magda (@mgdlkundera) is working on it.

Probably largely easier to implement this at server side than as client side.

Yes I think so too. I prepared timestamped data observe-composite PoC described here: https://github.com/eclipse-leshan/leshan/issues/1089

(and implementing it at server side can probably be done concurrently with implementing "write attributes" supports at client side without too much issue)

Is there any link between https://github.com/eclipse-leshan/leshan/issues/1089 and https://github.com/eclipse-leshan/leshan/pull/1514 apart from using timestamped data in notification?

[sbernard31]

Magda (@mgdlkundera) is working on it.

:warning: This is clearly not an easy task, even for me. So it could be a not so appropriate task for a Leshan beginner.

Is there any link between https://github.com/eclipse-leshan/leshan/issues/1089 and https://github.com/eclipse-leshan/leshan/pull/1514 apart from using timestamped data in notification?

At server side, there is no conflict. At client side, I'm not totally sure but I guess there is same kind of mechanism for both feature. I mean being able to intercept notification, store it and send it later. (which is bad idea because this not really how works CoAP observe and so this is really hard to reuse CoAP library without crappy code...)