• State Verified Answer
  • Replies 11 replies
  • Subscribers 88 subscribers
  • Views 2706 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 279241
Options

How do I know the network ID of my client and servers when using static provisioner?

Eugene Tan

As stated in the title.

I am using nrf52832 provisioner example with light_lightness example in v4.2.0. Provisioner is able to set up the network with clients and servers properly. However, if I have 2 provisioners, how do I differentiate which servers & clients are provisioned by? Can it be identified by RTT Viewer log?

And can I modify the network ID?

Parents
  • 0

    Hi,

    You can differentiate by their network ID. A network ID is a unique, public identifier derived from a Network Key. The network ID is included in the header of the messages sent by the example (after provisioning). 

    What do you mean by modifying the network ID?

  • 0 in reply to Mttrinh

    Hi,

    Sorry for the late response.

    Can you give more details on what you are trying to do here? Do you really in need of two independent networks? Having two different provisioners and two different networks might not be the solution here. You shouldn't often be in a situation with multiple provisioners being able to be confused about which nodes are provisioned onto which network.

    Also note that the static provisioner works in a fixed and predefined way. It has its own limitations and is mainly provided as a quick way to demonstrate all the other examples of the ecosystem, not really meant for production deployment. Often you would a use a computer(something like Interactive PyACI) or a mobile app(like the nRF Mesh app for mobile(iOS/Android)) as a provisioner.

  • 0 in reply to Mttrinh

    Hi,

    No, this is not possible with the static provisioner. Like mentioned the provisioner has its own limitation and its main purpose is to be a tool to evaluate SDK examples, The static provisioner is far from suitable for any production deployment. 

    I'm not completely sure what you want to accomplish but would using different app keys instead of entirely seperate networks be an option? 

  • 0 in reply to Mttrinh

    Hi,

    so how do I go about changing the app keys?

  • 0 in reply to Mttrinh

    Like already mentioned, this is much easier using a different provisioner, like the mobile app.

  • 0 in reply to Mttrinh

    Sorry, this must be frustrating but what if I really need to use the static provisioner example instead?

    Then how do I change the app keys? 

  • +1 in reply to Eugene Tan

    Hi,

    Keep in mind that this would require some filtering somehow in the static provisioner which isn't there now, to be able to decide which application/subnet to use for each unprovisioned device. As it stands now, the provisioner is extremely dumb and provisions all nodes with the same URI in the same way.

    To do this with app keys, the easiest way would be to

    1. Add another appkey to m_nw_state

    2. Initialize this appkey in prov_helper_provision_self , as well as add it to the provisioner in the same function

    3. Somehow filter the devices as they get picked up, and provide the correct app key for each configuration round. This is not trivial, but I'd suggest trying to do the filtering in the case NRF_MESH_PROV_EVT_LINK_CLOSED: of static void prov_evt_handler in provisioner_helper.c, using the correct key pointer in the call to node_setup_start on line 220.

    Like already mentioned many times in this thread, this is out of its original purpose and not something we recommend doing. If you insist on using the static provisioner this way then you have to keep in mind that we do not have the resources to provide support with the issues that will appear (when bending the example out of its original purpose) and that you will be on your own.

Reply
  • +1 in reply to Eugene Tan

    Hi,

    Keep in mind that this would require some filtering somehow in the static provisioner which isn't there now, to be able to decide which application/subnet to use for each unprovisioned device. As it stands now, the provisioner is extremely dumb and provisions all nodes with the same URI in the same way.

    To do this with app keys, the easiest way would be to

    1. Add another appkey to m_nw_state

    2. Initialize this appkey in prov_helper_provision_self , as well as add it to the provisioner in the same function

    3. Somehow filter the devices as they get picked up, and provide the correct app key for each configuration round. This is not trivial, but I'd suggest trying to do the filtering in the case NRF_MESH_PROV_EVT_LINK_CLOSED: of static void prov_evt_handler in provisioner_helper.c, using the correct key pointer in the call to node_setup_start on line 220.

    Like already mentioned many times in this thread, this is out of its original purpose and not something we recommend doing. If you insist on using the static provisioner this way then you have to keep in mind that we do not have the resources to provide support with the issues that will appear (when bending the example out of its original purpose) and that you will be on your own.

Children
Related