Closed KcLeung514 closed 2 years ago
Hi, I am unable to reproduce this issue? is this something you see happening intermittently?
Closing due to inactivity. Feel free to open if the problem persists.
Finally, I found out that the problem was caused by my usages. Sorry for that.
I created 2 BleManager
instances.
In order to handle the callback, they have their own MeshManagerApi
instances.
Let's say "meshManagerApi1" and "MeshManagerApi2"
Here is the scene.
meshManagerApi1.startProvisioning(meshNode)
// After provisioning done, align the `MeshNetwork` between "meshManagerApi1" and "MeshManagerApi2".
MeshManagerApi2.loadMeshNetwork()
// Export the mesh network data
MeshManagerApi2.exportMeshNetwork()
And the "App key binding data" is not included in "MeshManagerApi2" 's mesh network data.
========== @roshanrajaratnam
Is that possible to let 2 MeshManagerApi
instances share the same MeshNetwork
instance?
I tried something like below.
String networkJson = "..."
meshManagerApi1.importMeshNetworkJson(networkJson);
meshManagerApi2.loadMeshNetwork();
The meshManagerApi1 and meshManagerApi2 can have the same mesh network data, but mesh network data not aligned after provisioning.
Hi @KcLeung514 that's fine. It's an easy mistake to make.
To answer your question you have to export the network and import it from the other mesh manager instance. How do you manage the callbacks with multiple instances of the mesh network? I hope you are validating against the mesh network UUID?
To answer your question you have to export the network and import it from the other mesh manager instance.
I think this solution can let "meshManagerApi1" and "MeshManagerApi2" have the same mesh network data.
But I think I need to do this again when one of the "meshManagerApi" made any changes in mesh network.
MeshManagerApi#importMeshNetworkJson
involves write DB operations, will it write the same data to the DB again?
How do you manage the callbacks with multiple instances of the mesh network?
MeshManagerApi
instances, so that I can handle the callback separately.MeshManagerApi
manage the same network data
.MeshManagerApi
make changes in the mesh network, the data will be saved under the same mesh UUID.MeshManagerApi
, avoid make changes in the mesh network at the same time.network data
when any MeshManagerApi
make changes in the mesh network.@roshanrajaratnam
Please correct me if I doing something silly...
======
Assume that we have a method "MeshManagerApi#setMeshNetwork".
If we align network data
this way.
meshManagerApi2.setMeshNetwork(meshManagerApi1.meshNetwork)
Is that a workaround?
Well both instances will be using the same database in my opinion and mesh network UUID is used as the primary key in the database so theoretically this should work. Although I have not tested this thoroughly.
First why do you use 2 separate instances to manage the same network data?
Is that a workaround?
The correct way would be to import it as a json, this will validate the network before importing it.
First why do you use 2 separate instances to manage the same network data?
Because I want to manage to 2 bluetooth connection in one mesh network. One for provisioning device, One for send control message to other devices.
I have no idea how to use one MeshManagerApi
instance to manage 2 bluetooth connections.
When I use MeshManagerApi#createMeshPdu
, this method will return several responses through MeshManagerCallbacks#onMeshPduCreated
.
If the application needs to send different message over these connections at the same time, then I will need to call MeshManagerApi#createMeshPdu
2 times.
When I receive several responses from MeshManagerCallbacks#onMeshPduCreated
, I don't know which connection I should use to send data..
On BleManagerGattCallback#isRequiredServiceSupported
, how to know which BluetoothDevice
is currently connecting?
I have no idea how to use one
MeshManagerApi
instance to manage 2 bluetooth connections.
I don't see the need to use two instances of the mesh manager api. Here's a suggestion.
When I use
MeshManagerApi#createMeshPdu
, this method will return several responses throughMeshManagerCallbacks#onMeshPduCreated
. If the application needs to send different message over these connections at the same time, then I will need to callMeshManagerApi#createMeshPdu
2 times. When I receive several responses fromMeshManagerCallbacks#onMeshPduCreated
, I don't know which connection I should use to send data..On
BleManagerGattCallback#isRequiredServiceSupported
, how to know whichBluetoothDevice
is currently connecting?
I understand your issue, ususally there is no principle of BluetoothDevice
or it's MacAddress
in a mesh network eventhough there is a GATT connection. Ideally we should not depend on the MacAddress
because the address can change after a reboot. In addition, you are not communicating directly with a device. You are expecting the proxy to propagate your message based on the Unicast/Group/Label
address
Describe the bug The "App key binding data" of last provisioned node is missing in the exported JSON file. Import this mesh network data to the iOS nrf mesh library, and send mesh message to the model, the library will throw
AccessError.modelNotBoundToAppKey
error.To Reproduce Steps to reproduce the behavior:
Provision one node to the mesh network.
Bind app key to its vendor model (06170000). ( Send "ConfigModelAppBind" ) ( Ref: Log-01 )
Export current mesh network to JSON file. ( Ref: MeshNetwork-FirstExport.json )
Review the exported JSON file, and check the "App key binding data" of first provisioned node. The "App key binding data" is empty now. ( Path=Root > nodes > elements > models > bind )
Provision second node to the mesh network.
Bind app key to its vendor model (06170000). ( Send "ConfigModelAppBind" ) ( See Log-02 )
Export current mesh network to JSON file. ( Ref: MeshNetwork-SecondExport.json )
Review the exported JSON file, and check the "App key binding data" of first provisioned node. The "App key binding data" is filled. ( Path=Root > nodes > elements > models > bind )
Review the exported JSON file, and check the "App key binding data" of second provisioned node. The "App key binding data" is empty now. ( Path=Root > nodes > elements > models > bind )
Expected behavior The "App key binding data" of nodes should not loss in the exported JSON file.
Platform details:
Logs / Screenshots Log-01 - App client send "ConfigModelAppBind" to the first provisioned node, and receive response from that node.
Log-02 - App client send "ConfigModelAppBind" to the second provisioned node, and receive response from that node.
MeshNetwork-FirstExport.json
MeshNetwork-SecondExport.json