• State Suggested Answer
  • Replies 2 replies
  • Answers 1 answer
  • Subscribers 64 subscribers
  • Views 1060 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 242665
Options
This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Regarding nRF Mesh Multi-Provisioner

shaad

Hi, I have 2 questions regarding multiple controllers using nRF Mesh.

1. I used the import/export option to transfer the network details from Phone 1 to Phone 2. After import I also changed the unicast address of the provisioner as it says in the disclaimer after import. Now I am able to control my devices. Comparing the Json file before and after importing the network details from Phone 1 shows that the fields 'deviceKey' and 'unicastAddress' are changed in the phone's entry in 'nodes'. Are these fields changed so that the device being controlled needs to know that there is a different controller now? If so, why is the UUID not changed? And why is a different entry not made for Phone 2 altogether?

2. Can anyone explain what is the use of 'add provisioner' feature in settings/provisioner? How to use it?

Parents
  • 0

    Hello,

    Let me answer in more details.

    Each phone that you import the network on is a Provisioner. Should a Provisioner be able to send messages to the network, it must have a unique Unicast Address. Upon importing, you may modify the Unicast Address of the current provisioner, but it's better to have a separate instance of Provisioner for each phone, preferably before exporting. Each Provisioner instance has a unique Unicast Address, the Device Key and set of assigned ranges that it may use during provisioning other nodes or configuring old ones. This is to ensure that no two Provisioners will assign the same address to any node, group or scene.

    The iOS nRF Mesh app will actually create or restore the current Provisioner when importing a network configuration on a phone that never had this network or had it at least once before. It saves the UUID of the current Provisioner for each network UUID and tries to restore it. On Android version you need to manually set the current Provisioner to desired one after you import the network.

    So the recommended sequence should be like that:

    1. Create a new network on one of the phones.
    2. Create all Network Keys and Application Keys you plan to use.
    3. Define Groups, that all phones should know, and perhaps provision some initial devices.
    4. Create number of Provisioners. For each of them assign a non-overlapping Unicast Address Ranges, Group Address Ranges and Scene Ranges. Give them unique names, like "Andy's phone", "My iPhone", etc.
    5. Export the network configuration to all other phones. On each new phone set the current Provisioner to a different Provisioner instance.
    6. You may now start controlling nodes from all phones. Using iOS nRF Meshg you may also control other phones (as they are also nodes), for example send them new keys. This is not yet supported in the sample app on Android.
    7. You may also provision new nodes using any of the phones.
    8. To sync all phones, you need to export the network on all phones the made any changes to the network and merge the json file manually, then import it on all phones. Automatic merging hasn't been implemented as it's not obvious how to do that. For example, if one of the Provisioners has removed a Node, but the other still has it saved, should the merging add or remove this node in the result. There is only one timestamp per whole configuration and no "history", so it's not possible to deduct which event was the last one.
Reply
  • 0

    Hello,

    Let me answer in more details.

    Each phone that you import the network on is a Provisioner. Should a Provisioner be able to send messages to the network, it must have a unique Unicast Address. Upon importing, you may modify the Unicast Address of the current provisioner, but it's better to have a separate instance of Provisioner for each phone, preferably before exporting. Each Provisioner instance has a unique Unicast Address, the Device Key and set of assigned ranges that it may use during provisioning other nodes or configuring old ones. This is to ensure that no two Provisioners will assign the same address to any node, group or scene.

    The iOS nRF Mesh app will actually create or restore the current Provisioner when importing a network configuration on a phone that never had this network or had it at least once before. It saves the UUID of the current Provisioner for each network UUID and tries to restore it. On Android version you need to manually set the current Provisioner to desired one after you import the network.

    So the recommended sequence should be like that:

    1. Create a new network on one of the phones.
    2. Create all Network Keys and Application Keys you plan to use.
    3. Define Groups, that all phones should know, and perhaps provision some initial devices.
    4. Create number of Provisioners. For each of them assign a non-overlapping Unicast Address Ranges, Group Address Ranges and Scene Ranges. Give them unique names, like "Andy's phone", "My iPhone", etc.
    5. Export the network configuration to all other phones. On each new phone set the current Provisioner to a different Provisioner instance.
    6. You may now start controlling nodes from all phones. Using iOS nRF Meshg you may also control other phones (as they are also nodes), for example send them new keys. This is not yet supported in the sample app on Android.
    7. You may also provision new nodes using any of the phones.
    8. To sync all phones, you need to export the network on all phones the made any changes to the network and merge the json file manually, then import it on all phones. Automatic merging hasn't been implemented as it's not obvious how to do that. For example, if one of the Provisioners has removed a Node, but the other still has it saved, should the merging add or remove this node in the result. There is only one timestamp per whole configuration and no "history", so it's not possible to deduct which event was the last one.
Children
No Data
Related