BLE Mesh Proxy fine questions

RE: BLE Mesh Proxy fine questions

Hung Bui — Tue, 10 Mar 2020 11:15:03 GMT

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.

RE: BLE Mesh Proxy fine questions

thormj — Fri, 06 Mar 2020 18:01:57 GMT

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)

RE: BLE Mesh Proxy fine questions

Hung Bui — Tue, 25 Feb 2020 13:44:32 GMT

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