The recommended steps for import/export using the mobile app is as follows. I hope you are following the same steps. Please check it once.
Mesh database JSON export/Import
Cypress Mesh Controller framework stores mesh network information in .json file format specified by SIG MESH WG
1> During Provisioning Android Mesh Controller stores the database in application's internal memory
2> To exercise usecase such as control of mesh devices using multiple phones follow the below steps
a> After creating a network and provisioning few devices on phone P1use the option "export network" in the settings of home screen to export the required meshdb.
b> Cypress mesh lighting app stores the exported Meshdb in "/sdcard/exports" directory.
c> A user can now move the exported file to another phone (Say phone P2)
d> Install MeshLighting app on P2. Use the "import network" option avaible in the settings menu of main screen.
e> The user can now control the mesh devices using P2 .
From your description, I understand that, you have used Mobile_1 to provision x number of nodes and exported its database. Imported it to 3 other mobile device (mobile_2, Mobile3, Mobile4) by manually copying the JSON file. But only mobile_2 could control the mesh network. Other nodes connects to the network but failed to control the nodes. But Please confirm if my understanding is right.
I will try to check whether the import/export options show any irregular behavior or not.
But, I would like to take a look at the Android Debug (ADB) logs and Mesh DBs (.JSON) collected from the mobile devices which you have used.
"node connected but not working" -> One scenario which I can think about this is, the provisioner connects to the proxy mesh node correctly. But the messages is getting ignored by the nodes due to some mismatch in the message sequence number.
Please don't hesitate to ask us any quires/doubts that you get during your development. It would be great if you can attach the debug info/logs along with your query, if available (Especially for unique user scenarios).
Its our pleasure answer the your queries/Doubs, and provide you a robust Bluetooth mesh product.
Yes, I have followed the same procedure and your understanding is absolutely correct. Same Mesh DBs (.JSON) file exported from original device and imported to three android devices, where one device could control the nodes and other 2 devices could not control even though connected to the network.
I will collect the debug logs and get back to you.
Original device Lenovo tab's network file .JSON attached.
Please note this network file is shared with other android device Mobile1, Mobile2 and Mobile 3 via USB storage.
Mobile 1 - Connected to the network but could not able to control
- REALME 7 android version 10
- attached network file export and debug log.
Mobile 2 - Connected to the network, initially it was not able to control but yes after a period of two to three minutes or may be after connecting to debugger
- NOKIA android version 10
- attached debug log
Mobile 3 - Connected to the network and working
- Iphone 6S
Also, I've observed one thing but sometime (don't have pattern to re-simulate this thing),
- Device 1 configured first, coping network file from the original device and works fine
- Device 2 configured second, coping network file from the original device and does not work. It works after coping network file from Device 1
In my testing, general mesh DB import/export features are working fine.
We may need to check whether the issue is related to some particular android mobile device or android version.
Let us do some more testing on the issue and we will get back you.
"- Device 1 configured first, coping network file from the original device and works fine
- Device 2 configured second, coping network file from the original device and does not work. It works after coping network file from Device 1"
The above observation is an expected behavior. Here is why: -
Each provisioner add an entry (UUID) in the database, and gets an unicastaddress (e.g. 0001, 0101, 0201, etc.). The initial provisioner (prov_1) gets a unicastAddress = 0001. When this database is imported to two different provisioners (prov_2, prov_3), both gets the same unicastAddress = 0101. This creates a problem. Each packet in mesh is labeled with a source address (SRC) and a sequence number (SEQ). When a mesh node receives messages from a particular source (e.g. 0101) with different SEQ numbers, then only the latest (higher) sequence numbered message will be accepted, other messages will be discarded. This is the protection against replay attack. So prov_2 and prov_3 may not be able to communicate with the mesh network nodes properly (since SRC is same and SEQ is changed by each devices locally).
To tackle this, when multiple provisioners are configured in a network, we have to ensure that, at any moment, all the provisioners use the same and latest mesh database. It is recommend to keep the mesh database in a cloud and sync the changes. Upload the database file to the cloud whenever it is changed. Every provisioner needs to download the file as soon as the file is changed and never do changes to the old instance.
In your situation, for temporary testing, the third provisioner should be created by importing the latest database from the second provisioner, then things will work fine till the database is modified again (e.g. Due to add / remove a node, etc.).
What is the solution for the issue "connected to the network, initially it was not able to control but yes after a period of two to three minutes". This happened in the original device as well though no modification done later.
Please tell me one more thing, If I provision the nodes with original provisioner and import to provisioner prov_1, then export from prov_1 and import to prov_2 and so on. Will this approach works?. If this procedure works, then I can add / remove the node in the original provisioner and repeat the import process again to other provisioner as stated above.
Why didn't your team mention this key issue when using multi provisioner in the Cypress documents?
Please help me for the following queries too.
1. This network import problem 1<->2 then 2<-> 3 does not come up all the time, even two or three additional provisioner works with network import from original device, why?
2. There is no network import problem as stated above for IOS app, why?
3. How other vendor manage multi provisioner issue without cloud?
4. Why could we not have option to change unicast address manually in application?
5. Is there SDK / procedure to sync with cloud?
->"connected to the network, initially it was not able to control but yes after a period of two to three minutes"
This happens to the initial device only when you use multiple provisioners?
Is it reproducible with a single provisioner? Or when exactly the original device stuck at this issue?
I believe, you could control the network, not because you have waited 2-3 min. It's because you have done some operations (on/off etc.) to send messages during the initial minutes, which eventually increment the message sequence number. When the sequence number reached to a valid one, the device accepts the messages. Please make sure the original device did not overwritten the database.
->Will this approach works?
Yes. This should works ideally.
But, you can add nodes from any provisioners. The ultimate aim should be synchronize the database in use among all provisioners.
The 1st provision who created the network gets address 1. Then we exports the network, and json file is delivered to the 2nd provisioner. The 2nd provisioner opens database, does not find entry for his UUID and creates 2nd provisioner. It gets address 0x101. If the 3rd provisioner receives the same file as 2nd provisioner, It will open the file (without info about 2nd), and get himself 0x101 again. If 3rd provisioner receives the file with info about 2nd provisioner, it will assign himself address 0x201 and everything will work correctly.
->Why didn't your team mention this key issue when using multi provisioner in the Cypress documents?
I accept that this should be mentioned in our documents. But at the same time, my personal opinion is that the mesh DB can be managed manually, only when the number of provisioners are less than a cetain limit. The complexity increases when number of provisioners increases. It is not practical to export and match/check the DB of each provisioner manually.
So, an automated process and cloud synchronization is the best solution to maintain multiple provisioners DBs.
1. The issue may be happening due to same SRC address and different sequence number.
This could be the possible cause. When this condition occurs the network behaves strangely.
2. Ideally the same issue should happen for the IOS as well. But, the import/export logic behind the Android/IOS app could be different. Some of the differences are due to OS constraints. We always try to keep both apps same in functional part. I will inform this to the dev team to check this.
3. I am not aware about it.
Mesh spec does not define the management of mesh database. Keeping the DB in JSON will be useful for using protocols such as REST.
4. The local device address is assigned by the provisioner during provisioning.
5. We don't have examples of any specific cloud solution. Because the mesh solution which we provide should be flexible. Developer/customers can choose their own cloud infrastructure as per their requirement and integrate with the peer app.
1 of 1 people found this helpful
Thank you for your support and useful advice.