ESP BLE Mesh v0.5 Beta has been released

[marquesn]

Hi, @nvl1109
We will release a new BLE Mesh Version soon. It will include many new features, including `restoring the provision data of the node device`, `fast provisioning`, `wifi/ble_mesh coexistence`, etc... Stay tuned!

That is a great news, thank you.

Is there anyone tried with linux bluez 5.50?
I have tried with bluez, but it's failed to provision. the local_node.json and prov_db.json are taken from bluez code.

Code: Select all

[meshctl]# discover-unprovisioned on
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: yes
                Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
                        Device UUID: dddd240ac402fd8e0000000000000000
                        OOB: 0000
[meshctl]# provision dddd240ac402fd8e0000000000000000
Trying to connect Device 24:0A:C4:02:FD:8E ESP-BLE-MESH
Adapter property changed
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: no
Connection successful
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
AcquireNotify success: fd 7 MTU 517
Notify for Mesh Provisioning Out Data started
Open-Node: 0x559c78
Open-Prov: 0x556540
Open-Prov: proxy 0x55af78
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f
AcquireWrite success: fd 8 MTU 517
GATT-TX:         03 00 10
GATT-RX:         03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
         01 01 00 01 00 00 00 00 00 00 00 00
Provisioning failed
Attempting to disconnect from 24:0A:C4:02:FD:8E
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f
[meshctl]#

"Provisioning failed" message are shown.
In ESP32 console

Code: Select all

I (763) ble_mesh_node: BLE Mesh Node initialized
I (40113) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT
I (40113) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT
W (40303) BLE_MESH: Client wrote 0x0000 instead enabling notify

I am having this exact same issue when trying to use the meshctl tool from bluez 5.50. I am trying to use an RPi as a provisioner to provision multiple ESP32 BLE nodes.

I followed the guide from Bluetooth.com ( https://www.bluetooth.com/~/media/files ... shx?la=en ), but the only difference is that they are using nRF52 boards as the BLE mesh nodes.

[Christoph]

Thanks the publish works in the cliend.
But a server model which I already provided does not work. A second cliend model receives data. The message appears.

BLE_MESH: generic_status: model internal_data is NULL

A server model and not the cliend model must turn on the light or not?

Do I have to function in the server model?
gen_onoff_get_handler
call to switch the light?

[esp_liu]

Hi, @nvl1109
We will release a new BLE Mesh Version soon. It will include many new features, including `restoring the provision data of the node device`, `fast provisioning`, `wifi/ble_mesh coexistence`, etc... Stay tuned!

That is a great news, thank you.

Is there anyone tried with linux bluez 5.50?
I have tried with bluez, but it's failed to provision. the local_node.json and prov_db.json are taken from bluez code.

Code: Select all

[meshctl]# discover-unprovisioned on
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: yes
                Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
                        Device UUID: dddd240ac402fd8e0000000000000000
                        OOB: 0000
[meshctl]# provision dddd240ac402fd8e0000000000000000
Trying to connect Device 24:0A:C4:02:FD:8E ESP-BLE-MESH
Adapter property changed
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: no
Connection successful
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
AcquireNotify success: fd 7 MTU 517
Notify for Mesh Provisioning Out Data started
Open-Node: 0x559c78
Open-Prov: 0x556540
Open-Prov: proxy 0x55af78
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f
AcquireWrite success: fd 8 MTU 517
GATT-TX:         03 00 10
GATT-RX:         03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
         01 01 00 01 00 00 00 00 00 00 00 00
Provisioning failed
Attempting to disconnect from 24:0A:C4:02:FD:8E
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f
[meshctl]#

"Provisioning failed" message are shown.
In ESP32 console

Code: Select all

I (763) ble_mesh_node: BLE Mesh Node initialized
I (40113) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT
I (40113) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT
W (40303) BLE_MESH: Client wrote 0x0000 instead enabling notify

I am having this exact same issue when trying to use the meshctl tool from bluez 5.50. I am trying to use an RPi as a provisioner to provision multiple ESP32 BLE nodes.

I followed the guide from Bluetooth.com ( https://www.bluetooth.com/~/media/files ... shx?la=en ), but the only difference is that they are using nRF52 boards as the BLE mesh nodes.

Thank you for reporting this issue, i will have a try with the RPi.
Best Regards

[esp_liu]

Thanks the publish works in the cliend.
But a server model which I already provided does not work. A second cliend model receives data. The message appears.

BLE_MESH: generic_status: model internal_data is NULL

A server model and not the cliend model must turn on the light or not?

Do I have to function in the server model?
gen_onoff_get_handler
call to switch the light?

1. But a server model which I already provided does not work --> You can refer to the ble_mesh_node example, the demo defines a Generic OnOff Server Model
2. The log BLE_MESH: generic_status: model internal_data is NULL indicates that the Generic OnOff Client model is not initialized, you need to enable CONFIG_BT_MESH_GENERIC_ONOFF_CLI in the menuconfig.
3. A server model and not the client model must turn on the light or not? --> Don't quite understand this.
4. The

Code: Select all

gen_onoff_get_handler

is used by Generic OnOff Server model to handle the Generic OnOff Get message.

[marquesn]

That is a great news, thank you.

Is there anyone tried with linux bluez 5.50?
I have tried with bluez, but it's failed to provision. the local_node.json and prov_db.json are taken from bluez code.

Code: Select all

[meshctl]# discover-unprovisioned on
SetDiscoveryFilter success
Discovery started
Adapter property changed
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: yes
                Mesh Provisioning Service (00001827-0000-1000-8000-00805f9b34fb)
                        Device UUID: dddd240ac402fd8e0000000000000000
                        OOB: 0000
[meshctl]# provision dddd240ac402fd8e0000000000000000
Trying to connect Device 24:0A:C4:02:FD:8E ESP-BLE-MESH
Adapter property changed
[CHG] Controller AA:AA:AA:AA:AA:AA Discovering: no
Connection successful
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
AcquireNotify success: fd 7 MTU 517
Notify for Mesh Provisioning Out Data started
Open-Node: 0x559c78
Open-Prov: 0x556540
Open-Prov: proxy 0x55af78
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f
AcquireWrite success: fd 8 MTU 517
GATT-TX:         03 00 10
GATT-RX:         03 01 01 00 01 00 00 00 00 00 00 00 00
Got provisioning data (12 bytes)
         01 01 00 01 00 00 00 00 00 00 00 00
Provisioning failed
Attempting to disconnect from 24:0A:C4:02:FD:8E
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char0031
Write closed
Services resolved no
Characteristic property changed /org/bluez/hci0/dev_24_0A_C4_02_FD_8E/service002e/char002f
[meshctl]#

"Provisioning failed" message are shown.
In ESP32 console

Code: Select all

I (763) ble_mesh_node: BLE Mesh Node initialized
I (40113) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT
I (40113) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT
W (40303) BLE_MESH: Client wrote 0x0000 instead enabling notify

I am having this exact same issue when trying to use the meshctl tool from bluez 5.50. I am trying to use an RPi as a provisioner to provision multiple ESP32 BLE nodes.

I followed the guide from Bluetooth.com ( https://www.bluetooth.com/~/media/files ... shx?la=en ), but the only difference is that they are using nRF52 boards as the BLE mesh nodes.

Thank you for reporting this issue, i will have a try with the RPi.
Best Regards

Many thanks! Let me know how it goes.

[esp_liu]

I am having this exact same issue when trying to use the meshctl tool from bluez 5.50. I am trying to use an RPi as a provisioner to provision multiple ESP32 BLE nodes.

I followed the guide from Bluetooth.com ( https://www.bluetooth.com/~/media/files ... shx?la=en ), but the only difference is that they are using nRF52 boards as the BLE mesh nodes.

Thank you for reporting this issue, i will have a try with the RPi.
Best Regards

Many thanks! Let me know how it goes.

Hi,
Provisioning procedure failed because the provisioning OOB authentication method is not satisfied (If it is No OOB, BlueZ will terminate the provisioning procedure). So at least the device should use Static OOB for provisioning, and the modification is attached below:

Code: Select all

static uint8_t static_oob_val[1] = {0};

/* Disable OOB security for SILabs Android app */
static esp_ble_mesh_prov_t provision = {
    .uuid = dev_uuid,
    .static_val = static_oob_val,
    .static_val_len = sizeof(static_oob_val),
#if 0
    .output_size = 4,
    .output_actions = ESP_BLE_MESH_DISPLAY_NUMBER,
    .input_actions = ESP_BLE_MESH_PUSH,
    .input_size = 4,
#else
    .output_size = 0,
    .output_actions = 0,
#end

[marquesn]

Thank you for reporting this issue, i will have a try with the RPi.
Best Regards

Many thanks! Let me know how it goes.

Hi,
Provisioning procedure failed because the provisioning OOB authentication method is not satisfied (If it is No OOB, BlueZ will terminate the provisioning procedure). So at least the device should use Static OOB for provisioning, and the modification is attached below:

Code: Select all

static uint8_t static_oob_val[1] = {0};

/* Disable OOB security for SILabs Android app */
static esp_ble_mesh_prov_t provision = {
    .uuid = dev_uuid,
    .static_val = static_oob_val,
    .static_val_len = sizeof(static_oob_val),
#if 0
    .output_size = 4,
    .output_actions = ESP_BLE_MESH_DISPLAY_NUMBER,
    .input_actions = ESP_BLE_MESH_PUSH,
    .input_size = 4,
#else
    .output_size = 0,
    .output_actions = 0,
#end

Thanks for getting back to me! I've changed the OOB with those lines of code as indicated - and the meshctl tool now goes a step further, but still fails. The difference is that this time, it fails saying "Resource temporarily unavailable" as shown below:

Code: Select all

Trying to connect Device 30:AE:A4:10:84:06 ESP-BLE-MESH
Adapter property changed
[CHG] Controller B8:27:EB:BB:4A:E4 Discovering: no
Connection successful
Service added /org/bluez/hci0/dev_30_AE_A4_10_84_06/service0001
Service added /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e
Char added /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e/char002f:
Char added /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e/char0031:
Services resolved yes
Found matching char: path /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e/char002f, uuid 00002adb-0000-1000-8000-00805f9b34fb
Found matching char: path /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e/char0031, uuid 00002adc-0000-1000-8000-00805f9b34fb
Start notification on /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e/char0031
Characteristic property changed /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e/char0031
AcquireNotify success: fd 7 MTU 517
Notify for Mesh Provisioning Out Data started
Open-Node: 0x1eafe20
Open-Prov: 0x1eb5d18
Open-Prov: proxy 0x1ea7008
Initiated provisioning
Characteristic property changed /org/bluez/hci0/dev_30_AE_A4_10_84_06/service002e/char002f
AcquireWrite success: fd 8 MTU 517
GATT-TX:         03 00 10
GATT-RX:         03 01 01 00 01 00 01 00 00 00 00 00 00
Got provisioning data (12 bytes)
         01 01 00 01 00 01 00 00 00 00 00 00
GATT-TX:         03 02 00 00 01 00 00
GATT-TX:         03 03 71 5b ff ce 29 ef 9f 3e c2 2b cb f3 a1 89
GATT-TX:         1c 9c 5d a9 44 3b 68 53 fc 01 7c e8 a8 ae 43 11
GATT-TX:         98 e1 aa ff 73 93 57 6f 95 57 71 d4 e6 39 dc 33
GATT-TX:         4b d3 89 f3 df b1 b1 af fe 50 55 5f 83 db d1 ae
GATT-TX:         de ab
Failed to write: Resource temporarily unavailable

With this message, the meshctl tool still shows as if it is connected to the ESP32 node like this:

Code: Select all

[ESP32]#

But the ESP32 is still with the green LED turned on as if it has not been provisioned (the green LED does actually turn off if the device is provisioned by other mesh provisioning apps such as the nRF one and the Silicon Labs).

Over on the ESP32 side, it displays the following message when the meshctl tool tries to provision:

Code: Select all

I (162734) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT
I (162734) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT
W (162834) BLE_MESH: No Health Server available

When disconnecting, the ESP says:

Code: Select all

W (236444) BLE_MESH: Client wrote 0x0000 instead enabling notify
E (238444) BLE_MESH: Not connected

Please let me know if there is something else I could try, or if I missed something in your instructions.

[Christoph]

Thanks for the help to send and receive with the Generic OnOff server cliend model now works.

But I still have some questions:
where can i change the name of the ble device? Now all devices are called ESP-BLE-MESH

Can I also send and receive a string with the Generic OnOff model or which model would be usable for this?

[esp_liu]

Thanks for the help to send and receive with the Generic OnOff server cliend model now works.

But I still have some questions:
where can i change the name of the ble device? Now all devices are called ESP-BLE-MESH

Can I also send and receive a string with the Generic OnOff model or which model would be usable for this?

Hi,
You can use the API esp_ble_mesh_set_unprovisioned_device_name() to set the name of the device.
As per the Mesh Model spec, the Generic OnOff model doesn't support string. If you want to send/receive string, the best way is to define vendor client/server models, all the SIG-defined models have fixed-format messages.

[Christoph]

Thank you for your prompt reply. Is there a model what an array of int can send and receive?