Esp-idf: [BLE Mesh] How to send a message using UART and app in a mesh network ? (IDFGH-1874)

[John-nx]

Environment

• Development Kit: [ESP32-DevKitC]
• Kit version (DevKitC): [v4]
• Module or chip used: [ESP32-WROOM-32D]
• IDF version (ran git describe --tags to find it):
  // v4.0-dev-301-gc7c419da4
• Build System: ESP-IDF Tools // [Make|CMake]
• Compiler version (ran gcc --version to find it):
  // gcc (MinGW.org GCC-6.3.0-1) 6.3.0
• Operating System: [Windows]
• Power Supply: [USB]

Problem Description

I have no idea what message and in which format can be sent through UART 1 to a certain ble mesh node for turning on/off an LED.

//Detailed problem description goes here.

Expected Behavior

A message through the UART1 is sent to the device1 (ble_mesh_client_model) the same message is resent/relayed to the device2 (ble_mesh_node) and turns ON/OFF an LED belongs to the device2.

Actual Behavior

Steps to repropducer

-Device1 (ESP32-DevKitC) that runs the ble_mesh_client_model project.
-Device2 (ESP32-DevKitC) runs the ble_mesh_node project.
-nRF Mesh app is used for provisioning these two nodes
-The pin numbers 16 and 17 (on the (ESP32-DevKitC) are used to send a message (UAR1)
with a terminal emulator (termite)

• I have opened a serial session and can send messages successfully to the micro that is running ble_mesh_client_model (device1 ). At this point, if I monitor the device1 (ble_mesh_client_model ) and send a message like "0001" to it., on the command line I see:
  I (153032) BOARD: board_uart_task: input 0x00000001, remote_addr 0x0001

My questions is:
Which message and in which format must be sent to device1 (ble_mesh_client_model ) that turns an LED on/off in device2 (ble_mesh_node)?

Secondly, these two nodes are indeed proxy nodes, because I can send ON/OFF messages to them through nRF Mesh app, Is that right?

// It helps if you attach a picture of your setup/wiring here.

Code to reproduce this issue

Debug Logs

Other items if possible

[negativekelvin]

The UART is only for setting the node address, there is no command to set the state through the UART. The code that forwards the message to the node is here:
https://github.com/espressif/esp-idf/blob/9f145ff165099f32b92b7ee022a1debc5f0a583d/examples/bluetooth/esp_ble_mesh/ble_mesh_client_model/main/ble_mesh_demo_main.c#L338-L349

[WCCWCC]

Hi John-nx,

 We recommend that you read the documentation related to the project, under the same path.

 Detailed steps in the documentation.

[John-nx]

Thanks for the response.
The problem is the documentation/tutorial is really vague.
Could you please shed some lights on the followings:

1. What is the usage of setting an address using UART1 when I can change the state of any led/element using the nRF Mesh app anyways? (I mean without even using UART)

2. I can connect to ANY node (even my device2 which is flashed with ble_mesh_node), and change the state of an element in the other nodes (like node flashed with ble_mesh_client_model), always using nRF mesh app, what does this suppose to mean?
   It must work vice versa or not? Do both of the nodes have the relay role?

3. Again, since I can connect to both nodes (ble_mesh_client_mode and ble_mesh_node) with nRF Mesh app and send commands, this means that these BOTH nodes are indeed proxy nodes ?

Thank you so much

[WCCWCC]

Hi John-nx，
environment： nrf Mesh + Ble_mesh_client_mode + ble_mesh_node

• Ble_mesh_client_mode is based on ble_mesh_node.
  
  
  
  • Ble_mesh_client_mode can control the ble_mesh_node node, but needs to know the address of the ble_mesh_node node as the destination address of the message.
  
  
  • You need to enter the address of another ble_mesh_node node through the serial port and store it in the ble_mesh_client_mode node in this way.
  
  
  • You can see the processing behavior of the message received by the ble_mesh_client_mode node, which has sent a new message to control the ble_mesh_node node.
  
  
• Proxy and relay You can configure in menuconfig in coexistence, which is currently enabled by default.

[John-nx]

Thanks for your fast response.

I understood your response which is the same as what is written in tutorial.
However, my point was something else, let me put in in another way:

ble_mesh_node can ALSO control Ble_mesh_client_mode ! and there is NO need to enter the address of another node through serial port to control its LEDs.

Does this make sense to you?
P.S. about Proxy and relay we agree that they are active then.

[WCCWCC]

Hi John-nx，

 You can do this by using the group address, as long as you know the destination address of the sent message.

[John-nx]

Yes exactly, I do use group address, I have subscribed each element to a group,
Then again, I don't know any other way to send a message!
Is there any tutorial/documentation on how to send a message using any APP to a certain node? and monitor the relayed message?

Moreover, where in the "menuconfig" we can config the proxy and relay, can you give me the exact path?

[WCCWCC]

Hi John-nx，

1. Componet config-->BLE Mesh Support --> Relay support
2. Componet config-->BLE Mesh Support --> BLE Mesh GATT Proxy Service

• Is there any tutorial/documentation on how to send a message using any APP to a certain node? and monitor the relayed message?
  
  
  
  • Maybe you can refer to ble_mesh_provisioner demo,Can be solved(how to send a message to a certain node )
  
  
  • Maybe you can refer to ble_mesh_fast_provisioner,Used custom message and used EspBleMesh app.
  
  

[John-nx]

Hi Again,

I really appreciate your responses, I have a better vision on the whole thing now, however, my question is still there!

I took a look at the examples that you mentioned, they are not addressing about sending a command to a node (using unicast address). In my opinion, there is a lack of documentation here!

Honestly, I don't know why should I use a micro as a provisioner! while I can use a smartphone or computer device as it is stated in the Bluetooth website!
Let me go one step backward and state the issue as clear as I can:
In practice when a mesh network is created, how one is supposed to control the nodes?

• either by a smartphone or another node which is used as a remote control, do you agree on that?
  At this point,
• if you use nrf mesh app or any other app to simulate sending a message, there must be a guide on how to send messages to different types of addresses! (This a configuration thing at the app level)
  -and if a node is sopposed to be used plz refer me to the functions that do the same thing

Thanks!

[John-nx]

@WCCWCC @negativekelvin

[Campou]

Hi @John-nx

Sorry for the misunderstanding. Let's go back to the original questions.

1. Which message and in which format must be sent to device1 (ble_mesh_client_model ) that turns an LED on/off in device2 (ble_mesh_node)?
   Answer:
   Our idea here is to use the Generic OnOff Client Model in device1 (ble_mesh_client_model) to control the Generic OnOff Server Model in device2 (ble_mesh_node). So the message sent to device1 is the Generic OnOff Set message which is sent by the nRF Mesh App for example. And the format of the message is opcode (2 octets) + onoff (1 octet) + TID (1 octet). You can refer to the section 3.2.1 in Mesh Model Spec for more information about the message format.

2. Secondly, these two nodes are indeed proxy nodes, because I can send ON/OFF messages to them through nRF Mesh app, Is that right?
   Answer:
   The Proxy feature of the two nodes are both enabled. But in this situation, only device1 works as a Proxy Node which is directly connected to the phone. You can use the nRF Mesh App to control the device1 (send ON/OFF messages through GATT bearer), then device1 will foward the received messages (Generic OnOff Set) to device2 using the advertising bearer. The relationship is listed below.
   nRF Mesh App ---------GATT---------> device1 ---------ADV----------> device2

• Note: UART in the ble_mesh_client_model example is just used to input the unicast address of device2 (ble_mesh_node).

Thanks for you patience

[John-nx]

Hi @Campou,

Thank you so much for your response, now things are clear.
I managed to use the UART1 to choose which address (unicast) or addresses (group) are to be controlled.

However, this whole thing raises some even more important questions, would you please also shed some light on them?

-1. So, It seems that it is not possible to use the Publish field in the nRF app to set target addresses, is this right? and if yes this is going to be added or not?
I mean it is expected to configure the Publication Address for each client/switch in the Generic OnOff model, using the provisioner which in this case is nRF app.

-2. In the ble_mesh_client_model example, something is fishy!
Consider the communication process which you mentioned:
nRF Mesh App ---------GATT---------> device1 ---------ADV----------> device2
I expect to configure only "Geberic ON OFF Client" in the device1 (ble_mesh_client_model), however, to be able to control the device2
nRF Mesh App ---------GATT---------> device1 ---------ADV----------> device2
I needed to configure the device 1 (ble_mesh_client_model ) like below:
Generic ON OFF Client: Bound App key
Generic ON OFF Server: Bound App key, subscribe to the created group named MyGroup

Now using the MyGroup I can control device 2 (elements that are set by the UART)

This whole thing does not really make sense because, I am controlling LEDs in the device 2 (ble_mesh_node ) by another LED in device 1 (ble_mesh_client_model ), and not by using a switch!
The strange thing is in the nRF app I do see a switch icon alongside the MyGroup icon, but it just does not have any functionality or at least I do not know a way to configure it in order to control LEDs in the device 2.
My whole point is using the ble_mesh_client_model I expect to have/configure a physical switch or a software switch using nRF app, in order to publish a message. Is this right and can I do this?

Thank you in advance.

[Campou]

Hi @John-nx

1. I think it's possible to set the target address using the Publish field. And I had a try using the nRF Mesh App with your idea, it works fine. The only difference in ble_mesh_client_model example is that we use esp_ble_mesh_model_publish API to publish messages to ble_mesh_node. And in the nRF Mesh App, we should set the Publication address of the Generic OnOff Client Model to the unicast address of the ble_mesh_node.
2. Yes, the whole idea here is using Generic OnOff Client Model(in device1) to control the Generic Server Model(in device2). And you can use a physical switch in device1 to publish control messages to device2 with the publication address of device1 set to the unicast address of device2.
3. About the nRF Mesh App, I can only subscribe a group address to a model, and haven't find any icons to send messages to the group address.

Thanks.

[John-nx]

Hi @Campou
>

1. Yes, the whole idea here is using Generic OnOff Client Model(in device1) to control the Generic Server Model(in device2). And you can use a physical switch in device1 to publish control messages to device2 with the publication address of device1 set to the unicast address of device2.

That's what's I'm saying ! This is supposed to be the idea!
Have you actually used a physical switch in device1 to publish control messages to device2? Or do you know somebody who did that?
If yes, which pins did youuse and how did you do that? (the boot button obviously is not set for this job)
There is nothing about a switch in the ble_mesh_client_model example code!
On the other hand, the function switch_init() is defined in the ble_mesh_node code!!!!!

About using the Publish field, it is NOT possible to use it in for the ble_mesh_client_model example I'll try esp_ble_mesh_model_publish though!

Thanks

[Campou]

Hi @John-nx

The Boot button in ESP32-DevKitC can be used to send messages. And for the guidance of using Boot button, you can refer to the esp-iot-solution for some help, which includes a component for the button.

And we can modify the example properly in the future based on your idea.

Thanks & Regards

[John-nx]

Hi @Campou,

By the way, I wanted to try the publish thing that you mentioned:

1. I think it's possible to set the target address using the Publish field. And I had a try using the nRF Mesh App with your idea, it works fine. The only difference in ble_mesh_client_model example is that we use esp_ble_mesh_model_publish API to publish messages to ble_mesh_node. And in the nRF Mesh App, we should set the Publication address of the Generic OnOff Client Model to the unicast address of the ble_mesh_node.

What do you mean by "esp_ble_mesh_model_publish" ? there is no such thing, where can I find it?
Thanks

[Campou]

Hi @John-nx

esp_ble_mesh_model_publish() (in the header file esp_ble_mesh_networking_api.h) is an API which can be used to publish messages. And before using this API to publish messages, please make sure the corresponding Model Publication state has been configured properly.

Thanks.

[John-nx]

Hi @Campou
Yes, I understood that, however, I actually have not started to change the example codes as I first need to have basic functionality.

By the way, this is something minor, but now that we talked long about this example, did you know that the UART used in this example is not the one connected to the USB? Meaning that you cannot send the UART msg through USB.

Thanks

[Campou]

Hi @John-nx

Yes, the UART is just used to input the remote node address. And we have changed the client model example in the branch release/v4.0, will be released later.

Thanks.

[peakymember]

Hi @John-nx I have the same problem, Did you manage to solve it? I can easily turn on/off led using my phone and app nRF Mesh, but I have to do this without phone, just by using device1 and device2.

[trapplab]

Hi @peakymember and @John-nx,
I modified the ble_mesh_node example so you can publish the button state. With the nRF App as a provisioner you can subscribe the message to an unicast or group adress.

First I added a publisher model

static esp_ble_mesh_client_t onoff_client;
ESP_BLE_MESH_MODEL_PUB_DEFINE(onoff_cli_pub, 2 + 2, ROLE_NODE); //Two bytes for the message op code and two for the message
                                                                //the two message bytes are mandatory because otherwise the message is to short

static esp_ble_mesh_model_t pub_model[] = {
    ESP_BLE_MESH_MODEL_GEN_ONOFF_CLI(&onoff_cli_pub, &onoff_client),
};

//add the pub model into the element array
static esp_ble_mesh_elem_t elements[] = {
    ESP_BLE_MESH_ELEMENT(0, root_models, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(0, extend_model_0, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(0, extend_model_1, ESP_BLE_MESH_MODEL_NONE),
    ESP_BLE_MESH_ELEMENT(0, pub_model, ESP_BLE_MESH_MODEL_NONE),
};

When you call this function the state of the button gets published and you can toggle yout Led's

static void gen_onoff_publisher(uint8_t data)
{
    esp_err_t err;
    onoff_cli_pub.msg->data[2]=data;

    ESP_LOGI(TAG, "%s, Publish 0x%02x from addr 0x%02x",__func__, data,onoff_client.model->element->element_addr);
    err = esp_ble_mesh_model_publish(pub_model, ESP_BLE_MESH_MODEL_OP_GEN_ONOFF_SET_UNACK,
                                     2,(uint8_t*) onoff_cli_pub.msg->data+2, ROLE_NODE);
    if (err != ESP_OK) {
        ESP_LOGE(TAG, "%s: Publish Generic OnOff Status failed", __func__);
        return;
    }
}

I hope this helps you for a first test!

[John-nx]

Hi @trapplab

In which branch/commit you solved this issue?
HAVE YOU PUBLISHED A MESSAGE USING THE BUTTON ON THE MICRO?

For the client example one expects:
Firstly, setting a publish address to a switch, for example using the nRF mesh (which in this example is implemented poorly by UART)
Secondly, and more importantly publish the message set in the previous step using a physical switch for example boot button on the micro (which in this example is not implemented at all )

@peakymember if you want to use this client example, the code needs to change.

best

[trapplab]

Hi @John-nx

you can find the modified node example in my forked repository esp-idf in the branch release/v4.0.
I added a client model to the nodes model list to publish the button state.

I use a MH-ET LIVE MiniKit with a ESP32-WROOM-32 module on it. I connected an external button to the GPIO port number 18 and use the onboard led connected to GPIO port 2.

After flashing every setting is done with the nRF App.

1. To use the example I provision the ESP32 with the nRF App.
2. Then you can exchange the Application Key with the Generic On Off Client and publish its state to a unicast adress or group adress.
3. After that you exchange the App. Key for the Generic On Off Server and subscribe to a group adress
4. The led should now toggle if you press the button

With this example you can't send the adress via UART. And i think it's unnecessary because the adress selection could be made with the nRF App as a provisioner.

best regards

[John-nx]

Hi @trapplab

Thanks, I see what you did.
I tried to build the example that you modified but I am having problem building it! There are errors
I use idf tools and windows 10 cmd as the build environment, and I tried to use both remotes/origin/release/v4.0 and ble_mesh_release/esp-ble-mesh-v0.6.1 branches as the IDF path.

Can you plz tell me if you have done pull request or not?
I think either your forked version should be synchronized with the original upstream repo or they should merge your modifications.

Honestly, solving these problems is just a huge overhead to have a simple functionally! And it seems they won't finish !! Having said that let me know plz about your build environment and possibly other modifications that you did apart from the ble_mesh_node example folder.

Thanks
Regards

[John-nx]

With this example you can't send the adress via UART. And i think it's unnecessary because the adress selection could be made with the nRF App as a provisioner.

Of course, the UART is useless! The UART 1 is not even the one connected to the USB!!!!!!!

[Alvin1Zhang]

Thanks for reporting, the onoff_client example has been updated at here, feel free to reopen if the issue still happens, or please help file a new ticket for new issue. Thanks.