This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Commission Matter accessory using the Android CHIPTool and then control it with the Python CHIP controller, and vice versa

Hi,

I have been trying out the Matter samples as shown in this webinar. I have been following the instructions for version 1.7.0 of the SDK, specifically the ones in Configuring Matter development environment. In turn, the instructions pointed me to Thread border router, Working with Python CHIP controller, and Commissioning nRF Connect Accessory using Android CHIPTool.

After configuring the Thread Border Router using a Raspberry Pi and building the software for the radio co-processor, downloading the pre-built Python CHIP controller from GitHub, and installing the Android CHIPTool, I tried to follow the instructions in Using Python CHIP Controller for Matter accessory testing. I have managed to commission the Matter Accessory to the Thread network and toggle the LED on the device using the Python controller. However, I can only get the tool to work if I set the Node ID to 1. Furthermore, even though I have checked that the Fabric ID is (in this case) 1 using get-fabricid, I still need to use the hard-coded Fabric ID (5544332211) to Discover IPv6 address of the Matter accessory.

Once I have commissioned the accessory, I cannot discover it again using the known Fabric and Node ID values with the Android CHIPTool. That is, if I did the commissioning with the Python CHIP controller, I cannot use the Android tool to send CHIP commands as shown in these instructions. My first question: is this problem related to the issue mentioned in the known issues document (KRKNWK-11225: Android CHIPTool cannot communicate with a Matter device after the device reboots)?

Conversely, I have successfully commissioned and controlled the Matter accessory using the Android CHIPTool, but I cannot then use the Python CHIP controller to discover the IPv6 address of the accessory (even though I know the Fabric and Node IDs), and therefore, cannot control the accessory using the Python controller.

For reference, I have made sure to use the same version of the SDK (1.7.0) when building the Matter sample and the software for the OpenThread Border Router, the Python CHIP controller, and have used the specific version of the radio co-processor per the instructions in Installing OTBR manually (Raspberry Pi).

My second question: am I missing some steps in order to commission the Matter accessory with the Android CHIPTool, and then control it with the Python CHIP controller, and vice versa?

I will appreciate any information you can provide.

  • Hi David,

    I am sorry for the very late reply, but I am looking into this now, so will give you an answer as soon as possible.

    Best regards,

    Marjeris

  • Hi David,

    I am very sorry I haven't been able to provide answers to your questions yet. I have forwarded your questions to our Matter team since I am quite new at working in the Matter enviroment myself so hasn't been able to find out how the Android CHIP tool is support to work yet.. Just let me know if you have any progress in the issue or if you have other questions.

    Best regards,

    Marjeris

  • Hi Marjeris,

    Thank you very much. I haven't made any progress, but I have another question related to what I already mentioned: is the Fabric ID currently hard-coded? In the original question, I mentioned that I only got the demo to work using Node ID = 1 and Fabric ID = 5544332211. I have now confirmed that I can use other Node ID values when issuing the chip-device-ctrl > connect -ble 3840 20202021 1234 command (so I can set Node ID to 1234, for example). If I commission the device, and before closing the BLE connection, I check the Fabric ID using chip-device-ctrl > get-fabricid I get that Fabric ID is the same as the Node ID (1234). But if I try to resolve the IPv6 address of the Matter accessory using chip-device-ctrl > resolve 1234 1234, I get the following error:

    [1638878394.396620][72617:72625] CHIP:DL: Avahi resolve failed
    [1638878394.396646][72617:72625] CHIP:DIS: Node ID resolved failed with ../../src/platform/Linux/MdnsImpl.cpp:666: CHIP Error 0x000000AC: Internal error
    [1638878394.396652][72617:72625] CHIP:CTL: Error resolving node id: ../../src/platform/Linux/MdnsImpl.cpp:666: CHIP Error 0x000000AC: Internal error
    Failed to update node address: 172
    Exception ignored on calling ctypes callback function: <function ChipDeviceController.__init__.<locals>.HandleAddressUpdateComplete at 0x7fa1342441f0>
    Traceback (most recent call last):
    File "/ncs/modules/lib/matter/out/python_env/lib/python3.8/site-packages/chip/ChipDeviceCtrl.py", line 114, in HandleAddressUpdateComplete
    self.state = DCState.IDLEHandleCommissioningComplete
    File "/usr/lib/python3.8/enum.py", line 384, in __getattr__
    raise AttributeError(name) from None
    AttributeError: IDLEHandleCommissioningComplete

    If I try it all over again but use chip-device-ctrl > resolve 5544332211 1234, then the Node ID will be resolved and I'll be able to control the accessory. So again, my question: is the Fabric ID hard-coded? And if it is, where in the code can I see this?

  • Hi David,

    I will need come back to you for the new questions, but I found out why you were having problems when commissioning with the python chip controller and android chip controller:

    That is, if I did the commissioning with the Python CHIP controller, I cannot use the Android tool to send CHIP commands as shown in these instructions.

    The problem here is that you can't commission a device using one controller and control it using another at the present moment. Devices must belong to the same fabric to be able to communicate with each other and having the same fabric ID is not enough to say that they belong to the same fabric - the devices should also have the same root of trust. In the future, controllers will be able to communicate with an external service that provides the root of trust, but currently each controller application creates its own root of trust to ease testing. But the drawback is that using multiple controllers in the same fabric is not supported.

    Regarding the fabric ID question and 5544332211 constant, it is no longer needed in the current NCS master. Currently, the "resolve" command just takes node ID and fabric ID is retrieved automatically. It was just a limitation in thje past versions that 5544332211 had to be used for DNS service discovery.

  • Hi Marjeris,

    Thank you very much! I'll try out a newer version of NCS. Could you confirm which specific commit from master has been tested so I make sure to build and run that version?

Related