Hello, Currently I have been doing provisioning of #BluetoothMesh DEVICEs using #meshctl utility. But I've to individually makes connection with each device over PB-GATT for provisining & configuratio

#bluetoothmesh

Hello World !! ----------------------------------------------------------------------------------------------------------------------------- { "$schema":"file:\/\/\/BlueZ\/Mesh\/schema\/mesh.jsonschem

#bluetoothmesh

Hello World !! https://blog.bluetooth.com/provisioning-a-bluetooth-mesh-network-part-1 By reading this link, I understood that netKey, appKey, dveKey are AES-128 symmetric keys which are exchanged ove

#bluetoothmesh

Hi Vikrant, That's not completely true. Only the primary netkey and the devkey are distributed to the node during provisioning. The other netkeys (if any) and appkeys are distributed during the config

#bluetoothmesh

Hi Johan, Thanks for your reply. https://blog.bluetooth.com/provisioning-a-bluetooth-mesh-network-part-1 https://blog.bluetooth.com/provisioning-a-bluetooth-mesh-network-part-2#_ftn2 I've been further

#bluetoothmesh

Hi Vikrant, Yes. Yes. Yes. Yes. The provisioner doesn't really need to know if the key is static or public. It just needs to know which key to use for the provisioning. What the implementation is miss

#bluetoothmesh

Hi Johan, Many many thanks Johan, for your in detail explanation. I don't want to use static public-private key pair for DEVICE & happy with current implementation. It is inherently more secure since

#bluetoothmesh

>> How provisioner will understand from where to received/read DEVICE >> public key out of *Bluetooth-Link* or *OOB* channel ? >I believe this is out of scope for the specification, since any OOB >cha

#bluetoothmesh

Hi Vikrant, I answered this already here: https://lists.zephyrproject.org/pipermail/zephyr-devel/2018-January/008734.html I'm sure we'll eventually have proper support for it, but if you want to get i

#bluetoothmesh

Hello World !! By including NFFS support into #BluetoothMesh project, now I can access flash of nRF52. { Some useful links: http://docs.zephyrproject.org/api/file_system.html https://lists.zephyrproje

#bluetoothmesh

After testing I found that it is necessary to add __attribute__((packed)) after structure definationWhy ?? This will be helpful --> http://www.avabodh.com/cin/structure.html So I edit above mentioned

#bluetoothmesh

As per this document .... nrf5_SDK_for_Mesh_v1.0.1_src/doc/introduction/mesh_hw_resources.md (I've attached this file for reference......very informative) The mesh stack uses flash to store the follow

#bluetoothmesh

Hi Johan, Is SFCB better option than NFFS to save #BluetoothMesh's persistence data ? Will it help us in case of nRF51 series which has limited flash storage ? Thank You !! ---------- Forwarded messag

#bluetoothmesh

This is observation based on following configuration done by #meshctl. Two nRF52840-PDK boards has been used for it. For Board 1. after provisioning, I used following commands to configure it ********

#bluetoothmesh

Hello World !! This is observation based on following configuration done by #meshctl. Two nRF52840-PDK boards has been used for it. For Board 1. after provisioning, I used following commands to config

#bluetoothmesh

Hello to all, SoC like nRF52840 supports only 10k write cycles. Is that means, saving sequence no. as soon as NODE receives message, on flash could corrupt it after 500 days if it receives 20 messages

#bluetoothmesh

Hi Vikrant, Do you mean "sends" and not "receives"? The local sequence number is updated whenever you send a message. It's the RPL that's updated when you receive a message. Or are you talking about t

#bluetoothmesh

Hi Johan, Thanks for clarification & providing other additional important details. I think, Local sequence no. (for sender) & RPL (for receiver ) both are same for flash in terms of write cycle. Ultim

#bluetoothmesh

Hi Johan, In older version of Bluetooth, only 3 channels are used for advertising. But in Bluetooth 5 we can use data channels for advertising. Can we use data channels as ADV channel by configuring Z

#bluetoothmesh

Hi Vikrant, Agreed, but unfortunately it's not possible with Bluetooth Mesh 1.0. That said, it's possible we'll see a future Mesh specification version that allows taking advantage of Bluetooth 5.0 fe

#bluetoothmesh