Showing results for 
Search instead for 
Did you mean: 

Resource Library

Introducing Self-Configure Vendor Specific model in Bluetooth Mesh


Introducing Self-Configure Vendor Specific model in Bluetooth Mesh

This blog introduces a vendor specific mesh model used for self configuration of Bluetooth mesh nodes. It is demonstrated with the help of two mesh demo code examples  - Dimmer_self_config and Embedded_provisioner.

Generally, we provision and configure mesh devices with the help of an external configuration client (Eg. Provisioners such as mobile apps, MeshClient, etc.). But in some scenarios where the mesh network does not allow (or need not allow) access for cell phones or any external devices, we can use the self-configuration vendor specific model for fast configuration. For example, a dimmer switch can be sold with one or several light bulbs. User should be able to power up the devices and start using them.

Here, Dimmer_self_config is a simple dimmer application with self-configure feature. It works in concert with Embedded_provisioner app - a dimmable light​​​ application which also serves as an embedded provisioner and/or self-configured device. In this blog, we will be looking at the implementation of Self-Configure feature of Dimmer_self_config in detail. If you are not familiar with simple dimmer and light_dimmable apps, please see the Mesh AppNote -AN227069​.

In this use case, the Embedded_provisioner app is expected to create a mesh network, scan for un-provisioned devices and provision Dimmer_self_config app without the help of any external provisioner devices. After provisioning, the Embedded Provisioner sends the Application Key and a vendor specific command to start the self-configuration of Dimmer_self_config app based on the hardcoded rules. The rules for self-configuration is hardcoded in the shared embedded_provisioner.h. After the successful configuration of Dimmer_self_config, LED on the Embedded_provisioner can be controlled using the push button on the Dimmer_self_config app. (Note: Enable both EMBEDDED_PROVISION and SELF_CONFIG flags in Embedded_provisioner app for this use case).

Below figure summarizes the overall mesh network structure.


Now, let us see some key steps required to implement the self-configure feature.

Step1: The rules for self-configuration is hardcoded in the shared embedded_provisioner.h. This header file mainly provides the definition of vendor specific model, configuration parameters/rules, required structures , etc.

The Cypress vendor specific Self-Config model is defined as follow.


The configuration parameters/rules (eg. Group address used for publication/subscription) are also defined in embedded_provisioner.h


Step2: Define configuration data of necessary models.

Along with necessary models for simple dimmer app, we define three additional models as well for Dimmer_self_config to aid self-configuration feature.


  1. WICED_BT_MESH_MODEL_CONFIG_CLIENT – The model is used to represent an element that can control and monitor the configuration of a node.
  2. WICED_BT_MESH_MODEL_DEFAULT_TRANSITION_TIME_CLIENT – The model may operate on states defined by the Generic Default Transition Time Server model
  3. MESH_VENDOR_SELF_CONFIG_MODEL - Vendor Specific (VS) mesh model for used for Self-Configuration of the device.

Step3: Model Initializations.

Apart from the level client initialization, which is used for dimmer app functionality, we initialize the configuration client and default transition time client models as well with appropriate message callback handler passed as parameter to receive and process messages for respective the models.


mesh_default_transition_time_client_message_handler is implemented in mesh_default_transition_time_client.c.

Step4: Implementation of Vendor Server message handler to process vendor specific mesh messages.

As indicated earlier, the Embedded_provisioner needs to instruct the Dimmer_self_config app to start the self-configuration - based on the hardcoded rules - by sending appropriate vendor specific command. So, the Dimmer_self_config should have a vendor server message handler to process these vendor messages/commands and take appropriate actions.


mesh_vendor_server_message_handler() checks the model_id, opcode, subcode, etc. and ask the local device to do the self-configuration by calling self_configure() function.

Step5: Self-Configuration logic implementation.

self_configure(uint16_t node_addr) function implements the basic logic for self-configuration of the device by binding Application Key to all models, configure models for subscriptions, publications and setting default transition time.


The main sub functions called inside self_configure() for the configurations are: -

  • configure_model_app_bind (uint16_t node_addr, wiced_bt_mesh_core_config_model_t* p_model, uint8_t element_idx, uint16_t app_key_idx)
  • configure_model_sub (uint16_t node_addr, wiced_bt_mesh_core_config_model_t* p_model, uint8_t element_idx, uint16_t group_addr)
  • configure_model_pub (uint16_t node_addr, wiced_bt_mesh_core_config_model_t* p_model, uint8_t element_idx, uint16_t app_key_idx, uint16_t pub_addr, uint32_t pub_period, uint8_t pub_ttl, uint8_t pub_rxmit_count, uint16_t pub_rxmit_interval, uint8_t pub_credentials)
  • configure_default_transition_time (uint16_t node_addr, wiced_bt_mesh_core_config_model_t* p_model, uint16_t app_key_idx, uint32_t deftt)

Note: The Self Config logic can be combined with the normal configuration. For example, after performing hardcoded actions, the Provisioner can still use standard Config Relay Set method to turn the relay feature on or off.




Check the readme of each apps for testing instructions.

Version history
Revision #:
1 of 1
Last update:
‎Dec 29, 2020 01:55 AM
Updated by: