For on network provisioning chip-tool is not calling the PersistDeviceList #9550
Comments
|
Can you provide more details about the commands you are running? I'm having trouble reproducing this. |
|
I'm attaching logs from my system. Controller side: Device side: |
|
Is this just the open commissining window command that is failing? If so, it's probably because chip tool generates a new random node id for all pairing commands. Can you confirm whether this is the command you're having problems running? |
It looks like the previous version would generate a random nodeid and then attempt to open the pairing window on that. Issue project-chip#9550 indicates a general failure to send commands after provisioning, but it actually looks like the open pairing window command is the only one affected. Issue speculates that PersistDevice was not called, but confirmed that PersistDevice IS called. However, the data for a randomly generated node id would not be present so the symptoms may match. We also need to connect to the device before sending the open pairing windo command as it is a standard cluster command. Added calls to connect to the device before opening the pairing window. Test: ./chip-tool pairing onnetwork 0 20202021 3840 fc00::a 5540 ./chip-tool onoff on 1 ./chip-tool pairing open-commissioning-window 0 5000 1 3840 ./chip-tool pairing onnetwork 0 20202021 3840 fc00::a 5540 ./chip-tool onoff on 1
|
#9806 - Does this work for what you're trying to do? |
It looks like the previous version would generate a random nodeid and then attempt to open the pairing window on that. Issue #9550 indicates a general failure to send commands after provisioning, but it actually looks like the open pairing window command is the only one affected. Issue speculates that PersistDevice was not called, but confirmed that PersistDevice IS called. However, the data for a randomly generated node id would not be present so the symptoms may match. We also need to connect to the device before sending the open pairing windo command as it is a standard cluster command. Added calls to connect to the device before opening the pairing window. Test: ./chip-tool pairing onnetwork 0 20202021 3840 fc00::a 5540 ./chip-tool onoff on 1 ./chip-tool pairing open-commissioning-window 0 5000 1 3840 ./chip-tool pairing onnetwork 0 20202021 3840 fc00::a 5540 ./chip-tool onoff on 1
|
If you wipe the chip_* files in /tmp, does it work? |
|
SW Dev Bug Review: Closing this, as doesn't appear needed anymore and/or is complete, please reopen if needed. |
|
This issue still persists, I am getting the same error. 2022-11-18 15:06:18 Beeta-67376B PersistentStorage[20157] WARNING Initializing persistent storage from file: /tmp/chip-device-ctrl-storage.json ` |
|
Can you elaborate more on the problem you're having? I'm seeing a couple of errors here, but it doesn't appear to be related to persisting the device list. Can you indicate:
|
|
Yes of course. These logs are from a custom hardware running Linux debian armhf (bullseye). I am following the guide located at https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/python_chip_controller_building.md when I run this command in my python_env with root privileges i get the above mentioned error. What I expect is running Thanks. |
|
I'm still not totally sure what the setup is here. The logs look like they're coming from the python code (chip-device-ctrl), which is the controller side. Is that what's running on the custom hardware? Or do you have a device application running there and these are the host side logs? Either way, you've hit a documentation bug - chip-device-ctrl is deprecated. PR up here to add a documentation warning: #23724. If you want to use a python-based controller tool, matter-repl is the one that's currently being maintained. The other option is chip-tool, which is what is mostly used by the certification group. Can you specify:
If you're a CSA member, I would also suggest getting onto the slack. |
|
Yes the logs are coming from the python code. I tried to follow the documentation and I noticed that chip-repl has replaced chip-device-ctrl but I needed the device to act as a commissioner and there were some features in chip-repl which as of now do not exist in chip-repl. In any case I had a problem with MDNS, as the logs show.
Thank you. |
|
Which features do you need that are not available in chip-repl? Commissioning is definitely supported. When you start the repl, an object called devCtrl is created. You can call a number of different commissioning options there. The code offers commissioning helpers at several granularities. For the most part, if you're just looking to commission a device, you would just call either CommissionWifi or CommissionWithCode, depending on what you wanted to do. To do the equivalent using chip-tool (C++ tool): If you're simulating a matter device, you're talking about the server side (mostly). The commissioner/controller is the client side. You won't be able to test any of the actual commissioning code without an end device. Both the repl and chip-tool will fail out saying they can't find the device, so you're not going to be testing much. If you're using linux, you can run a simulated device on the same system as the commissioner. Most people use either the all-cluster or lighting example for basic testing. You can build that either using the scripts/build/build_examples.py script, or just using ninja directly. If you run that in a separate terminal, you can commission between them. The caveat here is that you will NOT be using BLE commissioning - you will be using on-network commissioning. If you want to test BLE, you need a separate BLE-capable device. |
|
Thanks for the comprehensive answer. Now logically i have a clear idea about my test scenario. However the issue that i originally had persists. I followed the python guide on building python_env for testing, when i try to run
and If i run the Now according to your suggestions I can just use chip-repl instead of chip-device-ctrl ... i get that but it would be nice to either change the guide or fix the issues with the chip-device-ctrl code. |
|
Update: I build the 'chip-all-clusters-app' on my Macbook (intel) and i am running the executable. It is advertising on the local network. I also compiled the chip-tool for my arm device and try to commission over WIFI the chip-all-clusters-app . When i run and finally the last log i receive from the chip-tool is this: P.S: the chip-repl tool gives me no CommissionableNode (empty arrary) when i run |
|
The guide has been updated to indicate that chip-device-ctrl is deprecated. Can you post the logs from both sides, and indicate how you determined that all-clusters was advertising? |
|
Yes. After a system shutdown, I tried the chip-all-clusters project again and now I am able to see the listed device in the output of the The output of chip-all-clusters-app running on my Macbook. [1669303867834] [6383:43091] CHIP: [DL] KVS will be written to: file:///tmp/chip_kvs and the output of the [1669303884.439016][6781:6781] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs Update: Chip-tool pairing works. :) and I was able to send an onoff toggle command to the (chip-all-cluster) app. Thank you for the help. Only issue is the time out error with the discovery command of the chip-tool. The last line of the above mentioned Console log. |
|
Good to hear. If you check the logs, it looks like the discover command was able to find things. Not sure why it's giving a timeout at the end, but if you're able to commission then the commissioner and device are both fine. |
Pair devices via IP. Specifically the KNX device. It has a control address of "1/1/1". I don't know how to put it together. Please guide me |
When chip tool is used with on network provisioning, its not calling the PersistDeviceList . So after pairing is complete, Device can not be controlled, since it fails retrieving the PariedDeviceList from the storage.
The text was updated successfully, but these errors were encountered: