Ocasional mesh configuration failure

RE: Ocasional mesh configuration failure

caca1989 — Tue, 17 Apr 2018 02:08:27 GMT

Hi Bjorn Kvaale,

I have created a new devzone case，this

RE: Ocasional mesh configuration failure

Bjørn Kvaale — Fri, 13 Apr 2018 10:55:11 GMT

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.

RE: Ocasional mesh configuration failure

caca1989 — Fri, 13 Apr 2018 07:07:35 GMT

Hi Bjorn Kvaale，

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

RE: Ocasional mesh configuration failure

caca1989 — Fri, 13 Apr 2018 06:58:18 GMT

Hi alasknnj，

how did you solve this problem?

RE: Ocasional mesh configuration failure

Bjørn Kvaale — Wed, 11 Apr 2018 08:38:19 GMT

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.

RE: Ocasional mesh configuration failure

alasknnj — Mon, 02 Apr 2018 14:43:51 GMT

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.

RE: Ocasional mesh configuration failure

Felix Tam — Fri, 30 Mar 2018 05:48:46 GMT

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.

RE: Ocasional mesh configuration failure

Jørgen Holmefjord — Wed, 28 Feb 2018 14:44:13 GMT

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)?

RE: Ocasional mesh configuration failure

alasknnj — Mon, 26 Feb 2018 16:32:11 GMT

Yes, I can run the demo with more than 1 server without a problem. I will attach the model code now. Just so you know, I mixed client and server together, because I need a device that can act as both, but not at the same time.

RE: Ocasional mesh configuration failure

Jørgen Holmefjord — Mon, 26 Feb 2018 16:05:53 GMT

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