ESP BLE Mesh v0.5 Beta has been released

esp_liu
Posts: 35
Joined: Wed Nov 28, 2018 4:12 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby esp_liu » Wed Feb 27, 2019 1:27 am

Christoph wrote:
Tue Feb 26, 2019 1:31 pm
Thank you for your prompt reply. Is there a model what an array of int can send and receive?
The SIG-defined Sensor Model can send/receive some messages with an array of octets.

Christoph
Posts: 8
Joined: Fri Feb 08, 2019 10:57 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby Christoph » Wed Feb 27, 2019 1:33 pm

Thanks, the sensor model, I will first use for first attempts.

I have one more question for example ble_mesh_provisioner:

I have a node with 2 elements with the nrf mesh app gets the primary element the first address and the second element the following address. Everything works. When provisioning with ble_mesh_provisioner I can only send messages to the primary element ... What do I have to do to make it work like the nrf mesh app?

esp_liu
Posts: 35
Joined: Wed Nov 28, 2018 4:12 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby esp_liu » Thu Feb 28, 2019 2:43 am

Christoph wrote:
Wed Feb 27, 2019 1:33 pm
Thanks, the sensor model, I will first use for first attempts.

I have one more question for example ble_mesh_provisioner:

I have a node with 2 elements with the nrf mesh app gets the primary element the first address and the second element the following address. Everything works. When provisioning with ble_mesh_provisioner I can only send messages to the primary element ... What do I have to do to make it work like the nrf mesh app?
When ble_mesh_provisioner provisions a node successfully, it will callback the node's primary element address and the number of node's element to the application layer. In the demo, the provisioner only send messages to the primary element and if going to send messages to the secondary element, please set the destination address to node->unicast + 1.
Note: the node's element number and primary element address are used to determine the unicast address of each element, in short the unicast address range of the node is [ primary element address, primary element address + element numer - 1 ]

Christoph
Posts: 8
Joined: Fri Feb 08, 2019 10:57 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby Christoph » Thu Feb 28, 2019 6:42 pm

In my example is the primary address 0x0006 to this I can send. The secundary element address is therefore 0x0007 to this I can not send. It works fine with the nrf mesh app but not with the provisoner example. I think the prosisioner example does not bind a key to the secundary elemet. The following message comes with provisioning:


0;32mI (26133) ble_mesh_provisioner: composition data e502000000000a000a00000003000000001001100100020000100110<27>[0m<\r>
<\n><27>[0;32mI (26433) ble_mesh_provisioner: esp_ble_mesh_config_client_cb, error_code = 0x00, event = 0x01, addr: 0x0006, opcode: 0x0000<27>[0m<\r>
<\n><27>[0;32mI (26563) ble_mesh_provisioner: esp_ble_mesh_config_client_cb, error_code = 0x00, event = 0x01, addr: 0x0006, opcode: 0x803d<27>[0m<\r>
<\n><27>[0;31mE (26563) BLE_MESH: Model not bound to AppKey 0x0000<27>[0m<\r>
<\n><27>[0;31mE (26563) BLE_MESH: Generic get message send failed (err -22)<27>[0m<\r>
<\n><27>[0;32mI (26573) ble_mesh_provisioner: esp_ble_mesh_generic_client_cb, error_code = 0xffffffea, event = 0x00, addr: 0x0006, opcode: 0x8201<27>[0m<\r>
<\n><27>[0;31mE (26583) ble_mesh_provisioner: Send generic client message failed, opcode 0x8201<27>[0m<\r>
<\n><27>[0;32mI (27593) ble_mesh_provisioner: PB-ADV link close, reason 0x00<27>[0m<\r>
<\n><27>[0;33mW (69243) BLE_MESH: Duplicate found in Network Message Cache

esp_liu
Posts: 35
Joined: Wed Nov 28, 2018 4:12 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby esp_liu » Fri Mar 01, 2019 2:22 am

Christoph wrote:
Thu Feb 28, 2019 6:42 pm
In my example is the primary address 0x0006 to this I can send. The secundary element address is therefore 0x0007 to this I can not send. It works fine with the nrf mesh app but not with the provisoner example. I think the prosisioner example does not bind a key to the secundary elemet. The following message comes with provisioning:


0;32mI (26133) ble_mesh_provisioner: composition data e502000000000a000a00000003000000001001100100020000100110<27>[0m<\r>
<\n><27>[0;32mI (26433) ble_mesh_provisioner: esp_ble_mesh_config_client_cb, error_code = 0x00, event = 0x01, addr: 0x0006, opcode: 0x0000<27>[0m<\r>
<\n><27>[0;32mI (26563) ble_mesh_provisioner: esp_ble_mesh_config_client_cb, error_code = 0x00, event = 0x01, addr: 0x0006, opcode: 0x803d<27>[0m<\r>
<\n><27>[0;31mE (26563) BLE_MESH: Model not bound to AppKey 0x0000<27>[0m<\r>
<\n><27>[0;31mE (26563) BLE_MESH: Generic get message send failed (err -22)<27>[0m<\r>
<\n><27>[0;32mI (26573) ble_mesh_provisioner: esp_ble_mesh_generic_client_cb, error_code = 0xffffffea, event = 0x00, addr: 0x0006, opcode: 0x8201<27>[0m<\r>
<\n><27>[0;31mE (26583) ble_mesh_provisioner: Send generic client message failed, opcode 0x8201<27>[0m<\r>
<\n><27>[0;32mI (27593) ble_mesh_provisioner: PB-ADV link close, reason 0x00<27>[0m<\r>
<\n><27>[0;33mW (69243) BLE_MESH: Duplicate found in Network Message Cache
Yes, you need to bind AppKey to the model within the secondary element at first (send Configuration Model App Bind message). In the demo, the Provisioner just bind AppKey with the model in the primary element, please change the demo properly.

marquesn
Posts: 5
Joined: Wed Feb 13, 2019 9:17 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby marquesn » Mon Mar 04, 2019 9:24 am

marquesn wrote:
Mon Feb 25, 2019 11:09 am
esp_liu wrote:
marquesn wrote:
Fri Feb 15, 2019 10:41 am

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.

Hi, I don't mean to be a pain - but I was just wondering if anyone has any updates or ideas on this issue since last week?

esp_liu
Posts: 35
Joined: Wed Nov 28, 2018 4:12 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby esp_liu » Mon Mar 04, 2019 9:27 am

marquesn wrote:
Mon Mar 04, 2019 9:24 am
marquesn wrote:
Mon Feb 25, 2019 11:09 am
esp_liu wrote:

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.

Hi, I don't mean to be a pain - but I was just wondering if anyone has any updates or ideas on this issue since last week?
Hi,
Currently testing a new beta version 0.6, it will be released soon. You can have a try with that version.

marquesn
Posts: 5
Joined: Wed Feb 13, 2019 9:17 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby marquesn » Mon Mar 04, 2019 9:38 am

esp_liu wrote:
Mon Mar 04, 2019 9:27 am
marquesn wrote:
Mon Mar 04, 2019 9:24 am
marquesn wrote:
Mon Feb 25, 2019 11:09 am



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.

Hi, I don't mean to be a pain - but I was just wondering if anyone has any updates or ideas on this issue since last week?
Hi,
Currently testing a new beta version 0.6, it will be released soon. You can have a try with that version.

Ok, thank you. Will there be a new dedicated forum discussion for it once it is released, or will this one be used for it instead?

SombraRPK
Posts: 18
Joined: Wed Jul 04, 2018 2:37 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby SombraRPK » Tue Mar 05, 2019 3:33 am

Hi! I'm stuck trying to get the UUID of my ESP32 BLE. Do you guys know how to obtain it? Thanks in advance!

Wangcheng
Posts: 73
Joined: Wed Mar 06, 2019 3:26 am

Re: ESP BLE Mesh v0.5 Beta has been released

Postby Wangcheng » Wed Mar 06, 2019 5:58 am

SombraRPK wrote:
Tue Mar 05, 2019 3:33 am
Hi! I'm stuck trying to get the UUID of my ESP32 BLE. Do you guys know how to obtain it? Thanks in advance!


There are two situations:
There are two situations:
1.Esp32 as provisioner:you can get the uuid by callback function。
esp_ble_mesh_register_unprov_adv_pkt_callback(example_recv_unprov_adv_pkt_callback);
2.Esp32 as node: The node's uuid is Initialization data.
static esp_ble_mesh_prov_t provision = {
#if defined(CONFIG_BT_MESH_NODE)
.uuid = dev_uuid,
.oob_pub_key = true,
.static_val = static_oob_val,
.static_val_len = 0x10,
.output_size = 4,
.output_actions = ESP_BLE_MESH_DISPLAY_NUMBER,
.input_actions = ESP_BLE_MESH_PUSH,
.input_size = 4

Who is online

Users browsing this forum: Bing [Bot], Google [Bot] and 89 guests