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]

I read through the comments an my impression is, that there is a gap in understanding coap/dtls and lwm2m.

Starts with lwm2m:

Usually your device registers once and then updates that registration in order to inform the server, that the device is still valid/used.

On that registration, the server may start the obervations, the application is interested in. Such an observation could simply be considered as continue-read. With that, the device may always send a new response, usually intended when the addressed resource has changed. If such a response requires an ACK of the server depends on the device, it may use NON (no ACK, no retransmission, may be lost) or CON (waits for ACK or retransmitts the response, if the ACK is not received, much more reliable).

So, you may send the responses as NON, but you must also notice, that it may get lost without further notice.  

Coap/dtls:

Though you wrote, your device wakes up from PSM, the first important thing is, if it gets a fresh ip-address or keeps a static one. With the static one, everything is easy as described above. With a fresh ip-address, it depends ...

(long story years ago in the oma/lwm2m github).

My personal conclusion:

Wait until draft-ietf-tls-dtls-connection-id is released and the DTLS libraries supports that (e.g. mbedtls and zephyr).

Leshan already supports that (at least, once it gets updated to Californium 3.0.0.).

Without, it will be a DTLS issue in the first place. If the encryption context is bound to th eip-address, but that is changing, encryption will not work.

[ced27]

Achim Kraus said:

On that registration, the server may start the obervations, the application is interested in. Such an observation could simply be considered as continue-read. With that, the device may always send a new response, usually intended when the addressed resource has changed. If such a response requires an ACK of the server depends on the device, it may use NON (no ACK, no retransmission, may be lost) or CON (waits for ACK or retransmitts the response, if the ACK is not received, much more reliable).

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

Achim Kraus said:

Though you wrote, your device wakes up from PSM, the first important thing is, if it gets a fresh ip-address or keeps a static one. With the static one, everything is easy as described above. With a fresh ip-address, it depends ...

By every new registration the device gets a new ip adresse