---
# System prepended metadata

title: How exactly the device join the network
tags: [CHIP, Engineer, Matter, Firmware]

---

# How exactly the device join the network

###### tags: `CHIP` `Matter` `Firmware` `Engineer`

> This note will give you a basic idea of the network in the lock-app example. And I assume you knows all steps in this [document](https://github.com/project-chip/connectedhomeip/blob/master/docs/guides/python_chip_controller_building.md)

## How many things we have here

Before the very first step in the example, let's find out how many device we should have

* A device running the lock-app example, I will call it matter device in this ntoe.
    * In this example, the efr32 thunderboard sensor 2
* A device running the controller, and I will call it the controller in this note.
    * In this example, the python running on my mac.
* A router, either wifi ap or openthread border router. I would like to call it the router in this post.
    * Remember, if you are using OpenThread like me, we actually have both the wifi ap and the OpenThread border router. I will show you the network down below.

## Get started!

### Step 0
This is the network when you just power on all the devices.
![](https://i.imgur.com/uFicFC8.jpg)

First at all, the controller(my mac) has been connected to the wifi network even though I haven't started the controller program. And the OpenThread border router(A raspberry pi 3B+) is also connected to the wifi network.

You may notice that there is a OpenThread NCP(Network Co-Processor). You can consider it is a (OpenThread)network card for the rasberry pi because rasberry pi 3B+ doesn't support OpenThread itself. Again, I am using another Silicon Lab thunderboard sensor 2 as the NCP. Actually, I have 3 thunderboard sensor 2 :satisfied: 

### Step 1
This is the network after you finish this command
:::info
More specifically, the controller and the matter devcie finish the PASE handsake. We will introduce the PASE laster
:::
`chip-device-ctrl > connect -ble 3840 20202021 1234`

![](https://i.imgur.com/w2xByPV.jpg)

And now, the controller can talk to the matter device by BLE.

The whole purpose of this BLE connection is that the controller can have the matter device join the OpenThread network, so that other devices in the OpenThread network can find this matter device.

### Step 2
This is the network after you finish these commands
```shell=
zcl NetworkCommissioning AddOrUpdateThreadNetwork 31 0 0 operationalDataset=hex:<Thread network credentials> breadcrumb=0
zcl NetworkCommissioning ConnectNetwork 31 0 0 networkID=hex:<Ext PANID> breadcrumb=0
```
![](https://i.imgur.com/rRwlDUP.jpg)

Although I only put a line between the matter device and the NCP, the matter device is actually commissioned to the OpenThread network. That is, the other devices could find the matter device by the OpenThread network. And that's how the next command works.
:::info
This command will trigger a CAES handshake, we will introduce that later as well
:::

`resolve <node id>`

This command actually is the command the controller uses to find the just-commissioned matter device by the node id. However, this command doesn't change any of the network.

### Step3
This is what happens after you close the BLE.
![](https://i.imgur.com/K9li1vM.jpg)

Now, you could send out any ZCL command you want~

## Hop

If you send out a ZCL command, the command will go like this
![](https://i.imgur.com/ugzdtRW.jpg)

And you can image, if there is any other matter device in the same OpenThread network, they can talk to each other because the OpenThread itself is a mesh network.


