Bluetooth Mesh JSON

[EAn]

Greetings to all,

I'm using nRF52840 with the latests SDKs (nRF5 SDK 15.3.0, mesh SDK 3.2.0). I have two questions which are related-

I'm trying to find a clever way of storing all the provisioning data in flash and be able to export it to a JSON file that could be used to reconfigure a provisioner in case of malfunction of another.

Question 1: Is there a recommended way of storying the provisioned network data in flash and export it? I want to use one of the nodes solely with a nRF52840 to serve as a client to some mesh-models  and as a provisioner. Therefore, this should be a solution contained within the firmware using the Nordic SDKs and any external libraries that may be required.

I was inspecting the JSON file created (by version 2.0.5 of the nRFMesh App for Android) when one exports the Network Settings. There are a few fields I can't understand what they are. I have highlighted them in bold.

Question 2: Could someone please explain to me what are the meaning of the fields I highlighted in bold?

In the netKeys section:

 "netKeys": [
    {
      "name": "Network Key 1",
      "index": 0,
      "key": "5992E9C7DEE2334BA76BDD2B14FF5A3D",
      "phase": 0,
      "minSecurity": "high",
      "timestamp": "1970-01-01T01:00:00+0100"
    }
  ]

What are the "phase" and "minSecurity" fields for?

Here is the case for one of the nodes:

 {
      "UUID": "C4FB244B3D5CE042A124D63E0627A21A",
      "name": "nRF5x Mesh Light",
      "deviceKey": "5AAF66D1CE7EBF395EC26214B80FE4B4",
      "unicastAddress": "0002",
      "security": "low",
      "configComplete": false,
      "cid": "0059",
      "pid": "0000",
      "vid": "0000",
      "crpl": "0028",
      "features": {
        "friend": 2,
        "lowPower": 2,
        "proxy": 1,
        "relay": 1
      },  
      "defaultTTL": 4,
      "networkTransmit": {
        "count": 2,
        "interval": 1
      },
      "netKeys": [
        {
          "index": 0,
          "updated": false
        }
      ],
      "appKeys": [
        {
          "index": 0,
          "updated": false
        }
      ],
      "elements": [
        {
          "name": "Element: 0x0002",
          "index": 0,
          "location": "0000",
          "models": [
            {
              "modelId": "0000",
              "bind": [],
              "subscribe": []
            },
            {
              "modelId": "0002",
              "bind": [],
              "subscribe": []
            },
            {
              "modelId": "1000",
              "bind": [
                0
              ],
              "subscribe": [],
              "publish": {
                "address": "FFFF",
                "index": 0,
                "ttl": 1,
                "period": 2560,
                "retransmit": {
                  "count": 1,
                  "interval": 1
                },
                "credentials": 0
              }
            }
          ]
        }
      ],
      "blacklisted": false
    }

What are the "cid", "pid", "vid", "crpl", location, bind, updated and credentials fields?

Also in the groups section, what is the parentAddress?

  "groups": [
    {
      "name": "DemoDevices",
      "address": "C000",
      "parentAddress": "0000"
    }

Thank you very much for your assistance!

Best regards,

//E

[tesc]

Hi,

Provisioning data is already stored in flash for nRF provisioners, see e.g. the light switch provisioner. You can implement functionality on the nRF to export to (and import from) the JSON format used by the nRF Mesh apps. I have asked internally if we have a specification, and you should expect an answer within a couple of days.

Regards,
Terje

[EAn]

Thank you for your prompt reply.

I know the data is stored in flash via the DSM in the light switch provisioner. I was asking in terms of portability of that data. Thanks for the information in any case ;)

"You can implement functionality on the nRF to export to (and import from) the JSON format used by the nRF Mesh apps." > That would be great to do. Any good pointer will be very helpful. Specially if there is a best practice already exemplified.

Thank you.

[tesc]

Hi,

I am afraid there will not be a specification for quite some time yet, but the resemblance to the Bluetooth mesh specification should (hopefully) be enough to understand what the various fields mean. I am sorry for the inconvenience.

Regards,
Terje