Hello,

It is difficult to tell what the random problem could be without further investigation.  Please contact our local support to help you figure out this issue.

BR
 

Hello,

It is hard to tell what the random problem could be without further investigation.  Please contact our local support to help you figure out this issue.

BR
 

The cmd_mesh_node_request_ivupdate command is called by the node that is initiating the IV update procedure, which is the Node B according to your description.  Node A should have updated the IV index automatically by the stack as the node was in the network when the procedure was ongoing.  Node C will a) update the IV index automatically by the stack and get the evt_mesh_node_changed_ivupdate_state event; b) get the evt_mesh_node_ivrecovery_needed event; or c) need to be re-provisioned; depending on the network state.

1. If the network IV index = current IV index + 1 and the IV Update Flag in the secure network beacon is 1 (IV Update in Progress), the stack will update the IV index automatically and generate the evt_mesh_node_changed_ivupdate_state event.

2. If the network IV index > current IV index + 1 and <= current IV index + 42, the stack will generate the evt_mesh_node_ivrecovery_needed event. The event is to notify the application that the node may have missed IV index updates and the stack will perform the IV index recovery procedure if the IV index recovery mode is enabled. The application can call the cmd_mesh_node_set_ivrecovery_mode command to enable or disable the IV index recovery mode. The stack will generate the evt_mesh_node_changed_ivupdate_state event when the procedure is done.

3. If the network IV index = current IV index + 1 but the IV Update Flag in the secure network beacon is 0 (Normal Operation), the stack will behave same as #2.

If you don't receive the evt_mesh_node_ivrecovery_needed event and you are sure that secure network beaconing is enabled on all nodes, please check the time limits in the section IV Update & Recovery Limitations of KBA 0513:
https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2019/09/02/iv_update_recoveryprocedureandsequencenumber-t90G

If you can reproduce this issue and are debugging the issue instead of investigating what was happening, you may use Mesh Test commands, such as the cmd_mesh_test_set_ivupdate_test_mode command to remove time limits and the cmd_mesh_test_set_local_config command to enable secure network beaconing locally, to help debug the issue.  The code example in KBA 0513 uses these commands to easily demonstrate different scenarios.

 

The cmd_mesh_node_request_ivupdate command is called by the node that is initiating the IV update procedure, which is the Node B according to your description.  Node A should have updated the IV index automatically by the stack as the node was in the network when the procedure was ongoing.  Node C will a) update the IV index automatically by the stack and get the evt_mesh_node_changed_ivupdate_state event; b) get the evt_mesh_node_ivrecovery_needed event; or c) need to be re-provisioned; depending on the network state.

1. If the network IV index = current IV index + 1 and the IV Update Flag in the secure network beacon is 1 (IV Update in Progress), the stack will update the IV index automatically and generate the evt_mesh_node_changed_ivupdate_state event.

2. If the network IV index > current IV index + 1 and <= current IV index + 42, the stack will generate the evt_mesh_node_ivrecovery_needed event. The event is to notify the application that the node may have missed IV index updates and the stack will perform the IV index recovery procedure if the IV index recovery mode is enabled. The application can call the cmd_mesh_node_set_ivrecovery_mode command to enable or disable the IV index recovery mode. The stack will generate the evt_mesh_node_changed_ivupdate_state event when the procedure is done.

3. If the network IV index = current IV index + 1 but the IV Update Flag in the secure network beacon is 0 (Normal Operation), the stack will behave same as #2.

If you don't receive the evt_mesh_node_ivrecovery_needed event and you are sure that secure network beaconing is enabled on all nodes, please check the time limits in the section IV Update & Recovery Limitations of KBA 0513:

https://www.silabs.com/community/wireless/bluetooth/knowledge-base.entry.html/2019/09/02/iv_update_recoveryprocedureandsequencenumber-t90G

 

If you can reproduce this issue and are debugging the issue instead of investigating what was happening, you may use Mesh Test commands, such as the cmd_mesh_test_set_ivupdate_test_mode command to remove time limits and the cmd_mesh_test_set_local_config command to enable secure network beaconing locally, to help debug the issue.  The code example in KBA 0513 uses these commands to easily demonstrate different scenarios.

 

Bluetooth Mesh might not be the solution you need in your use case. Bluetooth mesh nodes use broadcasting to transmit messages and the way to save power for the node that is powered by a battery is to stay in a power saving mode most of the time. It is similar to a BLE device but the difference is the low-power node requires a friend node to receive and cache messages for the LPN when it is sleeping.

For your use case we suggest using one or more central devices like a hub for your devices to communicate through:

• The central device sends out periodic advertisements
• All peripheral devices are in the EM2 mode with receiving periodic advertisements
• All peripheral devices synchronize messages via the periodic advertisements and receive user data from the central device
• A peripheral device can send user data via legacy/extended advertisements to the central device or to all other peripheral devices through the central device
• The central device scans for legacy/extended advertisements and sends user data to peripheral devices

 

Please see https://docs.silabs.com/bluetooth/2.13/general/adv-and-scanning/periodic-adv-bt5 for the periodic advertising concept.

 

Bluetooth Mesh might not be the solution you need in your use case. Bluetooth mesh nodes use broadcasting to transmit messages and the way to save power for the node that is powered by a battery is to stay in a power saving mode most of the time. It is similar to a BLE device but the difference is the low-power node requires a friend node to receive and cache messages for the LPN when it is sleeping.

For your use case we suggest using one or more central devices like a hub for your devices to communicate through:

• The central device sends out periodic advertisements
• All peripheral devices are in the EM2 mode with receiving periodic advertisements
• All peripheral devices synchronize messages via the periodic advertisements and receive user data from the central device
• A peripheral device can send user data via legacy/extended advertisements to the central device or to all other peripheral devices through the central device
• The central device scans for legacy/extended advertisements and sends user data to peripheral devices

Please see https://docs.silabs.com/bluetooth/2.13/general/adv-and-scanning/periodic-adv-bt5 for the periodic advertising concept.

 

As you described the problem could be none of the nodes was transmitting secure network beacons. You can issue the cmd_mesh_node_set_beacon_reporting command and check if the evt_mesh_node_beacon_received event is raised in the node C. If this event is raised, you can check further the event data 'iv_update' for the IV index update state and 'ivindex' for the IV index in the network. If this event is not raised, you will need to find out why secure network beacons broadcasting was disabled. The secure network beacon state in the configuration server is usually set by the provisioner.
 

Hi Thierry,

You can get the vendor model example projects we provided at GitHub:
https://github.com/silabs-kevin/vendor_model_server
https://github.com/silabs-kevin/vendor_model_client

See cmd_mesh_vendor_model_* commands and the evt_mesh_vendor_model_receive event in app.c that demonstrate how to send and receive vendor messages.

We are working on updating KBA_BT_0502 and other KBAs for Bluetooth Mesh SDK v2.x. You would be notified of the new articles published.

 

Hi Thierry,

You can get the vendor model example projects we provided on GitHub:
https://github.com/silabs-kevin/vendor_model_server
https://github.com/silabs-kevin/vendor_model_client

See cmd_mesh_vendor_model_* commands and the evt_mesh_vendor_model_receive event in app.c that demonstrate how to send and receive vendor messages.

We are working on updating KBA_BT_0502 and other KBAs for Bluetooth Mesh SDK v2.x. You would be notified of these new articles once they are published.

 

The stack doesn't limit the size of the subscription list. The only limit is the size of RAM and persistent storage. See BTMESH_HEAP_SIZE in mesh_sizes.h and main.c where a region of the stack heap (MESH_CFG_MAX_MODELS * MESH_CFG_MAX_SUBSCRIPTIONS * MESH_MEMSIZE_MODEL_PER_SUBSCRIPTION) is reserved for subscription lists and the stack stores the subscription lists in persistent storage.

The stack source code has no changes regarding the Max Subscriptions setting between v1.6 and v1.7.