Mesh reliable message

RE: Mesh reliable message

Damien Berger — Wed, 23 May 2018 08:47:55 GMT

Well i am trying to use a Nordic feature not to retransmit a message by my own, as in the light switch example.

RE: Mesh reliable message

MaximeMylle — Thu, 17 May 2018 07:36:41 GMT

If you want to retransmit a message i think youi're looking in the wrong place, i think you should handle that in the get method on the server side, not in the aknowledge on the client side, I'm sorry if im wrong, I'm not the expert but I have some experience making custom models

RE: Mesh reliable message

Damien Berger — Thu, 17 May 2018 07:18:39 GMT

I did not touch the access_reliable.c file, just trying to understand what it does. I want an acknowledged message as implemented in access_reliable.c file.
I do not want to "stop" it, it stops automatically after receiving the "ack". My problem is that the retransmissions of the message don't have the right content.

RE: Mesh reliable message

MaximeMylle — Thu, 17 May 2018 07:03:32 GMT

Hi damien, I just doont think you are supposed to look into acces_reliable.c. You should only make adjustments in your own model. If you dont want an acknowledged message, just simply send an unacknowleged message? why would you want to "stop" sending a reliable message, its just a one time call you make... I'd be happy to help you, maybe if you post a piece of code we could help you

RE: Mesh reliable message

Damien Berger — Thu, 17 May 2018 06:24:12 GMT

Yes they are configured correctly, i would not be able to send a message if not.

RE: Mesh reliable message

Mttrinh — Wed, 16 May 2018 16:05:11 GMT

To start with you can check if you have configured keys and/or addresses correctly?

RE: Mesh reliable message

Damien Berger — Mon, 14 May 2018 09:39:23 GMT

Did you manage to find something ?

RE: Mesh reliable message

Damien Berger — Wed, 09 May 2018 07:01:45 GMT

These functions are in access_reliable.c

Yes, there is only one message, i was referring to the re-transmission of this message when there is no ack received. These re-transmissions are sent by "reliable_timer_cb" with the "access_model_publish" function.

RE: Mesh reliable message

Mttrinh — Tue, 08 May 2018 12:36:29 GMT

Where did you find these functions access_reliable_rx_cb and reliable_timer_cb? I can't find it.

You mentions "the others messages sent, there should be only one reliable message at a time. That's why we have the reliable_transfer_active flag.

RE: Mesh reliable message

Damien Berger — Mon, 07 May 2018 14:21:27 GMT

As i said in my second post:

"The calling function is access_reliable_rx_cb, now it works better, my problem was in the find_index function : the model handles were not the same. Now it stops sending after receiving the "ACK" message."
"Now i have an other doubt : the first reliable message sent is correct but if the server does not respond with an ACK, the others messages sent does not contain the right packet, they have the right size, but the content is different."

You have more details in my others replies.
Thank you

RE: Mesh reliable message

Mttrinh — Mon, 07 May 2018 14:18:20 GMT

Hi,

I'm not sure I understand what you mean by "I don't know how to stop my model to send the reliable message". You need to make sure the server are sending you an ACK and after that ACK is received on the client, the client will call the callback. Can you give me more details about your issue and clarify what exactly that you are observing?

RE: Mesh reliable message

Damien Berger — Mon, 07 May 2018 14:01:13 GMT

Could somebody help me please ?

RE: Mesh reliable message

Damien Berger — Fri, 04 May 2018 13:45:57 GMT

I found this in the SDK for Mesh V2.0.0 release note:

BLE Mesh v2.0.0

Known issues and limitations

Publish re-transmission settings are not supported

Does this answer to my issue ? (i am not sure of the meaning of "publish retransmission")

The V2.0.1 does not fix this issue, right ?

Do you have a date for a new release that would fix this problem, or a solution that i could implement ?

RE: Mesh reliable message

Damien Berger — Fri, 04 May 2018 07:14:01 GMT

I am still investigating... The message is stored at that lines in add_reliable_message in access_reliable.c:

memcpy(&(m_reliable.pool[index].params), p_message, sizeof(access_reliable_t));

If i call this line after the memcpy:
__LOG_XB(LOG_SRC_APP, LOG_LEVEL_INFO, "add reliable cpy %u :", m_reliable.pool[index].params.message.p_buffer, m_reliable.pool[index].params.message.length);

I am able to print the correct message.

Then the function "reliable_timer_cb" is the one that sends the others messages if no acks are received with the "access_model_publish" function.

before the call of this function, in " else if (TIMER_OLDER_THAN(m_reliable.pool[i].next_timeout, timestamp))", i try to print my message and it does not work:

__LOG_XB(LOG_SRC_APP, LOG_LEVEL_INFO, "msg rel pub:", m_reliable.pool[i].params.message.p_buffer, m_reliable.pool[i].params.message.length);

My message was : 57686572652061726520796F75203F and it prints 01000000E7A80200D5A80200F5B502.

RE: Mesh reliable message

Damien Berger — Thu, 03 May 2018 12:25:30 GMT

The calling function is access_reliable_rx_cb, now it works better, my problem was in the find_index function : the model handles were not the same. Now it stops sending after receiving the "ACK" message.
Now i have an other doubt : the first reliable message sent is correct but if the server does not respond with an ACK, the others messages sent does not contain the right packet, they have the right size, but the content is different.