I am hoping to use BTmesh for a simple control network. The provisioning node will have a touchscreen display and will act as a controller for a group of devices, I would like to use it to provision the network and then reboot and be able to communicate as a node within the network. I don't see a way for the provisioner to configure the models for itself, when it is set up as a provisioner it can't use the configuration functions as it can't communicate with itself and unless I am mistaken there are no functions set up for a node to configure itself. Is there another method I could use to get the node configured?
The main point of provisioning is to share the secret Network Key (+ some other data, like unicast address of the provisioned element, NetKey Index, flags, IV index) via an authenticated channel. If the provisioner and a node is the same device, you can simply store these data in the non-volatile memory, so that after reboot the node will know everything that would have been shared by the provisioner.
Configuration is the same. The provisioner is to share the secret Application Key (that is needed to add a device to an application) via an encrypted channel. You can save the Application Key to the non-volatile memory, as well, so that after reboot the node will know the AppKey.
Ok, seems like the configuration may be more accessible/automated than I was thinking it was. I've noticed that the network key is saved and is available to the device to load once it has rebooted, sounds like the appkey is stored in the same way rather than needing to be loaded when initialized as a node which I couldn't find a function to do. I see functions for configuring the model once the appkey is on the node, so I think that the path forward is clearer now.
Thank you Arnold,
After looking things through a little bit further I am still confused as to how to self-configure the node. The API functions for the models I saw earlier are all seem to be focused on setting the data to be published for a model (eg cmd_mesh_vendor_model_set_publication) rather than adding a new publication/subscription address to it.
Would you be able to explain how to set the model subscription/publication parameters in a little more detail? I just don't see where to set these addresses.
The three operations I don't really understand are the node equivalents of:
Binding an application key to a model (gecko_cmd_mesh_prov_appkey_add from the provisioner)
Setting the publication parameters (gecko_cmd_mesh_prov_model_pub_set from the provisioner)
Setting the subscription address (gecko_cmd_mesh_prov_model_sub_add from the provisioner)
I have found cmd_mesh_generic_client_set which appears to bind an appkey and set the publication parameters for a client model, but I don't see a similar function for configuring a server model.
I think you are looking for these:
/** Bind a Model to an Appkey locally. **/
void gecko_cmd_mesh_debug_local_model_app_bind(const struct gecko_msg_mesh_debug_local_model_app_bind_cmd_t *msg);
/** Add an address to a local Model's subscription list. **/
void gecko_cmd_mesh_debug_local_model_sub_add(const struct gecko_msg_mesh_debug_local_model_sub_add_cmd_t *msg);
/** Get all entries in a local Model's subscription list. **/
void gecko_cmd_mesh_debug_local_model_sub_get(const struct gecko_msg_mesh_debug_local_model_sub_get_cmd_t *msg);
/** Set a local Model's publication address, key, and parameters. **/
void gecko_cmd_mesh_debug_local_model_pub_set(const struct gecko_msg_mesh_debug_local_model_pub_set_cmd_t *msg);
/** Get a local Model's publication address, key, and parameters. **/
void gecko_cmd_mesh_debug_local_model_pub_get(const struct gecko_msg_mesh_debug_local_model_pub_get_cmd_t *msg);
/** Add a pre-configured Network or Application Key. **/
void gecko_cmd_mesh_debug_add_key(const struct gecko_msg_mesh_debug_add_key_cmd_t *msg);
Although these are debug functions, I think we do not have standard functions for this usecase right now.
These look to be exactly what I was searching for, I've found the declarations for these in gecko_bgapi.h and things are making more sense now. Thank you for the help with this.
I hope that I am not being naive, but I'm having some trouble getting the debug functions tied into the project I am working on.
The only location where I was able to find the functions you reference in your last post is in the gecko_bgapi.h header file, which contains declarations for the bgapi functions with the arguments passed by pointer to the relevant data structure. Since the function declarations are different in gecko_bgapi.h than they are elsewhere (eg. gecko_bgapi_mesh_node_native.h, gecko_bgapi_mesh_generic_server_native.h, etc.) it is not possible to replace the includes for each of the component header files with gecko_bgapi.h without some heavy modification. Is there a better way to bring in these functions? I have tried creating a header file with only the 6 functions I am trying to use and the supporting data structures but once in place the functions don't seem to have been linked with the library functions.
Invoking: GNU ARM C Linker arm-none-eabi-gcc -g -gdwarf-2 -mcpu=cortex-m4 -mthumb -T "C:\Users\rjohnson.DIGITAL\SimplicityStudio\v4_workspace\soc-btmesh-light_822\linker\GCC\efr32bg13p.ld" -L"C:/SiliconLabs/SimplicityStudio/v4/developer/sdks/blemesh/v1.0//protocol/bluetooth_dev/lib/EFR32XG13X/GCC/" -Xlinker -no-enum-size-warning -Xlinker -no-wchar-size-warning -Xlinker --gc-sections -Xlinker -Map="soc-btmesh-light_822.map" -mfpu=fpv4-sp-d16 -mfloat-abi=softfp -o soc-btmesh-light_822.axf -Wl,--start-group "./dcd_light.o" "./gatt_db.o" "./graphics.o" "./main.o" "./device/EFR32_B_1_3_P/gcc/startup_efr32bg13p.o" "./device/EFR32_B_1_3_P/system_efr32bg13p.o" "./emdrv/dmadrv.o" "./emdrv/gpiointerrupt.o" "./emdrv/sleep.o" "./emdrv/tempdrv.o" "./emdrv/uartdrv.o" "./emlib/em_adc.o" "./emlib/em_cmu.o" "./emlib/em_core.o" "./emlib/em_crypto.o" "./emlib/em_emu.o" "./emlib/em_gpio.o" "./emlib/em_i2c.o" "./emlib/em_ldma.o" "./emlib/em_leuart.o" "./emlib/em_msc.o" "./emlib/em_rmu.o" "./emlib/em_rtcc.o" "./emlib/em_system.o" "./emlib/em_usart.o" "./glib/BRD4104A/bmp.o" "./glib/BRD4104A/dmd_display.o" "./glib/BRD4104A/glib.o" "./glib/BRD4104A/glib_bitmap.o" "./glib/BRD4104A/glib_circle.o" "./glib/BRD4104A/glib_font_narrow_6x8.o" "./glib/BRD4104A/glib_font_normal_8x8.o" "./glib/BRD4104A/glib_font_number_16x20.o" "./glib/BRD4104A/glib_line.o" "./glib/BRD4104A/glib_polygon.o" "./glib/BRD4104A/glib_rectangle.o" "./glib/BRD4104A/glib_string.o" "./kit/BRD4104A/bsp_bcc.o" "./kit/BRD4104A/bsp_stk.o" "./kit/BRD4104A/bsp_stk_leds.o" "./kit/BRD4104A/i2cspm.o" "./kit/BRD4104A/si7013.o" "./kit/BRD4104A/tempsens.o" "./kit/BRD4104A/udelay.o" "./kit_flashpwr/BRD4104A/mx25flash_spi.o" "./kit_lcd/BRD4104A/display.o" "./kit_lcd/BRD4104A/displayls013b7dh03.o" "./kit_lcd/BRD4104A/displaypalemlib.o" "./serial_vcom/retargetio.o" "./serial_vcom/retargetserial.o" "./src/InitDevice.o" "./stack/bt_mesh_stack/mesh_lib.o" -lm -lbluetooth_mesh -Wl,--end-group -Wl,--start-group -lgcc -lc -lnosys -Wl,--end-group ./main.o: In function `handle_gecko_event': C:\Users\rjohnson.DIGITAL\SimplicityStudio\v4_workspace\soc-btmesh-light_822\GNU ARM v4.8.3 - Default/../main.c:1200: undefined reference to `gecko_cmd_mesh_debug_local_model_pub_get' collect2.exe: error: ld returned 1 exit status make: *** [soc-btmesh-light_822.axf] Error 1 14:51:13 Build Finished (took 2s.683ms)
I've noticed that the function headers in the bgapi submodule headers are just doing some data handling moving the arguments into the cmd_msg struc before calling gecko_handle_command to carry out the command, and I'll probably try this next. Is a better way to get to the library functions?
sorry for the confusion, the debug commands are not included in the SDK. They are only available in our internal debug versions and they are intentionally stripped of from the public release.
At the moment, I don't think there is a way for a device to provision itself using the public SDK. Technically it is possible and I have used this in some of my own tests.
We well need to discuss this use case with our mesh experts internally, it seems like a valid use case that is not currently supported by our stack.
I'd just like to piggy back on this thread to say my use case very much favors a device that can provision itself as well. I'll be following the SDK releases.