Cannot bind app key for one of the model with PYACI Script

[SaSu]

Hello

I am trying to bind app key for one of the models with the help of PYACI Python script. I am using latest version v5.0.0 for PYACI script and downloaded it here: https://github.com/NordicSemiconductor/nRF5-SDK-for-Mesh , also with same version of documentation for commands https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.meshsdk.v2.1.1%2Fmd_scripts_interactive_pyaci_README.html.  And I am using Raspberry pi where my py script is running and nRF52840 with Serial Script running connected to Raspberry Pi with Ports /dev/ttyACM0 (or) /dev/ttyACM1. I am trying to bind app key for Sensor_Server Example and i get like this where all the earlier commands works well.

NOTE: examples are connected to Laptop which is obvious where we can run with bluetooth

 I also tried with Mesh Chat sample like above and get same problem

Another Question: we can identify the sample with last model ID where vendor Setup Model ID bound to "0059000a" which is 8 bit and where it should be 4 bit. Even in app i get the same ID

which is ok to setup in app but in this command - cc.model_app_bind(db.nodes[0].unicast_address, 0, mt.ModelId(0x1000)) it should have only 4 bit right?

Please help me as soon as possible. I really in need of help to continue my work further

Regards

[Hieu]

Hi Sai,

While getting the PyACI script to work, I ran into the same error.

The cause of the error, for my case, was that the nodes at index 0 (db.nodes[0]) was not the Light Bulb node that I am trying to interact with.
When I determine and use the correct node index, things work as it

should.

Could you please check your database.json and see if the nodes you want to talk with are not at index 0?

If you need help with checking that, you could copy the content of the file into a code block here.

Regards,

Hieu

[SaSu]

Hello

I apologise for my late response. Here is my content and i am trying to provision Sensor Server Example from nordic samples. Still not able to resolve this issue.

Regards

[Hieu]

Just want to let you know that I am still keeping your questions on my backlog. I tried to look into this today, but I haven't found anything regarding logging more information from scanning yet.

I will try to look into it further in the next two days.

Regards,

Hieu

[SaSu]

No problem if i dont get much information about scanning yet. for first Atleast can u please make sure "mesh chat" example works when we provision with PYACI script

Regards

[Hieu]

I have tested the Mesh Chat sample in another DevZone question 1-2 weeks ago and it worked just fine. The nodes can talk to each other correctly. Do you expect them to speak to each other or to the PyACI script?

Regards,

Hieu

[SaSu]

I expect to speak each other not to PyACI script, but as i told you there is problems to index numbers for me can u explain me in detail how to provision them with commands here please

Just curious is there a way they can speak to PyACI too?

Regards

[Hieu]

I was not able to reproduce the index problem. I will try again today, but I'd like to answer quickly about the PyACI part. I doubt that the PyACI script is able to speak to the Mesh Chat devices out of the box. To talk with the Mesh Chat devices, a device needs the Mesh Chat vendor model, which the script doesn't have.

You can consider building that model yourself.

I will try to get to the index problem again in the afternoon. So far that has been very weird. I have a theory that maybe the index value expected is not the index in the node database but the index in the list of devices scanned/currently found...

In your earlier report, I understand that the second device needs index == 0, but what about the first one? Does it also work with index == 0?

[SaSu]

Hieu said:

In your earlier report, I understand that the second device needs index == 0, but what about the first one? Does it also work with index == 0?

Yes first one also works with index==0 but i could not complete the provisioning process as i have problem in publication step, command number: 26.

Regards

[Hieu]

I still cannot reproduce the problem where the second node provisioned need to use index 0 to work.

I am wondering if you are using the correct parameters with publish_set() part...

Could you please post the full log of your attempt, in text form. In addition to the normal steps, each time before you call model_app_bind(), please also you run the following:

len(db.nodes)
db.nodes[0]
db.nodes[1]

Remember to redact the device key from the output of db.nodes[x].

---

I checked the printing scanned device address topic. This is currently not possible, because the serial firmware on the interface device does not send this information back to the script. See: Serial Event Details > Prov Unprovisioned Received.

If this is very important, I think you can look into the Serial example and see if you can update both the device firmware and the PyACI script to send, receive, and parse the advertising name in the Unprovisioned Received event.

---

SaSu said:

but i could not complete the provisioning process as i have problem in publication step, command number: 26.

The publication step is a part of the configuration, not the provisioning. I suspect this might have the same root cause as the index mix up. 

[SaSu]

Can you help me with the model id how to use 8 digit to 4 digit id:

Hieu said:

I suspect this might have the same root cause as the index mix up. 

yes i also have the same idea

[Hieu]

SaSu said:

Can you help me with the model id how to use 8 digit to 4 digit id:

Look at the ModelId class __init__ method, you can see that it accepts both the model_id and the company_id.

The company_id is relevant and should not be left default for the case of Vendor Models, and the Chat Model is one. Thus, instead of calling mt.ModelId() with the full four-byte ID, please call it with the two-byte Model ID and then the two-byte Company ID.

[SaSu]

Hieu said:

The company_id is relevant and should not be left default for the case of Vendor Models, and the Chat Model is one. Thus, instead of calling mt.ModelId() with the full four-byte ID, please call it with the two-byte Model ID and then the two-byte Company ID.

still says invalid model

{
  "$schema": "",
  "appKeys": [
    {
      "boundNetKey": 0,
      "index": 0,
      "key": "REDACTED",
      "name": "lights"
    },
    {
      "boundNetKey": 0,
      "index": 1,
      "key": "REDACTED",
      "name": "locks"
    }
  ],
  "groups": [
    {
      "address": 49153,
      "name": "Room 1",
      "parentAddress": 0
    },
    {
      "address": 49154,
      "name": "Room 2",
      "parentAddress": 0
    }
  ],
  "ivIndex": 0,
  "ivUpdate": 0,
  "meshName": "BT Mesh",
  "meshUUID": "01020304050607080102030405060708",
  "netKeys": [
    {
      "index": 0,
      "key": "REDACTED",
      "minSecurity": "low",
      "name": "root",
      "phase": 0
    }
  ],
  "nodes": [
    {
      "UUID": "7faea34d1484433380515cb2eb7b8ccc",
      "appKeys": [
        0
      ],
      "cid": "0059",
      "configComplete": false,
      "crpl": 10,
      "deviceKey": "REDACTED",
      "elements": [
        {
          "index": 0,
          "location": "0001",
          "models": [
            {
              "modelId": "0000"
            },
            {
              "modelId": "0002"
            },
            {
              "modelId": "0059000a"
            }
          ]
        }
      ],
      "features": {
        "friend": 0,
        "lowPower": 2,
        "proxy": 0,
        "relay": 0
      },
      "name": "chat",
      "netKeys": [
        0
      ],
      "pid": "0000",
      "security": "low",
      "unicastAddress": 16,
      "vid": "0000"
    }
  ],
  "provisioners": [
    {
      "UUID": "00000000000000000000000000000000",
      "allocatedGroupRange": [
        {
          "highAddress": 65279,
          "lowAddress": 49152
        }
      ],
      "allocatedUnicastRange": [
        {
          "highAddress": 32767,
          "lowAddress": 16
        }
      ],
      "name": "BT Mesh Provisioner"
    }
  ],
  "timestamp": "2023-04-04 18:29:38.250859"
}