How do I use access_model_reply() asynchronously and not have to save the content of p_reply

[Mahendra Tailor]

Hi

I have reported this before and now that you are a quarter away from a fully featured mesh sdk can I ask you to please enhance the SDK so that you supply a function that takes "access_message_rx_t * p_message" and returns a smaller struct that contains only the relevant information required for the stack to successfully send out the reply.

Why?

That is best explained using use case..

Imagine there is a mesh message that results in having to trigger some action that will take say 1000milliseconds to start and finish and *only then* can it send the reply.
At the moment in your sample light switch onoff app the reply is sent in the same 'thread' context as when the callback for the message happened.

For the reply to be sent in 'future' at the moment I have to save a deep copy if the entire  "access_message_rx_t * p_message" which means making a deep copy of "nrf_mesh_rx_metadata_t * p_core_metadata". I have no option but to do that as I do not know (and care) what information the stack uses to send out the response.

Ideally the function 

uint32_t access_model_reply(access_model_handle_t handle,
const access_message_rx_t * p_message,
const access_message_tx_t * p_reply)

should be changed to

uint32_t access_model_reply(access_model_handle_t handle,
const access_reply_context_t * p_reply_context,
const access_message_tx_t * p_reply)

And you add a new routine like ...

uint32_t access_extract_reply_context( const access_reply_context_t * p_reply_context
access_reply_context p_reply_context)

Or if this is not feasible please demonstrate how best to do what I wish to do with minimal memory usage.

Look forward to hearing from you

Regards

Mahendra

[tesc]

Hi,

We acknowledge that these are valid concerns and use-cases, and your suggestions are taken into account for further development of our Mesh stack.

For a workaround you don't need a full deep copy. The only data used by the access layer is appkey, subnet and source address from the access_message_rx_metadata_t structure of the received message:

// Excerpt from access.c, around line 333, in packet_tx()
if (p_rx_message != NULL)
{
    appkey_handle = p_rx_message->meta_data.appkey_handle;
    subnet_handle = p_rx_message->meta_data.subnet_handle;
    dst_address = p_rx_message->meta_data.src;
}

A better option might be to design your models such that an immediate reply is given to signal that the command is being executed, then after execution is complete there is a status published with the updated state. A similar concept is found in the Mesh Model Specification section 1.4.1 State transitions, where a state change is triggered then status is published throughout the transition.

Regards,
Terje

[Mahendra Tailor]

Hi Terje,
That is exactly what I did in our first release of our experimental firmware based on the 0.10.0 stack last December.
This time (sdk 2.1.1) I was too pushed for a deadline so took the easy way out and just stored the entire message.

Mainly because up to know when you release a new stack it has been a Sisyphean task form me as I have to port all the many tweaks I have had to make to the SDK given that I need to have runtime configurability and not compile time :-)
That is another of my requests to your developers so that the mesh is like the softdevice where you can create the gatt table at runtime.

Your suggestion about "A better option might be to design your models such that an immediate reply is given to signal that the command is being executed" is not feasible because we sell a BASIC programmable module to our customers and we literally don't know what model they are implementing.

In our BASIC firmware I have distilled the whole Mesh API to have just 12 functions and 2 events !

One event is when a message comes in and the other is updates for mesh state changes.
And of the 12 functions, half are just to create the element/mesh/opcode tree structure that is then submitted to a BleMeshStart() function. And then we have BleMeshPublish() and BleMeshReply().
That's it. Our customers can have their mesh device created and usable within a few hours.

Really looking forward to the fully featured SDK.

Kind regards
Mahendra

PS
We have released our firmware image for mesh which you could probably try on the PCA10056 board and it should work.
If you do, ping me to obtain a licence that you will need to enter to make it function.

[tesc]

Hi,

I see. As with previous requests you do have some special requirements based on the fact that your customers program the module.

I would really love to get my hands on your product, if I ever get to put aside time to do so. Currently my schedule is way to busy, but I will get back to you when (if) things calm down if that is OK with you. (=

Regards,
Terje