Make a mesh provisioner node visible through GATT

Hello all,

I am working on an application that involves two types of device inside a mesh network: devices that have to be provisionned (server) and devices that provision (client). Servers are also visible through "classic" BLE (GATT) and can be DFUed using OTA. I believe that this happens "magically" thanks to mesh_provisionee_prov_start method. i don't know exactly what make the node, "broadcasts" its name inside the method. On the other side, the client devices use the "provisioner_init" method, from the prov_helper file. But when I Init the provisioner, I can't see its name broadcasting. I want to be able to OTA my servers. How can I make a device at the same time provisioner and broadcasting its name in GATT ?

Thank for you help

Parents
  • Hi,

    It sounds like there is some confusion here. There are some different concepts:

    The first concept is provisioner / provisionee. The provisioner is used for creating a mesh network, and for provisioning other devices into the network. We call the device a node when it has been provisioned. In order for a network to use multiple provisioners, those provisioners must share the configuration database of the mesh network. Bluetooth SIG has specified a json format for sharing the mesh configuration database, but there is no specification for how to share this file. Our nRF Mesh app for iOS and for Android can export and import this format, but we do not have an implementation for the SoC.

    All Bluetooth mesh devices must support the provisionee role, which means they can be provisioned into a Bluetooth mesh network and become a node. This role is automatically handled by the mesh stack, and you should not change the provisionee behaviour of the node.

    The second concept is node configuration. All Bluetooth mesh devices are required to have a configuration model server, which is used for configuring the node. Some devices (usually the provisioner) have a configuration client, which is used for configuring other nodes. For accessing the configuration server of a node, one must have the device key for that node. This key is known to the provisioner.

    The third concept is DFU. DFU support has nothing to do with mesh_provisionee_prov_start, which rather is related to the process of becoming provisioned into a network, in nRF5 SDK for Mesh.

    Please note that for new projects we recommend the nRF Connect SDK. The older nRF5 SDK and nRF5 SDK for Mesh are now in maintenance mode. Read more about the SDKs and their state in our nRF Connect SDK and nRF5 SDK statement.

    For more on mesh concepts, see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_bt_mesh_concepts.html

    For more on DFU, see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-ncs.html

    Regards,
    Terje

Reply
  • Hi,

    It sounds like there is some confusion here. There are some different concepts:

    The first concept is provisioner / provisionee. The provisioner is used for creating a mesh network, and for provisioning other devices into the network. We call the device a node when it has been provisioned. In order for a network to use multiple provisioners, those provisioners must share the configuration database of the mesh network. Bluetooth SIG has specified a json format for sharing the mesh configuration database, but there is no specification for how to share this file. Our nRF Mesh app for iOS and for Android can export and import this format, but we do not have an implementation for the SoC.

    All Bluetooth mesh devices must support the provisionee role, which means they can be provisioned into a Bluetooth mesh network and become a node. This role is automatically handled by the mesh stack, and you should not change the provisionee behaviour of the node.

    The second concept is node configuration. All Bluetooth mesh devices are required to have a configuration model server, which is used for configuring the node. Some devices (usually the provisioner) have a configuration client, which is used for configuring other nodes. For accessing the configuration server of a node, one must have the device key for that node. This key is known to the provisioner.

    The third concept is DFU. DFU support has nothing to do with mesh_provisionee_prov_start, which rather is related to the process of becoming provisioned into a network, in nRF5 SDK for Mesh.

    Please note that for new projects we recommend the nRF Connect SDK. The older nRF5 SDK and nRF5 SDK for Mesh are now in maintenance mode. Read more about the SDKs and their state in our nRF Connect SDK and nRF5 SDK statement.

    For more on mesh concepts, see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/nrf/ug_bt_mesh_concepts.html

    For more on DFU, see https://developer.nordicsemi.com/nRF_Connect_SDK/doc/latest/mcuboot/readme-ncs.html

    Regards,
    Terje

Children
No Data
Related