This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Multiple proxy clients and concurrent updates

Hello Nordic,

We have constant success with provisioning servers into the mesh and communicating to smart devices via proxy node. However we do all provisioning with the smart device app (both android and iOS) and so a couple questions came up:

1: We don't have luck provisioning with one mobile (GATT) device and then trying to get the other GATT device to connect to the network. We tried copying the net key and app key from the provisioning device to the other device (both are mobile devices) that we want to connect but it doesn't find the network when scanning. Neither with the provisioning smart device connected and disconnected from the proxy server. Is there a specific procedure for connecting another smart device (GATT) that didn't provision the network? We do see the device in nRFConnect app and can connect but there's no way to send information since we technically are not sending a proxy PDU with appropriate keys etc. 

2: Assuming a solution exists to the first question, let's suppose there are multiple GATT devices connected via proxy nodes into the mesh. Should each GATT device have its own unicast address or can they all have the same unicast address? I would think there is no way for the network to "know" that the source address of the message is actually from different devices since they are relayed through proxy nodes. The reason for this question is that if I send a command from one device, I would want that state to reflect on all connected devices. The server is going to send a reply to the src of the message, so if the GATT devices can all have the same address they should all get the message passed to them. Similarly, when the server state is changed locally (button press on the device) it should publish, and again if the model publish address is a unicast address -- that of the GATT devices, state should reflect. Is this possible?

3: If the answer to 2 is "no" the best alternative that we can think of at the moment is to have all the GATT devices subscribe to a group address that all the servers publish state to. This requires a bit more coding to handle but is certainly feasible when building the mesh network. In this case how are GATT devices that want to connect to the mesh network assigned addresses? Is there a proxy feature that "provisions" a GATT device to be able to connect to the network (back at question 1 again) and assigns an address?

Apologies for the quantity of words. Thanks!

Parents
  • Some more information from our developers; 

    Our libraries and sample apps for Android and iOS now support multiple provisioners, net and app keys. But we only support provisioner mode for phones. 
    This means that you may export the whole network configuration from one phone and import it on another. Before exporting, you have to create a number of provisioner object, each gets it's own range for unicast addresses, group addresses and scenes. After importing, the other user has to select a different provisioner, which means that the other user's pphone may provision new devices without conflicts. 
    A provisioner may (and usually will) have a unicast address (will be a node in the network), otherwise it can't perform configurations on newly provisioned nodes. An address is given to the provisioner upon creation. It should not change it, but can, form any address from it's own range. 

    We do not support not-provisioner mode on phones (yet). That means that a phone with our library will be able to perform provisioning of new nodes. Not-provisioner mode would require a limited library, with all the provisioning related features removed. But you can still use the lib that we have, just not expose those features to the user, and get all the keys via export/import mechanism, not by provisioning. 

    In Mesh 1.0.1, there is no remote provisioning implemented in the Spec. That means, a phone would have to advertise as an unprovisioned device, a provisioner would have to connect to it via GATT and provision. 

    Best regards, 
    Joakim

Reply
  • Some more information from our developers; 

    Our libraries and sample apps for Android and iOS now support multiple provisioners, net and app keys. But we only support provisioner mode for phones. 
    This means that you may export the whole network configuration from one phone and import it on another. Before exporting, you have to create a number of provisioner object, each gets it's own range for unicast addresses, group addresses and scenes. After importing, the other user has to select a different provisioner, which means that the other user's pphone may provision new devices without conflicts. 
    A provisioner may (and usually will) have a unicast address (will be a node in the network), otherwise it can't perform configurations on newly provisioned nodes. An address is given to the provisioner upon creation. It should not change it, but can, form any address from it's own range. 

    We do not support not-provisioner mode on phones (yet). That means that a phone with our library will be able to perform provisioning of new nodes. Not-provisioner mode would require a limited library, with all the provisioning related features removed. But you can still use the lib that we have, just not expose those features to the user, and get all the keys via export/import mechanism, not by provisioning. 

    In Mesh 1.0.1, there is no remote provisioning implemented in the Spec. That means, a phone would have to advertise as an unprovisioned device, a provisioner would have to connect to it via GATT and provision. 

    Best regards, 
    Joakim

Children
No Data
Related