Mesh message queuing

RE: Mesh message queuing

tesc — Fri, 16 Mar 2018 10:30:21 GMT

Error code 14 (decimal) is NRF_ERROR_NULL. (See nrf_error.h for NRF_ERROR values.)

According to access_model_reliable_publish() documentation, NRF_ERROR_NULL means "NULL pointer given to function", i.e. the p_reliable argument was a NULL pointer.

RE: Mesh message queuing

Pooja — Fri, 16 Mar 2018 05:44:32 GMT

I am using ``access_model_reliable_publish(...)`` but it gives the error?

it return status value as 14.

<t: 57159>, nrf_mesh_sdk.c, 72, APP_ERROR: ..\nrf5_SDK_for_Mesh_v1.0.1_src\examples\light_switch\client\src\main.c:345 code 14

What's wrong with this?

RE: Mesh message queuing

tesc — Wed, 21 Feb 2018 17:10:14 GMT

Yes. Those are the API calls for non-reliable and reliable messages respectively.

Please note that only for the reliable publish you will get a response acknowledging that the message is received. In order not to loose anything you would have to use reliable publish.

There is a trade-off here, between reliable (loss-less) communication and speed.

RE: Mesh message queuing

AmiguelS — Tue, 20 Feb 2018 19:31:01 GMT

To convert the example from reliable messages to non-reliable messages, is it only needed to use ``access_model_publish(...)`` instead of ``access_model_reliable_publish(...)`` ?

RE: Mesh message queuing

AmiguelS — Mon, 19 Feb 2018 16:14:35 GMT

Hello, Thanks for the reply. Where can I configure the delivery method (reliable/non reliable)?

RE: Mesh message queuing

tesc — Mon, 19 Feb 2018 15:50:38 GMT

Hi,

For the light switch example, the client uses reliable messages and the server does not. Non-reliable messages are a lot faster than reliable messages, and so you should expect a significant difference between the two.

There should be no difference if you use the same method in both ends for sending the same message.

Regards,
Terje