Posts: 24
Registered: ‎09-29-2015
Accepted Solution

Bluetooth Mesh Provisioning and Subscribe/Publishing

I'm attempting to write my own app through an NCP node, and that all is going well.  However, I'm getting hung up on what needs to be done to get proper subscriptions and publishing working with models.


I'm starting with a node programmed with the light server BT mesh example code and my NCP node.  The NCP node is able to properly provision the light node to the network, but I'm now lost as to how to get the light node to toggle its LED.


I've tried assigning model subscriptions, and I'll occasionally appear to get that set properly with "success" responses from the light node, but when I issue either a generic_client_set or generic_client_publish command, nothing happens.


My question is this: what steps need to be taken in order to setup proper models after/during provisioning?  Is there any documentation clearly explaining this process?

Posts: 38
Registered: ‎08-11-2017

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

I haven't used the NCP, but using the C API (which I believe is essentially parallel to the BGAPI) I was able to provision and configure nodes with this set of steps:


a)Wait for gecko_evt_system_boot_id 
b) Initialize as a provisioner. -  gecko_cmd_mesh_prov_init()
c) Wait for gecko_evt_mesh_prov_initialized_id 
d) Create network key - gecko_cmd_mesh_prov_create_network() 
e) Create application key - gecko_cmd_mesh_prov_create_appkey() 
f) Scan for beacons - gecko_cmd_mesh_prov_scan_unprov_beacons() 
g) Wait for gecko_evt_mesh_prov_unprov_beacon_id 
h) Provision node - gecko_cmd_mesh_prov_provision_device() 
i) Wait for gecko_evt_mesh_prov_device_provisioned_id 
j) Deploy appkey to node - gecko_cmd_mesh_prov_appkey_add() 
k) Wait for gecko_evt_mesh_prov_config_status_id 
l) Bind model to appkey - gecko_cmd_mesh_prov_model_app_bind() 
m) Wait for gecko_evt_mesh_prov_config_status_id 
n) Add subscription address - gecko_cmd_mesh_prov_model_sub_add() 
o) Wait for gecko_evt_mesh_prov_config_status_id 
p) Set model publication parameters - gecko_cmd_mesh_prov_model_pub_set() 
q) Wait for gecko_evt_mesh_prov_config_status_id 
Looping back to step f for each additional node to be provisioned. 


As for the format of the commands to send to change the state, I think you will need cmd_mesh_generic_client_set to set the publication address of the OnOff client (do you have the OnOff client set up on the NCP?) and then call the cmd_mesh_generic_client_publish to send a message with the desired state.


I hope this helps,hopefully @JaakkoV will be able to set things straight if I have made a mistake here.


Best regards,


Posts: 24
Registered: ‎09-29-2015

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

Thanks, Rob.  I do believe the C API and BGAPI are analogous.  I'll walk through the steps you list and see if it helps at all.


That said, I'm curious about you asking if I have the On/Off client setup on the NCP.  Don't I only have to publish to the On/Off model with the client?  Are there other steps required?

Posts: 38
Registered: ‎08-11-2017

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

I think you need to have the OnOff client in the dcd table. Looking over the code for the ncp and light examples and this forum thread it seems that you are correct and that there is no need to do anything else initialize the OnOff client, the NCP example has the OnOff client in its dcd already. 

Posts: 24
Registered: ‎09-29-2015

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

I'm having some trouble now with the cmd_mesh_prov_model_sub_add.  I keep getting an 0x180 error (invalid parameter).  I think it comes down to my lack of understanding the elem_address parameter.  Does this assume I'm provisioning both a switch and light separately, where the light needs to know the address of the switch since it controls the On/Off model?

Posts: 38
Registered: ‎08-11-2017

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

The element address should be the same as the mesh address for the example project. If you had a light fixture with multiple lamps that you wanted to be able to control separately you would assign each to a separate OnOff server which is contained in a separate element with a different (sequential) mesh address to tell them apart.

Posts: 38
Registered: ‎08-11-2017

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

As far as other parameters to this command I can tell you what works for me:


address: The mesh address that was assigned to the 

elem_address: Same as address since the light example has a single element

netkey_index: The index that was assigned when you initialized the netkey, probably 0 but whatever value was returned when you set it. 

vendor_id: Since this is a SIG model use 0xFFFF

model_id: OnOff server is 0x1000

sub_address: A group address (I guess it doesn't have to be, that's just what I did). I think I used 0xC001 since group addresses are 0b11xxxxxxxxxxxxxx.



Posts: 24
Registered: ‎09-29-2015

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

Thank you for the help, @rjohnson!


I wasn't aware that group addresses needed to be in the format 0b11xxxxxx, and that seems to have been the problem.  After changing that, I get proper successful acknowledgements from the node.


Now I'm attempting to publish to the On/Off model to turn On/Off the LED on the board running the light example code.  Nothing has happened yet, but my commands seem to be in the correct format.


I'm still a bit confused as to why the On/Off model has different models for client/server.  If the light subscribes to 0x1000 (server model), and I publish to 0x1001 (client model), does the transaction happen properly?  My gut says the server needs to subscribe to the client model and the client needs to publish to the server model...

Posts: 38
Registered: ‎08-11-2017

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

Sounds like a step forward. 


The light has the server model on it and you are configuring that model to subscribe to the address that you are setting. In effect this just means that when a message with a your subscribed address in the destination field is received, it is passed up to the access layer (I think) where the opcode is evaluated and matched to the OnOff server. Both the OnOff server and OnOff client use the same opcodes, but the behaviors associated with them are different based on which role the node is acting in.


I haven't really had problems with sending since it was set up in the example I have used, but this is what is happening in the switch example when gecko_cmd_mesh_generic_client_publish is sent to change states:


resp = gecko_cmd_mesh_generic_client_publish(
    0,     // transition
    0,     // flags
    mesh_generic_request_on_off,     // type
    1,     // param len
    &req.on_off     /// parameters data




_my_index = 0 this is the element that the model is assigned to.

trid = 0 initially, incremented after each transaction. I think the stack will ignore any transaction with a transaction ID that is  less than or equal to the last transaction received from that node.

delay = 100, 50, or 0 (in the switch example, where each message is retransmitted 3x.)

mesh_generic_request_on_off = 0x00 

&req.on_off points to a structure where 0x01 is on and 0x00 is off.

Posts: 24
Registered: ‎09-29-2015

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

Yeah, I'm making progress.


Here's where I'm at now.  I just tried to simplify things to make sure everything was in order by provisioning both a light node and a switch node using and NCP node.  I got both devices provisioned, added app/network keys, and then attempted to set subscription and publications.


I'm subscribing the light node to model 0x1001 at address 0xc001, and I'm setting the switch node to publish to model 0x1001 at address 0xc001.  Everything seems to get successfully configured as the proper events occur with no error codes.  However, after doing that, button presses on the switch node result in nothing happen on the light node.


My basic steps for this:

  1. Provision light node and switch node with same app key and network key.
  2. Bind the 0x1001 model to the app key.
  3. Add a subscription to 0x1001 to the light node at address 0xc001
  4. Set the switch node to publish to 0x1001 at address 0xc001

I'm setting ttl and period on the mesh_prov_model_pub_set command to the switch to 0.  Would this be causing issues?  Am I missing some step above or configuring something the wrong way?

Posts: 24
Registered: ‎09-29-2015

Re: Bluetooth Mesh Provisioning and Subscribe/Publishing

Good news for anyone following this thread!


I got an NCP provisioner working with the light/switch example by SiLabs doing the following (similar to @rjohnson's steps above, but it points out my confusion in model IDs):


  1. Init NCP node as provisioner (CMD_PROV_INIT)
  2. Create a network using NCP (CMD_PROV_CREATE_NETWORK)
  3. Create an app key using NCP (CMD_PROV_CREATE_APPKEY)
  4. Scan for unprovisioned beacons (CMD_PROV_SCAN_UNPROV_BEACONS) - the light and switch nodes should be in an unprovisioned state here
  5. Provision light node using NCP (CMD_PROV_PROVISION_DEVICE) - the UUID should be that of the light node
  6. Provision switch node using NCP (CMD_PROV_PROVISION_DEVICE) - the UUID should be that of the switch node
  7. Send appkey to light node using NCP (CMD_PROV_APPKEY_ADD)
  8. Send appkey to the switch node using NCP (CMD_PROV_APPKEY_ADD)
  9. Bind model 0x1000 to app key on light node using NCP (CMD_PROV_MODEL_APP_BIND)
  10. Bind model 0x1001 to app key on switch node using NCP (CMD_PROV_MODEL_APP_BIND)
  11. Set switch node to publish to model 0x1001 using pub address 0xc001 using NCP (CMD_PROV_MODEL_PUB_SET)
  12. Subscribe light node to model 0x1000 using sub address 0xc001 using NCP (CMD_PROV_MODEL_SUB_ADD)

Note that many of these commands have associated events to show success/failure that I did not include in the steps above.


And with that, pressing buttons on the switch node controls the LEDs on the light node.  I was getting hung up on the Model IDs.  Both 0x1000 and 0x1001 are for the generic on/off model, but 0x1000 is the server model ID and 0x1001 is the client model ID.  Since the light node is a server it uses 0x1000, and since the switch node is a client it uses 0x1001.  I think the important thing here is that both nodes set these to use address 0xc001 (or whatever address of you decide to use that conforms to 0b11xxxxxx).


Now I will be working on using the NCP node as both provisioner and client to take away the need of the switch node.  I know this has some limitations in the current stack version, but it looks like people in the community have had some success with it.


@JaakkoV, please chime in on anything I have misunderstood, or if you have any insight on using an NCP as both provisioner and client in the current state of the stack.  I also seem to be lacking documentation on event's from the node after configuration (i.e. evt_mesh_prov_config_status).  The corresponding state IDs in the API documentation don't make much sense to me.  Is there any more documentation on this?