I discovered what I forgot to do. The provisioner, in my case the RPI, lost the connection with the network. When it happens you just need to execute the command: [meshctl]# connect [net_idx] [dst] //

#bluetoothmesh #ble #meshctl

Hi, I'm working with Zephyr Project to study and build light solutions using Mesh BLE. To proof the concept I'm using the following setup: - 2 boards of Nordic with nRF52832 model PCA10040; - Raspberr

#bluetoothmesh #ble #meshctl

Hi, I'm not able to provision any sample code using Bluez v5.49 #meshctl in case of latest master branch i.e v1.13rc2. Other observations: 1) Using #nRFMesh App (iOS) everything is Ok. 2) In case of Z

#meshctl

Hi to all, cd $(zephyr_base) git fetch origin pull/7283/head:BlueZMeshctl git checkout BlueZMeshctl I execute above commands & re-build samples/bluetooth/mesh & try to provision it using BlueZ 5.49 #m

#meshctl #bluetoothmesh

Hi Steve, Thanks for testing. Could you also please add some sort of "tested to be working" comment in the PR to help it get merged? It'd indeed be interesting for someone to analyze the difference. E

#meshctl #bluetoothmesh

Hi Johan, Works for me. Provisioning completes on samples/bluetooth/mesh and connects for configuration. The identity connection had previously failed. It's curious that the SILabs provisioner reporte

#meshctl #bluetoothmesh

Hi Steve, That's a good catch. I'm sorry for not realizing it earlier. I've uploaded an untested pull request that attempts to fix this. Could you try it please: https://github.com/zephyrproject-rtos/

#meshctl #bluetoothmesh

Hi, I had a chance to look at this further. More at the bottom. It doesn't appear that bt_mesh_proxy_identity_enable() gets called in prov.c:proxy_data(). The earlier call to bt_mesh_provision() close

#meshctl #bluetoothmesh

Hi, This was already identified as a bug in meshctl by Steve, a week ago or so. However, I haven't seen a patch submitted to BlueZ yet. Johan

#meshctl #bluetoothmesh

Hi Vikrant, I just did two tests today, the detail is: 1st test. I built “onoff-app” example basing on latest Zephyr project, the commit is 9968cda453ac7a91d513b6a50817c926c3fe5cc6 of today, you can s

#meshctl #bluetoothmesh

HI Kai, Today I tried to provision #BlueNRG Mesh (It is based on ST Mesh library to which we could provision using Silicon Labs Mesh App ) DEVICE using #meshctl, in this case too provisioning process

#meshctl #bluetoothmesh

Hi Johan, Some more detail. I added some instrumentation to parse_service_data and parse_mesh_service_data. The data type that gets passed to parse_mesh_service_data in data[0] is 0x00 while the funct

#bluetoothmesh #meshctl

Hi Johan, I think the patch exposes a problem with meshctl. Vikrant offers that the SILABS App works fine and also uses GATT for provisioning and configuration. Meshctl provisions fine, but hangs on d

#bluetoothmesh #meshctl

Hi Steve, Do you have more details on this? Is there a bug with the patch, or just something else that needs to be tuned somewhere? Johan

#bluetoothmesh #meshctl

Hi Vikrant, I tracked this down to Zephyr and bisected the problem to commit d6a549ceba735c294d0dfae56edd9f7e1c9d7fe6 Bluetooth: Mesh: Fix Node Identity advertising with PB-ADV Steve

#bluetoothmesh #meshctl

Hi Steve, Yes, you are right that #meshctl completes provisioning & fails after that. Silicon Labs still uses PB-GATT like #meshctl for provisioning & configuration of DEVICE. BlueZ 5.48 #meshctl was

#bluetoothmesh #meshctl

Hi Vikrant, I looked at this too. Provisioning seems to complete, but the proxy service isn't discovered. Meshctl just seems to hang waiting for the discovery to succeed. While this is happening, if I

#bluetoothmesh #meshctl

Hi, I am not able to provision my Devices which is executing sample example at $/zephyr/samples/boards/nrf52/mesh/onoff-app/ http://docs.zephyrproject.org/samples/boards/nrf52/mesh/onoff-app/README.ht

#bluetoothmesh #meshctl