The SIG-defined Sensor Model can send/receive some messages with an array of octets.
ESP BLE Mesh v0.5 Beta has been released
Re: ESP BLE Mesh v0.5 Beta has been released
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?
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?
Re: ESP BLE Mesh v0.5 Beta has been released
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.Christoph wrote: ↑Wed Feb 27, 2019 1:33 pmThanks, 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?
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 ]
Re: ESP BLE Mesh v0.5 Beta has been released
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
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
Re: ESP BLE Mesh v0.5 Beta has been released
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.Christoph wrote: ↑Thu Feb 28, 2019 6:42 pmIn 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
Re: ESP BLE Mesh v0.5 Beta has been released
marquesn wrote: ↑Mon Feb 25, 2019 11:09 amesp_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:
With this message, the meshctl tool still shows as if it is connected to the ESP32 node like this: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
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).Code: Select all
[ESP32]#
Over on the ESP32 side, it displays the following message when the meshctl tool tries to provision:
When disconnecting, the ESP says: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
Please let me know if there is something else I could try, or if I missed something in your instructions.Code: Select all
W (236444) BLE_MESH: Client wrote 0x0000 instead enabling notify E (238444) BLE_MESH: Not connected
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?
Re: ESP BLE Mesh v0.5 Beta has been released
Hi,marquesn wrote: ↑Mon Mar 04, 2019 9:24 ammarquesn wrote: ↑Mon Feb 25, 2019 11:09 amesp_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:
With this message, the meshctl tool still shows as if it is connected to the ESP32 node like this: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
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).Code: Select all
[ESP32]#
Over on the ESP32 side, it displays the following message when the meshctl tool tries to provision:
When disconnecting, the ESP says: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
Please let me know if there is something else I could try, or if I missed something in your instructions.Code: Select all
W (236444) BLE_MESH: Client wrote 0x0000 instead enabling notify E (238444) BLE_MESH: Not connected
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?
Currently testing a new beta version 0.6, it will be released soon. You can have a try with that version.
Re: ESP BLE Mesh v0.5 Beta has been released
esp_liu wrote: ↑Mon Mar 04, 2019 9:27 amHi,marquesn wrote: ↑Mon Mar 04, 2019 9:24 ammarquesn 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:
With this message, the meshctl tool still shows as if it is connected to the ESP32 node like this: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
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).Code: Select all
[ESP32]#
Over on the ESP32 side, it displays the following message when the meshctl tool tries to provision:
When disconnecting, the ESP says: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
Please let me know if there is something else I could try, or if I missed something in your instructions.Code: Select all
W (236444) BLE_MESH: Client wrote 0x0000 instead enabling notify E (238444) BLE_MESH: Not connected
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?
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?
Re: ESP BLE Mesh v0.5 Beta has been released
Hi! I'm stuck trying to get the UUID of my ESP32 BLE. Do you guys know how to obtain it? Thanks in advance!
Re: ESP BLE Mesh v0.5 Beta has been released
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: No registered users and 119 guests