Hi Vivek, As far as I know, the BT_HCI_MESH_EXT option is for HCI vendor extensions which haven’t been implemented yet. However, BlueZ doesn’t require or even support them, so this should be a non-iss

Hi Stefan, Have you enabled CONFIG_NET_BUF=y? That’s the only dependency for CONFIG_NET_BUF_USER_DATA_SIZE being defined. Johan

Hi, See this commit: https://github.com/zephyrproject-rtos/zephyr/pull/18270/commits/730778b4864abdd6a79cc38c071d03ae0aa6e015 Basically the fix is just to drop your custom bt_gatt_ccc_cfg array and no

Hi Paul, You need to configure proxy filtering to tell the proxy what addresses your proxy client is interested in. See section 6, and 6.4 in particular in the Mesh Profile Specification. There are ma

#bluetoothmesh #zephyrbluetoothmesh #nrf52-pca10040

Hi Gopal, The HCI device needs to be powered down first, using e.g. “hciconfig hci0 down”. Does that help? Johan

Hi Venkat, That depends on what the publish address is. If it’s a group address then any node that subscribes to this address, including the proxy node, will receive it. If it’s a unicast address it n

For the record, I found a minor bug with the bt_mesh_fault_update() API in that it wasn’t properly updating the publication message before sending it. I’ve submitted a PR (one-line patch) to fix this:

#zephyrbluetoothmesh

Hi Billy, Actually, I think I missed the fact in the earlier emails that this was specifically about the health server and not just any model publishing. The health server is a special case and does s

#zephyrbluetoothmesh

Hi Billy, (added zephyr-users back to CC - please don’t drop it since others may benefit from this information as well) There are a many problems with the above: 1. The model publication is expected t

#zephyrbluetoothmesh

Hi Billy, It should be working even with a single fault, and this has e.g. been tested with the PTS which does configure periodic publishing during some of its test cases. Is your source code availabl

#zephyrbluetoothmesh #bluetoothmesh

Hi Alexander, I don’t know if this is the cause of your issue, but it implies that you have something in flash (the storage partition) that the application doesn’t expect. Before investigating further

#bluetoothmesh #nrf52832

Hi, HCI_Read_Local_Extended_Features is a BR/EDR-only command, which is why you are getting this response from the LE-only controller. You’ll also see that it’s not listed in the supported commands re

#ble #nrf52840 #uart #hci

Hi, Notice that these are MGMT commands and events, i.e. just communication between BlueZ user space and the Linux kernel and not directly related to the controller. The Set PHY Configuration MGMT com

#ble #nrf52840 #uart #hci

Hi Lawrence, As far as I know, the Nitrogen only has a single-mode (LE-only) Bluetooth radio, whereas RFCOMM (and SPP) is a BR/EDR (Bluetooth Classic) protocol, so you won’t be able to use it on this

Hi Marco, Does your PC have a Bluetooth adapter? Does e.g. running "hciconfig" show hci0 for you? Johan

Hi Vikrant, There shouldn't at least be anything techical preventing it. We run the qualification tests periodically and know that they pass. So any company that wants to make a qualificaton listing j

Hi Vikrant, You should be able to use the same settings storage for your own data as well. The Bluetooth stack (Mesh included) uses the prefix "bt/" for all key names stored in settings, so as long as

Hi Rodrigo, Do you have CONFIG_BT_TINYCRYPT_ECC=y in your configuration? Johan

#bluetoothmesh #nrf52840

Hi Vikrant, I understood what you meant. And those are the steps I followed. I used Nordic's new iOS mesh app and used its "node reset" feature. Then I reprovisioned and after that did a power-cycle.

Hi Vikrant, I just tried your exact steps with the mesh_shell app, and it works correctly (i.e. after the power cycle the board comes back as provisioned). I used the nRF51 USB dongle, fwiw. Is it pos