Please tell me the function of the '(0x9C) Bluetooth Mesh Devkey Add' command

[hn_utc]

We are building a mesh network only with Nordic microcomputers (nRF52840).
The SDK version is 4.2.0 'nrf5_SDK_for_Mesh_v4.2.0_src'.
Since it uses the serial command, the provisioner is based on 'examples/provisioner' and uses the serial function added.
Provisionee uses 'examples/light_switch/server' as a base with serial functionality added.

Follow the steps below to perform provisioning and packet transmission.
(*The SDK version is 4.2.0 'nrf5_SDK_for_Mesh_v4.2.0_src'.)

(1) Perform provisioning as a Provisioner.
(2) Register Provisionee's Devkey with Serial Command '(0x9C) Bluetooth Mesh Devkey Add'.
(3) Repeat (1) and (2) up to the upper limit of MAX_PROVISIONEE_NUMBER.
(4) Delete the registered Devkey with Serial Command '(0x9D) Bluetooth Mesh DevKey Delete'.
(5) Furthermore, I become a Provisioner and perform provisioning and add some nodes.
(6) Register Provisionee's Devkey with Serial Command '(0x9C) Bluetooth Mesh Devkey Add'.
Repeat steps (1) and (2) several times.
(7) Register All Node ID (0xFFFF) in Serial Command '(0xA1) Bluetooth Mesh Addr Subscription Add'.
(8) Register the group ID in Serial Command '(0xA1) Bluetooth Mesh Addr Subscription Add'.
(9) Send a packet to Provisionee with Serial Command '(0xAB) Bluetooth Mesh Packet Send'.
At this time, specify the 'Address Handle' obtained in (7) or (8) for the parameter 'DST Addr Handle'.

Question 1
If packet transmission is always to All nodes or groups, is there no problem with (4)?
Does doing (4) have any impact?

Question 2
Is the following understanding correct?
・Nodes provisioned in (1) and (2) cannot send packets with individual addresses because the Devkey is deleted in (4).
・Nodes provisioned in (5) to (6) can individually specify addresses and send packets.

[Simonr]

Hi

Just to make sure we've understood this correctly. So you want to provision devices until you reach the maximum amount, then erase the devkey and repeat the process? How many devices are you planning on provisioning exactly? The maximum number of devices in a Mesh network is very high, so wouldn't it be easier to just increasing the MAX_PROVISIONEE_NUMBER instead?

1. From the Bluetooth SIG on device keys: "A device key, or DevKey, is used to secure direct communication with a specific Bluetooth Mesh device. It is typically only used when configuring a device. Each device in a Bluetooth Mesh network has a unique DevKey." I think erasing the DevKey will not be the answer here, as they are only used for configuring nodes, and there will still be a separate AppKey for all other models. From what I understand increasing the MAX_PROVISIONEE_NUMBER will be the correct way to go about this if the issue is that you reach the maximum supported provisioned devices number by default. Erasing the DevKey will not, to my knowledge, erase the addresses as well.

(4) will result in the node no longer being configurable, and you might run into other issues as well. I would not erase a DevKey without it being a part of a procedure requiring this from the specification side.

2. If nodes from (1) and (2)  can't send packets that are individually addressed, that won't be because of the DevKey being erased, but some other changes. either completely separate or as a consequential error. Regarding the nodes from (5) and (6) I'm not sure, as I'm not sure what exactly has been done to these. But it sounds like they should work as completely ordinary nodes, since nothing strange has been done to them as far as I can tell.

Best regards,

Simon

[hn_utc]

Currently, the number of nodes assumed is 100.
(In the future, there may be more than 100 units)
Nodes will be grouped by area.
One node belongs to all groups (Node 1).
Other nodes belong to one group.
Node 1 sends packets to Group A, and nodes belonging to Group A send packets to Node 1.
(Node 1 may also send packets to all nodes)

If MAX_PROVISIONEE_NUMBER is set to 90 or more, an error will occur.
(Is there something wrong with 'nRF5 SDK v17.1.0'?)
* The values of REPLAY_CACHE_ENTRIES and MAX_AVAILABLE_SERVER_NODE_NUMBER are also changed according to MAX_PROVISIONEE_NUMBER.

[Simonr]

Hi

What error occurs when setting the provisionee number this high exactly? The only limiting factor as far as I know is the memory on the nRF52840, so it could be that you're running out of flash memory on the nRF52840. It's also strongly recommended to move to the nRF Connect SDK when developing for BLE Mesh, or at least the latest nRF5 SDK version (v 5.0.0) as there could be bugs in v4.2.0 which is pretty old at this point. Also, note that nRF5 SDK for Mesh v4.2.0 is only tested and supported by nRF5 SDK v16.0.0. So there might be some unforeseen behavior if you combine v17.1.0 and Mesh v4.2.0.

Best regards,

Simon

[hn_utc]

Hi

I get a build error.
Please let me know what steps are missing.

Changed the constant below to (100) to provision 100 units.
MAX_PROVISIONEE_NUMBER
MAX_AVAILABLE_SERVER_NODE_NUMBER
REPLAY_CACHE_ENTRIES

I get a build error as below.
Compiling ‘device_state_manager.c’
nrf_mesh_assert.h
device_state_manager.c
static assertion failed: "unspecified message"
in definition of macro '_SELECT_ASSERT_FUNC'
in expansion of macro 'STATIC_ASSERT_SIMPLE'
in expansion of macro 'STATIC_ASSERT'
in expansion of macro 'NRF_MESH_STATIC_ASSERT'

The following two environments were used.
Both give the same build error.
case 1
nRF5_SDK_17.1.0_ddde560
nrf5sdkformeshv500src

case 2
nRF5_SDK_17.1.0_ddde560
nrf5_SDK_for_Mesh_v4.2.0_src

Best Regards

[Simonr]

Can you provide the full build log so we can see the entirety of it, as this just provides an "unspecified message" that doesn't tell us much. 

Best regards,

Simon

[hn_utc]

Thank you.

Would a "full build log" be okay with this?

forMesh50_BuildLog_0704.txt