how can i send a 100 or 500 bytes Payload from nRF9160 to Leshan server?

[ced27]

Hello,

i had a look at lwm2m_client_sample and it worked pretty well. Now my next step is to be able to send for example a 100 or 500 Bytes Payload from nRf9160 to Leshan server.

Since i am a new comer, i don't really know how to go about it.

Questions:

1. Is it possible in the first place to be able to send payload data to leshan server?

2. When yes. How can i go about it? 

3. When no. Is there any alternative of sending payload data using lwm2m?

I will be glad, if someone could help me.

best regards

Cedric

[Achim Kraus]

Unfortunately, my browser doesn't show the reply to other comments ... so.

"But my case is that i don't want the server to start the observations before i can send a new response"

That raises the question, why you think, that this is relevant ... or why your want to use lwm2m, if you want it in "your way". lwm2m tries to build a "reusable base" for different applications. A lwm2m device may be used in different applications without adapting the lwm2m devices firmware. At least sometimes this should be possible.

"By every new registration the device gets a new ip adresse"

Just to ensure "registration" in terms of the mobile network ... not a lwm2m-registration?

With that, let me repeat: wait for dtls connection id. That will solve your pain.

(I use it now for more than 2 years on Nb-IoT. The main left issue is the "mobile network registration time", which is in my experience in good cases 2s in bad up to 60s ... which makes the time for the server's ACK (additional 2s) less important. By the way, if you use NB IoT, the MTU is about 330 bytes, leaving something as 270 for the coap-message and 250 for the coap payload. 500 bytes may result on higher paket loss, but that will be up to you, to test, what works better.) 

[ced27]

Thanks for your contribution.

so if i understand, it will be good for my own interest to stay with lwm2m as it. Meaning the server starts observations before i can start sending a new response.

And when the device wakes up from PSM, it should wait for dtls connection id. 

And leshan server will support it once it gets update to Californium 3.0.0.

Is that correct?

[Achim Kraus]

"stay with lwm2m as it."

"wait for dtls connection id"

Yes, that is my recommendation.

Sure, if you want "many many" device "now", you may chose to use coap/dtls cid, patching mbedtls a little and using Californium 3.0.0-RC1.

Even, if you only want "many" devices "now", you may chose leshan (with Californium 2.6, which  is already supporting dtls connection id, but the deprecated version) and mbedtls 2.27 (with the "legacy" variant of dtls connection id).

But both will come with the burden to do the "integration/interoperability" on your own, as the zephyr PR shows.