Tip / Sign in to post questions, reply, level up, and achieve exciting badges. Know more

cross mob

Introducing Self-Configure Vendor Specific model in Bluetooth Mesh

Introducing Self-Configure Vendor Specific model in Bluetooth Mesh

DheerajPK_41
Moderator
Moderator
Moderator
750 replies posted 500 likes received 500 replies posted

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.

Capture.PNG

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.

abcdsa.PNG

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

qwq.PNG

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.

a.PNG

  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.

aa.PNG

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.

aaaa.PNG

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.

aaa.PNG

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.

Links:

mtb-example-btsdk-mesh-demo-dimmer-self-config

mtb-example-btsdk-mesh-demo-embedded-provisioner

Check the readme of each apps for testing instructions.

0 Likes
853 Views