Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Not able to provision the ESP - BLE-MESH Example. (IDFGH-11775) #12871

Closed
3 tasks done
Bosemani opened this issue Dec 26, 2023 · 33 comments
Closed
3 tasks done

Not able to provision the ESP - BLE-MESH Example. (IDFGH-11775) #12871

Bosemani opened this issue Dec 26, 2023 · 33 comments
Assignees
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally

Comments

@Bosemani
Copy link

Answers checklist.

  • I have read the documentation ESP-IDF Programming Guide and the issue is not addressed there.
  • I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
  • I have searched the issue tracker for a similar issue and not found a similar issue.

General issue report

Hai,
My sdk version is ESP-IDF v5.3-dev-1157 & Esp32-c3 development board.
I tried onoff_client, onoff_server, sensor ble mesh examples under this location esp-idf\examples\bluetooth\esp_ble_mesh
I haven't modified anything on code. I just changed BLE mesh log level.
I'm using NRF BLE MESH Android app for provisioning but I'm not able to complete the provisioning process. It always fails.

Here is the on-off server example on esp32-c3 log:

I (30) boot: ESP-IDF v5.3-dev-1157-g341a8f2d65 2nd stage bootloader
I (30) boot: compile time Dec 26 2023 10:33:55
I (31) boot: chip revision: v0.3
I (35) boot.esp32c3: SPI Speed      : 80MHz
I (40) boot.esp32c3: SPI Mode       : DIO
I (44) boot.esp32c3: SPI Flash Size : 2MB
I (49) boot: Enabling RNG early entropy source...
I (54) boot: Partition Table:
I (58) boot: ## Label            Usage          Type ST Offset   Length
I (65) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (73) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (80) boot:  2 factory          factory app      00 00 00010000 00177000
I (88) boot: End of partition table
I (92) esp_image: segment 0: paddr=00010020 vaddr=3c0e0020 size=3b4c8h (242888) map
I (140) esp_image: segment 1: paddr=0004b4f0 vaddr=3fc90a00 size=02f28h ( 12072) load
I (142) esp_image: segment 2: paddr=0004e420 vaddr=40380000 size=01bf8h (  7160) load
I (147) esp_image: segment 3: paddr=00050020 vaddr=42000020 size=dc5fch (902652) map
I (301) esp_image: segment 4: paddr=0012c624 vaddr=40381bf8 size=0ec34h ( 60468) load
I (317) boot: Loaded app from partition at offset 0x10000
I (317) boot: Disabling RNG early entropy source...
I (329) cpu_start: Unicore app
I (338) cpu_start: Pro cpu start user code
I (338) cpu_start: cpu freq: 160000000 Hz
I (338) cpu_start: Application information:
I (341) cpu_start: Project name:     onoff_server
I (347) cpu_start: App version:      1
I (351) cpu_start: Compile time:     Dec 26 2023 11:09:40
I (357) cpu_start: ELF file SHA256:  562da1cc4...
I (363) cpu_start: ESP-IDF:          v5.3-dev-1157-g341a8f2d65
I (369) cpu_start: Min chip rev:     v0.3
I (374) cpu_start: Max chip rev:     v1.99
I (379) cpu_start: Chip rev:         v0.3
I (383) heap_init: Initializing. RAM available for dynamic allocation:
I (391) heap_init: At 3FC9B410 len 00024BF0 (146 KiB): RAM
I (397) heap_init: At 3FCC0000 len 0001C710 (113 KiB): Retention RAM
I (404) heap_init: At 3FCDC710 len 00002950 (10 KiB): Retention RAM
I (411) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
I (418) spi_flash: detected chip: generic
I (422) spi_flash: flash io: dio
W (426) spi_flash: Detected size(4096k) larger than the size in the binary image header(2048k). Using the size in the binary image header.
I (439) sleep: Configure to isolate all GPIO pins in sleep state
I (446) sleep: Enable automatic switching of GPIO sleep configuration
I (453) coexist: coex firmware version: c02915e
I (467) coexist: coexist rom version 9387209
I (468) main_task: Started on CPU0
I (468) main_task: Calling app_main()
I (468) EXAMPLE: Initializing...
I (468) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (478) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (488) gpio: GPIO[8]| InputEn: 0| OutputEn: 0| OpenDrain: 0| Pullup: 1| Pulldown: 0| Intr:0
I (508) BLE_INIT: BT controller compile version [b877d66]
I (508) BLE_INIT: Bluetooth MAC: 7c:df:a1:c2:0e:82
I (508) phy_init: phy_version 1130,b4e4b80,Sep  5 2023,11:09:30
Bluetooth Mesh v1.1 commit: [154b4fcc98]
I (568) BLE_MESH: Friend not supported
I (628) EXAMPLE: ESP_BLE_MESH_PROV_REGISTER_COMP_EVT, err_code 0
I (628) EXAMPLE: ESP_BLE_MESH_NODE_PROV_ENABLE_COMP_EVT, err_code 0
I (628) EXAMPLE: BLE Mesh Node initialized
I (638) main_task: Returned from app_main()
I (6818) EXAMPLE: ESP_BLE_MESH_NODE_PROV_LINK_OPEN_EVT, bearer PB-GATT
W (8468) BLE_MESH: No Health Server context provided
I (9368) BLE_MESH: Algorithm:   0x00
I (9368) BLE_MESH: Public Key:  0x00
I (9368) BLE_MESH: Auth Method: 0x00
I (9368) BLE_MESH: Auth Action: 0x00
I (9378) BLE_MESH: Auth Size:   0x00
I (9638) BLE_MESH: Remote Random: 977f71785a107b753fa2ab3ddfec264f
I (9738) BLE_MESH: Primary Element: 0x001c
I (9738) BLE_MESH: net_idx 0x0000 flags 0x00 iv_index 0x0000
I (9738) BLE_MESH: DevKey 0600416b9d5b3221629100404c71b29f
I (9738) BLE_MESH: NetKey ae415409468ef870f8559d1279eaaa97
W (9748) BLE_MESH: No Health Server context provided
I (9758) BLE_MESH: Primary address 0x001c, element count 3
I (9758) BLE_MESH: Scan is already started
I (9768) EXAMPLE: ESP_BLE_MESH_NODE_PROV_LINK_CLOSE_EVT, bearer PB-GATT
I (9768) EXAMPLE: ESP_BLE_MESH_NODE_PROV_COMPLETE_EVT
I (9778) EXAMPLE: net_idx: 0x0000, addr: 0x001c
I (9778) EXAMPLE: flags: 0x00, iv_index: 0x00000000
W (10808) BT_HCI: hcif disc complete: hdl 0x2, rsn 0x13
I (17158) BLE_MESH: recv, app_idx 0xfffe src 0x0001 dst 0x001c
I (17158) BLE_MESH: recv, len 3: 800800
I (17158) BLE_MESH: send, app_idx 0xfffe src 0x001c dst 0x0001
I (17168) BLE_MESH: send, len 32: 0200e502000000000a0003000000020000000010000001000010000001000010
I (17178) BLE_MESH: Seg, send_tag 0x03, send_szmic 0, aszmic 0
I (17178) BLE_MESH: Use security credentials 0x00, proxy 0
I (17188) BLE_MESH: Network PDU, count 2, interval 20
I (17188) BLE_MESH: Use security credentials 0x00, proxy 0
I (17198) BLE_MESH: Network PDU, count 2, interval 20
I (17208) BLE_MESH: Use security credentials 0x00, proxy 0
I (17208) BLE_MESH: Network PDU, count 2, interval 20
I (18228) BLE_MESH: Attempts: 3
I (18228) BLE_MESH: Resending 0/2, cred 0x00
I (18228) BLE_MESH: Resending 1/2, cred 0x00
I (18228) BLE_MESH: Resending 2/2, cred 0x00
I (19248) BLE_MESH: Attempts: 2
I (19248) BLE_MESH: Resending 0/2, cred 0x00
I (19248) BLE_MESH: Resending 1/2, cred 0x00
I (19248) BLE_MESH: Resending 2/2, cred 0x00
I (20268) BLE_MESH: Attempts: 1
I (20268) BLE_MESH: Resending 0/2, cred 0x00
I (20268) BLE_MESH: Resending 1/2, cred 0x00
I (20268) BLE_MESH: Resending 2/2, cred 0x00
I (21288) BLE_MESH: Attempts: 0
I (21288) BLE_MESH: Resending 0/2, cred 0x00
I (21288) BLE_MESH: Resending 1/2, cred 0x00
I (21288) BLE_MESH: Resending 2/2, cred 0x00
W (22308) BLE_MESH: Ran out of retransmit attempts
W (358928) BT_HCI: hcif disc complete: hdl 0x2, rsn 0x13

In Nrf mesh app it's getting stop at "Sending composition data get...."
Screenshot_2023-12-21-19-57-35-26_3207d904ec569c183efa42395aeecd91

Why is this happening? How to resolve this.

Best Regards
Bose

@espressif-bot espressif-bot added the Status: Opened Issue is new label Dec 26, 2023
@github-actions github-actions bot changed the title Not able to provision the ESP - BLE-MESH Example. Not able to provision the ESP - BLE-MESH Example. (IDFGH-11775) Dec 26, 2023
@Bosemani
Copy link
Author

update
I tried in ESP-IDF v5.1.1-439-gcb174b0fe1-dirty version Its working.
But ESP-IDF v5.3-dev-1157-g341a8f2d65 not able to provision.
Why it's not working in master branch?

@Bosemani
Copy link
Author

hai @forx157
Any update?

@Herbrant
Copy link

Hi @Bosemani! I have the same problem using the nrf mesh application for Android. I tried doing the same with the Apple appand it worked without any problem.
If you take a look to the source code of the nrf mesh application it seems that the Android app supports BLE Mesh 1.0.1 while the Apple app supports BLE Mesh 1.1. Maybe the problem is related to the version of the supported protocol by the application.

If you don't have an apple product, you can try to do the same using an esp32 as provisioner.

@Bosemani
Copy link
Author

Hai @Herbrant
Thank you for your response.
I tested by using another esp32 as provisioner. Its working well.
In NRF mesh android app, we need to wait for their update.

@Herbrant
Copy link

Right now I have a problem with the provisioner and the onoff_client of the examples directory.
It seems that the provisioner has some problem in the appkey configuration phase:

...
W (58547) BLE_MESH: Receive generic status message timeout
I (58547) EXAMPLE: example_ble_mesh_generic_client_cb, error_code = 0x00, event = 0x03, addr: 0x0008, opcode: 0x8201
I (58557) BLE_MESH: Client message 0x00008201 with timeout 4000ms
I (58567) BLE_MESH: send, app_idx 0x0000 src 0x0001 dst 0x0008
I (58567) BLE_MESH: send, len 2: 8201
I (58577) BLE_MESH: Unseg, send_tag 0x00, send_szmic 0, aszmic 0
I (58587) BLE_MESH: Use security credentials 0x00, proxy 0
I (58587) BLE_MESH: Network PDU, count 2, interval 20
W (62597) BLE_MESH: Receive generic status message timeout
I (62597) EXAMPLE: example_ble_mesh_generic_client_cb, error_code = 0x00, event = 0x03, addr: 0x0008, opcode: 0x8201
I (62607) BLE_MESH: Client message 0x00008201 with timeout 4000ms
I (62607) BLE_MESH: send, app_idx 0x0000 src 0x0001 dst 0x0008
I (62617) BLE_MESH: send, len 2: 8201
I (62617) BLE_MESH: Unseg, send_tag 0x00, send_szmic 0, aszmic 0
I (62627) BLE_MESH: Use security credentials 0x00, proxy 0
I (62637) BLE_MESH: Network PDU, count 2, interval 20
W (66647) BLE_MESH: Receive generic status message timeout
I (66647) EXAMPLE: example_ble_mesh_generic_client_cb, error_code = 0x00, event = 0x03, addr: 0x0008, opcode: 0x8201
I (66647) BLE_MESH: Client message 0x00008201 with timeout 4000ms
I (66657) BLE_MESH: send, app_idx 0x0000 src 0x0001 dst 0x0008
I (66657) BLE_MESH: send, len 2: 8201
I (66667) BLE_MESH: Unseg, send_tag 0x00, send_szmic 0, aszmic 0
I (66677) BLE_MESH: Use security credentials 0x00, proxy 0
I (66677) BLE_MESH: Network PDU, count 2, interval 20

onoff_client:

...
I (3530) EXAMPLE: net_idx 0x0000, app_idx 0x0000
I (3540) AppKey: 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 
I (3680) BLE_MESH: recv, app_idx 0xfffe src 0x0001 dst 0x0008
I (3680) BLE_MESH: recv, len 8: 803d080000000010
I (3680) BLE_MESH: send, app_idx 0xfffe src 0x0008 dst 0x0001
I (3690) BLE_MESH: send, len 9: 803e02080000000010
I (3700) BLE_MESH: Unseg, send_tag 0x02, send_szmic 0, aszmic 0
I (3700) BLE_MESH: Use security credentials 0x00, proxy 0
I (3710) BLE_MESH: Network PDU, count 2, interval 20
I (3780) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (3780) BLE_MESH: recv, len 2: 8201
I (7830) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (7830) BLE_MESH: recv, len 2: 8201
I (11880) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (11880) BLE_MESH: recv, len 2: 8201
I (15920) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (15920) BLE_MESH: recv, len 2: 8201
I (19960) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (19960) BLE_MESH: recv, len 2: 8201
I (24020) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (24020) BLE_MESH: recv, len 2: 8201
I (28060) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (28060) BLE_MESH: recv, len 2: 8201
I (32100) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (32100) BLE_MESH: recv, len 2: 8201
I (36150) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (36150) BLE_MESH: recv, len 2: 8201
I (40190) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (40190) BLE_MESH: recv, len 2: 8201
I (44240) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (44240) BLE_MESH: recv, len 2: 8201

You are able to send messages from the client to the server? @Bosemani

@ankit-thealchemist
Copy link

I have done provisioning on the tag v5.1.2 on esp32 c3. Its working fine for me

@Bosemani
Copy link
Author

Right now I have a problem with the provisioner and the onoff_client of the examples directory.
It seems that the provisioner has some problem in the appkey configuration phase:

...
W (58547) BLE_MESH: Receive generic status message timeout
I (58547) EXAMPLE: example_ble_mesh_generic_client_cb, error_code = 0x00, event = 0x03, addr: 0x0008, opcode: 0x8201
I (58557) BLE_MESH: Client message 0x00008201 with timeout 4000ms
I (58567) BLE_MESH: send, app_idx 0x0000 src 0x0001 dst 0x0008
I (58567) BLE_MESH: send, len 2: 8201
I (58577) BLE_MESH: Unseg, send_tag 0x00, send_szmic 0, aszmic 0
I (58587) BLE_MESH: Use security credentials 0x00, proxy 0
I (58587) BLE_MESH: Network PDU, count 2, interval 20
W (62597) BLE_MESH: Receive generic status message timeout
I (62597) EXAMPLE: example_ble_mesh_generic_client_cb, error_code = 0x00, event = 0x03, addr: 0x0008, opcode: 0x8201
I (62607) BLE_MESH: Client message 0x00008201 with timeout 4000ms
I (62607) BLE_MESH: send, app_idx 0x0000 src 0x0001 dst 0x0008
I (62617) BLE_MESH: send, len 2: 8201
I (62617) BLE_MESH: Unseg, send_tag 0x00, send_szmic 0, aszmic 0
I (62627) BLE_MESH: Use security credentials 0x00, proxy 0
I (62637) BLE_MESH: Network PDU, count 2, interval 20
W (66647) BLE_MESH: Receive generic status message timeout
I (66647) EXAMPLE: example_ble_mesh_generic_client_cb, error_code = 0x00, event = 0x03, addr: 0x0008, opcode: 0x8201
I (66647) BLE_MESH: Client message 0x00008201 with timeout 4000ms
I (66657) BLE_MESH: send, app_idx 0x0000 src 0x0001 dst 0x0008
I (66657) BLE_MESH: send, len 2: 8201
I (66667) BLE_MESH: Unseg, send_tag 0x00, send_szmic 0, aszmic 0
I (66677) BLE_MESH: Use security credentials 0x00, proxy 0
I (66677) BLE_MESH: Network PDU, count 2, interval 20

onoff_client:

...
I (3530) EXAMPLE: net_idx 0x0000, app_idx 0x0000
I (3540) AppKey: 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 12 
I (3680) BLE_MESH: recv, app_idx 0xfffe src 0x0001 dst 0x0008
I (3680) BLE_MESH: recv, len 8: 803d080000000010
I (3680) BLE_MESH: send, app_idx 0xfffe src 0x0008 dst 0x0001
I (3690) BLE_MESH: send, len 9: 803e02080000000010
I (3700) BLE_MESH: Unseg, send_tag 0x02, send_szmic 0, aszmic 0
I (3700) BLE_MESH: Use security credentials 0x00, proxy 0
I (3710) BLE_MESH: Network PDU, count 2, interval 20
I (3780) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (3780) BLE_MESH: recv, len 2: 8201
I (7830) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (7830) BLE_MESH: recv, len 2: 8201
I (11880) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (11880) BLE_MESH: recv, len 2: 8201
I (15920) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (15920) BLE_MESH: recv, len 2: 8201
I (19960) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (19960) BLE_MESH: recv, len 2: 8201
I (24020) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (24020) BLE_MESH: recv, len 2: 8201
I (28060) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (28060) BLE_MESH: recv, len 2: 8201
I (32100) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (32100) BLE_MESH: recv, len 2: 8201
I (36150) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (36150) BLE_MESH: recv, len 2: 8201
I (40190) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (40190) BLE_MESH: recv, len 2: 8201
I (44240) BLE_MESH: recv, app_idx 0x0000 src 0x0001 dst 0x0008
I (44240) BLE_MESH: recv, len 2: 8201

You are able to send messages from the client to the server? @Bosemani

Hai @Herbrant
I tried the same example, but I'm not facing any issues. But I haven't modified any code. Just loaded in two boards and checked the logs. It's working. I'm using the master branch.

@Bosemani
Copy link
Author

I have done provisioning on the tag v5.1.2 on esp32 c3. Its working fine for me

Hai @ankit-thealchemist
Did you tried the master branch? In the 5.1 version it's working.but recent versions it's not working using the nrf app.

@ankit-thealchemist
Copy link

@Bosemani No, I never work on the master branch, its in the dev phase and buggy. I always use the tags, they are stable.

Check this, it happened it before also
#6997

@chegewara
Copy link
Contributor

#12254 (comment)

@Fighter19
Copy link

I have done provisioning on the tag v5.1.2 on esp32 c3. Its working fine for me

I can confirm, had problem with the master, I built today. No problem with the nRF App an v5.1.2.
Thanks for the hint.

@Bosemani
Copy link
Author

I have done provisioning on the tag v5.1.2 on esp32 c3. Its working fine for me

I can confirm, had problem with the master, I built today. No problem with the nRF App an v5.1.2. Thanks for the hint.

Hai @Fighter19
I'm using v5.3-dev-2032-g4d90eedb6e.
What is your version?
also are u using android nrf mesh app?

@Bosemani
Copy link
Author

#12254 (comment)

Hai @chegewara
I don't have any provisioned devices to try this. Also, We are planning MESH V1.1 devices only in a network.
Do you know any other Android app, that will support BLE Mesh V1.1 devices?

@chegewara
Copy link
Contributor

Hi,
I am 90% sure its issue with espressif mesh code, in particular with proxy out characteristic in proxy server.
I tested with nrf mesh, sti mesh and silab mesh app, also with espressif espmesh app. None can provision mesh node from master.

If you dont have any provisioned esp32 devices, then its easy solution. Grab esp32 devkit and flash any mesh example built with idf 5.1. You have tool to work with mesh 5.1, because you can continue provisioning and play with mesh v1.1.

Specs says that mesh 1.1 shall be backward compatible, so any provisioner which works with mesh 1.0 should works with v1.1, just wont handle new features.

@Bosemani
Copy link
Author

Hi,
I am 90% sure its issue with espressif mesh code, in particular with proxy out characteristic in proxy server.
I tested with nrf mesh, sti mesh and silab mesh app, also with espressif espmesh app. None can provision mesh node from master.

If you dont have any provisioned esp32 devices, then its easy solution. Grab esp32 devkit and flash any mesh example built with idf 5.1. You have tool to work with mesh 5.1, because you can continue provisioning and play with mesh v1.1.

Specs says that mesh 1.1 shall be backward compatible, so any provisioner which works with mesh 1.0 should works with v1.1, just wont handle new features.

Hai @chegewara
Thank you so much for your reply.
I will try to use idf version 5.1 and master brach for testing.

@chegewara
Copy link
Contributor

There is one more thing i just learned.
esp32 with ble mesh v1.1 works with silab mesh app, but this time is the issue (small) with the app.

  • after initial provisioning app stuck
  • when you restart app you can work with esp32 node, which is provisioned
  • the way this app is handling models kinda sucks, at least comparing to nRF mesh, but you dont need this extra esp32 node i mentioned earlier to work

@chegewara
Copy link
Contributor

Looks like i dont know what i am saying about, maybe except how to workaround provisioning issues with nrf mesh.

Here is what i found:

  • even esp32 ble mesh provisioner v1.0 cant provision device with mesh v1.1
  • composition data in v1.1 looks different (additional 2 bytes value in front), according to logs
    -- composition data from v1.0 e502 0000 0000 0a00 0300 and v1.1 0200 e502 0000 0000 0a00 0300
  • ble mesh v1.1 specs does not mention about this additional value - table 4.2 - https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=554899

@Bosemani
Copy link
Author

Looks like i dont know what i am saying about, maybe except how to workaround provisioning issues with nrf mesh.

Here is what i found:

  • even esp32 ble mesh provisioner v1.0 cant provision device with mesh v1.1
  • composition data in v1.1 looks different (additional 2 bytes value in front), according to logs
    -- composition data from v1.0 e502 0000 0000 0a00 0300 and v1.1 0200 e502 0000 0000 0a00 0300
  • ble mesh v1.1 specs does not mention about this additional value - table 4.2 - https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=554899

Hai @chegewara
I haven't looked into it.
It's Great. This means, we need a V1.1 provisioner to provision the v1.1 device.
Nrf iOS app will support v1.1, that's the reason we can provision using iOS.
But Android nrf doesn't support v1.1.

@chegewara
Copy link
Contributor

chegewara commented Feb 29, 2024

I believe this is relevant info

mesh v1.0
image

mesh v1.1
image

I believe there should be option to set this value in API, but either i cant find it or is not implemented.
This does not explain the fact that nRF mesh on android can provision mesh v1.1 device anyway, just cant get composition data after reconnecting.

PS espressif provisioner mesh v1.0 can work with node mesh v1.1 when you disable this option in menuconfig CONFIG_BLE_MESH_PROV_EPA
in other case you can see logs like this:
E (1450) BLE_MESH: Invalid algorithms 0x0003

it does not explain why nrf mesh cant provisioning mesh v1.1 node, even if EPA is disabled, so i still believe its issue with proxy out characteristic

@Bosemani
Copy link
Author

Bosemani commented Mar 5, 2024

CONFIG_BLE_MESH_PROV_EPA

Hai @chegewara
Thank you for your great effort.
do you have any workaround for this?

@chegewara
Copy link
Contributor

chegewara commented Mar 12, 2024

Ive found it, finally.
It has nothing to do with anything i said earlier, and for sure with ble mesh v1.1.
provisioning cant pass this check
https://github.com/espressif/esp-idf/blob/master/components/bt/esp_ble_mesh/core/net.c#L1813
This is the fix

    if (IS_ENABLED(CONFIG_BLE_MESH_GATT_PROXY_SERVER) &&
       bt_mesh_private_gatt_proxy_state_get() != BLE_MESH_PRIVATE_GATT_PROXY_ENABLED &&
       net_if == BLE_MESH_NET_IF_PROXY) {

Thanks

PS now it works with nRF connect and silab app too

@ruslanslobozhenuk
Copy link

Наконец-то я нашел его. Это не имеет ничего общего ни с чем, о чем я говорил ранее, и уж точно с ble mesh v1.1. подготовка не может пройти эту проверку https://github.com/espressif/esp-idf/blob/master/comComponents/bt/esp_ble_mesh/core/net.c#L1813 Это исправление

    if (IS_ENABLED(CONFIG_BLE_MESH_GATT_PROXY_SERVER) &&
       bt_mesh_private_gatt_proxy_state_get() != BLE_MESH_PRIVATE_GATT_PROXY_ENABLED &&
       net_if == BLE_MESH_NET_IF_PROXY) {

Спасибо

PS теперь он работает и с nRF Connect, и с приложением Silab.

Very good work!!! Thank YOU!!!

@forx157
Copy link
Collaborator

forx157 commented Mar 13, 2024

@chegewara
Thank you very much for your excellent work and apologies for the oversight in our code, we will be fixing this as soon as possible, thanks again for your efforts.

@chegewara
Copy link
Contributor

No problem, im glad it is that easy fix
I honestly believe this ble mesh component is very good job of you guys.
If lame like me can easy build any mesh device, node models or provisioner, without issue and get clear info when something is wrong (like missing setup server or or light models) then its very good.

I can only complain that mesh in esp-idf 5.1 is not C++ friendly (macros wont let use it in C++), but its fixed in 5.3.

Thanks

@Bosemani
Copy link
Author

No problem, im glad it is that easy fix
I honestly believe this ble mesh component is very good job of you guys.
If lame like me can easy build any mesh device, node models or provisioner, without issue and get clear info when something is wrong (like missing setup server or or light models) then its very good.

I can only complain that mesh in esp-idf 5.1 is not C++ friendly (macros wont let use it in C++), but its fixed in 5.3.

Thanks

@chegewara Very good work! Thank you.

@forx157
Copy link
Collaborator

forx157 commented Mar 14, 2024

@chegewara
Could you show me the code for this operation?

@chegewara
Copy link
Contributor

@forx157
Sorry, i deleted my previous post because i want to perform more tests to make sure i am not doing anything stupid and later to confirm its related to vendor or all models.

I am trying to figure out whats wrong.
All i know right now, that esp_ble_mesh_model_publish is somehow changing data in esp_ble_mesh_model_pub_t net buffer. (when i pass data straight to publish function, then all works fine)
I have this code

        ESP_LOG_BUFFER_HEX("TAG update 3", pub.msg->data, pub.msg->len);
        esp_ble_mesh_model_publish(_model, set_opcode, pub.msg->len, pub.msg->data, ROLE_NODE);
        ESP_LOG_BUFFER_HEX("TAG update 4", pub.msg->data, pub.msg->len);

and this output:

I (47917) TAG update 3: 12 34 <---- before call to publish
I (47917) TAG update 4: c4 34 12 c4 34  <----- after call to publish

I have more or less complicated C++ library, which should not be the cause of the problem, but who know.

Thanks for attention

@chegewara
Copy link
Contributor

chegewara commented Mar 14, 2024

Im not sure if my deduction is correct, but i found something.
To perform this test i am doing some "stupid" operations, but results are interesting.

  • i have this variable as a class member (its correctly initialized) esp_ble_mesh_model_pub_t pub = {};
  • i update value in net buffer with
        memcpy(pub.msg->data, data, len);
        pub.msg->len = len;
        ESP_LOG_BUFFER_HEX("TAG update 2", pub.msg->data, pub.msg->len);

and get correct result

TAG update 2: 44 44 44 44 <--- data sent to vendor model from nrf mesh

now the strange part only for this test purpose

    void publishState(size_t len, uint8_t* data)
    {
        esp_ble_mesh_model_publish(_model, set_opcode, len, data, ROLE_NODE); <--- here i pass data
        ESP_LOG_BUFFER_HEX("TAG update 3", pub.msg->data, pub.msg->len);
        esp_ble_mesh_model_publish(_model, set_opcode, pub.msg->len, pub.msg->data, ROLE_NODE); <---- here i pass `pub` with previously updated data
        ESP_LOG_BUFFER_HEX("TAG update 4", pub.msg->data, pub.msg->len);
    }

and here is log

I (56527) TAG update 3: c4 34 12 44 44 44 44 <--- correctly updated pub.msg->data with opcode
I (56537) TAG update 4: c4 34 12 c4 34 12 c4 44 12 c4 <--- data corrupted

we can observe 2 things:

  • on first call to publish i pass data straight to the function, even tho pub data is updated with opcode (which is probably expected in normal usage)
  • on second call to publish pub is updated again with opcode, but the pointer is not reset to begin of data buffer, so data are corrupted

Bear in mind that in normal use case i call only one time publish function with data passed from pub

I hope i described it that it can be understand, even if its a bit messy

Thanks

@forx157
Copy link
Collaborator

forx157 commented Mar 14, 2024

@chegewara
Is the pub msg you are using being used to initialise the publish model?

@chegewara
Copy link
Contributor

@forx157
yes, it is (i believe)

    BLE_MESH_MODEL_PUB_DEFINE(&pub, 3 + 20, ROLE_NODE, __COUNTER__);
    _model = new esp_ble_mesh_model_t(ESP_BLE_MESH_VENDOR_MODEL(cid, vid, vnd_op, &pub, NULL));

here is my updated macro, so i could use the same pub name in many class objects

#define BLE_MESH_MODEL_PUB_DEFINE(_name, _msg_len, _role, __n__)     \
    NET_BUF_SIMPLE_DEFINE_STATIC(bt_mesh_pub_msg_##__n__, _msg_len); \
    esp_ble_mesh_model_pub_t *_tmp = _name;                          \
    _tmp->msg = &bt_mesh_pub_msg_##__n__;                            \
    _tmp->update = (uint32_t)NULL;                                   \
    _tmp->dev_role = _role;

It is working with on-off server w/o issue

@forx157
Copy link
Collaborator

forx157 commented Mar 14, 2024

@chegewara
This is the problem, when you use this pub to initialise the publish model you should not pass this memory in esp_ble_mesh_model_publish. pub.msg this memory is used on the stack to hold the information passed in by the user, and this is caused when you pass pub.msg into this function memcpy(pub.msg.data, pub.msg.data, pub.msg.data_len) .

For details you can refer to the implementation in the function esp_ble_mesh_model_publish:

    if (act == BTC_BLE_MESH_ACT_MODEL_PUBLISH) {
        bt_mesh_model_msg_init(model->pub->msg, opcode);
         // if you passed pub.msg.data in,The essence of this line of code becomes
        // net_buf_simple_add_mem(model->pub->msg, model->pub->msg.data, model->pub->msg.data_len);
        net_buf_simple_add_mem(model->pub->msg, data, length);
    } else {
        msg_data = (uint8_t *)bt_mesh_malloc(op_len + length);
        if (msg_data == NULL) {
            return ESP_ERR_NO_MEM;
        }
        esp_ble_mesh_model_msg_opcode_init(msg_data, opcode);
        memcpy(msg_data + op_len, data, length);
    }

@chegewara
Copy link
Contributor

Ok, so i dont have to update data in pub, just pass data into publsih function and low level stack will update pub for me?

@forx157
Copy link
Collaborator

forx157 commented Mar 14, 2024

Yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Resolution: Done Issue is done internally Status: Done Issue is done internally
Projects
None yet
Development

No branches or pull requests

8 participants