Ocasional mesh configuration failure

[alasknnj]

I have created my own mesh model, based on the light switch example, and had no problems with it when using 1 client and 1 server. 

But when I use 2 servers, I noticed that configuration of the second server seems to fail sometimes. The provisioning is always okay, what I noticed is that the server sides seems to fail to send the reply for the APP_ADDKEY or APP_BIND when the failure occurs.

What is strange is that the actual call for access_model_reply returns NRF_SUCCESS, but since the client didn't receive the reply, it keeps sending the message, and the server keeps replying unsuccessfully to the client.

Sometimes, when the client has not timeout waiting for the reply, it actually manages to receive one and configure the server. But that's not usually the case when there is this issues with the server.

The first server added to the network has no issue at all when configuring. When the second server manages to be configured, the mesh network works without any apparent problem.

Another strange behavior I noticed is that after provisioning and configuring the first server, if I turn off this first server and start the provisioning of the second server, there is no issue during configuration of the second server.

Could it be some kind of interference? I don't really have many ideas for the cause of the problem.

Thanks.

----------------------------------------------------

Here is my custom model. Also, I'm aware I should change ACCESS_COMPANY_ID_NORDIC to 0xFFFF while developing, I just couldn't figure out yet how should my OPCODEs change with that.

stemblox.zip

[Jørgen Holmefjord]

Are you able to run the light switch demo with more than one server? Could you post the code of your model?

[Jørgen Holmefjord]

It sounds like this issue could be related to missing handling of or out of order receiption of status messages. If client lose ACCESS_SUCCESS for the first APPKEY_ADD, the server should respond with ACCESS_STATUS_KEY_INDEX_ALREADY_STORED if it gets a new APPKEY_ADD with a key it already have. Are you handling this in your model? 

Could you provide RTT logs of the provisoner and server when this issue occurs? Are you using the latest version of the Mesh SDK (currently v1.01)?

[Felix Tam]

I encountered  the same issue as Jargen and I have tried both mesh SDK 1.0 and 1.01.

It was all fine if  the server and client is separated. But once I combine both in the same code,

the client can provision only one server. I am using SDK14.2. As my application is mobile phone +

52832, one temporary fix is to disable the mesh of the server once provisioned and enable the mesh of

all the servers provisioned once the provisioning is completed. In doing so, the client can provision more

than ten servers. Of course, the disabling and enabling of the mesh needed to be controlled by the

mobile app.

I was wandering if Nordic has an agenda to look into this issue.

[alasknnj]

As of the time I had these issues, I was using Mesh SDK v1.0. We had since then moved on without the mesh feature in our product, leaving that for when there will be more support, but also because nRF58240 is not out yet. 

In our code, we were handling ACCESS_STATUS_KEY_INDEX_ALREADY_STORED, because we based on the light switch example, which handled that, what we saw was that sometimes the provisioner did not receive a response at all, while the provisionee kept trying to send. At times, the response was received, but the response for the model binds were not.

Just to make sure that messages were sent in order, as detailed in the documentation, I had removed a function call from the example, which led to some out of order messages, but I don't really recall now the specific messages that were out of order, I do remember commenting out this line:

void provisioner_configure(uint16_t address)
{
    m_target_address = address;
    if (m_prov_state == PROV_STATE_PROV)
    {
        /* Wait for the NRF_MESH_PROV_EVT_LINK_CLOSED event. */
        m_prov_state = PROV_STATE_CONFIG_FIRST;
    }
    else
    {
        m_prov_state = PROV_STATE_CONFIG_FIRST;
        //do_config_step();
    }
}

But with or without this, the occasional configuration failure still happened.

[Bjørn Kvaale]

Sorry for the delayed response. alasknnj Felix Tam May I ask why you want to run the server & client on the same device? I am not sure if we have an agenda to look into this, as the "regular" usecase up until now has been to have the server & client separated on two different boards. You can send me a private message & then I can give you both the contact details of your local Regional Sales Manager. They should know more about agenda questions.

[caca1989]

Hi Bjorn Kvaale，

I encountered the same problem，How to solve this problem？ Ths！

[Bjørn Kvaale]

Hi caca1989, could you please create a new devzone case where you explain exactly what is happening (preferably with some log information) & we'll take a look at it there? Thanks.

[caca1989]

Hi Bjorn Kvaale,

 I have created a new devzone case，this