Cette page a été traduite par l'API Cloud Translation.

Créer un réseau Thread avec des cartes nRF52840 et OpenThread

1. Présentation

OpenThread publié par Google est une mise en œuvre Open Source du protocole réseau Thread®. Google Nest a lancé OpenThread pour rendre la technologie utilisée dans les produits Nest accessible à tous les développeurs, afin d'accélérer le développement de produits pour la maison connectée.

La spécification Thread définit un protocole de communication sans fil entre appareils fiable et sécurisé, basé sur IPv6, pour les applications domestiques. OpenThread met en œuvre toutes les couches réseau Thread, y compris IPv6, 6LoWPAN et IEEE 802.15.4 avec sécurité MAC, maillage de liens et routage du maillage.

Dans cet atelier de programmation, vous allez programmer OpenThread sur du matériel réel, créer et gérer un réseau Thread et transmettre des messages entre les nœuds.

Ce que vous allez apprendre

Créer des binaires de CLI OpenThread et faire clignoter sur des cartes de développement
Créer un RCP composé d'une machine Linux et d'une carte de développement
Communiquer avec un RCP à l'aide du daemon OpenThread et de ot-ctl
Gérer manuellement les nœuds Thread avec GNU Screen et la CLI OpenThread
Mise en service sécurisée des appareils sur un réseau Thread
Fonctionnement de la multidiffusion IPv6
Transmettre des messages entre plusieurs nœuds Thread avec UDP

Prérequis

Matériel:

3 cartes de développement nordic Semiconductor nRF52840
Câbles USB vers micro USB pour connecter les cartes
Une machine Linux avec au moins trois ports USB

Logiciels :

GNU Toolchain
Outils de ligne de commande Nordic NRF5x
Logiciel Segger J-Link
OpenThread
Git

2. Premiers pas

Simulation OpenThread

Avant de commencer, nous vous recommandons de suivre cet atelier de programmation pour vous familiariser avec les concepts de base de Thread et avec la CLI OpenThread.

Bornes de port série

Vous devez savoir comment vous connecter à un port série via un terminal. Cet atelier de programmation utilise GNU Screen et fournit une présentation de l'utilisation, mais tout autre logiciel de terminal peut être utilisé.

Machine Linux

Cet atelier de programmation a été conçu pour utiliser une machine Linux basée sur le format i386 ou x86 afin d'héberger un appareil Thread co-processeur (RCP) et de faire clignoter toutes les cartes de développement Thread. Toutes les étapes ont été testées sur Ubuntu 14.04.5 LTS (Trusty Tahr).

Cartes nordique semi-conducteur nRF52840

Cet atelier de programmation utilise trois cartes PDK nRF52840.

Installer SEGGER J-Link

Nous utilisons SEGGER J-Link pour programmer les cartes nRF52840, qui disposent de modules JTAG intégrés. Installez-la sur votre ordinateur Linux.

Téléchargez le package adapté à votre ordinateur, puis installez-le à l'emplacement approprié. Sous Linux, il s'agit de /opt/SEGGER/JLink.

Installer les outils de ligne de commande nRF5x

Les outils de ligne de commande nRF5x vous permettent de transférer les fichiers binaires OpenThread vers les cartes nRF52840. Installez la version nRF5x-Command-Line-Tools-<OS> appropriée sur votre ordinateur Linux.

Placez le package extrait dans le dossier racine ~/.

Installer ARM GNU Toolchain

La chaîne d'outils ARM GNU est utilisée pour la création.

Nous vous recommandons de placer l'archive extraite dans /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ sur votre ordinateur Linux. Suivez les instructions d'installation du fichier readme.txt de l'archive.

Installer l'écran (facultatif)

L'écran est un outil simple pour accéder aux appareils connectés via un port série. Cet atelier de programmation utilise le filtrage d'écran, mais vous pouvez utiliser n'importe quelle application de terminal de port série.

$ sudo apt-get install screen

3. Cloner les dépôts

OpenThread

Clonez et installez OpenThread. Les commandes script/bootstrap garantissent que la chaîne d'outils est installée et que l'environnement est correctement configuré:

$ mkdir -p ~/src
$ cd ~/src
$ git clone --recursive https://github.com/openthread/openthread.git
$ cd openthread
$ ./script/bootstrap

Créez le daemon OpenThread:

$ script/cmake-build posix -DOT_DAEMON=ON

Vous êtes maintenant prêt à compiler et ouvrir Flash aux cartes nRF52840.

4. Configurer le jointur RCP

Build et flash

Créez l'exemple OpenThread nRF52840 avec Joiner et la fonctionnalité USB native. Un appareil utilise le rôle de jointure pour s'authentifier de manière sécurisée et être mis en service sur un réseau Thread. L'utilisation de l'USB natif permet d'utiliser l'interface ADC ACM d'USB comme transport série entre le nRF52840 et l'hôte.

Commencez toujours par nettoyer le dépôt des builds précédents en exécutant rm -rf build.

$ cd ~/src
$ git clone --recursive https://github.com/openthread/ot-nrf528xx.git
$ cd ot-nrf528xx
$ script/build nrf52840 USB_trans

Accédez au répertoire contenant le binaire RCP OpenThread et convertissez-le au format hexadécimal:

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-rcp ot-rcp.hex

Connectez le câble USB au port de débogage micro USB situé à côté de la broche d'alimentation externe de la carte nRF52840, puis branchez-le à la machine Linux. Définissez le bouton Source d'alimentation nRF sur la carte nRF52840 sur VDD. Lorsque la LED est correctement connectée, le LED5 est activé.

S'il s'agit de la première carte connectée à la machine Linux, elle apparaît en tant que port série /dev/ttyACM0 (toutes les cartes nRF52840 utilisent ttyACM comme identifiant de port série).

$ ls /dev/ttyACM*
/dev/ttyACM0

Notez le numéro de série de la carte nRF52840 utilisée pour le RCP:

Accédez à l'emplacement des outils de ligne de commande nRFx, puis flashez le fichier hexadécimal RCP OpenThread sur la carte nRF52840, en utilisant le numéro de série de la carte. Notez que si vous omettez l'option --verify, un message d'avertissement vous indique que le processus Flash peut échouer sans erreur.

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924  --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-rcp.hex --reset

Le résultat suivant est généré en cas de réussite:

Parsing hex file.
Erasing user available code and UICR flash areas.
Applying system reset.
Checking that the area to write is not protected.
Programing device.
Applying system reset.
Run.

Ajoutez le libellé "RCP" au tableau afin de ne pas confondre ses rôles.

Se connecter à un port USB natif

Étant donné que la compilation RCP OpenThread permet d'utiliser la norme ACM ADC native comme transport série, vous devez utiliser le port nRF USB de la carte nRF52840 pour communiquer avec l'hôte RCP (machine Linux).

Débranchez l'extrémité micro-USB du câble USB du port de débogage de la carte nRF52840 clignote, puis rebranchez-la sur le port micro USB nRF à côté du bouton RÉINITIALISER. (Installation de Python groupée). Définissez le bouton Source d'alimentation nRF sur USB.

Démarrer le Daemon OpenThread

Dans la conception RCP, utilisez le Daemon OpenThread pour communiquer avec l'appareil Thread et le gérer. Commencez ot-daemon avec l'indicateur détaillé -v afin de pouvoir afficher la sortie du journal et vérifier qu'elle est en cours d'exécution:

$ cd ~/src/openthread
$ ./build/posix/src/posix/ot-daemon -v \
    'spinel+hdlc+uart:///dev/ttyACM0?uart-baudrate=115200'

Si l'opération réussit, ot-daemon en mode détaillé génère une sortie semblable à celle-ci:

ot-daemon[228024]: Running OPENTHREAD/20191113-00831-gfb399104; POSIX; Jun  7 2020 18:05:15
ot-daemon[228024]: Thread version: 2
ot-daemon[228024]: RCP version: OPENTHREAD/20191113-00831-gfb399104; SIMULATION; Jun  7 2020 18:06:08

Laissez cette fenêtre de terminal ouverte afin que les journaux de ot-daemon puissent être affichés.

Utilisez ot-ctl pour communiquer avec le nœud RCP. ot-ctl utilise la même CLI que l'application CLI OpenThread. Par conséquent, vous pouvez contrôler les nœuds ot-daemon de la même manière que les autres appareils Thread simulés.

Dans une deuxième fenêtre de terminal, démarrez ot-ctl:

$ ./build/posix/bin/ot-ctl
>

Vérifiez le state du nœud 2 (le nœud RCP) que vous avez commencé avec ot-daemon:

> state
disabled
Done

5. Configurer les FTD

Les deux autres nœuds Thread utilisés dans cet atelier de programmation sont les fils complets (FTD) de la conception standard System-on-Chip (SoC). Dans un environnement de production, vous pouvez utiliser wpantund, un pilote d'interface réseau de production, pour contrôler les instances NCP OpenThread, mais dans cet atelier de programmation, nous utiliserons ot-ctl, le thread CLI

Le premier est le Commissaire, qui assure l'authentification et la mise en service sécurisées des appareils sur le réseau. L'autre appareil fonctionne comme un jointur qui peut s'authentifier auprès du réseau Thread.

Build et flash

Créez l'exemple FTD OpenThread pour la plate-forme nRF52840, avec les rôles de commissaire et de jointure activés:

$ cd ~/src/ot-nrf528xx
$ rm -rf build
$ script/build nrf52840 USB_trans -DOT_JOINER=ON -DOT_COMMISSIONER=ON

Accédez au répertoire contenant le binaire CLI FTD (OpenThread Full Thread Device) et convertissez-le au format hexadécimal:

$ cd ~/src/ot-nrf528xx/build/bin
$ arm-none-eabi-objcopy -O ihex ot-cli-ftd ot-cli-ftd.hex

Branchez le câble USB sur le port micro USB situé à côté de la broche d'alimentation externe de la carte nRF52840, puis branchez-le sur la machine Linux. Si le RCP est toujours associé à la machine Linux, ce nouveau tableau doit apparaître comme port série /dev/ttyACM1 (toutes les cartes nRF52840 utilisent ttyACM comme identifiant de port série).

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1

Comme précédemment, notez le numéro de série de la carte nRF52840 utilisée pour le flux FTD:

Accédez à l'emplacement des outils de ligne de commande nRFx, puis flashez le fichier hexadécimal FTD de la CLI OpenThread sur la carte nRF52840, en utilisant le numéro de série de la carte:

$ cd ~/nrfjprog/
$ ./nrfjprog -f nrf52 -s 683704924 --verify --chiperase --program \
       ~/src/ot-nrf528xx/build/bin/ot-cli-ftd.hex --reset

Ajoutez un libellé "Commissaire" au tableau.

Se connecter à un port USB natif

Étant donné que le build FTD d'OpenThread permet l'utilisation de la clé USB CDC ACM native comme transport série, vous devez utiliser le port nRF USB de la carte nRF52840 pour communiquer avec l'hôte RCP (machine Linux).

Vérifier le build

Vérifiez que la compilation est réussie en accédant à la CLI OpenThread à l'aide de GNU Screen à partir d'une fenêtre de terminal. Les cartes nRF52840 utilisent un débit en bauds de 115 200.

$ screen /dev/ttyACM1 115200

Dans la nouvelle fenêtre, appuyez plusieurs fois sur la touche Retour du clavier pour afficher l'invite de la CLI OpenThread >. Affichez l'interface IPv6 et vérifiez les adresses:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:1cd6:87a9:cb9d:4b1d
Done

Ctrl+a→

d pour le dissocier de l'écran de la CLI du commissaire FTD et revenir au terminal Linux pour que le tableau suivant puisse clignoter. Pour accéder de nouveau à la CLI à tout moment, utilisez screen -r à partir de la ligne de commande. Pour afficher la liste des écrans disponibles, utilisez la commande screen -ls:

$ screen -ls
There is a screen on:
        74182.ttys000.mylinuxmachine        (Detached)
1 Socket in /tmp/uscreens/S-username.

Configurer le jointur FTD

Répétez le processus ci-dessus pour faire clignoter le troisième tableau nRF52840 à l'aide de la version ot-cli-ftd.hex existante. Lorsque vous avez terminé, reconnectez le tableau au PC à l'aide du port USB nRF et définissez le bouton Source d'alimentation nRF sur VDD.

Si les deux autres nœuds sont associés à la machine Linux lorsque ce troisième tableau est connecté, il doit apparaître comme port série /dev/ttyACM2:

$ ls /dev/ttyACM*
/dev/ttyACM0  /dev/ttyACM1  /dev/ttyACM2

Ajoutez le libellé "Jointeur" au tableau.

Lorsque vous effectuez la validation à l'aide de l'écran, au lieu de créer une instance d'écran à partir de la ligne de commande, réassociez-la à la fenêtre existante et créez une nouvelle fenêtre (que vous avez utilisée pour le Commissaire FTD):

$ screen -r

Créez une fenêtre à l'écran en appuyant sur Ctrl+a → c.

Une nouvelle invite de ligne de commande apparaît. Accédez à la CLI OpenThread pour le Joint FTD:

$ screen /dev/ttyACM2 115200

Dans cette nouvelle fenêtre, appuyez plusieurs fois sur la touche Retour du clavier pour afficher l'invite de la CLI OpenThread >. Affichez l'interface IPv6 et vérifiez les adresses:

> ifconfig up
Done
> ipaddr
fe80:0:0:0:6c1e:87a2:df05:c240
Done

Maintenant que la CLI de l'opérateur FTD se trouve dans la même instance de Screen que le commissaire FTD, vous pouvez passer de l'un à l'autre en appuyant sur Ctrl+a → n.

Ctrl+a→

d à tout moment pour quitter l'écran.

6. Configuration des fenêtres de terminal

À l'avenir, vous basculerez fréquemment d'un appareil Thread à l'autre. Vérifiez donc que tous ces appareils sont actifs et facilement accessibles. Jusqu'à présent, nous utilisons l'écran pour accéder aux deux flux de données. Cet outil permet aussi d'utiliser l'écran partagé dans la même fenêtre de terminal. Utilisez-la pour voir comment un nœud réagit aux commandes émises sur un autre.

Dans l'idéal, quatre fenêtres devraient être disponibles:

Service / journaux ot-daemon
RCP Joiner via ot-ctl
FTD Commissioner via la CLI OpenThread
FTD Joiner via la CLI OpenThread

Si vous souhaitez utiliser votre propre configuration de terminal ou de port série, vous pouvez passer à l'étape suivante. Configurez les fenêtres de terminal de tous les appareils en fonction de vos besoins.

Utiliser l'écran

Pour plus de simplicité, ne démarrez qu'une session de visionnage. Vous devez en avoir une une lors de la configuration des deux périodes de suivi.

Toutes les commandes de l'écran commencent par Ctrl+a.

Commandes de base de l'écran:

Réintégrer une session à l'écran (à partir de la ligne de commande)	`screen -r`
Quitter la session screen	Ctrl+a → `d`
Créer une fenêtre dans la session Screen	Ctrl+a → `c`
Passer d'une fenêtre à l'autre dans la même session Screen	Ctrl+a → `n` (avant)Ctrl+a → `p` (arrière)
Fermer la fenêtre active dans la session "Écran"	Ctrl+a → `k`

Écran partagé

Avec la fonctionnalité Écran, vous pouvez diviser le terminal en plusieurs fenêtres:

Les commandes de screen sont accessibles à l'aide de Ctrl+a. Chaque commande doit commencer par cette combinaison de clés d'accès.

Si vous avez suivi exactement l'atelier de programmation, vous devriez avoir deux fenêtres (FTD Commissaire, FTD Joiner) sur la même instance Screen. Pour partager l'écran entre les deux, saisissez d'abord votre session Écran existante:

$ screen -r

Vous devez utiliser l'un des appareils FTD. Procédez comme suit dans l'écran:

Ctrl+a → S pour diviser la fenêtre horizontalement
Ctrl+a → Tab pour déplacer le curseur dans la nouvelle fenêtre vide
Ctrl+a → n pour passer à la nouvelle fenêtre
Si c'est le cas, appuyez à nouveau sur Ctrl+a → n pour afficher l'autre appareil FTD.

Les deux sont désormais visibles. Passez de l'un à l'autre à l'aide de Ctrl+a → Tab. Nous vous recommandons de modifier le nom de chaque fenêtre avec Ctrl+a → A pour éviter toute confusion.

Utilisation avancée

Pour fractionner davantage l'écran en quadrant et afficher les journaux ot-daemon et le jointeur RCP ot-ctl, ces services doivent être démarrés dans cette même instance Screen. Pour ce faire, arrêtez ot-daemon et quittez ot-ctl, puis redémarrez-les dans de nouvelles fenêtres d'écran (Ctrl+a → c).

Cette configuration n'est pas obligatoire et fait l'objet d'exercices pour l'utilisateur.

Fractionnez et passez d'une fenêtre à l'autre à l'aide des commandes suivantes:

Créer une fenêtre	Ctrl+a → `c`
Scinder la fenêtre verticalement	Ctrl+a →
Scinder la fenêtre horizontalement	Ctrl+a → `S`
Accéder à la fenêtre affichée suivante	Ctrl+a → `Tab`
Avancer ou revenir en arrière dans la fenêtre affichée	Ctrl+a → `n` ou `p`
Renommer la fenêtre active	Ctrl+a → `A`

Quittez l'écran à tout moment en appuyant sur Ctrl+a → d, puis réassociez-le avec screen -r à partir de la ligne de commande.

Pour en savoir plus sur l'écran, consultez le guide de référence sur l'écran GNU.

7. Créer le réseau Thread

Maintenant que tous les écrans et toutes vos fenêtres de terminal sont configurés, nous allons créer notre réseau Thread. Dans le cadre du commissaire FTD, créez un nouvel ensemble de données opérationnelles et validez-le en tant qu'ensemble actif. L'ensemble de données opérationnel correspond à la configuration du réseau Thread que vous créez.

## FTD Commissioner ##
----------------------

> dataset init new
Done
> dataset
Active Timestamp: 1
Channel: 11
Channel Mask: 07fff800
Ext PAN ID: c0de7ab5c0de7ab5
Mesh Local Prefix: fdc0:de7a:b5c0/64
Network Key: 1234c0de7ab51234c0de7ab51234c0de
Network Name: OpenThread-c0de
PAN ID: 0xc0de
PSKc: ebb4f2f8a68026fc55bcf3d7be3e6fe4
Security Policy: 0, onrcb
Done

Notez la clé réseau 1234c0de7ab51234c0de7ab51234c0de qui vous servira plus tard.

Validez cet ensemble de données en tant qu'ensemble actif:

> dataset commit active
Done

Affichez l'interface IPv6:

> ifconfig up
Done

Démarrez l'opération associée au protocole Thread:

> thread start
Done

Vérifiez l'état de l'appareil après quelques instants. Il doit s'agir du leader. Obtenez également le Rloc16 pour référence ultérieure.

## FTD Commissioner ##
----------------------

> state
leader
Done
> rloc16
0c00
Done

Vérifiez les adresses IPv6 de l'appareil:

## FTD Commissioner ##
----------------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00        # Leader Anycast Locator (ALOC)
fdc0:de7a:b5c0:0:0:ff:fe00:c00         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:6394:5a75:a1ad:e5a    # Mesh-Local EID (ML-EID)
fe80:0:0:0:1cd6:87a9:cb9d:4b1d         # Link-Local Address (LLA)

Le réseau "atelier de programmation" est désormais visible lorsqu'il est analysé depuis d'autres appareils Thread.

Dans ot-ctl sur le membre PRC:

## RCP Joiner ##
----------------

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |

Depuis la CLI OpenThread sur FTD Joiner:

## FTD Joiner ##
----------------

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Si le réseau "atelier de programmation" n'apparaît pas dans la liste, relancez la recherche.

Vous remarquerez peut-être que dans les deux analyses, le réseau ne semble pas joignable (colonne J sur le jointeur RCP et jointure FTD). Cela signifie simplement que la mise en service Thread n'est pas active sur le réseau. Vous pouvez toujours l'utiliser hors bande, en saisissant manuellement la clé réseau dans l'appareil associé.

8. Ajouter le jointeur RCP

Ajoutons le Jointeur RCP au réseau Thread que nous venons de créer en utilisant un processus hors bande. Recherchez des réseaux sur le RCP Joiner:

## RCP Joiner ##
----------------

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Pour rejoindre la réunion, définissez la clé réseau (que nous venons d'obtenir auprès du commissaire FTD) sur le Joint RCP dans son ensemble de données actif.

## RCP Joiner ##
----------------

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Vérifiez que l'ensemble de données est correctement défini.

## RCP Joiner ##
----------------

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Affichez Thread pour que le RCP Joiner rejoint le réseau "atelier de programmation". Attendez quelques secondes, puis vérifiez l'état, Rloc16 et ses adresses IPv6:

## RCP Joiner ##
----------------

> thread start
Done
> state
child
Done
> rloc16
0c01
Done
> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:0c01         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f    # Mesh-Local EID (ML-EID)
fe80:0:0:0:18e5:29b3:a638:943b          # Link-Local Address (LLA)
Done

Notez l'adresse IPv6 du réseau maillé local (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f ici). Vous l'utiliserez plus tard.

Revenez au commissaire de FTD, et vérifiez que les tables du routeur et des enfants sont bien connectées au même réseau. Utilisez le protocole Rloc16 pour identifier le jointure RCP.

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  35 | 1ed687a9cb9d4b1d |

Done
> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|VER| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+---+------------------+
|   1 | 0x0c01 |        240 |         25 |     3 |   89 |1|1|1|  2| 1ae529b3a638943b |
Done

Pinguez l'adresse du réseau maillé local de l'opérateur RCP (l'adresse locale obtenue à partir de la sortie ipaddr de l'opérateur RCP) pour vérifier la connectivité:

## FTD Commissioner ##
----------------------

> ping fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f
> 8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=1 hlim=64 time=40ms

Nous avons maintenant un réseau Thread composé de deux nœuds, illustré par ce diagramme de topologie:

otcodelab_top01C_2nœuds.png

Diagrammes de topologie

Tout au long de l'atelier de programmation, nous afficherons un nouveau schéma de topologie Thread à chaque changement d'état du réseau. Les rôles de nœud sont décrits comme suit:

Les routeurs sont toujours des pentagones, et les appareils finaux sont toujours des cercles. Les chiffres figurant sur chaque nœud représentent l'ID du routeur ou l'ID enfant affiché dans la sortie de la CLI, en fonction du rôle et de l'état actuels de chaque nœud à ce moment-là.

9. Rejoindre le programme FTD

Ajoutons à présent le troisième appareil Thread au réseau "atelier de programmation". Cette fois, nous allons utiliser le processus de mise en service intrabande plus sécurisé. Dans le champ FTD Joiner, recherchez le réseau:

## FTD Joiner ##
----------------

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 0 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | f65ae2853ff0c4e4 | 11 | -36 |  57 |

Un 0 dans la colonne J indique que la mise en service Thread n'est pas active sur l'appareil.

Soyez précis lors de la mise en service sur cet appareil suivant et n'autorisons que le membre du programme FTD à rejoindre le programme. Toujours sur le compte du FTD, obtenez le eui64 pour que le commissaire puisse l'identifier:

## FTD Joiner ##
----------------

> eui64
2f57d222545271f1
Done

Dans la section Commission FTD, démarrez le commissaire et spécifiez le type d'appareil eui64 qui peut être associé, ainsi que les identifiants de jointure (par exemple, J01NME). L'identifiant de jointure est une chaîne spécifique à l'appareil qui comprend tous les caractères alphanumériques en majuscules (0 à 9 et AY, à l'exclusion des points I, O, Q et Z) pour une facilité de lecture comprise entre 6 et 32 caractères.

## FTD Commissioner ##
----------------------

> commissioner start
Done
> commissioner joiner add 2f57d222545271f1 J01NME
Done

Passez à FTD Joiner, puis relancez la recherche:

## FTD Joiner ##
----------------

> scan
| J | Network Name     | Extended PAN     | PAN  | MAC Address      | Ch | dBm | LQI |
+---+------------------+------------------+------+------------------+----+-----+-----+
| 1 | OpenThread-c0de  | c0de7ab5c0de7ab5 | c0de | 1ed687a9cb9d4b1d | 11 | -45 | 196 |

Comme indiqué par 1 dans la colonne J, la mise en service Thread est désormais active sur le réseau. Lancez le rôle de jointure avec les identifiants de jointure que vous venez de configurer dans le Commissaire FTD:

## FTD Joiner ##
----------------

> ifconfig up
Done
> joiner start J01NME
Done

Dans la minute qui suit, vous recevez la confirmation d'une authentification réussie:

## FTD Joiner ##
----------------

>
Join success

Ouvrez Thread pour que le Jointure FTD rejoint le réseau de l'atelier de programmation, puis vérifiez immédiatement l'état et RTL16:

## FTD Joiner ##
----------------

> thread start
Done
> state
child
Done
> rloc16
0c02
Done

Vérifiez les adresses IPv6 de l'appareil. Notez qu'il n'y a pas d'ALO. En effet, cet appareil n'est pas le leader et ne dispose pas d'un rôle Anycast qui nécessite un ATL.

## FTD Joiner ##
----------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:c02         # Routing Locator (RLOC)
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd    # Mesh-Local EID (ML-EID)
fe80:0:0:0:e4cd:d2d9:3249:a243         # Link-Local Address (LLA)

Passez immédiatement au commissaire FTD, puis vérifiez le routeur et les tables enfants pour vérifier que trois appareils existent dans le réseau "atelier de programmation" :

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         25 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
|   2 | 0x0c02 |        240 |         15 |     3 |   44 |1|1|1|1| e6cdd2d93249a243 |
Done

D'après le RTL16, le jointeur FTD a rattaché le réseau en tant qu'appareil de fin (enfant). Voici notre nouvelle topologie:

10. Fil de discussion en action

Les appareils Thread de cet atelier de programmation sont un type spécifique d'appareil à thread complet (FTD, Router Éligible Device Device, appareil fin de réseau éligible). Cela signifie qu'ils peuvent fonctionner comme routeurs ou appareils finaux. Ils peuvent aussi être utilisés pour la promotion d'un appareil final vers un routeur.

Thread peut prendre en charge jusqu'à 32 routeurs, mais tente de maintenir le nombre de routeurs entre 16 et 23. Si un REED est associé en tant qu'appareil de fin (enfant) et que le nombre de routeurs est inférieur à 16, après une période aléatoire de deux minutes, il passe automatiquement en routeur.

Si votre réseau Thread comportait deux enfants après avoir ajouté le jointeur FTD, attendez au moins deux minutes, puis revérifiez le routeur et les tables enfants sur le commissaire aux États-Unis:

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       63 |         0 |     3 |      3 |   1 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         61 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
Done

FTD Joiner (MAC étendu = e6cdd2d93249a243) s'est transformé en routeur. Notez que le niveau d'impact RTL16 est différent (b800 au lieu de 0c02). En effet, le RTL16 est basé sur l'ID de routeur et l'ID enfant d'un appareil. Lors de la transition d'un appareil final vers un routeur, les valeurs de son ID de routeur et de son ID d'enfant changent, tout comme le Rloc16.

Confirmez le nouvel état et le code RTL16 sur l'opérateur FTD Joiner:

## FTD Joiner ##
----------------

> state
router
Done
> rloc16
b800
Done

Rétrograder FTD Joiner

Vous pouvez tester ce comportement en revenant manuellement à une édition FTD Joiner d'un routeur sur un Appareil final. Définissez l'état sur "child" (enfant) et vérifiez le Rloc16:

## FTD Joiner ##
----------------

> state child
Done
> rloc16
0c03
Done

Sur l'écran du commissaire FTD, le Joint FTD devrait maintenant apparaître dans la table enfant (ID = 3). Elle peut se trouver dans les deux cas pendant la transition:

## FTD Commissioner ##
----------------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |        3 |         0 |     0 |      0 |  50 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       63 |         0 |     3 |      3 |   1 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0x0c01 |        240 |         61 |     3 |   89 |1|1|1|1| 1ae529b3a638943b |
|   3 | 0x0c03 |        240 |         16 |     3 |   94 |1|1|1|1| e6cdd2d93249a243 |
Done

Après un certain temps, elle sera rétablie à l'aide d'un routeur avec un Rloc de b800.

Supprimer la variante optimale

La variante optimale est auto-élue parmi tous les routeurs à thread. Cela signifie que si le responsable actuel est supprimé du réseau Thread, l'un des autres routeurs deviendra le nouveau responsable.

Dans le cadre du commissaire FTD, arrêtez Thread pour le supprimer du réseau Thread:

## FTD Commissioner ##
----------------------

> thread stop
Done
> ifconfig down
Done

En l'espace de deux minutes, FTD Joiner devient le nouveau responsable Thread. Vérifiez l'état et les adresses IPv6 du jointur FTD:

## FTD Joiner ##
----------------

> state
leader
Done
> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00       # Now it has the Leader ALOC!
fdc0:de7a:b5c0:0:0:ff:fe00:b800
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd
fe80:0:0:0:e4cd:d2d9:3249:a243
Done

Vérifiez la table enfant. Vous remarquerez qu'il existe un nouveau Rloc16. Il s'agit du Joint RCP, indiqué par son ID et son adresse MAC étendue. Pour maintenir le réseau Thread, il a changé les routeurs parents du commissaire FTD au jointeur FTD. Cela entraîne un nouveau Rloc16 pour le jointur RCP, car son ID de routeur est passé de 3 à 46.

## FTD Joiner ##
----------------

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0xb801 |        240 |         27 |     3 |  145 |1|1|1|1| 1ae529b3a638943b |
Done

Vous devrez peut-être patienter quelques minutes, le temps que le participant RPC s'associe au jointeur FTD en tant qu'enfant. Vérifiez l'état et le Rloc16 pour confirmer que:

## RCP Joiner ##
--------------

> state
child
> rloc16
b801

Réintégrer le commissaire FTD

Un réseau Thread avec deux nœuds n'est pas très amusant. Remettons le commissaire de FTD en ligne.

Dans le cadre du commissaire FTD, redémarrez Thread:

## FTD Commissioner ##
----------------------

> ifconfig up
Done
> thread start
Done

Au bout de deux minutes, il se reconnecte automatiquement au réseau "atelier de programmation" en tant qu'appareil de fin, puis se transforme en routeur.

## FTD Commissioner ##
----------------------

> state
router
Done

Consultez le routeur et les tables enfants du FTD Joiner pour vérifier:

## FTD Joiner ##
----------------

> router table
| ID | RLOC16 | Next Hop | Path Cost | LQ In | LQ Out | Age | Extended MAC     |
+----+--------+----------+-----------+-------+--------+-----+------------------+
|  3 | 0x0c00 |       63 |         0 |     3 |      3 |   0 | 1ed687a9cb9d4b1d |
| 46 | 0xb800 |       46 |         0 |     0 |      0 |  15 | e6cdd2d93249a243 |

> child table
| ID  | RLOC16 | Timeout    | Age        | LQ In | C_VN |R|S|D|N| Extended MAC     |
+-----+--------+------------+------------+-------+------+-+-+-+-+------------------+
|   1 | 0xb801 |        240 |        184 |     3 |  145 |1|1|1|1| 1ae529b3a638943b |
Done

Notre réseau Thread est à nouveau composé de trois nœuds.

11. Dépannage

La gestion d'un réseau Thread avec plusieurs appareils sur différentes fenêtres de terminal ou d'écran peut être complexe. Suivez ces conseils pour réinitialiser l'état du réseau ou de votre espace de travail en cas de problème.

Écran

Si vous vous perdez lors d'une opération de configuration (trop de fenêtres d'écran ou d'écrans à l'écran), arrêtez de fermer les fenêtres avec Ctrl+a kk jusqu'à ce qu'il n'en ait aucune, et screen -ls sur la ligne de commande renvoie No Sockets found. Ensuite, recréez des fenêtres d'écran pour chaque appareil. Les états de l'appareil sont conservés même si l'écran est arrêté.

Nœuds de thread

Si la topologie du réseau Thread ne correspond pas à la description décrite dans cet atelier de programmation ou si les nœuds se déconnectent pour une raison quelconque (par exemple parce que la machine Linux qui les alimente est passée en veille), il est préférable d'arrêter Thread, d'effacer les identifiants réseau et de recommencer depuis la page Créez le réseau Thread.

Pour réinitialiser les temps de trajet, procédez comme suit:

## FTD Commissioner or FTD Joiner ##
------------------------------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

Vous pouvez réinitialiser le RCP de la même manière via ot-ctl:

## RCP Joiner ##
----------------

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

12. Utiliser la multidiffusion

La multidiffusion permet de communiquer des informations à un groupe d'appareils en même temps. Dans un réseau Thread, les adresses spécifiques sont réservées à l'utilisation de multidiffusion avec différents groupes d'appareils, en fonction du champ d'application.

Adresse IPv6	Scope (Portée)	Livré à
`ff02::1`	Lien local	Toutes les valeurs FTD et MED
`ff02::2`	Lien local	Tous les flux de données et les routeurs de bordure
`ff03::1`	Locale (maille)	Toutes les valeurs FTD et MED
`ff03::2`	Locale (maille)	Tous les flux de données et les routeurs de bordure

Comme nous n'utilisons pas de routeur de bordure dans cet atelier de programmation, nous allons nous concentrer sur les deux adresses de multidiffusion FTD et MED.

Lien local

Le champ d'application "Link-Local" comprend toutes les interfaces Thread accessibles par une seule transmission radio, ou un "saut" unique. La topologie du réseau spécifie les appareils qui répondent à un ping vers l'adresse de multidiffusion ff02::1.

Pinguez ff02::1 depuis le commissaire FTD:

## FTD Commissioner ##
----------------------

> ping ff02::1
> 8 bytes from fe80:0:0:0:e4cd:d2d9:3249:a243: icmp_seq=2 hlim=64 time=9ms

Il y a deux autres appareils sur le réseau (FTD Joiner et RCP Joiner), mais le commissaire à la conférence FTD n'a reçu qu'une réponse de la part de FTD Joiner's Link-Local Address (LLA). Cela signifie que le jointeur FTD est le seul appareil que le commissaire FTD peut atteindre avec un seul saut.

Pinguez maintenant ff02::1 depuis FTD Joiner:

## FTD Joiner ##
----------------

> ping ff02::1
> 8 bytes from fe80:0:0:0:1cd6:87a9:cb9d:4b1d: icmp_seq=1 hlim=64 time=11ms
8 bytes from fe80:0:0:0:18e5:29b3:a638:943b: icmp_seq=1 hlim=64 time=24ms

Deux réponses ! En vérifiant les adresses IPv6 des autres appareils, nous pouvons voir que le premier (se terminant par 4b1d) est le LLA du commissaire aux services d'urgence et le second (qui se termine par 943b) est le LLA du commissaire RCP.

Cela signifie que le jointeur FTD est directement connecté au commissaire FTD et au Jointeur RCP, ce qui confirme notre topologie.

Locale (maille)

Le champ d'application Mesh-Local comprend toutes les interfaces Thread accessibles au sein du même réseau Thread. Examinons les réponses à un ping vers l'adresse de multidiffusion ff03::1.

Pinguez ff03::1 depuis le commissaire FTD:

## FTD Commissioner ##
----------------------

> ping ff03::1
> 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:b800: icmp_seq=3 hlim=64 time=9ms
8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=3 hlim=64 time=68ms

Cette fois, le commissaire à la certification FTD a reçu deux réponses, l'une provenant du localisateur de routage de l'opérateur de jointure FTD (RLO se terminant par b800) et l'autre provenant du numéro EID de jointure RCP (ML-EID, se terminant par d55f). En effet, le champ d'application local du réseau maillé comprend l'ensemble du réseau Thread. Peu importe où se trouve un appareil sur le réseau, il est abonné à l'adresse ff03::1.

Pinguez ff03::1 depuis le membre FTD pour confirmer le même comportement:

## FTD Joiner ##
----------------

> ping ff03::1
> 8 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00: icmp_seq=2 hlim=64 time=11ms
8 bytes from fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f: icmp_seq=2 hlim=64 time=23ms

Notez le temps de réponse du jointur RCP dans les deux sorties ping. Le RCP Joiner a mis plus de temps à joindre le commissaire FTD (68 ms) qu'à atteindre le Jointeur FTD (23 ms). C'est parce qu'il doit faire deux sauts pour atteindre le commissaire FTD, contre un saut pour le FTD Joiner.

Vous avez peut-être également remarqué que le ping multicast local de maillage a répondu avec le RTL uniquement pour les deux FTD, et non le Joint RCP. car les FTD sont des routeurs au sein du réseau, tandis que le RCP est un appareil final.

Vérifiez l'état du membre du programme PRC pour confirmer:

## RCP Joiner ##
----------------

> state
child

13. Envoyer des messages avec UDP

L'un des services d'application fournis par OpenThread est le protocole de datagramme utilisateur (UDP), un protocole de couche de transport. Une application basée sur OpenThread peut utiliser l'API UDP pour transmettre des messages entre les nœuds d'un réseau Thread, ou vers d'autres appareils dans un réseau externe (comme Internet, si le réseau Thread possède un routeur de bordure).

Les sockets UDP sont exposés via la CLI OpenThread. Nous allons l'utiliser pour transmettre les messages entre les deux flux.

Obtenez l'adresse EID locale du maillage pour le jointur FTD. Nous utilisons cette adresse, car elle est accessible depuis n'importe où au sein du réseau Thread.

## FTD Joiner ##
----------------

> ipaddr
fdc0:de7a:b5c0:0:0:ff:fe00:fc00        # Leader Anycast Locator (ALOC)
fdc0:de7a:b5c0:0:0:ff:fe00:b800        # Routing Locator (RLOC)
fe80:0:0:0:e4cd:d2d9:3249:a243         # Link-Local Address (LLA)
fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd    # Mesh-Local EID (ML-EID)
Done

Démarrez UDP et associez-le à un socket pour toute adresse IPv6:

## FTD Joiner ##
----------------

> udp open
Done
> udp bind :: 1212

Passez au commissaire FTD, démarrez UDP et connectez-vous au socket que vous avez configuré sur le FTD Joiner, en utilisant son ML-EID:

## FTD Commissioner ##
----------------------

> udp open
Done
> udp connect fdc0:de7a:b5c0:0:3e2e:66e:9d41:ebcd 1212
Done

La connexion UDP doit être active entre les deux nœuds. Envoyez un message au commissaire FTD:

## FTD Commissioner ##
----------------------

> udp send hellothere
Done

Sur la pageJointeur FTD, le message UDP a été reçu.

## FTD Joiner ##
----------------

> 10 bytes from fdc0:de7a:b5c0:0:0:ff:fe00:c00 49153 hellothere

14. Félicitations !

Vous avez créé un réseau Thread physique.

Vous savez maintenant:

Différence entre les types d'appareils Thread, les rôles et les habilitations
Comment les appareils Thread gèrent leur état au sein du réseau
comment transmettre des messages simples entre les nœuds à l'aide d'UDP

Liens associés

Pour développer cet atelier de programmation, essayez les exercices suivants:

Retransformez la carte Joint FTD en tant que MTD à l'aide du binaire ot-cli-mtd et observez qu'elle ne se transforme jamais en routeur ou tente de devenir la variante optimale.
Ajoutez d'autres appareils au réseau (essayez une autre plate-forme), et esquissez la topologie en utilisant les tables de routeur et enfant, ainsi que des pings vers les adresses de multidiffusion.
Utiliser le pyspinel pour contrôler le NCP
Convertissez le NCP en routeur de bordure à l'aide du routeur de bordure ThreadThread et connectez votre réseau Thread à Internet

Documentation complémentaire

Consultez openthread.io et GitHub pour accéder à diverses ressources OpenThread, y compris:

Supported Platforms (Plates-formes compatibles) : découvrez toutes les plates-formes compatibles avec OpenThread
Build OpenThread - Plus de détails sur la création et la configuration d'OpenThread
Thread Prime : présente tous les concepts de Thread présentés dans cet atelier de programmation

Références :