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

BLE Mesh Proxy fine questions

I have an existing phone app (using the traditional GATT system), and I would like mesh-enable my products so that if the products can see each other, then the phone can connect to and control any node (so, not so much an automation system but a relay system for configuration messages).

1. Is there a good tutorial on how the mesh-proxy connection works in the firmware/phone side (does the proxy "broadcast" all the BLE Node addresses so it's truly transparent, or should I put in a GATT attribute for "I really want to connect with  this node?"

2. Can I pre-share the NSK for a "all nodes are part of the mesh out of the box"?  I don't expect the factories that our sensors are in to be close to each other (and if they are, cutting nodes out would be just as easy as commissioning them in...

  • Hi Thor, 

    1. We currently don't have a tutorial for the mesh proxy protocol. The best source for this is at chapter 6 in the Bluetooth Mesh spec v1.0.1 

    At section 6.3 you can find the Proxy PDU description. The phone send the normal Mesh packet inside a GATT packet. The proxy node receive the packet and transparently relays the mesh packet into the mesh network. 
    You can also have a look at our nRF Mesh app source code as the reference. 

    2. What is the NSK ? You can pre-provision a node to put it to an mesh network in production. It's not defined in the Bluetooth Mesh spec, but there shouldn't be a problem to do so. Have a look here: https://devzone.nordicsemi.com/nordic/short-range-guides/b/bluetooth-low-energy/posts/mass-provisioning-of-nordic-ble-mesh-nodes

  • 1. After playing around with the mesh proxy from a different vendor, I think I understand what it does/how it works -- it creates  "mesh config in/out" and "mesh data in/out" services in the GATT system; if a phone app wants to talk to the devices in the mesh, the app needs to be mesh-enabled (no simple "Turn EB0FACE off please," via GATT but the app has to make the Mesh-ADV packet, and then stuff it into the "Mesh-In" GATT attribute)...

    So, I'm thinking of making my own BLE "Operator" service so that "a list of mesh nodes" is exposed via GATT, and the phone can send messages "to a node" without having to be mesh-enabled (Write the Node address to an attribute, then write the commands into a different attribute; my proxy would talk that and use the BLE-Mesh services to make and send the correct "mesh" commands)

    To do that, I'd like to have a way to query the mesh (from a node in the mesh) to get "a list of all nodes that have the "light bulb" profile exposed... is there an approved BLE-Mesh method of doing this (a "who's there" message)?

    2. I was thinking of the NetKey, but the python scripts should show me what they're doing under the hood...

    Does the "network manager" need to be "refereshed" or even "present" with the new nodes, or can Light bulb_0013 automatically relay messages to/from Light bulb_0011 out-of-the-box if they can see each other?

    If they can, and I can "get a list of 'Light Bulbs'," I think that would solve 99% of my desire to "mesh out of the box" (and if 2 networks touch, we can blacklist that node and force a key update with "any mesh-management application" instead of coding it into our UI application) 

  • Hi Thor, 
    1. You are right about the how the GATT proxy protocol works. You need to stuff the Mesh-ADV packet into the GATT packet and send it over. So on the phone there must be a minimal mesh stack implemented in the app. 

    To make things simple, you can implement what you plan, a gateway node that deal with mesh and provide the phone a customized (and simpler) interface. In your case, you want to have a list of active light bulb nodes. The disadvantage of this method is that it's proprietary and it requires special gateway nodes to be implemented. 

    To get the list of active light-bulb node, there are several options. You can either have them broadcast a message to a group address, periodically. The gateway node then can subscribe to that address and get the list. Or you can do the opposite, the light bulb subscribe to a group address and wait for the polling message from the gateaway they then send a status message back after the query. 

    2. I'm not sure I understand your question regarding "network manager". You can pre-provision the nodes in production. They can work right out of the box. This is not recommended by the spec, but it doesn't violate it AFAIK.

    If there is different network key for different networks, then they don't talk to each other. 

Related