Not able to receive status messages published by onoff Server using message context instead of default publish parameters set by provisioner

[Susheel]

Hello,

I am trying to send status messages to a Client model with a specific unicast address on one node. This node's parent element has both generic onoff server and client models implemented. All onoff server and client models across all nodes are configured to publish and subscribe to specific group addresses (0xc000 and 0xc001 respectively). When I try to publish a status message to this client model using the message context (with the destination address as the elements unicast address) instead of using the default publish parameters, it does get received by the access layer but, not by the client model (breakpoint at status handler does not hit).

When I publish a get/set message to the server model in the same element, using the same context instead of the default publish parameters, it gets received by the model (breakpoint at get/set handlers get hit). Am I missing something here? Please suggest.

I am working with NCS 1.9.1 on nRF52480 DK's

[AHaug]

Hi,

Our Mesh team has had a look at the case and have the following input to come with:

At first glance the code looks OK but we would like you to try the following first before we dig deeper:

When msg ctx is allocated and initialized like this:

	struct bt_mesh_msg_ctx ctx;
	ctx.addr= 0x001;
        ...

ctx will have a garbage in it. It should be either memset, or initialized with {} or initialized like this:

	struct bt_mesh_msg_ctx ctx = {
                .addr = 0x0001,
                ...
        };

Example from http://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_bt_mesh_vendor_model_chat_sample_walk_through.html:

	struct bt_mesh_msg_ctx ctx = {
		.addr = addr,
		.app_idx = chat->model->keys[0],
		.send_ttl = BT_MESH_TTL_DEFAULT,
		.send_rel = true,
	};

Let us know if this solves the issue

Kind regards,
Andreas

[Susheel]

Hello Andreas, 

I made the changes but, it did not solve the issue. Here is a log output from my provisioner node.

light switch sends the set message to the light node. Light node replies with a status message to both the light switch node(with group address 0xc001) and the provisioner node (with address 0x0001). The message reaches the access layer but not the model layer. Please advice.

Regards,

Susheel

[AHaug]

Hi, 

• Could you attach a minimal sample that recreates the issue including configuration files?
  • Don't upload anything that contains sensitive information without converting this to a private case. Let me know if we need to do so.
• Also what devices are you using as a light and switch nodes?

Kind regards,
Andreas

[Susheel]

I have attached the files requested. This is just a test setup and no sensitive information is shared.

Test setup:

• 2 nRF52480 DK's (one light and the other light switch, 1 nRF52 DK acting as the provisioner.
• I have added onoff server and client models to the provisioner node composition.
• For this code to work, you would have to provision the client first as it is hardcoded to send a context message to 0x0006 which would then be the first element address of the light server(0x0001 -> provisioner; 0x0002 to 0x0005 -> client; 0x0006 to 0x0009 -> server).

3750.sample.zip

Regards,

Susheel

[AHaug]

Hi,

Susheel said:

I have attached the files requested. This is just a test setup and no sensitive information is shared.

Thank you for supplying this information!

Susheel said:

I made the changes but, it did not solve the issue. Here is a log output from my provisioner node.

After this reply, the mesh team did some more testing of your previously supplied with the first fix we suggested (initializing ctx with {} or set with a struct):

1. I had to increase CONFIG_MAIN_STACK_SIZE to 2500 (approximate value). Default value was not enough and the device was rebooting when tried to add app key.
2. I had to uncomment code in the configure_self function to subscribe the provisioner to the group address
3. I had to comment out the code with if (flag == 4) otherwise the provisioner didn't configure publication on the light_switch.

I was able to receive messages from the light_switch on the provisioner:

Waiting for unprovisioned beacon...
SET: request received.. with onoff status 1 from node address 3
[00:07:07.092,956] <dbg> bt_mesh_access: bt_mesh_model_recv: app_idx 0x0000 src 0x0003 dst 0x0001
[00:07:07.093,017] <dbg> bt_mesh_access: bt_mesh_model_recv: len 4: 82030105
[00:07:07.093,017] <dbg> bt_mesh_access: bt_mesh_model_recv: OpCode 0x00008203
[00:07:07.093,048] <wrn> bt_mesh_access: Elem: 0
[00:07:07.093,078] <wrn> bt_mesh_access: Model: 1000
[00:07:07.098,693] <dbg> bt_mesh_access: bt_mesh_model_publish: 
[00:07:07.098,724] <dbg> bt_mesh_access: bt_mesh_model_publish: Publish Retransmit Count 1 Interval 50ms
[00:07:07.099,029] <dbg> bt_mesh_access: mod_publish: 427099
[00:07:07.213,195] <dbg> bt_mesh_access: publish_sent: err 0, time 427213
[00:07:07.213,195] <dbg> bt_mesh_access: next_period: Publishing took 115ms

I will relay your latest reply to them, but before we do the next step of solving this issue could you try step 1-3 suggested by the Mesh team together with initializing ctx as suggested, and see if that gives the same results that we were able to produce?

Kind regards 
Andreas