The 'chip-tool-web' is a web-based graphical user interface (GUI) for the Matter controller, designed specifically for i.MX SoC customers. It provides an intuitive interface for commissioning Matter devices, sending Matter messages and performing other Matter-specific actions.
With the chip-tool-web, you can easily configure, manage and monitor Matter devices without the need to use complex command lines.
- Source files
- Building and running the chip-tool-web
- Using chip-tool-web to commission a Matter device
- Controlling a Matter device OnOff cluster
- Opening the commissioning window for the commissioned Matter device
- Subscribing a Matter device OnOff cluster
- Getting status for a commmissioned Matter device
- Binding for light and switch Matter device
- Controlling a Matter device mediaplayback cluster
- Controlling a Matter device Energy EVSE Cluster
- Additional Notes
You can find the source files for the chip-tool-web in the ${matter}/examples/chip-tool/webui directory, which are separated into frontend and backend components. This allows easy customization and modification based on specific requirements and use cases.
Before using the chip-tool-web, you must compile it from source on Linux (armv71/aarch64) or macOS.
Note: To ensure compatibility, you should always build the chip-tool-web from the same revision of the
connectedhomeiprepository.
The steps to compile the chip-tool-web are the same as How to build Matter application
After compilation, you will find two binaries, chip-tool and chip-tool-web, in the ${matter}/out/chip-tool-web/ folder. However, please note that the chip-tool binary in this folder may not work as expected. Therefore, it is recommended not to use the chip-tool binary located in the out/chip-tool-web directory.
Before using chip-tool-web, make sure that the i.MX board is properly connected to the Internet.
The image built by meta-nxp-connectivity includes the chip-tool binary in the i.MX SOC /usr/bin directory, and all frontend files are already copied to /usr/share/chip-tool-web/. Therefore, to use chip-tool-web, you only need to copy the newly compiled chip-tool-web binary to the /usr/bin directory.
If you want to specify a custom location for the frontend files, you can follow these steps:
- Copy the
frontendfile to the desired location:$ cp ${matter}/examples/chip-tool/webui/frontend $frontend_path - Export the
CHIP_TOOL_WEB_FRONTENDvariable and set it to the path of the frontend files:$ export CHIP_TOOL_WEB_FRONTEND=$frontend_path - If you want to make this variable persistent across sessions, add the above command to your shell configuration file (e.g.,
~/.bashrc).
After completing the setup, run the following command to verify that chip-tool-web is working properly:
$ chip-tool-web
If you see the following log: CHIP:DL: CHIP task running, everything is working fine.
The chip-tool-web can run on a variety of devices, including desktops, laptops, and mobile devices. To access the chip-tool-web, follow these steps:
- Open a web browser (such as Chrome, IE, Safari, etc.) on the device you want to use.
- Enter the IP address of the i.MX board followed by
:8889in the address bar of the browser. You can find the IP address of the i.MX board by running theifconfigcommand on the board. - You will see the
chip-tool-webhome page. Follow the instructions in the section to proceed.
Here is an example of opening chip-tool-web on an Apple mobile phone using Safari:
Note: The network connected to the running device must be on the same segment as the i.MX device.
This section provides instructions for using chip-tool-web to commission Matter devices, with a focus on the chip-lighting-app application clusters on i.MX MPU platforms.
It should be noted that while chip-tool-web provides a graphical user interface (GUI) for executing commands through buttons and other visual controls, it does not completely replace the chip-tool command line tool. Users can still use the chip-tool command line tool if they prefer or need to, but chip-tool-web provides an additional option for interacting with Matter devices. The following sections will provide a detailed overview of the features currently available in chip-tool-web.
An official Matter document explaining how to use chip-tool as a Matter controller, can be found here.
For more information on how to use Matter applications on i.MX MPU platforms, see the NXP Matter demos guide.
The chip-tool offers two modes of operation: Single Command Mode and Interactive Mode, each with unique features and appropriate use cases. For detailed information about these modes, please refer to the official documentation available at Interactive mode versus single-command mode.
It should be noted that chip-tool-web uses the Interactive Mode to allow users to conveniently send multiple commands through the web interface and to improve the management of Matter devices.
To access the Pairing feature in chip-tool-web, first open the navigation bar and select Pairing. This will display the following menu interface:
On the pairing page, there are three buttons to select the type of pairing: ONNETWORK, BLE-WIFI, and BLE-THREAD. These buttons allow the user to select the different pairing modes to use. After clicking the appropriate button, the user interface for the selected pairing type will appear.
The remainder of this section provides a detailed overview of each of these pairing methods.
Click on the ONNETWORK pairing type selection button, the display interface will be as shown below.
You should specify a node alias for the node ID so that you can identify it by node alias. If you enter the correct parameters and click the onnetwork button on this interface, the following command will be triggered to discover devices and attempt to pair with the first discovered one using the provided setup code:
$ chip-tool pairing onnetwork-commissioning-mode <node_id> <pin_code>
In this command:
- <node_id> is the user-defined ID of the node being commissioned.
- <pin_code> is device specific setup PIN code determined in the step and used to discover the device.
Click on the BLE-WIFI pairing type selection button, the display interface will be as shown below.
You should specify a node alias for the node ID so that you can identify it by node alias. If you enter the correct parameters and click the BLE-WIFI button on this interface, the following command will be triggered to commission the device to the existing WiFI network:
$ chip-tool pairing ble-wifi <node_id> <ssid> <password> <pin_code> <discriminator>
In this command:
- <node_id> is the user-defined ID of the node being commissioned.
- <ssid> and <password> are credentials determined in the step.
- <pin_code> and <discriminator> are device-specific keys determined in the step.
For example:
chip-tool pairing ble-wifi 1 xyz secret 20202021 3840
If you prefer the hexadecimal format, add hex: prefix when entering ssid, password. For example:
$ chip-tool pairing ble-wifi <node_id> hex:<ssid> hex:<password> <pin_code> <discriminator>
Note: The <node_id> can be provided as a hexadecimal value with the
0xprefix.
Click on the BLE-THREAD pairing type selection button, the display interface will be as shown below.
You should specify a node alias for the node ID so that you can identify it by node alias. If you enter the correct parameters and click the BLE-Thread button on this interface, the following command will be triggered to commission the device to the existing Thread network:
$ chip-tool pairing ble-thread <node_id> hex:<operational_dataset> <pin_code> <discriminator>
In this command:
- <node_id> is the user-defined ID of the node being commissioned.
- <operational_dataset> is the Operational Dataset determined in the step.
- <pin_code> and <discriminator> are device-specific keys determined in the step.
Note: When entering the <operational_dataset>, there is no need to add the
hex:prefix, as this is already added by default in the chip-tool-web backend.
To obtain the Thread network credentials, you can either form the OpenThread network manually by following the instructions provided in the Configure OpenThread Network, or via otbr-web.
Once the network has been formed, you can retrieve the Thread network credentials by clicking the GET-DATASET button in chip-tool-web instead of manually typing the ot-ctl dataset active -x command.
Once the pairing process is complete, the Matter device is successfully commissioned to the network. For the lighting application, the On/Off clusters are implemented in chip-tool-web, allowing you to control the end devices using the onoff cluster commands.
To access the onoff function in the chip-tool-web, first open the navigation bar and select OnOff. The following interface will be displayed:
Commands list supported for the onoff cluster:
+-------------------------------------------------------------------------------------+
| Commands: |
+-------------------------------------------------------------------------------------+
| * off |
| * on |
| * toggle |
| * read |
+-------------------------------------------------------------------------------------+Use the following buttons to control or read the status of the OnOff attribute (e.g. visualized by the LED status):
-
Use the
ONbutton to trigger the following command to turn on the state of the OnOff attribute:$ chip-tool onoff on <node_id> <endpoint_id> -
Use the
TOGGLEbutton to trigger the following command to toggle the state of the OnOff attribute:$ chip-tool onoff toggle <node_id> <endpoint_id> -
Use the
OFFbutton to trigger the following command to turn off the state of the OnOff attribute:$ chip-tool onoff off <node_id> <endpoint_id> -
Use the
READbutton to trigger the following command to read the state of the OnOff attribute state:$ chip-tool onoff read on-off <node_id> <endpoint_id>In above commands:
- <node_id> is the user-defined ID of the commissioned node.
- <endpoint_id> is the ID of the endpoint with OnOff cluster implemented.
The following will introduce the content of READ button in detail.
After clicking the READ button to trigger the corresponding command, a report will later be displayed in the Get Report section of the page. The page does not clear previously generated reports and always displays the latest report at the top of the list.
The report is output in text format with the following structure:
Report from ${nodealias} ${nodeid}:${endpoint}. Cluster:${cluster}
${attribute}:${value}
- ${nodealias}: The node alias of the device.
- ${nodeid}: The nodeid of the device.
- ${endpoint}: The endpoint of the device.
- ${cluster}: The cluster name to which the device belongs.
- ${attribute}: The name of the attribute being reported. In this case, the default attribute is
On-Off. - ${value}: The value of the attribute. There are two possible values:
TRUEorFALSE.TRUEindicates that the light is on, whileFALSEindicates that the light is off.
The following is an example of a multiple read of a device whose nodealias is Light and nodeid and endpoint are both 1.
Multi-admin feature allows you to join Matter device to multiple Matter fabrics and have multiple different Matter administrators administer it. Chip-tool-web supports the Basic Commissioning Method to open the commissioning window of i.MX Matter device for a new administrator from another fabric.
To access the Multi-admin function in the chip-tool-web, first open the navigation bar and select MultiAdmin. The following interface will be displayed:
Select the node alias of the paired Matter device, and the page will automatically fill in the corresponding node ID. Then enter the value of windows timeout and click the OPEN COMMISSIONING WINDOW button to trigger the Open Commissioning window:
$ chip-tool pairing open-commissioning-window <node_id> <option> <window_timeout> <iteration> <discriminator>
In this command:
- <node_id> is the ID of the node that should open commissioning window.
- <option> is equal to
0for Basic Commissioning Method. - <window_timeout> is time in seconds, before the commissioning window closes.
- <iteration> is number of PBKDF iterations to use to derive the PAKE verifier.
- <discriminator> is device specific discriminator determined during commissioning.
Note: The <iteration> and <discriminator> values are ignored because the <option> is set to 0.
You can then commission the Matter device to a new fabric using another instance of the CHIP tool by below cmd or via the onnetwork pairing.
$ chip-tool pairing code <node_id> <payload>
In this command:
- <node_id> is the user-defined ID of the commissioned node.
- <payload> is the the QR code payload or a manual pairing code generated by the first commissioner instance when opened commissioning window. Since you are using the Basic Commissioning Method to open commissioning window, the manual pairing code should be
34970112332.
Subscribing to an attribute lets you mirror the state of the attribute as it changes in the Matter network. Chip-tool-web support for subscribing to the on-off attribute of the onoff cluster.
To access the Subscribe function in the chip-tool-web, first open the navigation bar and select Subscribe. The following interface will be displayed:
Select the node alias of the paired Matter device, and the page will automatically fill in the corresponding node ID. Then enter the value of windows timeout and click the SUBSCRIBE button to trigger the subscribe command:
$ chip-tool onoff subscribe on-off <min-interval> <max-interval> <node_id> <endpoint_id>
In this command:
- <min-interval> specifies the minimum number of seconds that must elapse since the last report for the server to send a new report.
- <max-interval> specifies the number of seconds that must elapse since the last report for the server to send a new report.
- <node-id> is the user-defined ID of the commissioned node.
- <endpoint_id> is the ID of the endpoint where the
onoffcluster is implemented.
The subscribe report with the on-off attribute is updated on Subsribe Status section when it changes. The page does not clear previously generated reports and always displays the latest report at the top of the list.
The following is an example of the subscription statue of a device whose nodealias is Light and whose nodeid and endpoint are both 1.
The report is output in text format with the following structure:
Subscribe Report from ${nodealias} ${nodeid}:${endpoint}. Cluster:${cluster}
${attribute}:${value}
The elements of the subscribe report are the same as those of the OnOff read report.
Note: Because subscribe must maintain the subscription status in interactive mode, please do not enter any other commands in the console of the i.MX Matter devices when the chip-tool-web initiates the subscribe command, as this may interrupt the update of the subscribe report.
Chip-tool-web stores the node ID and node alias of the paired device in the chip_tool_config.web.ini file. If TMPDIR is not set, the chip_tool_config.web.ini file is located in the /tmp/ directory. If export TMPDIR=${tmpfir} is set, it is stored in the ${tmpfir} directory. You can see the node ID and node alias of all paired nodes in GetStatus tab, and you can delete the paired node information on this page so that you will no longer see information about that node in the node alias selection on other tabs.
To access the GetStatus function in the chip-tool-web, first open the navigation bar and select GetStatus. The following interface will be displayed:
Select the node alias of the paired Matter device, and the page will automatically fill in the corresponding node ID. Then click the DELETE-STORAGENODE button to delete the paired node information, then this node will not be displayed in the chip-tool-web front page.
The provisioned nodes is displayed in text format with the following structure:
Node Alias: ${nodealias}
node ID: ${nodeid}
In the structure above:
- ${nodealias}: The node alias of the device.
- ${nodeid}: The nodeid of the device.
Binding describes a relationship between the device that contains the binding cluster and the end device. The chip-tool-web supports binding a light in one light_switch_combo device to the switch in another light_switch_combo device, allowing the light in another device to be controlled by the switch of one device.
To access the Binding function in the chip-tool-web, first open the navigation bar and select Binding. The following interface will be displayed:
First, the light_switch_combo application should run properly on the K32W Matter device, and then use the chip-tool-web ble-thread pairing method to pair with two light_switch_combo devices separately.
Two light-switch_combo devices, one used as the switch device and the other used as the light device. Before binding, the access control list must be written. Therefore, in the Light Node Alias section, select the node alias that you want to use as the light device. In the Switch Node Alias section, select the node alias you want to use as the switch device, and they corresponding node IDs will be filled in automatically. ACL EndPoint ID is recommended to use endpoint 0. Then click the WRITE ACL button to trigger write acl command like below.
chip-tool accesscontrol write acl <acl_data> <node_id> <endpoint_id>
In this command:
- <acl_data> is the ACL data formatted as a JSON array. Here is the
'[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null },{"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": [<Switch Node Id>], "targets": null }]'. - <node_id> is the ID of the node that is going to receive ACL. Here is <Light node ID>..
- <endpoint_id> is the ID of the endpoint on which the
accesscontrolcluster is implemented. 0 means all enpoints.
For more details, you can refer to access control guide.
After trigger the write access list command, you can click the WRITE BINDING button to binding the Light and Switch device, it will trigger the command:
$ ./chip-tool binding write binding <binding_data> <node_id> <endpoint_id>
In this command:
- <binding_data> is the binding data formatted as a JSON array. Here is
[{"fabricIndex": 1, "node": <Light NodeId>, "endpoint": <Light EndPoint ID>, "cluster": 6}]'. - <node_id> is the ID of the node that is going to receive the binding. Here is <Switch node ID>.
- <endpoint_id> is the ID of the endpoint on which the
bindingcluster is implemented. Here is the <Switch EndPoint ID> of the switch device.
After the binding command is successfully executed, press SW2 two times on the device acting as Switch to register the binding entry, and then you can control the light (D3) on the peer device (light device) just by pressing SW2/SW3.
The i.MX Matter supports nxp-media-app from the 2023 q4 release, you can control the media player and read information through the chip-tool-web.
Before controlling media app, you need to place media files in the /home/root/media folder of the nxp-media-app device.
To access the MediaControl function in the chip-tool-web, first open the navigation bar and select MediaControl. The following interface will be displayed:
Select the node alias of the paired Matter nxp-media-app device, and the page will automatically fill in the corresponding node ID. Then enter the Endpoint ID and click the LAUNCH APP or STOP APP button to launch or stop the app by below commands.
$ chip-tool applicationlauncher launch-app <launcher_data> <node_id> <endpoint_id>
$ chip-tool applicationlauncher stop-app <launcher_data> <node_id> <endpoint_id>
In this command:
- <launcher_data> is the Launcher data formatted as a JSON array. Here is the
'{"catalogVendorID": 123, "applicationID": "exampleid"}'. - <node_id> is the ID of the node that is going to receive launcher data.
- <endpoint_id> is the ID of the endpoint on which the
applicationlaunchercluster is implemented.
Use the following buttons in the Media Control section to control the status of the mediaplayback attribute:
-
Use the
PLAYbutton to trigger the following command to change the current media playback state to play:$ chip-tool mediaplayback play <node_id> <endpoint_id> -
Use the
PAUSEbutton to trigger the following command to change the current media playback state to pause:$ chip-tool mediaplayback pause <node_id> <endpoint_id> -
Use the
STOPbutton to trigger the following command to change the current media playback state to stop:$ chip-tool mediaplayback stop <node_id> <endpoint_id> -
Use the
PRIVIOUSbutton to trigger the following command to play privious media:$ chip-tool mediaplayback privious <node_id> <endpoint_id> -
Use the
NEXTbutton to trigger the following command to play next media:$ chip-tool mediaplayback next <node_id> <endpoint_id> -
Use the
START OVERbutton to trigger the following command to start over the media being played:$ chip-tool mediaplayback start-over <node_id> <endpoint_id> -
Use the
REWINDbutton to trigger the following command to rewind the current media, and then you can use thePLAYbutton to play the rewinded media:$ chip-tool mediaplayback rewind <node_id> <endpoint_id> -
Use the
FAST FORWARDbutton to trigger the following command to fast forward the current media:$ chip-tool mediaplayback fast-forward <node_id> <endpoint_id>In above commands:
- <node_id> is the user-defined ID of the commissioned node.
- <endpoint_id> is the ID of the endpoint with
mediaplaybackcluster implemented.
Use the following buttons to read the status of the mediaplayback attribute in the Media Status section. The page and results are shown in the following:
- Use the
CURRENTSTATEbutton to trigger the following command to read the current state of media playback:$ chip-tool mediaplayback read current-state <node_id> <endpoint_id> - Use the
STARTTIMEbutton to trigger the following command to read the start time of the currently playing media:$ chip-tool mediaplayback read start-time <node_id> <endpoint_id> - Use the
DURATIONbutton to trigger the following command to read the duration of the currently playing media:$ chip-tool mediaplayback read duration <node_id> <endpoint_id> - Use the
PLAYBACK SPEEDbutton to trigger the following command to read the playback speed of the currently playing media:$ chip-tool mediaplayback read playback-speed <node_id> <endpoint_id>
In above commands:
- <node_id> is the user-defined ID of the commissioned node.
- <endpoint_id> is the ID of the endpoint with mediaplayback cluster implemented.
The media read report is output in text format with the following structure:
Report from ${nodealias} ${nodeid}:${endpoint}. Cluster:${cluster}
${attribute}:${value}
In the structure above,
- ${nodealias}: The node alias of the device.
- ${nodeid}: The nodeid of the device.
- ${endpoint}: The endpoint of the device.
- ${cluster}: The cluster name to which the device belongs.
- ${attribute}: The name of the attribute being reported. In this case, the default attributes are
CurrentState,StartTime,Duration,PlatbackSpeed. - ${value}: The value of the attribute. There are three possible values for
CurrentState:Play,Pause,Stop. The value of start time always be0. The value ofDurationis currently playing media's duration. There are five possible values forPlatbackSpeed:1.000000,2.000000,4.000000,8.000000,10.000000.
Note: To perform EEVSE control related operations on the chip-tool-web, relevant parameters must be added. For example, run the application with the command "$chip-energy-management-app --enable-key 000102030405060708090a0b0c0d0e0f", and then perform the onnetwork pairing operation on the chip-tool-web.
Once the pairing process is complete, the Matter device is successfully commissioned to the network. For the chip-energy-management-app, the EEVSE clusters are implemented in chip-tool-web, allowing you to control the end devices using the energyevse cluster commands.
To access the energyevse function in the chip-tool-web, first open the navigation bar and select EevseControl. The following interface will be displayed:
Select the node alias of the paired Matter chip-energy-management-app device, and the page will automatically fill in the corresponding node ID. Then enter the Endpoint ID and click the TRIGGER or CLEAR button to trigger or clear the simulated event.
- The
START TRIGGER EVENTbutton is used to simulate a start event as the basis for triggering subsequent simulated events. - The
TRIGGER PLUGGEDINbutton is used to simulate a plugged-in event. Indicates that electric vehicles is connected to the charging station. This event must be triggered after a start event has-been triggered. - The
TRIGGER CHARGING DEMANDbutton is used to simulate a charging demand event. Indicates that electric vehicles have a charging requirement. This event must be triggered after a plugged-in event has-been triggered. - The
CLEAR TRIGGER EVENTbutton is used to clear the simulated start event. - The
CLEAR PLUGGEDINbutton is used to clear the simulated pluggedin event. - The
CLEAR CHARGING DEMANDbutton is used to clear the simulated charging demand event.
When simulating events, the principle of "last trigger, first clear" should be used, e.g. the order should be: START TRIGGER EVENT -- TRIGGER PLUGGEDIN -- TRIGGER CHARGING DEMAND -- CLEAR CHARGING DEMAND -- CLEAR PLUGGEDIN -- CLEAR TRIGGER EVENT
After the simulated charging demand event is triggered. Enter the value of minimum charge current and maximum charge current, and click the ENABLE CHARGING button to start charging by below commands.
$ chip-tool energyevse enable-charging null <minimum_charge_current> <maximum_charge_current> <node_id> <endpoint_id> --timedInteractionTimeoutMs 3000
In this command:
- <minimum_charge_current> is the minimum charge current(mA).
- <maximum_charge_current> is the maximum charge current(mA).
- <node_id> is the user-defined ID of the commissioned node.
- <endpoint_id> is the ID of the endpoint with energyevse cluster implemented.
Enter the value of user maximum charge current and click the WRITE USER MAXIMUM CHARGE CURRENT button to set user-maximum-charge-current sttribute value by below commands.
chip-tool energyevse write <user_maximum_charge_current> <node_id> <endpoint_id>
In this command:
- <user_maximum_charge_current> is the user-defined maximum charge current(mA).
Click the DISABLE CHARGING button to disable charging value by below commands.
chip-tool energyevse disable <node_id> <endpoint_id> --timedInteractionTimeoutMs 3000
Use the following buttons to read the status of the energyevse attribute in the EEVSE Status section. The page and results are shown below:
- Use the
STATEbutton to trigger the following command to read the state of energyevse:$ chip-tool energyevse read state <node_id> <endpoint_id> - Use the
SUPPLY STATEbutton to trigger the following command to read the supply-state of energyevse:$ chip-tool energyevse read supply-state <node_id> <endpoint_id> - Use the
FAULT STATEbutton to trigger the following command to read the fault-state of energyevse:$ chip-tool energyevse read fault-state <node_id> <endpoint_id> - Use the
CHARGING ENABLED UNTILbutton to trigger the following command to read the charging-enabled-until of tenergyevse:$ chip-tool energyevse read charging-enabled-until <node_id> <endpoint_id> - Use the
MINIMUM CHARGE CURRENTbutton to trigger the following command to read the minimum-charge-current of energyevse:$ chip-tool energyevse read minimum-charge-current <node_id> <endpoint_id> - Use the
MAXIMUM CHARGE CURRENTbutton to trigger the following command to read the maximum-charge-current of energyevse:$ chip-tool energyevse read maximum-charge-current <node_id> <endpoint_id> - Use the
SESSION IDbutton to trigger the following command to read the session-id of energyevse:$ chip-tool energyevse read session-id <node_id> <endpoint_id> - Use the
SESSION DURATIONbutton to trigger the following command to read the session-duration of energyevse:$ chip-tool energyevse read session-duration <node_id> <endpoint_id>
The EEVSE read report is output in text format with the following structure:
Report from ${nodealias} ${nodeid}:${endpoint}. Cluster:${cluster}
${attribute}:${value}
In the structure above,
- ${nodealias}: The node alias of the device.
- ${nodeid}: The nodeid of the device.
- ${endpoint}: The endpoint of the device.
- ${cluster}: The cluster name to which the device belongs.
- ${attribute}: The name of the attribute being reported. In this case, the default attributes are
state,supplystate,faultstate,chargingenableduntil,minimumchargecurrent,maximumchargecurrent,sessionid,sessionduration. - ${value}: The value of the attribute.
-
Deleting the
/tmp/chip_tool_config.inifile and any other.inifiles in the/tmpdirectory may help to resolve problems caused by outdated configuration. Runningrm -rf /tmp/chip_*will remove these files. This will allow the chip-tool-web to rebuild its configuration files from scratch. -
The timeout for all buttons in the chip-tool-web that execute commands is set to 60 seconds. During the command execution process, the interface will display the command execution waiting effect. Please wait patiently for the command to finish executing and return a result of
successorfailed. -
In general, commands related to
Pairingmay take longer to execute, while commands related toOnOfffunctionality will execute faster. If a pairing command takes a long time to execute and returns withfailed, please check that the device configuration follows the documentation. Also, try pairing again after runningrm -rf /tmp/chip_*. -
The chip-tool-web supports commissioning multiple devices at the same time. However, in the current version, only one device can be connected at a time in each pairing mode. Therefore, the current version of chip-tool-web can pair and control three devices at the same time. Note that you should not run
rm -rf /tmp/chip_*while commissioning multiple devices at once, as this will erase the useful information of the successfully paired devices. -
New features are still being developed and expanded.

















