Beware that this post is related to an SDK in maintenance mode
More Info: Consider nRF Connect SDK for new designs
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

Matter Examples Communication

Hi,

im testing the Matter template example from Framework 1.8, with the prebuild chip-device-ctrl from github releases.

After provisioning the device as described in https://developer.nordicsemi.com/nRF_Connect_SDK/doc/1.8.0/matter/python_chip_controller_building.html#using-python-chip-controller-for-matter-accessory-testing everything works fine until either side is restarted.

After restarting the device and sending a command to a cluster the device logs:

E: 7268 [IN]Data received on an unknown connection (2). Dropping it!!
E: 7274 [EM]Error receiving message from UDP:[2001:<public IPv6>]:41737: Error CHIP:0x0000007F

After restarting the python controller it cant resolve the device ip:

chip-device-ctrl > resolve 1234                         
[1643805666.978146][526278:526283] CHIP:DL: Avahi resolve failed
[1643805666.978178][526278:526283] CHIP:DIS: Node ID resolved failed with ../../src/platform/Linux/DnssdImpl.cpp:692: CHIP Error 0x000000AC: Internal error
[1643805666.978190][526278:526283] CHIP:CTL: Error resolving node id: ../../src/platform/Linux/DnssdImpl.cpp:692: CHIP Error 0x000000AC: Internal error
Failed to update node address: 172

Parents
  • i have looked into this a little more and discovered that the Device is advertising a different name than what chip-device-ctrl is looking for.

    The python controller seems to generate a new fabric on every start.

    Is the fabric not saved?

  • Hi Jannis,

    Python CHIP Controller doesn't save the fabric, so if it's restarted, all the information about fabric ID and sessions is lost. On the other hand, if the accessory is restarted, then only the current session is lost and the device will ignore all messages from the controller. There should be some logic in place for recovery in such a situation, but it's not yet implemented. The workaround is to use close-session and resolve 1234 commands in the Python CHIP Controller to manually drop and re-establish the lost session on the controller side.

    Best regards,

    Charlie

Reply
  • Hi Jannis,

    Python CHIP Controller doesn't save the fabric, so if it's restarted, all the information about fabric ID and sessions is lost. On the other hand, if the accessory is restarted, then only the current session is lost and the device will ignore all messages from the controller. There should be some logic in place for recovery in such a situation, but it's not yet implemented. The workaround is to use close-session and resolve 1234 commands in the Python CHIP Controller to manually drop and re-establish the lost session on the controller side.

    Best regards,

    Charlie

Children
No Data
Related