mirror of
https://github.com/espressif/esp-idf.git
synced 2025-07-30 02:37:19 +02:00
Merge branch 'doc/broken_readme_links_v4.1' into 'release/v4.1'
Docs: Fix broken README links (v4.1) See merge request espressif/esp-idf!9502
This commit is contained in:
Krzysztof Budzynski
@ -3,11 +3,11 @@ ESP-IDF Blufi demo
|
||||
|
||||
This is the demo for bluetooth config wifi connection to ap.
|
||||
|
||||
To test this demo, you need to prepare a mobile phone with blufi application installed. You can download the blufi application from [Android version](https://github.com/EspressifApp/EspBlufi) and [iOS version](https://itunes.apple.com/cn/app/espblufi/id1450614082?mt=8).
|
||||
To test this demo, you need to prepare a mobile phone with blufi application installed. You can download the blufi application from [Android version](https://github.com/EspressifApp/EspBlufi) and [iOS version](https://itunes.apple.com/cn/app/espblufi/id1450614082?mt=8).
|
||||
|
||||
Blufi is completely open source, here is the download link:
|
||||
|
||||
* [blufi source code](https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/blufi)
|
||||
* [blufi source code](https://github.com/espressif/esp-idf/tree/master/examples/bluetooth/bluedroid/ble/blufi)
|
||||
|
||||
* [BluFi protocol](https://docs.espressif.com/projects/esp-idf/en/latest/api-guides/blufi.html?highlight=blufi#the-frame-formats-defined-in-blufi)
|
||||
|
||||
|
||||
@ -5,10 +5,10 @@ This example demonstrates the coexistence of gattc and gatts.
|
||||
|
||||
This example creates a GATT service and starts ADV. The ADV name is `ESP_GATTS_DEMO`, then waits to be connected. At the same time, a gatt client is created, the ADV name is `ESP_GATTS_DEMO`, the device is connected, and the data is exchanged. If the device is not found within 120 seconds, the example will stop scanning.
|
||||
|
||||
ESP-IDF also allows users to create a GATT service via an attribute table, rather than add attributes one by one. And it is recommended for users to use. For more information about this method, please refer to [gatt_server_service_table_demo](../gatt_server_service_table).
|
||||
ESP-IDF also allows users to create a GATT service via an attribute table, rather than add attributes one by one. And it is recommended for users to use. For more information about this method, please refer to [gatt_server_service_table_demo](../../ble/gatt_server_service_table).
|
||||
|
||||
To test this example, you can run the [gatt_client_demo](../gatt_client), which can scan for and connect to this example automatically, and run [gatt_server_demo](../gatt_server), Waiting to be connected. They will start exchanging data once the GATT client has enabled the notification function of the GATT server.
|
||||
To test this example, you can run the [gatt_client_demo](../../ble/gatt_client), which can scan for and connect to this example automatically, and run [gatt_server_demo](../../ble/gatt_server), Waiting to be connected. They will start exchanging data once the GATT client has enabled the notification function of the GATT server.
|
||||
|
||||
Please check the [tutorial](tutorial/Gatt_Server_Example_Walkthrough.md) for more information about the gatts part of this example.
|
||||
Please check the [tutorial](tutorial/Gatt_Client_Example_Walkthrough.md) for more information about the gattc part of this example.
|
||||
Please check the [tutorial](../../ble/gatt_server/tutorial/Gatt_Server_Example_Walkthrough.md) for more information about the gatts part of this example.
|
||||
Please check the [tutorial](../../ble/gatt_client/tutorial/Gatt_Client_Example_Walkthrough.md) for more information about the gattc part of this example.
|
||||
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# ESP-BLE-MESH Examples
|
||||
|
||||
[ESP-BLE-MESH]($IDF_PATH/components/bt/esp_ble_mesh/) is the official Bluetooth® Mesh stack of Espressif Systems. We will provide long-term support for new features, performance optimization, etc.
|
||||
[ESP-BLE-MESH](../../../components/bt/esp_ble_mesh/) is the official Bluetooth® Mesh stack of Espressif Systems. We will provide long-term support for new features, performance optimization, etc.
|
||||
|
||||
Please help note that breaking changes may be introduced into ESP-BLE-MESH on [minor IDF versions](https://docs.espressif.com/projects/esp-idf/en/latest/versions.html).
|
||||
|
||||
|
||||
@ -6,7 +6,7 @@ This demo completes the following functions:
|
||||
1. Provisioning an unprovisioned device and change it to a node.
|
||||
2. Binding the provisioner's Appkey to its own models.
|
||||
3. Sending messages to the node about the Appkey and the fast provisioning information.
|
||||
4. Getting the addresses of all the nodes in the fast provisioning network.
|
||||
4. Getting the addresses of all the nodes in the fast provisioning network.
|
||||
5. Controlling the nodes by their group address.
|
||||
|
||||
**Note: The demo's functionality is similar to that of the EspBleMesh app.**
|
||||
@ -24,7 +24,7 @@ This demo has only one element, in which the following four models are implement
|
||||
|
||||
## 2. Code Analysis
|
||||
|
||||
Code initialization part reference [Initializing the Bluetooth and Initializing the BLE Mesh](../../../ble_mesh_wifi_coexist/tutorial%20%20%20%20%20%20/ble_mesh_wifi_coexist.md)
|
||||
Code initialization part reference [Initializing the Bluetooth and Initializing the BLE Mesh](../../../ble_mesh_wifi_coexist/tutorial/BLE_Mesh_WiFi_Coexist_Example_Walkthrough.md)
|
||||
|
||||
### 2.1 Data Structure
|
||||
|
||||
@ -51,7 +51,7 @@ The events and APIs in this section are presented in the same order with code ex
|
||||
|
||||
#### 2.2.1.1 Set the UUID Filter
|
||||
|
||||
The `esp_ble_mesh_provisioner_set_dev_uuid_match` API is called by the provisioner to set the part of the device UUID to be compared before starting to provision.
|
||||
The `esp_ble_mesh_provisioner_set_dev_uuid_match` API is called by the provisioner to set the part of the device UUID to be compared before starting to provision.
|
||||
|
||||
```
|
||||
/**
|
||||
@ -83,7 +83,7 @@ if (err != ESP_OK) {
|
||||
|
||||
#### 2.2.1.2 Add local Appkey
|
||||
|
||||
The provisioner has no Appkey right after it has been initialized. Therefore, you have to add a local Appkey for the provisioner by calling the `esp_ble_mesh_provisioner_add_local_app_key`.
|
||||
The provisioner has no Appkey right after it has been initialized. Therefore, you have to add a local Appkey for the provisioner by calling the `esp_ble_mesh_provisioner_add_local_app_key`.
|
||||
|
||||
```c
|
||||
err = esp_ble_mesh_provisioner_add_local_app_key(prov_info.app_key, prov_info.net_idx, prov_info.app_idx);
|
||||
@ -96,7 +96,7 @@ Please check the return value of the API calling and the return value of `ESP_BL
|
||||
|
||||
#### 2.2.1.3 Bind Appkey to local model
|
||||
|
||||
To control the server model, the client model uses messages to control the server model and these message must be encrypted by the Appkey. To that end, users must bind the Appkey of the provisioner to its local models, which are the **Generic OnOff Client** model and the **Vendor Client** model, by calling the `esp_ble_mesh_provisioner_add_local_app_key` api.
|
||||
To control the server model, the client model uses messages to control the server model and these message must be encrypted by the Appkey. To that end, users must bind the Appkey of the provisioner to its local models, which are the **Generic OnOff Client** model and the **Vendor Client** model, by calling the `esp_ble_mesh_provisioner_add_local_app_key` api.
|
||||
|
||||
```c
|
||||
prov_info.app_idx = param->provisioner_add_app_key_comp.app_idx;
|
||||
@ -118,7 +118,7 @@ Please check the return value of the API calling and the return value of the `ES
|
||||
|
||||
### 2.2.2 Provisioning a device
|
||||
|
||||
The unprovisioned devices continuously send the **Unprovisioned Device** beacon, which contains the value of its UUID.
|
||||
The unprovisioned devices continuously send the **Unprovisioned Device** beacon, which contains the value of its UUID.
|
||||
|
||||
* If the UUID matched, a `ESP_BLE_MESH_PROVISIONER_RECV_UNPROV_ADV_PKT_EVT` event will be triggered, which will add the unprovisioned device information to the queue of to-be-provisioned devices.
|
||||
|
||||
@ -160,7 +160,7 @@ return esp_ble_mesh_config_client_set_state(&common, &set);
|
||||
```
|
||||
|
||||
* If API calling succeeds, an `ESP_BLE_MESH_CFG_CLIENT_SET_STATE_EVT` event will be triggered, which sends other cache information (`example_fast_prov_info_set_t`) to the node's **Vendor Server** model by calling the `example_send_fast_prov_info_set` function;
|
||||
* If API calling (`example_send_fast_prov_info_set`) succeeded, a message with an opcode of `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_SET` will be sent, whose acknowledgement (with an opcode of `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_STATUS`) will further trigger an `ESP_BLE_MESH_MODEL_OPERATION_EVT` event
|
||||
* If API calling (`example_send_fast_prov_info_set`) succeeded, a message with an opcode of `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_SET` will be sent, whose acknowledgement (with an opcode of `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_STATUS`) will further trigger an `ESP_BLE_MESH_MODEL_OPERATION_EVT` event
|
||||
```c
|
||||
err = example_send_fast_prov_info_set(fast_prov_client.model, &info, &set);
|
||||
if (err != ESP_OK) {
|
||||
@ -168,7 +168,7 @@ return esp_ble_mesh_config_client_set_state(&common, &set);
|
||||
return;
|
||||
}
|
||||
```
|
||||
* If API calling (`example_send_fast_prov_info_set`) times out, an `ESP_BLE_MESH_CLIENT_MODEL_SEND_TIMEOUT_EVT` event will be triggered.
|
||||
* If API calling (`example_send_fast_prov_info_set`) times out, an `ESP_BLE_MESH_CLIENT_MODEL_SEND_TIMEOUT_EVT` event will be triggered.
|
||||
* If API calling times out, an `ESP_BLE_MESH_CFG_CLIENT_TIMEOUT_EVT` event is triggered.
|
||||
|
||||
After that, this node has the ability to provisioning other nodes as a provisioner, and further controls other nodes.
|
||||
@ -177,7 +177,7 @@ After that, this node has the ability to provisioning other nodes as a provision
|
||||
|
||||
### 2.2.4 Controlling the node
|
||||
|
||||
When the `ESP_BLE_MESH_MODEL_OPERATION_EVT` event is triggered, the provisioner starts a timer.
|
||||
When the `ESP_BLE_MESH_MODEL_OPERATION_EVT` event is triggered, the provisioner starts a timer.
|
||||
|
||||
```c
|
||||
ESP_LOG_BUFFER_HEX("fast prov info status", data, len);
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
# 1. Introduction
|
||||
## 1.1 Demo Function
|
||||
|
||||
This demo is used for fast provisioning networks. It takes no more than 60 seconds to provisioning 100 devices in this demo.
|
||||
This demo is used for fast provisioning networks. It takes no more than 60 seconds to provisioning 100 devices in this demo.
|
||||
|
||||
This demo must be used with the EspBleMesh app. For details about how to use the EspBleMesh app, please click [here](EspBleMesh.md).
|
||||
|
||||
@ -18,7 +18,7 @@ This demo has only one element, where the following five Models are implemented:
|
||||
|
||||
## 2. Code Analysis
|
||||
|
||||
Code initialization part reference [Initializing the Bluetooth and Initializing the BLE Mesh](../../../ble_mesh_wifi_coexist/tutorial%20%20%20%20%20%20/ble_mesh_wifi_coexist.md)
|
||||
Code initialization part reference [Initializing the Bluetooth and Initializing the BLE Mesh](../../../ble_mesh_wifi_coexist/tutorial/BLE_Mesh_WiFi_Coexist_Example_Walkthrough.md)
|
||||
|
||||
### 2.1 Data Structure
|
||||
|
||||
@ -99,7 +99,7 @@ The variables that are related to the address management are described in the fo
|
||||
|
||||
The cache data is required, so a node can change its role to become a provisioner. During this process, the `esp_ble_mesh_set_fast_prov_info` and `esp_ble_mesh_set_fast_prov_action` APIs are called.
|
||||
|
||||
The node's cache data, which are described in the following table, is sent by the provisioner.
|
||||
The node's cache data, which are described in the following table, is sent by the provisioner.
|
||||
|
||||
| Variable Name |Description |
|
||||
| ----------------------|------------------------- |
|
||||
@ -124,7 +124,7 @@ There are two timers in this demo, which are:
|
||||
* The timer starts or resets and starts when a Temporary Provisioner provisions an unprovisioned device.
|
||||
* The Temporary Provisioner will send a message (Address information) to the Primary Provisioner.
|
||||
2. `disable_fast_prov_timer` is used to disable the provisioning capabilities.
|
||||
* The node starts the timer when it receives a **Generic OnOff Get/Set/Set Unack** message sent by the EspBleMesh app. The group address should be used if you want to disable the provisioning capabilities of all nodes.
|
||||
* The node starts the timer when it receives a **Generic OnOff Get/Set/Set Unack** message sent by the EspBleMesh app. The group address should be used if you want to disable the provisioning capabilities of all nodes.
|
||||
|
||||
The variables that are related to these two timers are described below:
|
||||
|
||||
@ -137,7 +137,7 @@ The variables that are related to these two timers are described below:
|
||||
|
||||
#### 2.2.1 Vendor Server Model
|
||||
|
||||
The **Vendor Server** Model implements the node's `fast_prov_server` state, which has been covered in the previous section.
|
||||
The **Vendor Server** Model implements the node's `fast_prov_server` state, which has been covered in the previous section.
|
||||
|
||||
```c
|
||||
example_fast_prov_server_t fast_prov_server = {
|
||||
@ -160,7 +160,7 @@ example_fast_prov_server_t fast_prov_server = {
|
||||
};
|
||||
```
|
||||
|
||||
The `fast_prov_srv_op` is used to register the minimum length of messages. For example, the minimum length of the `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_SET` message is registered as 3 octets.
|
||||
The `fast_prov_srv_op` is used to register the minimum length of messages. For example, the minimum length of the `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_SET` message is registered as 3 octets.
|
||||
|
||||
```c
|
||||
static esp_ble_mesh_model_op_t fast_prov_srv_op[] = {
|
||||
@ -178,11 +178,11 @@ The `example_fast_prov_server_init` function is used to register the callback fu
|
||||
err = example_fast_prov_server_init(&vnd_models[0]);
|
||||
if (err != ESP_OK) {
|
||||
ESP_LOGE(TAG, "%s: Failed to initialize fast prov server model", __func__);
|
||||
return err;
|
||||
return err;
|
||||
}
|
||||
```
|
||||
|
||||
The `fast_prov_server` struct represents the Vendor server's states. The `CID_ESP` and `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_SRV` constants, which consist of the vendor server Model's Model id `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_SRV`, are used to identity the Vendor server Model.
|
||||
The `fast_prov_server` struct represents the Vendor server's states. The `CID_ESP` and `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_SRV` constants, which consist of the vendor server Model's Model id `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_SRV`, are used to identity the Vendor server Model.
|
||||
|
||||
|
||||
```c
|
||||
@ -236,7 +236,7 @@ if (err != ESP_OK) {
|
||||
}
|
||||
```
|
||||
|
||||
The `CID_ESP` and `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_CLI` constants, which consist of the vendor client Model's Model id `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_CLI`, are used to identity the Vendor client Model.
|
||||
The `CID_ESP` and `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_CLI` constants, which consist of the vendor client Model's Model id `ESP_BLE_MESH_VND_MODEL_ID_FAST_PROV_CLI`, are used to identity the Vendor client Model.
|
||||
|
||||
```c
|
||||
|
||||
@ -270,7 +270,7 @@ static esp_ble_mesh_elem_t elements[] = {
|
||||
|
||||
* INFO_SET
|
||||
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
| -----| ------------- | -------------|
|
||||
|Opcode| `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_SET` | `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_INFO_STATUS` |
|
||||
|Function| This message contains all the information as a Provisioner |Checks each field of the Provisioner information and set the corresponding flag bit. The returned status is variable.|
|
||||
@ -279,7 +279,7 @@ static esp_ble_mesh_elem_t elements[] = {
|
||||
|
||||
* NODE_ADDR
|
||||
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
| -----| ------------- | -------------|
|
||||
|Opcode| `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_NODE_ADDR` | `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_NODE_ADDR_ACK` |
|
||||
|Function| Temporary Provisioner reports the address of the node it has provisioned. |Used to check if the message was sent successfully. |
|
||||
@ -287,7 +287,7 @@ static esp_ble_mesh_elem_t elements[] = {
|
||||
|
||||
* ADDR_GET
|
||||
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
| -----| ------------- | -------------|
|
||||
|Opcode| `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_NODE_ADDR_GET` | `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_NODE_ADDR_STATUS` |
|
||||
|Function|Top Provisioner gets the address of all nodes obtained from Primary Provisioner. | Returns the address of all nodes, but does not contain its own. |
|
||||
@ -295,7 +295,7 @@ static esp_ble_mesh_elem_t elements[] = {
|
||||
|
||||
* NET_KEY_ADD
|
||||
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
|Meaning | Opcode-send | Opcode-ack |
|
||||
| -----| ------------- | -------------|
|
||||
|Opcode | `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_NET_KEY_ADD` | `ESP_BLE_MESH_VND_MODEL_OP_FAST_PROV_NET_KEY_STATUS` |
|
||||
|Function| Reserved for later use | Reserved for later use |
|
||||
@ -310,7 +310,7 @@ static esp_ble_mesh_elem_t elements[] = {
|
||||
esp_ble_mesh_register_prov_callback(example_ble_mesh_provisioning_cb);
|
||||
```
|
||||
|
||||
1. The callback function will be triggered when the **Vendor Server** Model:
|
||||
1. The callback function will be triggered when the **Vendor Server** Model:
|
||||
* Receives a message that indicates the Onoff state of the client Model; or
|
||||
* Calls any APIs that send messages.
|
||||
|
||||
@ -346,7 +346,7 @@ static esp_ble_mesh_elem_t elements[] = {
|
||||
esp_ble_mesh_register_custom_model_callback(example_ble_mesh_custom_model_cb);
|
||||
```
|
||||
|
||||
1. The callback function will be triggered when the **Vendor Client** model:
|
||||
1. The callback function will be triggered when the **Vendor Client** model:
|
||||
* Receives any message sent by the vendor server Model; or
|
||||
* Calls any APIs that send messages.
|
||||
|
||||
@ -383,7 +383,7 @@ The Vendor Client Model calls the `esp_ble_mesh_client_model_send_msg` API to se
|
||||
esp_ble_mesh_msg_ctx_t ctx = {
|
||||
.net_idx = info->net_idx,
|
||||
.app_idx = info->app_idx,
|
||||
.addr = info->dst,
|
||||
.addr = info->dst,
|
||||
.send_rel = false,
|
||||
.send_ttl = 0,
|
||||
};
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
1. This demo forwards the message sent by the nRF Mesh app.
|
||||
2. The user enters the address of the destination node and use it to forwarded packet.
|
||||
3. The types of the forwarded message include:
|
||||
* `ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_GET`,
|
||||
* `ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_GET`,
|
||||
* `ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET`,
|
||||
* `ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET_UNACK`.
|
||||
4. The destination node reports its Onoff state with the `ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_STATUS` message.
|
||||
@ -38,7 +38,7 @@ You can choose from the 4 message sequences described below:
|
||||
|
||||
## 2. Code Analysis
|
||||
|
||||
Code initialization part reference [Initializing the Bluetooth and Initializing the BLE Mesh](../../ble_mesh_wifi_coexist/tutorial%20%20%20%20%20%20/ble_mesh_wifi_coexist.md)
|
||||
Code initialization part reference [Initializing the Bluetooth and Initializing the BLE Mesh](../../../ble_mesh_wifi_coexist/tutorial/BLE_Mesh_WiFi_Coexist_Example_Walkthrough.md)
|
||||
|
||||
### 2.1 Model Definition
|
||||
|
||||
@ -47,7 +47,7 @@ Code initialization part reference [Initializing the Bluetooth and Initializing
|
||||
```c
|
||||
//Allocating memory for publishing messages.
|
||||
ESP_BLE_MESH_MODEL_PUB_DEFINE(onoff_srv_pub, 2 + 1, MSG_ROLE);
|
||||
//Registering the minimum length of messages. For example, the minimum length of the ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET message is registered as 2 octets.
|
||||
//Registering the minimum length of messages. For example, the minimum length of the ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET message is registered as 2 octets.
|
||||
static esp_ble_mesh_model_op_t onoff_op[] = {
|
||||
{ ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_GET, 0, 0},
|
||||
{ ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET, 2, 0},
|
||||
@ -93,7 +93,7 @@ esp_ble_mesh_register_generic_client_callback(esp_ble_mesh_generic_cb);
|
||||
| ESP_BLE_MESH_GENERIC_CLIENT_SET_STATE_EVT | ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET | The event triggered when the Generic Onoff Client Model receives acknowledgment after sending the `ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET` message |
|
||||
| ESP_BLE_MESH_GENERIC_CLIENT_PUBLISH_EVT | NA | The event triggered when the Generic Onoff Client Model receives publishing messages. |
|
||||
| ESP_BLE_MESH_GENERIC_CLIENT_TIMEOUT_EVT | ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET | The event triggered when API (that send messages) calling times out |
|
||||
|
||||
|
||||
|
||||
#### 2.2.2 The Callback function for the Generic Onoff Server Model
|
||||
|
||||
@ -120,7 +120,7 @@ esp_ble_mesh_register_custom_model_callback(esp_ble_mesh_model_cb);
|
||||
### 2.3 Model that Sends Message
|
||||
#### 2.3.1 Message Control
|
||||
|
||||
The `esp_ble_mesh_set_msg_common` function is used to set the message controlling parameters.
|
||||
The `esp_ble_mesh_set_msg_common` function is used to set the message controlling parameters.
|
||||
|
||||
| Parameter Name |Description |
|
||||
| ----------------------|------------------------- |
|
||||
@ -134,10 +134,10 @@ The `esp_ble_mesh_set_msg_common` function is used to set the message controllin
|
||||
| `msg_timeout` | The maximum time the Model will wait for an acknowledgement |
|
||||
| `msg_role` | The role of message (node/provisioner) |
|
||||
|
||||
> Note:
|
||||
>
|
||||
> Note:
|
||||
>
|
||||
> Please check the `ESP_BLE_MESH_MODEL_SEND_COMP_EVT` event to see if the message is sent successfully.
|
||||
> This event is just for sending sig Model and vendor Model messages, not for all Models.
|
||||
> This event is just for sending sig Model and vendor Model messages, not for all Models.
|
||||
|
||||
#### 2.3.2 The Generic Onoff Client sends message
|
||||
|
||||
@ -196,15 +196,15 @@ Users can adjust the address of the destination node.
|
||||
#define UART1_RX_PIN GPIO_NUM_17
|
||||
```
|
||||
|
||||
The `board_uart_task` task is used to receive commands sent via the serial port, among which, the`remote_addr` represents the address of destination node that the message is forwarded to. Please enters hexadecimal string, such as 5, for this parameter. The address will be converted to 0x05 automatically.
|
||||
|
||||
The `board_uart_task` task is used to receive commands sent via the serial port, among which, the`remote_addr` represents the address of destination node that the message is forwarded to. Please enters hexadecimal string, such as 5, for this parameter. The address will be converted to 0x05 automatically.
|
||||
|
||||
```c
|
||||
static void board_uart_task(void *p)
|
||||
{
|
||||
{
|
||||
uint8_t *data = calloc(1, UART_BUF_SIZE);
|
||||
uint32_t input;
|
||||
|
||||
while (1) {
|
||||
|
||||
while (1) {
|
||||
int len = uart_read_bytes(MESH_UART_NUM, data, UART_BUF_SIZE, 100 / portTICK_RATE_MS);
|
||||
if (len > 0) {
|
||||
input = strtoul((const char *)data, NULL, 16);
|
||||
@ -213,7 +213,7 @@ static void board_uart_task(void *p)
|
||||
memset(data, 0, UART_BUF_SIZE);
|
||||
}
|
||||
}
|
||||
|
||||
|
||||
vTaskDelete(NULL);
|
||||
}
|
||||
```
|
||||
@ -225,7 +225,7 @@ The steps for this demo:
|
||||
|
||||
1. The nRF Mesh App provisionings the unprovisioned devices into nodes;
|
||||
2. The nRF Mesh App adds a Appkey to these nodes, and bind the Models of these nodes to this Appkey.
|
||||
3. The nRF Mesh App sends a controlling message to the Generic Onoff Client Model. Then the Client Model forwards this message to the server Model of the other node.
|
||||
3. The nRF Mesh App sends a controlling message to the Generic Onoff Client Model. Then the Client Model forwards this message to the server Model of the other node.
|
||||
|
||||
The timing sequence diagram of this demo is shown below：
|
||||
|
||||
@ -233,7 +233,7 @@ The timing sequence diagram of this demo is shown below：
|
||||
|
||||
>Note:
|
||||
>
|
||||
>The node **only forwards the message after it receives the controlling message sent by the app**. That is said, the node will **not** forwards messages to the other nodes every time the user enters the address of the destination node through the serial port.
|
||||
>The node **only forwards the message after it receives the controlling message sent by the app**. That is said, the node will **not** forwards messages to the other nodes every time the user enters the address of the destination node through the serial port.
|
||||
|
||||
|
||||
# 4. The nRF Mesh App
|
||||
|
||||
@ -3,7 +3,7 @@
|
||||
|
||||
## 1. Introduction
|
||||
|
||||
This demo shows how a BLE Mesh device can function as a Provisioner. If you are new to BLE Mesh, please start by checking [Demo for ESP BLE Mesh Node](../../ble_mesh_node/README.md).
|
||||
This demo shows how a BLE Mesh device can function as a Provisioner.
|
||||
|
||||
## 2. Code Flow
|
||||
|
||||
@ -53,7 +53,7 @@ The following procedures are needed for the initialization with `ble_mesh_init`.
|
||||
|
||||
### 2.2 Set and Bind AppKey
|
||||
|
||||
While working as a Provisioner, a BLE Mesh device also needs to configure such parameters as AppKey, TTL, and Proxy after provisioning is finished. It is not required if a BLE Mesh device works as a node.
|
||||
While working as a Provisioner, a BLE Mesh device also needs to configure such parameters as AppKey, TTL, and Proxy after provisioning is finished. It is not required if a BLE Mesh device works as a node.
|
||||
|
||||
Please note that successful configuring of AppKeys is of vital importance. App can only send/receive data (set a state, get a state and publish) after an AppKey has been set and bound.
|
||||
|
||||
|
||||
@ -1,7 +1,7 @@
|
||||
ESP BLE Mesh and WiFi Coexist example
|
||||
========================
|
||||
|
||||
此demo是用来测试当BLE Mesh实现正常的配网和收发消息的正常功能时，WiFi 所能达到的最大throughput值。用户可以根据此demo中的throughput值来实现自己需要的应用场景。如果用户对ESP32 BLE Mesh使用方法还不熟悉的话， 可以参考[BLE Mesh brief introduction](../ble_mesh_node/README.md)
|
||||
此demo是用来测试当BLE Mesh实现正常的配网和收发消息的正常功能时，WiFi 所能达到的最大throughput值。用户可以根据此demo中的throughput值来实现自己需要的应用场景。
|
||||
|
||||
此demo主要分为两个部分：
|
||||
|
||||
|
||||
@ -14,7 +14,7 @@ When PPP connection has been established, the IP packet flow from application si
|
||||
### Hardware Required
|
||||
|
||||
To run this example, you need an ESP32 dev board (e.g. ESP32-WROVER Kit) or ESP32 core board (e.g. ESP32-DevKitC).
|
||||
For test purpose, you also need a cellular modem module. Here we take the [SIM800L](http://www.simcom.com/product/showproduct.php?lang=en&id=277) and [BG96](https://www.quectel.com/product/bg96.htm) as an example.
|
||||
For test purpose, you also need a cellular modem module. Here we take the [SIM800L](https://www.simcom.com/product/SIM800.html) and [BG96](https://www.quectel.com/product/bg96.htm) as an example.
|
||||
You can also try other modules as long as they embedded PPP protocol.
|
||||
|
||||
**Note:** Since SIM800L only support **2G** which will **not** work in some countries. And also keep in mind that in some other countries it will stop working soon (many remaining 2G networks will be switched off in the next 2-3 years). So you should **check with your local providers for further details** if you try this example with any 2G modules.
|
||||
|
||||
@ -1,6 +1,6 @@
|
||||
# OTA Tool Example
|
||||
|
||||
This example demonstrates common operations the OTA tool [otatool.py](../../../components/app_update/otatool.py) allows the user to perform:
|
||||
This example demonstrates common operations the OTA tool [otatool.py](../../../../components/app_update/otatool.py) allows the user to perform:
|
||||
|
||||
- reading, writing and erasing OTA partitions,
|
||||
- switching boot partitions, and
|
||||
@ -44,7 +44,7 @@ Shell script:
|
||||
./otatool_example.sh
|
||||
```
|
||||
|
||||
The script searches for valid target devices connected to the host and performs the operations on the first one it finds. This could present problems if there
|
||||
The script searches for valid target devices connected to the host and performs the operations on the first one it finds. This could present problems if there
|
||||
are multiple viable target devices attached to the host. To perform the operations on a specific device, specify the port it is attached to during script invocation ("/dev/ttyUSB2" for example):
|
||||
|
||||
Python script:
|
||||
|
||||
Reference in New Issue
Block a user