nRF Connect Mesh Light/Light Switch Example unreliable

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Marius Waage Aabel — Tue, 15 Aug 2023 17:50:47 GMT

Haha, yes, I saw it is old, but I experienced the same, and since this did not conclude, I thought it might not be fixed yet. I will create a new ticket :-) Thanks!

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Hung Bui — Mon, 14 Aug 2023 11:35:24 GMT

Hi Marius,
The issue here is 3 years old and the mesh problem on NRF53 should have been fixed. Please create a new ticket and describe your issue there.
Please make sure you explain how you do provisioning and how you tested.
Also please pay attention to the extra configuration for NRF53 in boards folder and in child_image\hci_rpmsg.conf , for example in our light_switch sample.

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Marius Waage Aabel — Mon, 14 Aug 2023 10:20:18 GMT

Any update on this? I work on a mesh project and have several 5340DK I would like to use. The 5340DK does not seem to be able to send and/or receive messages on the mesh, using Light and Light switch samples from NDK Conenct 2.4.1.

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Jacob B — Tue, 11 Aug 2020 12:00:48 GMT

Hi Hung,

Glad to hear you are able to reproduce it and interesting that this doesn't occur on nRF52. I don't experience the double click issue you descirbe though. Please let us know when you hear back from the developer.

Thanks,

Jacob

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Hung Bui — Tue, 11 Aug 2020 11:55:59 GMT

Hi Jacob,

I'm testing the example here and can reproduce the issue. I will check with the developer to see what could be wrong here.
When testing with the nRF52 instead of the nRF53 I don't see any problem, but on the nRF53 what I observed was that the light server still work normally it can receive the command from other nodes (nRF52) with no problem. But the light client doesn't work as it should I don't see other node to receive the command from the NRF53. The local light server model on the same node can receive but not the external node.

In addition what I observed is that when you click the button it only switches on the LED, if you want to switch off the LED you need to double click (one click - 1 second - another click). It maybe designed that way but I would need to double check.

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Jacob B — Mon, 10 Aug 2020 14:52:06 GMT

Hi Hung,

When using 0xFFFF it works ~50% of the time, when using 0xC000 it has never worked. It seems the setup is correct when using address 0xFFFF as it sometimes does work, it is just very unreliable which doesn't seem like a problem with the address but the network itself. Any thoughts on what could be causing the reliability issues? Thanks

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Hung Bui — Mon, 10 Aug 2020 14:44:02 GMT

Hi Jacob,
Sorry that I'm a bit confused. You meant that when you use group 0xC000 it always works. But when you use 0xFFFF no LED illuminated ?
Have you double check if there is any light switch server located at the primary element of the node ?

I wouldn't suggest to use 0xFFFF for normal operation. It should only be used for special command that you want to address all nodes regardless the configuration.

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Jacob B — Fri, 07 Aug 2020 15:26:36 GMT

Hi Hung,

- Correct, when pressing button one on the light switch LED 1 on the light switch illuminates but no LEDs on the light illuminate

- That is useful to know about 0xFFFF

- In this case it does not work it all, with/without re-transmission. The group is controllable by the nRF mesh app when connected to the light via proxy

The above logging issue was fixed by re-importing the project into embedded studio once the prj.conf file had been changed.

The following logs are generated by the light switch when button 1 is pressed (LED 1 on light does not illuminate nore are any logs printed by the light):

[00:32:36.685,974] <dbg> bt_mesh_access.bt_mesh_model_publish:
[00:32:36.686,004] <dbg> bt_mesh_access.bt_mesh_model_publish: Publish Retransmit Count 7 Interval 50ms
[00:32:36.686,004] <dbg> bt_mesh_access.model_send: net_idx 0x0000 app_idx 0x0000 dst 0xc000
[00:32:36.686,004] <dbg> bt_mesh_access.model_send: len 4: 82030148
[00:32:36.817,993] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:36.817,993] <dbg> bt_mesh_access.publish_sent: Publishing next time in 50ms
[00:32:36.868,103] <dbg> bt_mesh_access.mod_publish:
[00:32:36.868,103] <dbg> bt_mesh_access.mod_publish: period 0 ms
[00:32:36.999,664] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:36.999,664] <dbg> bt_mesh_access.publish_sent: Publishing next time in 50ms
[00:32:37.049,774] <dbg> bt_mesh_access.mod_publish:
[00:32:37.049,774] <dbg> bt_mesh_access.mod_publish: period 0 ms
[00:32:37.181,152] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:37.181,182] <dbg> bt_mesh_access.publish_sent: Publishing next time in 50ms
[00:32:37.231,262] <dbg> bt_mesh_access.mod_publish:
[00:32:37.231,262] <dbg> bt_mesh_access.mod_publish: period 0 ms
[00:32:37.362,823] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:37.362,823] <dbg> bt_mesh_access.publish_sent: Publishing next time in 50ms
[00:32:37.412,933] <dbg> bt_mesh_access.mod_publish:
[00:32:37.412,933] <dbg> bt_mesh_access.mod_publish: period 0 ms
[00:32:37.544,525] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:37.544,555] <dbg> bt_mesh_access.publish_sent: Publishing next time in 50ms
[00:32:37.594,635] <dbg> bt_mesh_access.mod_publish:
[00:32:37.594,635] <dbg> bt_mesh_access.mod_publish: period 0 ms
[00:32:37.726,470] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:37.726,501] <dbg> bt_mesh_access.publish_sent: Publishing next time in 50ms
[00:32:37.776,580] <dbg> bt_mesh_access.mod_publish:
[00:32:37.776,580] <dbg> bt_mesh_access.mod_publish: period 0 ms
[00:32:37.908,172] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:37.908,203] <dbg> bt_mesh_access.publish_sent: Publishing next time in 50ms
[00:32:37.958,282] <dbg> bt_mesh_access.mod_publish:
[00:32:37.958,282] <dbg> bt_mesh_access.mod_publish: period 0 ms
[00:32:38.089,874] <dbg> bt_mesh_access.publish_sent: err 0
[00:32:41.337,615] <dbg> bt_mesh_beacon.beacon_send:
[00:32:41.337,646] <dbg> bt_mesh_beacon.secure_beacon_send:
[00:32:41.337,677] <dbg> bt_mesh_beacon.bt_mesh_beacon_create: net_idx 0x0000 flags 0x00 NetID c2c18b859325129b
[00:32:41.337,707] <dbg> bt_mesh_beacon.bt_mesh_beacon_create: IV Index 0x00000000 Auth 5194e44054260785
[00:32:41.407,714] <dbg> bt_mesh_beacon.beacon_complete: err 0

The following logs are generated by the light when group 0xC000 is switched on via proxy (the LEDs assigned to this address do illuminate):

D: rssi 0 net_if 2
D: 22 bytes: 57833b0a2d7674fdef17c646c9b83978fca2de36a21f
D:
D: NID 0x57 net_idx 0x0000
D: NID 0x57 net_idx 0x0000
D: IVI 0 net->iv_index 0x00000000
D: src 0x0001
D: Decryption successful. Payload len 18
D: src 0x0001 dst 0xc000 ttl 5
D: PDU: 57050000770001c00076066f5839f3542a0c
D: No matching LPN for address 0xc000
D: src 0x0001 dst 0xc000 seq 0x00000077 friend_match 0
D: Payload 76066f5839f3542a0c
D: AFK 1 AID 0x36
D: Waiting 5 seconds
D: AKF 1 AID 0x36
D: len 8: 066f5839f3542a0c
D: app_idx 0x0000 src 0x0001 dst 0xc000
D: len 4: 8203010a
D: OpCode 0x00008203
D:
D:
D:
D:
D: TTL 5 CTL 0 dst 0xc000
D: Relaying packet. TTL is now 4
D:
D:
D: src 0x0001 seq 0x000077 old_iv 0
D: Stored RPL bt/mesh/RPL/1 value

Any further suggestions would be much appreciated.

RE: nRF Connect Mesh Light/Light Switch Example unreliable

Hung Bui — Fri, 07 Aug 2020 14:08:59 GMT

Hi Jacob,

Could you clarify what you meant by "the relavent LED on the Light Switch illuminates but not on the Light when the Light Switch is pressed." I assume you meant the light on the light server didn't turn on.
Please be aware that the address 0xFFFFF only address all nodes, not all elements. This means this address is only consumed by the first element of each node, not all the elements of the node. So if you light switch model is on the 2nd element it won't process the address destination 0xFFFF.

If you configure the light server to subscribe to a group address (for example 0xC000) and you publish the command from the light switch to that group address, would it work without retransmission ?