search

espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.23k stars 7.18k forks source link

[BLE Mesh] Does losing power leads to losing the provisioning of a node in a bluetooth mesh network? (IDFGH-1867) #4074

Closed John-nx closed 4 years ago

John-nx commented 4 years ago

Environment

Problem Description

It seems that when a node loses power (USB is disconnected for example), the mentioned node loses also the provisioning information so that when connected to a power supply again it must be provisioned again, IS that right? if so when this problem will be fixed?

//Detailed problem description goes here.

Expected Behavior

After losing power and re-connecting to a power supply the node must join the mesh network again!

Actual Behavior

Node loses provisioning information.

Steps to reproduce

-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 -Disconnect a node and reconnect it to the USB power

Code to reproduce this issue

Debug Logs

Other items if possible

Alvin1Zhang commented 4 years ago

@John-nx Thanks for reporting, we will look into it. Thanks.

WCCWCC commented 4 years ago

Hi John-nx， If you want the node to communicate with other nodes after the node is powered back on, you can enable the node's power-down save function.

Componet config --> Ble mesh Support --> Store BLE Mesh Node configuration persistently

John-nx commented 4 years ago

@WCCWCC Nope didn't work!

John-nx commented 4 years ago

This is just so principal about BLE mesh!

John-nx commented 4 years ago

In fact, activating the "Store BLE Mesh Node configuration persistently", the iussue has become more severe as I neither see the device provisioned nor unprovisioned, now I need to flash it !

Campou commented 4 years ago

Hi @John-nx

Please enable the node NVS storage functionality through make menuconfig. Component config -> BLE Mesh Support -> Store BLE Mesh Node configuration persistently

After the device is provisioned successfully and restarted, the App will not show it in the Scanner of the nRF Mesh App, instead we need to click the CONNECT on the top right and the App will start to scan the proxy advertising of the device.

I have tested using the branch ble_mesh_release/esp-ble-mesh-v0.6.1 with NVS storage on, each time after the device is restarted, the App can connect with it successfully and control the RGB light.

The attachment is the ble_mesh_node example test log.

ble_mesh_node_nvs_test.log

Thanks.

John-nx commented 4 years ago

Hi @Campou

Thanks for your response.

Actually, I am working on the latest version of the ble_mesh_release/esp-ble-mesh-v0.6.1 branch. However, I conducted another test from scratch to make sure, the result is as I previously mentioned.

-I enabled the Store BLE Mesh Node configuration persistently through menuconfig -I flashed the ble_mesh_node example -The device is provisioned successfully, but after resetting or disconnecting and reconnecting the power, the nRF Mesh App will see the device, neither as an unprovisioned device (usingScanner) nor as a provisioned device (clicking on the CONNECT)

Here is a screenshot of the monitored port after resetting it: image

Thanks

Campou commented 4 years ago

Hi @John-nx

The difference between the two logs is : No subnets to advertise on, and this will cause the problem you have met.

But unfortunately, I couldn't reproduce this issue on my side. So could you please share me the followings which will be a great help.

BTW, after pulling the latest code of the branch ble_mesh_release/esp-ble-mesh-v0.6.1 and running git describe --tags, the log on my side is as following. Please make sure it's the same on your side. Selection_002

Thanks.

John-nx commented 4 years ago

Hi @Campou

I will share with you the files, but now I cannot do that, because as I told you I had to flash it again with the mentioned option disabled in order to provision it again. Anyways I will reproduce the problem and send you the files.

However, I noticed that running git describe --tags I have slightly a different result : Note that I do not have any uncommitted changes!

image

Running git log --oneline image

Thanks

Campou commented 4 years ago

Hi @John-nx

Thanks for you support. When the files are provided, we can look into this issue immediately.

Thanks.

John-nx commented 4 years ago

Hi @Campou,

Sorry for the late response.

-I pulled first image -I enabled the "Store BLE Mesh Node configuration persistently" in the menu config and saved the sdkconfig file (to be sure that the right sdkconfig is used, I removed others (sdkconfig.defaults and sdkconfig.old)) -I flashed the ble_mesh_node example (using ESP32-DevKitC and idf.py in windows cmd) -After a reset, the device not only loses the provisioning data but also cannot be provisioned anymore -Here are the files: try to unzip the file, I had to add .log nither binary nor zip files are not supported debug.7z.log

Thanks

Campou commented 4 years ago

Hi @John-nx

We have fixed this issue on the branch ble_mesh_release/esp-ble-mesh-v0.6.1, please pull and have a try.

Thanks.

John-nx commented 4 years ago

Hi, Im sorry to say that, but the new release does not seem to be working! image

I cannot even provision a node le alone the rest! image

Campou commented 4 years ago

Hi @John-nx,

Seen from the log, and after enabling the BLE Mesh NVS functionality, when you reboot the device, it will restore the corresponding information, there is no need to provision it again.

If the device needs to be provisioned another time, please erase the flash firstly.

Thanks

John-nx commented 4 years ago

Hi @Campou

Please read my comments more carefully, every time I try my best to mention the problem as clear as possible but you interpret another thing!

The device cannot be provisioned IN THE FIRST PLACE! using nRF Mesh and your app.

Best

Campou commented 4 years ago

Hi @John-nx

If my above comments lead to some misunerstanding, then sorry here.

Thanks.

John-nx commented 4 years ago

Hi @Campou

I still cannot provision the device in the first place. Let me explain more: when I use the nRF app to provision the device, the nRF app hangs/stops during the provisioning process, as shown in photo below :

prov

and then I have to terminate this step by force, by going to the app menu. Now if I reset the device I get the error and log that I had previously sent you!

Note:

  1. I am on the ble_mesh_release/esp-ble-mesh-v0.6.1 branch and pulled the latest version
  2. Each time I erase the micro and build and flash a clean version
  3. I have used both ESP32-DevKitC and WROVER
  4. I have flashed ble_mesh_node example (both with the Store "BLE Mesh Node configuration persistently" option enabled and disabled )
  5. I use ESP-IDF Tools Installer (version 2.1 and with python 3 ) and Windows 10
  6. when I flash the example (and before provisioning) the log is correct as you shown above

Actually, I am not working on this project anymore I just wanted to give a try and see whether the problem of losing provisioning data after power reset is solved or not, however, now I cannot even provision the node!

Thanks Here is the log:

I (0) cpu_start: App cpu up. I (471) heap_init: Initializing. RAM available for dynamic allocation: I (478) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (484) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (490) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (496) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM I (502) heap_init: At 3FFCA3A8 len 00015C58 (87 KiB): DRAM I (508) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (515) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (521) heap_init: At 40091A28 len 0000E5D8 (57 KiB): IRAM I (527) cpu_start: Pro cpu start user code I (210) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (211) ble_mesh_node: Initializing... I (211) gpio: GPIO[18]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:2 I (241) BTDM_INIT: BT controller compile version [3861d9f] I (241) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE BLE MESH LIB 0619 I (331) phy: phy_version: 4100, 6fa5e27, Jan 25 2019, 17:02:06, 0, 0 BLE MESH LIB 0619 BLE MESH LIB 0619 I (701) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_PROV_REGISTER_COMP_EVT I (701) ble_mesh_node: ESP_BLE_MESH_PROV_REGISTER_COMP_EVT, err_code 0 I (711) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT I (711) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT, err_code 0 I (721) ble_mesh_node: BLE Mesh Node initialized I (620751) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT I (620751) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT W (627471) BLE_MESH: bt_mesh_attention, No Health Server context provided W (631371) BLE_MESH: bt_mesh_attention, No Health Server context provided I (631391) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_LINK_CLOSE_EVT I (631391) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_LINK_CLOSE_EVT, bearer PB-GATT I (631401) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_COMPLETE_EVT I (631411) ble_mesh_node: net_idx: 0x0000, addr: 0x0006 I (631421) ble_mesh_node: flags: 0x00, iv_index: 0x00000000 W (637561) BLE_MESH: Composition page 255 not available W (639811) BLE_MESH: Ran out of retransmit attempts ets Jun 8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0018,len:4 load:0x3fff001c,len:6332 load:0x40078000,len:11308 ho 0 tail 12 room 4 load:0x40080400,len:6700 entry 0x40080764 I (30) boot: ESP-IDF v4.0-dev-311-ga3287a7ad 2nd stage bootloader I (30) boot: compile time 12:30:16 I (31) boot: Enabling RNG early entropy source... I (36) boot: SPI Speed : 40MHz I (41) boot: SPI Mode : DIO I (45) boot: SPI Flash Size : 2MB I (49) boot: Partition Table: I (52) boot: ## Label Usage Type ST Offset Length I (60) boot: 0 nvs WiFi data 01 02 00009000 00006000 I (67) boot: 1 phy_init RF data 01 01 0000f000 00001000 I (74) boot: 2 factory factory app 00 00 00010000 00100000 I (82) boot: End of partition table I (86) esp_image: segment 0: paddr=0x00010020 vaddr=0x3f400020 size=0x2c1e0 (180704) map I (158) esp_image: segment 1: paddr=0x0003c208 vaddr=0x3ffbdb60 size=0x03450 ( 13392) load I (164) esp_image: segment 2: paddr=0x0003f660 vaddr=0x40080000 size=0x00400 ( 1024) load 0x40080000: _WindowOverflow4 at C:/Projects/ESP32/esp-idf/components/freertos/xtensa_vectors.S:1779

I (166) esp_image: segment 3: paddr=0x0003fa68 vaddr=0x40080400 size=0x005a8 ( 1448) load I (175) esp_image: segment 4: paddr=0x00040018 vaddr=0x400d0018 size=0x8bf60 (573280) map 0x400d0018: _flash_cache_start at ??:?

I (384) esp_image: segment 5: paddr=0x000cbf80 vaddr=0x400809a8 size=0x11080 ( 69760) load I (423) boot: Loaded app from partition at offset 0x10000 I (423) boot: Disabling RNG early entropy source... I (424) cpu_start: Pro cpu up. I (427) cpu_start: Application information: I (432) cpu_start: Project name: ble_mesh_node I (438) cpu_start: App version: 1 I (442) cpu_start: Compile time: Nov 15 2019 12:29:49 I (448) cpu_start: ELF file SHA256: 7c64b87c7d56ac9b... I (454) cpu_start: ESP-IDF: v4.0-dev-311-ga3287a7ad I (461) cpu_start: Starting app cpu, entry point is 0x4008104c 0x4008104c: call_start_cpu1 at C:/Projects/ESP32/esp-idf/components/esp32/cpu_start.c:267

I (0) cpu_start: App cpu up. I (471) heap_init: Initializing. RAM available for dynamic allocation: I (478) heap_init: At 3FFAFF10 len 000000F0 (0 KiB): DRAM I (484) heap_init: At 3FFB6388 len 00001C78 (7 KiB): DRAM I (490) heap_init: At 3FFB9A20 len 00004108 (16 KiB): DRAM I (496) heap_init: At 3FFBDB5C len 00000004 (0 KiB): DRAM I (502) heap_init: At 3FFCA3A8 len 00015C58 (87 KiB): DRAM I (508) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM I (515) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM I (521) heap_init: At 40091A28 len 0000E5D8 (57 KiB): IRAM I (527) cpu_start: Pro cpu start user code I (210) cpu_start: Starting scheduler on PRO CPU. I (0) cpu_start: Starting scheduler on APP CPU. I (211) ble_mesh_node: Initializing... I (211) gpio: GPIO[18]| InputEn: 1| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:2 I (241) BTDM_INIT: BT controller compile version [3861d9f] I (241) system_api: Base MAC address is not set, read default base MAC address from BLK0 of EFUSE BLE MESH LIB 0619 I (341) phy: phy_version: 4100, 6fa5e27, Jan 25 2019, 17:02:06, 0, 0 BLE MESH LIB 0619 BLE MESH LIB 0619 E (701) BT_GATT: GATTS_StopService service_handle: 46 is not in use I (711) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_COMPLETE_EVT I (711) ble_mesh_node: net_idx: 0x0000, addr: 0x0006 I (711) ble_mesh_node: flags: 0x00, iv_index: 0x00000000 W (721) BOARD: led green is already off I (721) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_PROV_REGISTER_COMP_EVT I (731) ble_mesh_node: ESP_BLE_MESH_PROV_REGISTER_COMP_EVT, err_code 0 I (741) ble_mesh_node: esp_ble_mesh_prov_cb, event = ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT I (751) ble_mesh_node: ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT, err_code -120 I (751) ble_mesh_node: BLE Mesh Node initialized

Campou commented 4 years ago

Hi @John-nx

When I tried with the latest Android App (version 2.1.0), I met the same problem. And I switch back to the old version which is version 1.1.0. Test about 3 times, it works fine, the following are the screenshots of the test.

Sample Sample Sample

And in the Github website of Nordic, some developer has submitted an issue for this https://github.com/NordicSemiconductor/Android-nRF-Mesh-Library/issues/268.

Also I have a test with the lastes iOS version, and everything goes well.

Thanks.

John-nx commented 4 years ago

Hi @Campou ,

Alright, thanks. I would downgrade the app and test again.

John-nx commented 4 years ago

Hi @Campou

First things first, I downgraded the nRF mesh one version to the v2.0.5 (in my opinion, it does not make any sense to downgrade to 1.1.0), and I could provision the node successfully, and more importantly, after a reset, the node was working just fine and I was able to connect to it! However, there was one minor problem: when I wanted to reconnect to the node after a rest, instead of showing the name of the node in the searching list, nRF was showing "UNKNOWN DEVICE".

Secondly, I noticed that the version 2.1.0 is released 15 days ago! So it seemed odd to me that such a bug issue still exists ! I thought maybe it works with the Nordic micros and I was right! I tried to provision a nordic micro with the latest nRF mesh Android app (v2.1.0), and it worked successfully! At this point, I think it's your job to find the problem. BTW you work as a developer and support for esspressif , right?

Best

Alvin1Zhang commented 4 years ago

@John-nx Thanks for reporting and keeping sharing updates, and thanks @Campou for the support. Feel free to reopen the issue if it still happens, or file a new ticket for new issue. Thanks.

ashish-iottive commented 2 years ago

@Alvin1Zhang @Campou Could you provide proper screenshots of the whole BLE Node Provisioning Storage, I am running example of onoff_server from esp_ble_mesh example. I am facing same problem how to store the ble mesh provision via nRF mesh Android Mobile Application cause the device lost the provisioning settings after its gets restart. Environment Development Kit: [ESP32-DevKitC] Kit version (DevKitC): [v1] Module or chip used: [ESP32-WROOM-32] IDF version : // v4.3 Build System: ESP-IDF Tools // [Make|CMake] Operating System: [Windows] Power Supply: [USB]

Hi @John-nx

Please enable the node NVS storage functionality through make menuconfig. Component config -> BLE Mesh Support -> Store BLE Mesh Node configuration persistently

  • Note: about this functionality, we have pushed a bugfix to the branch ble_mesh_release/esp-ble-mesh-v0.6.1 last week, please pull and have a try.

After the device is provisioned successfully and restarted, the App will not show it in the Scanner of the nRF Mesh App, instead we need to click the CONNECT on the top right and the App will start to scan the proxy advertising of the device.

I have tested using the branch ble_mesh_release/esp-ble-mesh-v0.6.1 with NVS storage on, each time after the device is restarted, the App can connect with it successfully and control the RGB light.

The attachment is the ble_mesh_node example test log.

ble_mesh_node_nvs_test.log

Thanks.

Here is the screenshot of the monitor after flash: Screenshot 2021-12-01 170038

.