CNX Software: Erste Schritte mit dem GL-S200 Thread Border Router Kit

Letzte Woche haben wir uns die Hardware des GL.iNet GL-S200 Thread Border Router Kits mit drei nRF52840 Thread Dev Boards angesehen. Inzwischen hatte ich Gelegenheit, mit dem Kit zu arbeiten. Daher berichte ich im zweiten Teil des Tests von meinen ersten Erfahrungen.

Ersteinrichtung des GL-S200

Ich verband den WAN-Port mit meinem Ethernet-Switch, der wiederum mit meinem Modemrouter verbunden war, und den LAN-Port mit meinem Laptop. So konnte ich über die Standard-IP-Adresse (192.168.8.1) auf die Weboberfläche zugreifen. Der GL-S200 verwendet dasselbe Admin Panel wie andere GL.iNet-Router, etwa der Beryl AX Router, den wir zu Beginn des Jahres getestet haben.

Ein Assistent begrüßt Sie, in dem Sie die Sprache auswählen und ein neues Passwort für das Admin Panel festlegen. Anschließend erhalten Sie Zugriff auf das vertraute GL.iNet Admin Panel 4.x.x.

Nach Abschluss des Assistenten sollte sich das System automatisch mit dem Internet verbinden und die mittlere RGB-LED am Gerät grün leuchten.

Thread-Netzwerk

Als Erstes wechseln Sie im linken Bereich zu THREAD MESH, um das Thread-Netzwerk zu aktivieren.

Nach einem Klick auf Enable erhalten Sie drei IPv6-Adressen:

• Link-Local Address – Alle Schnittstellen, die mit einer einzelnen Funkübertragung erreichbar sind

• Local Address – Alle Schnittstellen, die außerhalb eines Thread-Netzwerks erreichbar sind (in der OpenThread-Dokumentation scheint dies Global Address zu heißen)

  Update von GL.iNet: Der Zugriff auf das globale IPv6-Internet wird von OT/OTBR noch nicht unterstützt.

  Die offizielle Antwort von OpenThread finden Sie hier: https://github.com/openthread/openthread/discussions/8794

  Die lokale Adresse ist eine OMR-Adresse (off-mesh-routable), über die Sie von der Wi-Fi-/Ethernet-Seite auf Thread-Geräte zugreifen können.

• Mesh-Local EID – Alle Schnittstellen, die innerhalb desselben Thread-Netzwerks erreichbar sind

Wenn Sie eigene Thread-Geräte haben, können Sie zum Menü Thread Commissioning wechseln und die EUI64 Ihrer Geräte sowie den Pre-Shared Key eingeben. GL.iNet hat jedoch einen einfacheren Bereich in der Weboberfläche für die eigenen Thread Dev Boards, kurz TBD, eingerichtet.

Im Bereich GL DEV BOARD->Devices können wir auf die Schaltfläche Add Devices und anschließend auf Apply klicken. Wenn wir den SW2-Schalter auf einem Board drücken, wird es automatisch zum GL-S200 Thread Border Router hinzugefügt.

Wir sollten den Typ A0+A1 auswählen und dem Board einen Namen geben. Das Gleiche können wir für die beiden anderen Boards wiederholen. Anschließend zeigt das Admin Panel Temperatur-, Druck-, Feuchtigkeits- und Beleuchtungsstärkewerte für alle drei Boards an.

GL-S200-Firmware-Update

Zu diesem Zeitpunkt fiel mir ein, dass ich etwas vergessen hatte: GL.iNet teilte mir mit, dass eine neue Firmware für den GL-S200 verfügbar sei, die ich manuell einspielen sollte. Wechseln wir dafür zu „SYSTEM->Upgrade“.

Im Admin Panel wird die Firmware 4.1.3 Release 5 als aktuell angezeigt, da die neue Firmware nicht auf den OTA-Server übertragen wurde. Mir wurde jedoch ein Download-Link zu einer neueren Firmware bereitgestellt, die am 6. März 2023 kompiliert wurde.

Ich lud die Datei herunter, wechselte zum Bereich Local Upgrade und lud die Datei auf den GL-S200 Thread Border Router hoch.

Die Überprüfung war erfolgreich. Daher klickte ich auf Install und installierte schließlich Firmware 4.1.3 Release7 auf meinem Gerät.

Firmware der Thread Dev Boards aktualisieren

Während ich mich mit dem Firmware-Update beschäftigte, stellte ich fest, dass auch für die Thread Dev Boards ein Firmware-Update von Version 1.1.5 auf 1.1.9 verfügbar war. Ich führte es durch, und es funktionierte problemlos.

Thread-Topologie

Thread basiert auf Mesh-Netzwerken. Befinden sich Knoten in Routernähe, verbinden sie sich direkt mit dem Router; bei zu großer Entfernung oder schwachem Signal können sie selbst als Router agieren. Mit allen Geräten auf meinem Schreibtisch …

… hatte das Netzwerk erwartungsgemäß eine Stern-Topologie.

Daher stellte ich die Boards weiter auseinander und in einer geraden Linie auf; eines platzierte ich sogar im Freien.

Das Board im Freien lässt sich anhand der höheren Temperatur und Beleuchtungsstärke leicht erkennen.

Wenn wir im Topologiediagramm auf „Self“ klicken, sehen wir auch die Signalstärke des mit dem Thread Border Router verbundenen Knotens. Ich konnte das Thread Dev Board jedoch nie als Router einsetzen. Wir gingen sogar nach draußen, um außer Reichweite zu kommen oder zumindest ein schwächeres Signal zu erhalten, doch das Mesh-Netzwerk funktionierte nicht wie erwartet. Daher fragte ich die GL.iNet-Ingenieure. Sie antworteten, dass dafür eine Thread-Router-Firmware erforderlich sei:

Unsere Standard-TBD-Firmware ist derzeit vom Typ Thread-Endgerät und kann nicht direkt miteinander verbunden werden. Wir stellen Ihnen im Laufe des Tages die Thread-Router-Firmware und die entsprechende TBD-Flash-Anleitung bereit.

Sie schickten mir die Router-Firmware sowie das mcumgr Dienstprogramm für Linux und Windows.

Ich schloss eines der Thread Dev Boards an einen Linux-PC (Ubuntu 22.04) an:

print(“Hello World”) wird als print(“Hello World”)` angezeigt.

$ bt -l
 port |  age (sec) | device     | driver           | description
------+------------+------------+------------------+----------------------
 *  0 |       1137 | ttyUSB0    | ch341-uart       | USB Serial

Der serielle Port wird erkannt. Daher kann ich den folgenden Befehl ausführen, um den aktuellen Firmwarestatus zu überprüfen:

$ sudo ./mcumgr --conntype serial --connstring=/dev/ttyUSB0,baud=460800 image list
Error: NMP timeout
jaufranc@cnx-laptop-4:~/edev/GL-S200/TBD upgrade$ sudo ./mcumgr --conntype serial --connstring=/dev/ttyUSB0,baud=460800 image list
Images:
 image=0 slot=0
    version: 1.1.9
    bootable: true
    flags: active confirmed
    hash: 88b4725af7975e0b60915c320a82082bb2dda923b736f0e31d2c7d4d67cac3d3
 image=0 slot=1
    version: 1.1.5
    bootable: true
    flags:
    hash: 4d8548e6910e7214d8325a7d1a49a8390fb25cce983bdb0b15bfecc657f7860b
Split status: N/A (0)

Beim ersten Mal schlug es mit dem Fehler „NMP timeout“ fehl, beim zweiten Versuch funktionierte es jedoch. Wir sehen, dass sich die im Admin Panel aktualisierte Firmware 1.1.9 in Slot 0 und die frühere Firmware 1.1.5 in Slot 1 befindet. Nun kann ich versuchen, die Router-Firmware zu flashen:

$ sudo ./mcumgr --conntype serial --connstring=/dev/ttyUSB0,baud=460800 image upload GL-Thread-Dev-Board-FTD-OTA-v1.1.9.bin
 426.58 KiB / 426.58 KiB [========================] 100.00% 8.93 KiB/s 47s
Done

Überprüfen wir es erneut:

$ sudo ./mcumgr --conntype serial --connstring=/dev/ttyUSB0,baud=460800 image list
Images:
 image=0 slot=0
    version: 1.1.9
    bootable: true
    flags: active confirmed
    hash: 88b4725af7975e0b60915c320a82082bb2dda923b736f0e31d2c7d4d67cac3d3
 image=0 slot=1
    version: 1.1.9
    bootable: true
    flags:
    hash: 7dbb8a9867a000bb968099593bc1f6c2c7bb28ab458719f499364c4a77feca9f
Split status: N/A (0)
Done

Die Firmware in Slot 0 ist die aktuell ausgeführte Firmware, während die Firmware in Slot 1 die gerade geflashte Router-Version ist. Wir können wie folgt zur neuen Firmware wechseln:

sudo ./mcumgr --conntype serial --connstring=/dev/ttyUSB0,baud=460800 image test 7dbb8a9867a000bb968

Anschließend können wir das Board neu starten und sicherstellen, dass sich die neue Firmware mit dem Hash-Präfix 7dbb in Slot 0 befindet:

$ sudo ./mcumgr --conntype serial --connstring=/dev/ttyUSB0,baud=460800 image list
Images:
 image=0 slot=0
    version: 1.1.9
    bootable: true
    flags: active confirmed
    hash: 7dbb8a9867a000bb968099593bc1f6c2c7bb28ab458719f499364c4a77feca9f
 image=0 slot=1
    version: 1.1.9
    bootable: true
    flags:
    hash: 88b4725af7975e0b60915c320a82082bb2dda923b736f0e31d2c7d4d67cac3d3
Split status: N/A (0)

Nachdem wir das Board wieder zum Admin Panel hinzugefügt haben, sehen wir den Thread Leader (GL-S200), zwei Endgeräte und einen Router, also das Board, das wir gerade mit der Router-Firmware geflasht haben.

Keines der Endgeräte ist mit dem Router auf Board 1 verbunden, da sich alle auf meinem Schreibtisch befinden und mit dem GL-S200 verbunden sind. Daher brachte ich Board 1 zusammen mit einem der Endgeräte in einen anderen Raum, 12 Meter vom GL-S200 Thread Border Router entfernt. Die Topologie änderte sich jedoch nicht. Die Verbindung scheint „klebrig“ zu sein: Ein Thread-Knoten verbindet sich nur dann mit einem anderen Router, wenn er außer Reichweite ist, nicht allein aufgrund der Signalstärke.

Als ich den GL-S200 jedoch ausschaltete und neu startete, hatten sich die beiden Endgeräte erneut mit dem Router auf Board 1 verbunden, der nun der „Thread Leader“ im Netzwerk war.

Es funktioniert also. Ich hatte jedoch nicht erwartet, dass es genau so funktioniert: Board 2 ist 10 Zentimeter vom GL-S200 Thread Border Router (self) entfernt und Board 1 12 Meter, doch Board 2 verband sich auch nach einiger Zeit nicht erneut mit dem GL-S200. Anders gesagt: Solange die Verbindung besteht, verbindet sich ein Thread-Knoten nicht mit einem anderen Router, selbst wenn dieser näher ist und ein stärkeres Signal bietet. Für die Akkulaufzeit ergibt das vermutlich Sinn.

Daher nahm ich Board 2 (Endgerät) und Board 1 (Router) auf einen kurzen Ausflug außerhalb der Reichweite des GL-S200 mit. Dann schaltete ich zuerst Board 1 und anschließend Board 2 ein, um sicherzustellen, dass sie sich verbanden, und ging nach Hause zurück. Es funktionierte: Wie im obigen Diagramm verbindet sich Board 2 über Board 1 als Router mit dem GL-S200 „Thread Leader“.

Informationen zum GL Thread Dev Board

Wenn wir bei einem bestimmten Gerät auf die drei Punkte in der Spalte Action klicken, erhalten wir Zugriff auf weitere Optionen: Device Detail, View Records, Edit Device, Get Code und Reset Device.

Geräteinformationen

Wir erhalten die EUI-64, den Namen, die IPv6-Adresse, die erweiterte MAC-Adresse (64-Bit statt der üblichen 48-Bit), die Firmwareversion und Sensordaten.

View Records

Nachdem die Boards über 24 Stunden lang gelaufen waren, rief ich das Menü „View Records“ auf, um Diagramme mit den Sensorwerten eines bestimmten Boards anzusehen.

Es sieht größtenteils in Ordnung aus. Wie Sie unten links sehen, gibt es Werte um 21 Uhr, doch das Diagramm beginnt aus irgendeinem Grund erst um 23 Uhr. Das ist bei allen Boards gleich.

Im Stundendiagramm sieht es noch schlechter aus. Da wir auf der linken Seite immer einen Datenpunkt erhalten, scheint es sich eher um einen Anzeigefehler als um fehlende Datenpunkte zu handeln.

Codebeispiele

Der Bereich „Get Code“ ist möglicherweise der wichtigste Teil, wenn Sie Ihre eigenen Thread-Geräte mit den fünf bereitgestellten Codebeispielen überwachen und steuern möchten.

Um die Beispiele auszuführen, müssen wir uns per SSH mit dem GL-S200 Thread Border Router verbinden. Beginnen wir mit dem Code zum Auslesen von Sensordaten.

root@GL-S200:~# /usr/bin/demo_get_sensor_data
1 dev_id=9483c44004df0679 connected=1 temperature=31.300811 humidity=43.409729 brightness=0 pressure=97.817392
2 dev_id=9483c47d79c19475 connected=1 temperature=32.742767 humidity=53.620910 brightness=0 pressure=97.814472
3 dev_id=9483c4ec736c4f68 connected=1 temperature=31.292800 humidity=42.652893 brightness=0 press

Wir können auch ein bestimmtes Gerät anhand seiner EUI-64 auswählen:

root@GL-S200:~# /usr/bin/demo_get_sensor_data 9483c44004df0679
dev_id=9483c44004df0679 connected=1 temperature=31.300811 humidity=43.409729 brightness=0 pre

Hier ist der Quellcode als Referenz:

#!/bin/sh
# Note, this file is stored in /usr/bin/demo_get_sensor_data
# Usage: demo_get_sensor_data <dev_id>
# It will print all sensor data if <dev_id> is null, and the <dev_id> is the EUI64 of the device, which saved in /etc/config/thread_devices

. /usr/share/libubox/jshn.sh

dev_id=$1
if [ -z "$dev_id" ]; then
    res=$(curl -s localhost/rpc -d '{"jsonrpc":"2.0","id":"0","method":"call","params":["","gw","get_device_list",{}]}')

    json_init
    json_load "$res"
    json_select result
    json_select device_list
    idx=1
    while json_is_a ${idx} object; do
        json_select ${idx}
        json_get_var dev_id dev_id
        json_get_var connected connected

        json_select dev_data
        json_get_var val_temp temperature
        json_get_var val_humi humidity
        json_get_var val_brightness brightness
        json_get_var val_pressure pressure
        echo "$idx dev_id=$dev_id connected=$connected temperature=$val_temp humidity=$val_humi brightness=$val_brightness pressure=$val_pressure"

        json_select ..
        json_select ..

        idx=$((idx + 1))
    done
else
    res=$(curl -s localhost/rpc -d "{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"call\",\"params\":[\"\",\"gw\",\"get_device_status\",{\"dev_id\":\"$dev_id\"}]}")

    json_init
    json_load "$res"
    json_select result
    json_get_var dev_id dev_id
    json_get_var connected connected
    json_select dev_data
    json_get_var val_temp temperature
    json_get_var val_humi humidity
    json_get_var val_brightness brightness
    json_get_var val_pressure pressure
    echo "dev_id=$dev_id connected=$connected temperature=$val_temp humidity=$val_humi brightness=$val_brightness pressure=$val_pressure"
fi

Probieren wir die anderen Beispiele aus.

ls  /usr/bin/demo*
/usr/bin/demo_control_gpio         /usr/bin/demo_sensor_trigger
/usr/bin/demo_control_led          /usr/bin/demo_user_action_trigger
/usr/bin/demo_get_sensor_data

Das zweite Beispiel steuert die zwei RGB-LEDs auf dem anhand seiner EUI-64-Geräte-ID ausgewählten Board:

root@GL-S200:~#  /usr/bin/demo_control_led 9483c44004df0679
LED OFF
LED ON
LED OFF
LED TOGGLE
Changle LED Color to Red light
Changle LED Color to Orange light
Changle LED Color to Yellow light
Changle LED Color to Green light
Changle LED Color to Blue light
Changle LED Color to Indigo light
Changle LED Color to Purple light
Changle LED Color to White light

Hier ist eine kurze Videodemonstration, die das Ergebnis zeigt.

Das GPIO-Steuerungsbeispiel setzt einige I/O-Pins für ein bestimmtes Board in den Ausgabemodus und auf niedrigen beziehungsweise hohen Pegel:

root@GL-S200:~#  /usr/bin/demo_control_gpio 9483c44004df0679
Get GPIO Status
GPIO 0.15: 0
GPIO 0.16: 0
GPIO 0.17: 0
GPIO 0.20: 0
Set GPIO 0.15/0.16/0.17/0.20 to output low level
Get GPIO Status
GPIO 0.15: 0
GPIO 0.16: 0
GPIO 0.17: 0
GPIO 0.20: 0
Set GPIO 0.15/0.16/0.17/0.20 to output high level
Get GPIO Status
GPIO 0.15: 1
GPIO 0.16: 1
GPIO 0.17: 1
GPIO 0.20: 1

Die letzten beiden Beispiele zur Steuerung der LEDs und GPIOs verwenden den Befehl coap_cli „small CoAP implementation“, um beispielsweise die LEDs auszuschalten:

coap_cli -B 2 -N -e "$ctl_cmd_led_off" -m put coap://[$addr]/cmd 1>/dev/null 2>/

Verwendung von coap_cli:

root@GL-S200:~# coap_cli
coap_cli v4.2.1 -- a small CoAP implementation
Copyright (C) 2010-2019 Olaf Bergmann <bergmann@tzi.org> and others

TLS Library: None

Usage: coap_cli [-a addr] [-b [num,]size] [-e text] [-f file] [-l loss]
		[-m method] [-o file] [-p port] [-r] [-s duration] [-t type]
		[-v num] [-A type] [-B seconds] [-K interval] [-N] [-O num,text]
		[-P addr[:port]] [-T token] [-U]
		[[-k key] [-u user]]
		[[-c certfile] [-C cafile] [-R root_cafile]] URI

	URI can be an absolute URI or a URI prefixed with scheme and host

General Options
	-a addr		The local interface address to use
	-b [num,]size	Block size to be used in GET/PUT/POST requests
	       		(value must be a multiple of 16 not larger than 1024)
	       		If num is present, the request chain will start at
	       		block num
	-e text		Include text as payload (use percent-encoding for
	       		non-ASCII characters)
	-f file		File to send with PUT/POST (use '-' for STDIN)
	-l list		Fail to send some datagrams specified by a comma
	       		separated list of numbers or number ranges
	       		(for debugging only)
	-l loss%	Randomly fail to send datagrams with the specified
	       		probability - 100% all datagrams, 0% no datagrams
	-m method	Request method (get|put|post|delete|fetch|patch|ipatch),
	       		default is 'get'
	-o file		Output received data to this file (use '-' for STDOUT)
	-p port		Listen on specified port
	-r     		Use reliable protocol (TCP or TLS)
	-s duration	Subscribe to / Observe resource for given duration
	       		in seconds
	-t type		Content format for given resource for PUT/POST
	-v num 		Verbosity level (default 3, maximum is 9). Above 7,
	       		there is increased verbosity in GnuTLS logging
	-A type		Accepted media type
	-B seconds	Break operation after waiting given seconds
	       		(default is 90)
	-K interval	send a ping after interval seconds of inactivity
	-N     		Send NON-confirmable message
	-O num,text	Add option num with contents text to request. If the
	       		text begins with 0x, then the hex text is converted to
	       		binary data
	-P addr[:port]	Use proxy (automatically adds Proxy-Uri option to
	       		request)
	-T token	Include specified token
	-U     		Never include Uri-Host or Uri-Port options
PSK Options (if supported by underlying (D)TLS library)
	-k key 		Pre-shared key for the specified user
	-u user		User identity for pre-shared key mode
PKI Options (if supported by underlying (D)TLS library)
	-c certfile	PEM file containing both CERTIFICATE and PRIVATE KEY
	       		This argument requires (D)TLS with PKI to be available
	-C cafile	PEM file containing the CA Certificate that was used to
	       		sign the certfile. This will trigger the validation of
	       		the server certificate.  If certfile is self-signed (as
	       		defined by '-c certfile'), then you need to have on the
	       		command line the same filename for both the certfile and
	       		cafile (as in '-c certfile -C certfile') to trigger
	       		validation
	-R root_cafile	PEM file containing the set of trusted root CAs that
	       		are to be used to validate the server certificate.
	       		The '-C cafile' does not have to be in this list and is
	       		'trusted' for the verification.
	       		Alternatively, this can point to a directory containing
	       		a set of CA PEM files

Examples:
	coap-client -m get coap://[::1]/
	coap-client -m get coap://[::1]/.well-known/core
	coap-client -m get coap+tcp://[::1]/.well-known/core
	coap-client -m get coaps://[::1]/.well-known/core
	coap-client -m get coaps+tcp://[::1]/.well-known/core
	coap-client -m get -T cafe coap://[::1]/time
	echo -n 1000 | coap-client -m put -T cafe coap://[::1]/time -f -

Das Action-Trigger-Beispiel meldet den Status des Drehknopfs:

root@GL-S200:~#  /usr/bin/demo_user_action_trigger 9483c44004df0679
2023/03/19 17:38:14 info (/usr/bin/demo_user_action_trigger:34) 9483c44004df0679: Press the knob.
2023/03/19 17:38:16 info (/usr/bin/demo_user_action_trigger:34) 9483c44004df0679: Press the knob.
2023/03/19 17:38:18 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679: Turn the knob forward
2023/03/19 17:38:19 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679: Turn the knob forward
2023/03/19 17:38:20 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679: Turn the knob forward
2023/03/19 17:38:20 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679: Turn the knob reverse
2023/03/19 17:38:21 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679: Turn the knob reverse
2023/03/19 17:38:21 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679: Turn the knob reverse
2023/03/19 17:38:23 info (/usr/bin/demo_user_action_trigger:34) 9483c44004df0679: Press the knob.
2023/03/19 17:38:25 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679: Turn the

Der Code basiert auf der Binärdatei /usr/bin/eco [Update: Offenbar handelt es sich um das eco-lua Lua-Interpreterprojekt, siehe den Kommentarbereich]:

#!/usr/bin/env eco

-- Note, this file is stored in /usr/bin/demo_user_action_trigger, It listens for events reported when the user operates the knob.
-- Usage: demo_sensor_trigger

local ubus = require 'eco.ubus'
local sys = require 'eco.sys'
local cjson = require 'cjson'
local log = require "glog"

local OPT_TURNING_THE_KNOB = 1
local OPT_PRESS_THE_KNOB = 2

log.level(log.LOG_INFO)

sys.signal(sys.SIGINT, function()
    print('
Got SIGINT, now quit')
    eco.unloop()
end)

local con, err = ubus.connect()
if not con then
    error(err)
end

con:listen('user_active_trigger', function(ev, msg)
    local event_data = cjson.encode(msg)
    log.debug('Recievd user active trigger ' .. ev .. ' ' .. event_data)

    local trigger, operation, direction = msg.trigger, msg.operation, msg.direction
    if operation == OPT_TURNING_THE_KNOB then
        log.info(trigger .. ': Turn the knob ' .. direction)
    elseif operation == OPT_PRESS_THE_KNOB then
        log.info(trigger .. ': Press the knob.')
    else
        log.err('Unknown operation!')
    end
end)

Dasselbe gilt für das Sensor-Trigger-Beispiel, das den PIR-Sensor aller mit dem GL-S200 Thread Border Router verbundenen Thread Dev Boards überwacht:

root@GL-S200:~#  /usr/bin/demo_sensor_trigger
2023/03/19 17:47:46 info (/usr/bin/demo_sensor_trigger:31) 9483c44004df0679: Human body detected.
2023/03/19 17:47:46 info (/usr/bin/demo_sensor_trigger:31) 9483c4ec736c4f68: Human body detected.
2023/03/19 17:47:49 info (/usr/bin/demo_sensor_trigger:31) 9483c4ec736c4f68: Human body detected.
2023/03/19 17:47:52 info (/usr/bin/demo_sensor_trigger:31) 9483c44004df0679: Human body detected.
2023/03/19 17:48:15 info (/usr/bin/demo_sensor_trigger:31) 9483c47d79c19475: Human body detected.

All diese Beispiele können Ihnen den Einstieg in eigene Skripte erleichtern.

GL-S200 „Automations“

Der Bereich GL DEV BOARDS enthält außerdem einen Abschnitt „Automations“.

Ich versuche, die RGB-LEDs auf zwei Thread Dev Boards mit dem Drehknopf auf dem verbleibenden dritten Board zu steuern.

Nachdem wir der Automatisierung einen Namen gegeben haben, können wir User Action und dann das Board auswählen, das wir als Drehknopf verwenden: „Board 2“.

Ich wählte „Turning the knob“ und anschließend „Device(s) Action“ aus.

Da ich die beiden anderen Boards steuern möchte, wählte ich „Board 1“ und „Board 2“ aus.

Danach ist „Change Color“ die einzige Option. Wählen wir sie also aus und klicken auf Apply.

Das funktioniert jedoch nicht: Die RGB-LEDs bleiben ausgeschaltet, egal in welche Richtung ich den Knopf drehe. Schließlich stellte ich fest, dass die RGB-LEDs eingeschaltet sein müssen, bevor sich die Farben ändern lassen. Daher erstellte ich eine weitere Automatisierung, um die LEDs durch Drücken des Drehknopfs ein- und auszuschalten.

Und jetzt funktioniert es.

Der Bereich Automation unterstützt auch Webhooks. Daher entschied ich mich, eine Automatisierung zu erstellen, die mich bei erkannter Bewegung in Discord benachrichtigt. Dafür erstellte ich einen Discord-Server und erhielt eine Webhook-URL (https://discord.com/api/webhooks/xxxx), indem ich der Anleitung auf Discord folgte.

Anschließend erstellte ich eine weitere Automatisierung und wählte Sensor Trigger aus …

… „Human Body Detected“ (das lediglich bedeutet, dass der PIR-Bewegungssensor ausgelöst wurde)

… und „Webhook“.

Dort fügte ich meine Webhook-URL hinzu, wählte Json aus und ergänzte etwa folgenden Inhalt:

{"content":"OMG! Somebody has just entered the bedroom!"}

Abschließend klickte ich auf Apply und wiederholte den Vorgang, um Bewegungen in der Küche und im Büro zu erkennen.

Nun kann ich Discord öffnen und im Haus umhergehen, um die PIR- Bewegungssensoren aller drei Boards auszulösen.

Erfolg! Der Bereich für Automatisierungen ist ziemlich gelungen, scheint jedoch nur mit GL.iNet Thread Dev Boards zu funktionieren. Ich fragte daher, ob der Quellcode geteilt würde, damit Anwender die Lösung für ihre eigenen Thread-Geräte anpassen können, erhielt auf diese konkrete Frage aber keine Antwort.

Verschiedenes

Wie andere GL.iNet-Netzwerkgeräte unterstützt der GL-S200 GoodCloud für den Fernzugriff. Der Nutzen ist jedoch begrenzt, da die Thread- und Bluetooth- Funktionen nicht unterstützt werden.

Zunächst dachte ich, die Taste Mode Switch könne zum Wechsel zwischen BLE und Thread dienen. Wie bei früheren Routern kann sie jedoch so eingestellt werden, dass sie WireGuard oder OpenVPN ein- bzw. ausschaltet.

Aus Zeitgründen habe ich die Bluetooth-Funktion nicht getestet. Ich erwarte jedoch, dass Oberfläche und Nutzung ähnlich wie bei der GL-S10 BLE-zu-MQTT-Bridge sind, die ich letztes Jahr getestet habe.

Das war eine interessante Erfahrung, und ich möchte GL.iNet dafür danken, dass das GL-S200 Thread Border Router Kit zur Evaluierung bzw. zum Beta-Test bereitgestellt wurde. Das von mir erhaltene Kit kann für $154.00 zuzüglich Versand vorbestellt werden. Falls Sie bereits eigene Thread-Knoten haben, ist der GL-S200 allein während des Vorbestellzeitraums für $79 erhältlich; danach kostet er $99.

Jean-Luc Aufranc (CNXSoft) Jean-Luc gründete CNX Software 2010 zunächst nebenberuflich. Er kündigte anschließend seine Stelle als Manager für Softwareentwicklung und begann später im Jahr 2011, täglich hauptberuflich Nachrichten und Tests zu schreiben.

Diesen Test auf CNX Software lesen