Thread-Netzwerk mit nRF52840-Boards und OpenThread erstellen

1. Einführung

26b7f4f6b3ea0700.png

OpenThread, das von Google veröffentlicht wurde, ist eine Open-Source-Implementierung des Thread®-Netzwerkprotokolls. Google Nest hat OpenThread veröffentlicht, um Entwicklern die in Nest-Produkten verwendete Technologie allgemein zugänglich zu machen und so die Entwicklung von Produkten für das vernetzte Zuhause zu beschleunigen.

Die Thread-Spezifikation definiert ein IPv6-basiertes, zuverlässiges, sicheres und energiesparendes Kommunikationsprotokoll für drahtlose Geräte zwischen Geräten für Heimanwendungen. OpenThread implementiert alle Thread-Netzwerkschichten, einschließlich IPv6, 6LoWPAN, IEEE 802.15.4 mit MAC-Sicherheit, Mesh-Link-Einrichtung und Mesh-Routing.

In diesem Codelab programmieren Sie OpenThread auf echter Hardware, erstellen und verwalten ein Thread-Netzwerk und leiten Nachrichten zwischen Knoten weiter.

4806d16a8c137c6d.jpeg

Lerninhalte

  • OpenThread-CLI-Binärdateien erstellen und auf Entwicklungsboards flashen
  • RCP aus einem Linux-Computer und einem Dev-Board erstellen
  • Über OpenThread Daemon und ot-ctl mit einem RCP kommunizieren
  • Thread-Knoten manuell mit GNU Screen und der OpenThread-CLI verwalten
  • Sichere Inbetriebnahme von Geräten in einem Thread-Netzwerk
  • Funktionsweise von IPv6-Multicast
  • Nachrichten zwischen Thread-Knoten mit UDP weiterleiten

Voraussetzungen

Hardware:

  • 3 Entwicklungsboards von Nordic Semiconductor nRF52840
  • 3 USB-auf-Micro-USB-Kabel zum Verbinden der Karten
  • Ein Linux-Computer mit mindestens 3 USB-Ports

Software:

  • GNU-Toolchain
  • Nordic nRF5x-Befehlszeilentools
  • Segger J-Link-Software
  • OpenThread
  • Git

2. Erste Schritte

OpenThread-Simulation

Bevor Sie beginnen, sollten Sie das Codelab für die OpenThread-Simulation durchgehen, um sich mit den grundlegenden Thread-Konzepten und der OpenThread-Befehlszeile vertraut zu machen.

Terminals der seriellen Ports

Sie sollten wissen, wie Sie eine Verbindung zu einem seriellen Port über ein Terminal herstellen. Dieses Codelab verwendet GNU Screen und bietet eine Nutzungsübersicht. Sie können aber auch jede andere Terminalsoftware verwenden.

Linux-Computer

Dieses Codelab wurde entwickelt, um einen i386- oder x86-basierten Linux-Computer als Host für ein RCP-Thread-Gerät (Radio Co-Processor) zu verwenden und alle Thread-Entwicklungsboards zu flashen. Alle Schritte wurden unter Ubuntu 14.04.5 LTS (Trusty Tahr) getestet.

nRF52840-Platinen von Nordic Semiconductor

In diesem Codelab werden drei nRF52840-PDK-Boards verwendet.

a6693da3ce213856.png

Wir verwenden SEGGER J-Link, um die nRF52840-Karten mit integrierten JTAG-Modulen zu programmieren. Installieren Sie diese Datei auf Ihrem Linux-Computer.

Laden Sie das entsprechende Paket für Ihren Computer herunter und installieren Sie es am richtigen Speicherort. Unter Linux ist dies /opt/SEGGER/JLink.

nRF5x-Befehlszeilentools installieren

Mit den nRF5x-Befehlszeilentools können Sie die OpenThread-Binärdateien auf die nRF52840-Boards flashen. Geeignetes nRF5x-Command-Line-Tools-<OS> installieren auf Ihrem Linux-Computer erstellen.

Legen Sie das extrahierte Paket im Stammordner ~/ ab.

ARM GNU-Toolchain installieren

Die ARM GNU-Toolchain dient dem Bauen.

Wir empfehlen, das extrahierte Archiv auf Ihrem Linux-Computer in /opt/gnu-mcu-eclipse/arm-none-eabi-gcc/ zu speichern. Eine Installationsanleitung finden Sie in der Datei readme.txt des Archivs.

Installationsbildschirm (optional)

Screen ist ein einfaches Tool für den Zugriff auf Geräte, die über einen seriellen Port verbunden sind. In diesem Codelab wird Screen verwendet. Sie können jedoch jede beliebige Terminalanwendung mit seriellem Port verwenden.

$ sudo apt-get install screen

3. Repositories klonen

OpenThread

Klonen und installieren Sie OpenThread. Mit den script/bootstrap-Befehlen wird dafür gesorgt, dass die Toolchain installiert und die Umgebung richtig konfiguriert ist:

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

OpenThread-Daemon erstellen:

$ script/cmake-build posix -DOT_DAEMON=ON

Jetzt können Sie OpenThread erstellen und auf den nRF52840-Boards flashen.

4. RCP Joiner einrichten

Build und Flash

Erstellen Sie das OpenThread-nRF52840-Beispiel mit Joiner und nativer USB-Funktionalität. Ein Gerät verwendet die Joiner-Rolle, um sich sicher zu authentifizieren und in einem Thread-Netzwerk in Betrieb zu nehmen. Natives USB ermöglicht die Verwendung von USB CDC ACM als serielle Übertragung zwischen dem nRF52840 und dem Host.

Bereinigen Sie immer zuerst das Repository vorheriger Builds, indem Sie rm -rf build ausführen.

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

Gehen Sie zum Verzeichnis mit der OpenThread-RCP-Binärdatei und konvertieren Sie es in das Hexadezimalformat:

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

Stecken Sie das USB-Kabel in den Micro-USB-Debug-Port neben dem externen Stromanschluss der nRF52840-Platine und schließen Sie es dann an den Linux-Computer an. Stellen Sie den Schalter für die nRF-Stromquelle auf der nRF52840-Platine auf VDD. Wenn die Verbindung korrekt hergestellt ist, leuchtet LED5.

20a3b4b480356447.png

Wenn dies das erste an den Linux-Computer angeschlossene Board ist, wird es als serieller Port /dev/ttyACM0 angezeigt (alle nRF52840-Karten verwenden ttyACM als Kennung des seriellen Ports).

$ ls /dev/ttyACM*
/dev/ttyACM0

Notieren Sie sich die Seriennummer der für die RCP verwendeten nRF52840-Karte:

c00d519ebec7e5f0.jpeg

Navigieren Sie zum Speicherort der nRFx-Befehlszeilentools und flashen Sie die OpenThread-RCP-Hexadezimaldatei auf die nRF52840-Platine unter Verwendung der Seriennummer der Karte. Wenn Sie das Flag --verify weglassen, wird eine Warnmeldung angezeigt, dass der Flash-Prozess ohne Fehler fehlschlagen kann.

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

Bei Erfolg wird die folgende Ausgabe generiert:

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.

Beschriften Sie die Tafel mit „RCP“ damit Sie später die Vorstandsrollen nicht verwechseln.

Mit nativem USB-Kabel verbinden

Da der OpenThread-RCP-Build die Verwendung von nativem USB-CDC-ACM als serielle Übertragung ermöglicht, müssen Sie den nRF-USB-Port auf der nRF52840-Karte verwenden, um mit dem RCP-Host (Linux-Computer) zu kommunizieren.

Trennen Sie das Micro-USB-Ende des USB-Kabels vom Debug-Port der geblinkten nRF52840-Karte und schließen Sie es dann wieder an den Micro-USB-nRF USB-Anschluss neben der Schaltfläche Zurücksetzen an. Stellen Sie den Schalter für nRF-Stromquelle auf USB.

46e7b670d2464842.png

OpenThread-Daemon starten

Verwenden Sie im RCP-Design OpenThread Daemon, um mit dem Thread-Gerät zu kommunizieren und es zu verwalten. Beginnen Sie ot-daemon mit dem ausführlichen Flag -v, damit Sie die Logausgabe sehen und prüfen können, ob sie ausgeführt wird:

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

Bei Erfolg generiert ot-daemon im ausführlichen Modus eine Ausgabe ähnlich der folgenden:

ot-daemon[12463]: Running OPENTHREAD/thread-reference-20200818-1938-g0f10480ed; POSIX; Aug 30 2022 10:55:05
ot-daemon[12463]: Thread version: 4
ot-daemon[12463]: Thread interface: wpan0
ot-daemon[12463]: RCP version: OPENTHREAD/thread-reference-20200818-1938-g0f10480ed; SIMULATION; Aug 30 2022 10:54:10

Lassen Sie dieses Terminalfenster geöffnet, damit die Protokolle von ot-daemon angezeigt werden können.

Verwenden Sie ot-ctl, um mit dem RCP-Knoten zu kommunizieren. ot-ctl verwendet dieselbe Befehlszeile wie die OpenThread-CLI-Anwendung. Daher können Sie ot-daemon-Knoten auf dieselbe Weise steuern wie die anderen simulierten Thread-Geräte.

Starten Sie ot-ctl in einem zweiten Terminalfenster:

$ sudo ./build/posix/src/posix/ot-ctl
>

Prüfen Sie den state von Knoten 2 (dem RCP-Knoten), den Sie mit ot-daemon gestartet haben:

> state
disabled
Done

5. FTDs einrichten

Die anderen beiden Thread-Knoten, die in diesem Codelab verwendet werden, sind Full-Thread-Geräte (FTDs) im standardmäßigen System-on-Chip-Design (SoC). In einer Produktionseinstellung kann zur Steuerung von OpenThread-NCP-Instanzen wpantund verwendet werden, ein produktionstauglicher Netzwerkschnittstellentreiber. In diesem Codelab verwenden wir jedoch ot-ctl, die OpenThread-Befehlszeile.

Ein Gerät fungiert als Commissioner, um Geräte in diesem Netzwerk sicher zu authentifizieren und in Betrieb zu nehmen. Das andere Gerät fungiert als Joiner, das der Commissioner beim Thread-Netzwerk authentifizieren kann.

Build und Flash

Erstellen Sie das OpenThread-FTD-Beispiel für die nRF52840-Plattform und aktivieren Sie die Rollen „Provisioner“ und „Joiner“:

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

Gehen Sie zum Verzeichnis mit dem FTD-Befehlszeilen-Binärprogramm (OpenThread Full Thread Device) und konvertieren Sie es in das Hexadezimalformat:

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

Stecken Sie das USB-Kabel in den Micro-USB-Port neben dem externen Stromanschluss auf der nRF52840-Platine und schließen Sie es dann an den Linux-Computer an. Wenn die RCP noch mit dem Linux-Computer verbunden ist, sollte diese neue Karte als serieller Port /dev/ttyACM1 angezeigt werden. Alle nRF52840-Karten verwenden ttyACM als Kennung des seriellen Ports.

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

Notieren Sie sich wie zuvor die Seriennummer der für die FTD verwendeten nRF52840-Karte:

c00d519ebec7e5f0.jpeg

Navigieren Sie zum Speicherort der nRFx-Befehlszeilentools und flashen Sie die FTD-Hexadezimaldatei der OpenThread CLI mithilfe der Seriennummer auf der nRF52840-Platine:

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

Beschriften Sie die Tafel mit „Commissioner“.

Mit nativem USB-Kabel verbinden

Da der OpenThread FTD-Build die Verwendung von nativem USB-CDC-ACM als seriellen Transport ermöglicht, müssen Sie den nRF-USB-Port auf der nRF52840-Karte verwenden, um mit dem RCP-Host (Linux-Computer) zu kommunizieren.

Trennen Sie das Micro-USB-Ende des USB-Kabels vom Debug-Port der geblinkten nRF52840-Karte und schließen Sie es dann wieder an den Micro-USB-nRF USB-Anschluss neben der Schaltfläche Zurücksetzen an. Stellen Sie den Schalter für nRF-Stromquelle auf USB.

46e7b670d2464842.png

Build überprüfen

Prüfen Sie, ob der Build erfolgreich war, indem Sie in einem Terminalfenster über GNU Screen auf die OpenThread-Befehlszeile zugreifen. Die nRF52840-Boards verwenden eine Baudrate von 115.200.

$ screen /dev/ttyACM1 115200

Drücken Sie im neuen Fenster mehrmals die Eingabetaste auf der Tastatur, um die >-Eingabeaufforderung der OpenThread-Befehlszeile aufzurufen. Rufen Sie die IPv6-Schnittstelle auf und prüfen Sie die Adressen:

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

Drücken Sie Strg + A →

d um den Bildschirm der FTD Commissioner CLI zu trennen und zum Linux-Terminal zurückzukehren, damit das nächste Board geflasht werden kann. Sie können die Befehlszeile jederzeit wieder aufrufen. Geben Sie dazu screen -r in der Befehlszeile ein. Mit screen -ls kannst du eine Liste der verfügbaren Bildschirme aufrufen:

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

FTD-Joiner einrichten

Wiederholen Sie den obigen Prozess, um das dritte nRF52840-Board mit dem vorhandenen ot-cli-ftd.hex-Build zu flashen. Wenn Sie fertig sind, verbinden Sie die Karte über den nRF-USB-Port wieder mit dem PC und stellen Sie den Schalter für die nRF-Stromquelle auf VDD.

Wenn die anderen beiden Knoten an den Linux-Computer angeschlossen sind, wenn diese dritte Karte angeschlossen ist, sollte sie als serieller Port /dev/ttyACM2 angezeigt werden:

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

Beschriften Sie die Tafel mit dem Namen „Joiner“.

Bei der Überprüfung mit Screen sollten Sie, anstatt eine neue Screen-Instanz über die Befehlszeile zu erstellen, wieder an die vorhandene Instanz anhängen und darin ein neues Fenster öffnen, das Sie für den FTD-Beauftragten verwendet haben:

$ screen -r

Erstellen Sie auf dem Bildschirm ein neues Fenster mit Strg + A → c.

Eine neue Befehlszeilen-Eingabeaufforderung wird angezeigt. Greifen Sie auf die OpenThread-Befehlszeile für den FTD-Joiner zu:

$ screen /dev/ttyACM2 115200

Drücken Sie in diesem neuen Fenster mehrmals die Eingabetaste auf der Tastatur, um die >-Eingabeaufforderung der OpenThread-Befehlszeile aufzurufen. Rufen Sie die IPv6-Schnittstelle auf und prüfen Sie die Adressen:

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

Da sich die FTD Joiner-Befehlszeile nun in derselben Bildschirminstanz wie der FTD Provisioner befindet, können Sie mit Strg + A → n zwischen ihnen wechseln.

Drücken Sie Strg + A →

d , um den Bildschirm zu verlassen.

6. Einrichtung des Terminalfensters

In Zukunft wirst du häufig zwischen Thread-Geräten wechseln. Achte also darauf, dass alle aktiv und leicht zugänglich sind. Bisher haben wir Screen verwendet, um auf die beiden FTDs zuzugreifen. Dieses Tool ermöglicht auch den Splitscreen im selben Terminalfenster. Damit können Sie sehen, wie ein Knoten auf Befehle reagiert, die auf einem anderen ausgeführt werden.

Idealerweise sollten Sie vier Fenster sofort zur Hand haben:

  1. ot-daemon-Dienst / Logs
  2. RCP Joiner über ot-ctl
  3. FTD Commissioner über OpenThread-CLI
  4. FTD-Joiner über OpenThread-CLI

Wenn Sie Ihre eigene Terminal- bzw. serielle Portkonfiguration oder ein eigenes Tool verwenden möchten, können Sie diesen Schritt überspringen. Konfigurieren Sie die Terminalfenster für alle Geräte so, wie es für Sie am besten passt.

Bildschirm verwenden

Starten Sie aus Gründen der Nutzerfreundlichkeit nur eine Bildschirmsitzung. Sie sollten bereits einen von haben, wenn Sie beide FTDs einrichten.

Alle Befehle auf dem Bildschirm starten mit Strg + A.

Grundlegende Befehle für den Bildschirm:

Erneut an die Bildschirmsitzung anhängen (über die Befehlszeile)

screen -r

Bildschirmsitzung verlassen

Strg + A → d

Neues Fenster in der Bildschirmsitzung erstellen

Strg + A → c

In derselben Bildschirmsitzung zwischen Fenstern wechseln

Strg + A → n (Vorwärts) Strg + A → p (Zurück)

Aktuelles Fenster in der Bildschirmsitzung beenden

Strg + A → k

Splitscreen

Mit dem Bildschirm können Sie das Terminal in mehrere Fenster aufteilen:

f1cbf1258cf0a5a.png

Auf die Befehle in screen kann mit Strg + A zugegriffen werden. Jeder Befehl sollte mit dieser Zugriffsschlüsselkombination beginnen.

Wenn Sie das Codelab genau befolgt haben, sollten Sie zwei Fenster (FTD Commissioner, FTD Joiner) auf derselben Screen-Instanz haben. Um den Bildschirm zwischen den beiden zu teilen, rufen Sie zuerst Ihre vorhandene Bildschirmsitzung auf:

$ screen -r

Sie sollten eines der FTD-Geräte verwenden. Gehen Sie auf dem Bildschirm wie folgt vor:

  1. Strg + A → S, um das Fenster horizontal zu teilen
  2. Strg + A → Tab, um den Cursor in das neue leere Fenster zu verschieben
  3. Strg + A → n, um zum nächsten Fenster zu wechseln
  4. Ist dies mit dem oberen Fenster identisch, drücken Sie Strg + A → n, um das andere FTD-Gerät aufzurufen.

Sie sind jetzt beide sichtbar. Drücken Sie Strg + A → Tab, um zwischen ihnen zu wechseln. Wir empfehlen, jedes Fenster mit „Strg + A → A“ umzubenennen, um Verwechslungen zu vermeiden.

Erweiterte Nutzung

Um den Bildschirm weiter in Quadranten aufzuteilen und die ot-daemon-Logs und den RCP-Joiner ot-ctl anzusehen, müssen diese Dienste innerhalb derselben Bildschirminstanz gestartet werden. Beenden Sie dazu ot-daemon, beenden Sie ot-ctl und starten Sie die Apps in einem neuen Fenster neu (Strg + A → c).

Diese Einrichtung ist nicht erforderlich und dient dem Nutzer als Übung.

Mit den folgenden Befehlen können Sie Fenster teilen und zwischen Fenstern wechseln:

Neues Fenster erstellen

Strg + A → c

Fenster vertikal teilen

Strg + A →

Fenster horizontal teilen

Strg + A → S

Zum nächsten angezeigten Fenster wechseln

Strg + A → Tab

Im angezeigten Fenster vor- oder zurückwechseln

Strg + A → n oder p

Aktuelles Fenster umbenennen

Strg + A → A

Sie können den Bildschirm jederzeit mit „Strg + A → d“ verlassen und über die Befehlszeile mit screen -r wieder anhängen.

Weitere Informationen zum Bildschirm finden Sie in der Kurzanleitung für den GNU-Bildschirm.

7. Thread-Netzwerk erstellen

Nachdem Sie alle Terminalfenster und -bildschirme konfiguriert haben, können Sie unser Thread-Netzwerk erstellen. Erstellen Sie im FTD Commissioner ein neues operatives Dataset und übergeben Sie einen Commit als aktives Dataset. Das operative Dataset ist die Konfiguration für das Thread-Netzwerk, das Sie erstellen.

## 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

Notieren Sie sich den Netzwerkschlüssel 1234c0de7ab51234c0de7ab51234c0de, der später verwendet wird.

Übernehmen Sie für dieses Dataset ein Commit als aktives Dataset:

> dataset commit active
Done

Rufen Sie die IPv6-Schnittstelle auf:

> ifconfig up
Done

Thread-Protokollvorgang starten:

> thread start
Done

Prüfen Sie nach einem Moment den Gerätestatus. Es sollte der Leader sein. Sie können auch RLOC16 zur späteren Verwendung abrufen.

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

> state
leader
Done
> rloc16
0c00
Done

Prüfen Sie die IPv6-Adressen des Geräts:

## 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)

Das „Codelab“ Netzwerk ist jetzt sichtbar, wenn von anderen Thread-Geräten gescannt wird.

Ab ot-ctl im RCP Joiner:

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

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -36 | 232 |

Über die OpenThread-Befehlszeile im FTD-Joiner:

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

> scan
| PAN  | MAC Address      | Ch | dBm | LQI |
+------+------------------+----+-----+-----+
| c0de | 1ed687a9cb9d4b1d | 11 | -38 | 229 |

Wenn das „Codelab“ Netzwerk nicht in der Liste angezeigt wird, versuchen Sie es noch einmal.

8. RCP-Joiner hinzufügen

Thread Commissioning ist im Netzwerk nicht aktiv. Das bedeutet, dass wir den RCP Joiner dem gerade erstellten Thread-Netzwerk über einen Out-of-Band-Inbetriebnahmeprozess hinzufügen müssen.

Im FTD Commissioner haben wir uns den Netzwerkschlüssel notiert, zum Beispiel 1234c0de7ab51234c0de7ab51234c0de. Wenn Sie den Netzwerkschlüssel noch einmal nachschlagen müssen, führen Sie den folgenden Befehl im FTD Commissioner aus:

## FTD Commissioner ##

> dataset networkkey
1234c0de7ab51234c0de7ab51234c0de
Done

Legen Sie als Nächstes im RCP Joiner den Netzwerkschlüssel des aktiven Datasets auf den Netzwerkschlüssel des FTD Commissioner fest:

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

> dataset networkkey 1234c0de7ab51234c0de7ab51234c0de
Done
> dataset commit active
Done

Prüfen Sie, ob das Dataset richtig festgelegt ist.

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

> dataset
Network Key: 1234c0de7ab51234c0de7ab51234c0de

Thread einrichten, damit der RCP-Joiner dem Codelab beitritt Netzwerk. Warten Sie einige Sekunden und prüfen Sie den Status, RLOC16 und seine IPv6-Adressen:

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

> ifconfig up
Done
> 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

Notieren Sie sich die Mesh-Local-IPv6-Adresse (fdc0:de7a:b5c0:0:66bf:99b9:24c0:d55f hier). Sie benötigen sie später.

Prüfen Sie im FTD Commissioner den Router und die untergeordneten Tabellen, um sicherzugehen, dass beide Geräte zum selben Netzwerk gehören. Verwenden Sie RLOC16, um den RCP-Joiner zu identifizieren.

## 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

Pingen Sie die lokale Mesh-Adresse des RCP-Joiner an (die Mesh-Local-Adresse, die aus der ipaddr-Ausgabe des RCP-Joiners abgerufen wird), um die Konnektivität zu prüfen:

## 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

Wir haben jetzt ein Thread-Netzwerk, das aus zwei Knoten besteht, wie in diesem Topologiediagramm dargestellt:

otcodelab_top01C_2nodes.png

Topologiediagramme

Während Sie den Rest des Codelabs durcharbeiten, wird jedes Mal ein neues Thread-Topologiediagramm angezeigt, wenn sich der Status des Netzwerks ändert. Knotenrollen werden so angegeben:

b75a527be4563215.png

Router sind immer Fünfecke und Endgeräte immer Kreise. Die Zahlen auf jedem Knoten stellen die Router-ID oder die untergeordnete ID dar, die in der CLI-Ausgabe angezeigt wird, je nach aktueller Rolle und Status des jeweiligen Knotens zum jeweiligen Zeitpunkt.

9. FTD-Joiner in Betrieb nehmen

Jetzt fügen wir dem „Codelab“ das dritte Thread-Gerät hinzu Netzwerk. Dieses Mal verwenden wir den sichereren In-Band-Inbetriebnahmeprozess und gestatten nur dem FTD-Joiner den Beitritt.

Rufen Sie für den FTD Joiner die eui64 ab, damit der FTD-Beauftragte sie identifizieren kann:

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

> eui64
2f57d222545271f1
Done

Starten Sie den FTD Commissioner und geben Sie die eui64 des Geräts an, das beitreten kann, zusammen mit den Anmeldedaten des Joiners, z. B. J01NME. Die Joiner-Anmeldedaten sind ein gerätespezifischer String zwischen 6 und 32 Zeichen, der alle Großbuchstaben alphanumerischen Zeichen (0–9 und A–Y, ausgenommen I, O, Q und Z) enthält, die zur besseren Lesbarkeit verwendet werden.

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

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

Wechseln Sie zum FTD-Joiner. Starten Sie die Joiner-Rolle mit den Joiner-Anmeldedaten, die Sie gerade im FTD-Beauftragten eingerichtet haben:

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

> ifconfig up
Done
> joiner start J01NME
Done

Innerhalb etwa einer Minute erhalten Sie eine Bestätigung über eine erfolgreiche Authentifizierung:

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

>
Join success

Thread aufrufen, damit der FTD-Joiner mit dem Codelab verbunden wird und überprüfen Sie sofort den Status und RLOC16:

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

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

Prüfen Sie die IPv6-Adressen des Geräts. Beachten Sie, dass es kein ALOC gibt. Das liegt daran, dass dieses Gerät weder der Leader ist noch eine Anycast-spezifische Rolle hat, für die ein ALOC erforderlich ist.

## 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)

Wechseln Sie sofort zum FTD Commissioner und prüfen Sie anhand des Routers und der untergeordneten Tabellen, ob im „Codelab“ drei Geräte vorhanden sind. Netzwerk:

## 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

Basierend auf RLOC16 hat der FTD-Joiner als Endgerät (untergeordnetes Gerät) an das Netzwerk angehängt. Hier ist unsere aktualisierte Topologie:

otcodelab_top01C_ed01.png

10. Thread in Aktion

Die Thread-Geräte in diesem Codelab sind eine bestimmte Art von Full-Thread-Gerät (Full Thread Device, FTD), die als Router Allowed End Device (REED) bezeichnet wird. Das heißt, sie können entweder als Router oder als Endgerät fungieren und sich von einem Endgerät zu einem Router hochstufen.

Thread kann bis zu 32 Router unterstützen, versucht jedoch, die Anzahl der Router zwischen 16 und 23 zu halten. Wenn ein REED als Endgerät angehängt wird und die Anzahl der Router unter 16 liegt, wird es nach einem zufälligen Zeitraum innerhalb von zwei Minuten automatisch zu einem Router hochgestuft.

Wenn sich nach dem Hinzufügen des FTD-Joiner in Ihrem Thread-Netzwerk zwei untergeordnete Elemente befinden, warten Sie mindestens zwei Minuten und prüfen Sie dann den Router und die untergeordneten Tabellen noch einmal im FTD Commissioner:

## 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

Der FTD-Joiner (Extended MAC = e6cdd2d93249a243) hat sich zu einem Router hochgestuft. Beachte, dass sich RLOC16 unterscheidet (b800 statt 0c02). Das liegt daran, dass RLOC16 auf der Router-ID und der untergeordneten ID eines Geräts basiert. Wenn vom Endgerät zu einem Router gewechselt wird, ändern sich die Werte der Router-ID und der untergeordneten ID. Dies gilt auch für RLOC16.

otcodelab_top01C.png

Bestätigen Sie den neuen Status und RLOC16 auf dem FTD-Joiner:

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

> state
router
Done
> rloc16
b800
Done

Downgrade des FTD-Joiner durchführen

Sie können dieses Verhalten testen, indem Sie manuell ein Downgrade des FTD-Joiner von einem Router auf ein Endgerät durchführen. Ändern Sie den Status in „Child“ und prüfen Sie RLOC16:

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

> state child
Done
> rloc16
0c03
Done

otcodelab_top01C_ed02.png

Im FTD Commissioner sollte nun der FTD-Joiner in der untergeordneten Tabelle angezeigt werden (ID = 3). Während des Übergangs kann es sogar in beiden enthalten sein:

## 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

Nach einiger Zeit wechselt er wieder zu einem Router mit einem RLOC von b800.

otcodelab_top01C.png

Führungselement entfernen

Der Leader wird unter allen Thread-Routern selbst gewählt. Wenn also der aktuelle Leader aus dem Thread-Netzwerk entfernt wird, wird einer der anderen Router zum neuen Leader.

Fahren Sie Thread im FTD Commissioner herunter, um ihn aus dem Thread-Netzwerk zu entfernen:

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

> thread stop
Done
> ifconfig down
Done

Innerhalb von zwei Minuten wird der FTD-Joiner zum neuen Thread-Leader. Prüfen Sie den Status und die IPv6-Adressen des FTD-Joiner, um zu prüfen:

## 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

otcodelab_top02C_01.png

Prüfen Sie die untergeordnete Tabelle. Sie sehen, dass es ein neues RLOC16 gibt. Dies ist der RCP-Joiner, wie aus seiner ID und seinem erweiterten MAC hervorgeht. Um das Thread-Netzwerk zusammenzuhalten, hat es die übergeordneten Router gewechselt, vom FTD Commissioner zum FTD Joiner. Dies führt zu einem neuen RLOC16 für den RCP-Joiner, da sich seine Router-ID von 3 in 46 geändert hat.

## 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

Es kann einige Minuten dauern, bis der RCP Joiner als untergeordnetes Element an den FTD-Joiner angehängt wurde. Prüfen Sie den Status und RLOC16, um Folgendes zu bestätigen:

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

> state
child
> rloc16
b801

FTD-Beauftragter wieder anhängen

Ein Thread-Netzwerk mit zwei Knoten macht nicht viel Spaß. Bringen wir den FTD-Beauftragten wieder online.

Starten Sie Thread im FTD Commissioner neu:

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

> ifconfig up
Done
> thread start
Done

Innerhalb von zwei Minuten wird es automatisch wieder an das Codelab angehängt. Netzwerk als Endgerät und bewirbt sich dann zu einem Router.

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

> state
router
Done

Überprüfen Sie den Router und die untergeordneten Tabellen im FTD Joiner, um Folgendes zu bestimmen:

## 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

otcodelab_top02C_02.png

Unser Thread-Netzwerk besteht wieder aus drei Knoten.

11. Fehlerbehebung

Die Verwaltung eines Thread-Netzwerks mit mehreren Geräten in verschiedenen Terminal- oder Bildschirmfenstern kann kompliziert sein. Befolgen Sie diese Tipps zum „Zurücksetzen“. Status des Netzwerks oder Ihres Arbeitsbereichs, falls Probleme auftreten.

Display

Wenn Sie sich jemals in Ihrer Konfiguration verlieren (zu viele Bildschirmfenster oder „Bildschirme im Bildschirm“), schließen Sie mit Strg + a → K weiter Bildschirmfenster, bis keine vorhanden sind und screen -ls in der Befehlszeile No Sockets found ausgibt. Erstellen Sie dann die Bildschirmfenster für jedes Gerät neu. Der Gerätestatus wird auch bei Beendigung des Bildschirms beibehalten.

Threadknoten

Wenn die Thread-Netzwerktopologie nicht der Beschreibung in diesem Codelab entspricht oder Knoten aus irgendeinem Grund getrennt werden, z. B. weil der Linux-Computer, auf dem sie betrieben werden, in den Ruhezustand gekommen ist, sollten Sie Thread beenden, die Netzwerkanmeldedaten löschen und mit dem Schritt Thread-Netzwerk erstellen noch einmal beginnen.

So setzen Sie die FTDs zurück:

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

Der RCP kann auf die gleiche Weise über ot-ctl zurückgesetzt werden:

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

> thread stop
Done
> ifconfig down
Done
> factoryreset
Done

12. Multicast verwenden

Multicast wird verwendet, um Informationen an eine Gruppe von Geräten gleichzeitig zu kommunizieren. In einem Thread-Netzwerk werden bestimmte Adressen je nach Umfang für die Multicast-Nutzung mit verschiedenen Gerätegruppen reserviert.

IPv6-Adresse

Ebene

Zugestellt an

ff02::1

Link-Local

Alle FTDs und MEDs

ff02::2

Link-Local

Alle FTDs und Border Router

ff03::1

Mesh-Netzwerk (lokal)

Alle FTDs und MEDs

ff03::2

Mesh-Netzwerk (lokal)

Alle FTDs und Border Router

Da wir in diesem Codelab keinen Border Router verwenden, konzentrieren wir uns auf die beiden FTD- und MED-Multicast-Adressen.

Der Link-Local-Bereich umfasst alle Thread-Schnittstellen, die über eine einzelne Funkübertragung oder einen einzelnen „Hop“ erreichbar sind. Die Netzwerktopologie gibt vor, welche Geräte auf einen Ping an die Multicast-Adresse ff02::1 reagieren.

Pingen Sie ff02::1 vom FTD Commissioner an:

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

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

Im Netzwerk befinden sich zwei weitere Geräte (FTD Joiner und RCP Joiner), aber der FTD Commissioner hat nur eine Antwort von der Link-Local-Adresse (LLA) des FTD Joiner erhalten. Das bedeutet, dass der FTD-Joiner das einzige Gerät ist, das der FTD-Beauftragte mit einem einzigen Hop erreichen kann.

otcodelab_top02C_02_LL.png

Pingen Sie jetzt ff02::1 über den FTD-Joiner an:

## 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

Zwei Antworten! Bei der Überprüfung der IPv6-Adressen der anderen Geräte stellen wir fest, dass die erste (mit der Endung 4b1d) die LLA des FTD-Beauftragten und die zweite (mit der Endung 943b) die LLA des RCP Joiner ist.

otcodelab_top02C_02_LL02.png

Das bedeutet, dass der FTD-Joiner direkt mit dem FTD-Beauftragten und dem RCP-Joiner verbunden ist, was unsere Topologie bestätigt.

Mesh-Netzwerk (lokal)

Der Mesh-Local-Bereich umfasst alle Thread-Schnittstellen, die innerhalb desselben Thread-Netzwerks erreichbar sind. Sehen wir uns die Antworten auf einen Ping an die Multicast-Adresse ff03::1 an.

Pingen Sie ff03::1 vom FTD Commissioner an:

## 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

Dieses Mal hat der FTD-Beauftragte zwei Antworten erhalten: eine vom Routing Locator des FTD Joiner (RLOC, endend auf b800) und eine von der Mesh-Local-EID des RCP Joiner (ML-EID, mit der Endung d55f). Das liegt daran, dass der lokale Mesh-Bereich das gesamte Thread-Netzwerk umfasst. Ganz gleich, wo sich ein Gerät im Netzwerk befindet, es wird die ff03::1-Adresse abonniert.

otcodelab_top02C_02_ML.png

Pingen Sie ff03::1 über den FTD-Joiner an, um das gleiche Verhalten zu bestätigen:

## 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

otcodelab_top02C_02_LL02.png

Notieren Sie sich die Antwortzeit für den RCP-Joiner in beiden Ping-Ausgaben. Der RCP-Joiner brauchte viel länger, um den FTD-Beauftragten zu erreichen (68 ms), als er den FTD-Joiner erreichte (23 ms). Das liegt daran, dass zwei Sprünge nötig sind, um den FTD-Beauftragten zu erreichen, im Vergleich zu einem Sprung für den FTD-Joiner.

Möglicherweise haben Sie auch festgestellt, dass der lokale Multicast-Ping mit dem RLOC nur für die beiden FTDs und nicht für den RCP Joiner mit dem RLOC geantwortet hat. Das liegt daran, dass die FTDs Router im Netzwerk sind, während der RCP ein Endgerät ist.

Prüfen Sie zur Bestätigung den Status von RCP Joiner:

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

> state
child

13. Nachrichten mit UDP senden

Einer der von OpenThread bereitgestellten Anwendungsdienste ist das User Datagram Protocol (UDP), ein Transport Layer-Protokoll. Eine auf OpenThread basierende Anwendung könnte die UDP-API verwenden, um Nachrichten zwischen Knoten in einem Thread-Netzwerk oder an andere Geräte in einem externen Netzwerk (z. B. das Internet, wenn das Thread-Netzwerk über einen Border Router verfügt) weiterzuleiten.

UDP-Sockets werden über die OpenThread-Befehlszeile freigegeben. Lassen Sie uns damit Nachrichten zwischen den beiden FTDs übergeben.

Rufen Sie die Mesh-Local-EID-Adresse für den FTD-Joiner ab. Wir verwenden diese Adresse, weil sie von überall im Thread-Netzwerk erreichbar ist.

## 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

Starten Sie UDP und binden Sie es an einen Socket für eine beliebige IPv6-Adresse:

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

> udp open
Done
> udp bind :: 1212

Wechseln Sie zum FTD Commissioner, starten Sie UDP und stellen Sie mithilfe der ML-EID eine Verbindung zu dem Socket her, den Sie im FTD Joiner eingerichtet haben:

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

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

Die UDP-Verbindung sollte zwischen den beiden Knoten aktiv sein. Senden Sie eine Nachricht vom FTD-Beauftragten:

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

> udp send hellothere
Done

Im FTD Joiner ist die UDP-Nachricht eingegangen.

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

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

14. Glückwunsch!

Du hast ein physisches Thread-Netzwerk erstellt.

b915c433e7027cc7.png

Jetzt wissen Sie:

  • Unterschied zwischen Gerätetypen, Rollen und Bereichen für Threads
  • wie Thread-Geräte ihren Status im Netzwerk verwalten
  • Wie einfache Nachrichten zwischen Knoten mit UDP weitergeleitet werden

Nächste Schritte

Probiere die folgenden Übungen aus, die auf diesem Codelab aufbauen:

  • Flashen Sie das FTD-Joiner Board noch einmal als MTD mit dem ot-cli-mtd-Binärprogramm und stellen Sie fest, dass es sich nie selbst auf einen Router aktualisiert oder versucht, der Leader zu werden
  • Fügen Sie dem Netzwerk weitere Geräte hinzu (probieren Sie eine andere Plattform aus) und skizzieren Sie die Topologie mithilfe von Routern und untergeordneten Tabellen sowie Pings zu den Multicast-Adressen.
  • Pyspinel zur Kontrolle des NCP verwenden
  • Konvertieren Sie den NCP mithilfe eines OpenThread-Border-Routers in einen Border-Router und verbinden Sie das Thread-Netzwerk mit dem Internet

Weitere Informationen

Unter openthread.io und GitHub finden Sie eine Vielzahl von OpenThread-Ressourcen, darunter:

Referenz: