nRF Mesh android app mesh network import issues

RE: nRF Mesh android app mesh network import issues

Amanda Hsieh — Fri, 21 Nov 2025 15:39:22 GMT

Hi,

We need to test this. Ideally, step 8 should not set the address to 0006; it should be 0001 as it was before.

-Amanda H.

RE: nRF Mesh android app mesh network import issues

Steve Butler — Mon, 17 Nov 2025 08:02:03 GMT

A solution is to use a unique Provisioner on each phone.

I'm not even looking at multiple phones at the moment, though that is the end goal. I'm currently just wanting to switch between different mesh networks whilst on the same phone.

This should be sufficient, given they changed to a new address, which was never* used.

The steps I take (all on the same phone) are below:

1. create new mesh network mn1 (provisioner has unicast addr. 0x0001)

2. provision device in mn1 (device elements have unicast addr's 0x0002 -> 0x0005)

(mesh messages can be successfully sent at this point)

3. export mn1 to remote db

4. create new mesh network mn2 (provisioner has unicast addr. 0x0001)

5. export mn2 to remote db

6. re-import mn1 from remote json (provisioner unicast set to nex available addr, 0x0006)

(again, mesh messages can be successfully sent as the unicast address is changed and never used before)

7. re-import mn2 (provisioner addr stays as 0x0001 as there's no provisioned nodes)

8. re-import mn1 (provisioner unicast set to next available addr, 0x0006)

(unable to send mesh messages, until I change unicast address to 0x0007. I'm assuming this is because 0x0006 has been used previously?)

Now I could just ensure that every time I switch networks I set the provisioner to a previously unused unicast address. But doing this would limit the number of times I could switch between networks?

RE: nRF Mesh android app mesh network import issues

Amanda Hsieh — Fri, 07 Nov 2025 14:55:07 GMT

Hi,

Each Element, identified by a Unicast Address, in a mesh network must always use a higher Sequence Number then was used previously from the same address (those are stored in the Reply Protection List on Relay Nodes and nodes that processed each message from that Element).

This "last Sequence Number" isn't stored in JSON, and it is not exported, as it changes too quickly. It is, however, stored locally on the phone, so after the app is restarted, the last Seq Num is loaded. When you export/import a mesh network on a phone that doesn't have this Sequence Number stored for this given Unicast Address, such a node would start sending messages with Seq Num = 0. They are discarded on all other nodes until they are greater than what they knew before. This is expected behavior.

A solution is to use a unique Provisioner on each phone. Before exporting user shall create a new Provisioner in nRF Mesh / Settings / Provisioners, assign it a unique Unicast Address and range of addresses for unicast addresses, groups, and scenes, and only then export the network. On the other phone, which imports the network, you will be asked to select which Provisioner instance shall be assigned to that phone. You need to select the new Provisioner from which address no message has yet been sent. The 2nd phone is free to transmit messages with Seq Num = 0, other nodes will add this source address to their RPL.

It is also possible to export mesh network config with a subset of nodes, and a subset of Provisioners. I.e. user can select only the 2nd Provisioner to be exported. The 2nd phone, upon import, will simply assign that Provisioner instance to itself, as there's no other choice. Such "partial" export prevents this new phone to send a Config message to the 1st phone, i.e., a Config Node Reset (which requires the Device Key of the 1st Provisioner's Node).

[quote user=""]Why does changing the unicast address of the provisioner not work? Am I missing something?[/quote]

This should be sufficient, given they changed to a new address, which was never* used.

*-never expires when the IV Index changes high enough that it can be reused.

Regards,
Amanda H.