CNX Software recenzuje pierwsze kroki z zestawem routera brzegowego Thread GL-S200

W zeszłym tygodniu przyjrzeliśmy się sprzętowi z zestawu routera brzegowego Thread GL.iNet GL-S200 z trzema płytkami Thread Dev Board nRF52840, a teraz miałem czas popracować z zestawem, więc w drugiej części recenzji opiszę swoje pierwsze doświadczenia.

Pierwsza konfiguracja GL-S200

Podłączyłem port WAN do przełącznika Ethernet połączonego z moim routerem z modemem, a port LAN do laptopa, aby otworzyć interfejs WWW pod domyślnym adresem IP (192.168.8.1). GL-S200 korzysta z tego samego panelu administracyjnego co inne routery GL.iNet, na przykład router Beryl AX który recenzowaliśmy na początku roku.

Przywita Cię kreator umożliwiający wybór języka i ustawienie nowego hasła panelu administracyjnego. Po zakończeniu uzyskasz dostęp do znanego panelu administracyjnego GL.iNet 4.x.x.

Po zakończeniu kreatora system powinien automatycznie połączyć się z Internetem, a środkowa dioda RGB na urządzeniu zaświeci na zielono.

Sieć Thread

Najpierw przejdź do THREAD MESH w lewym panelu, aby włączyć sieć Thread.

Po kliknięciu Enable otrzymasz trzy adresy IPv6:

• Link-Local Address — wszystkie interfejsy osiągalne za pomocą pojedynczej transmisji radiowej

• Local Address — Wszystkie interfejsy osiągalne spoza sieci Thread (wygląda na to, że w dokumentacji nazwano go Global Address — zobacz dokumentację OpenThread)

  Aktualizacja od GL-iNet: dostęp do globalnego Internetu IPv6 nie jest jeszcze obsługiwany przez OT/OTBR.

  Możesz zapoznać się z oficjalną odpowiedzią OpenThread: https://github.com/openthread/openthread/discussions/8794

  Adres lokalny to adres OMR(off-mesh-routable), który umożliwia dostęp do urządzeń Thread od strony Wi-Fi/Ethernet.

• Mesh-Local EID — wszystkie interfejsy osiągalne w obrębie tej samej sieci Thread

Jeśli masz własne urządzenia Thread, możesz przejść do menu Thread Commissioning i wprowadzić ich EUI64 oraz klucz współdzielony. GL.iNet przygotował jednak prostszą sekcję interfejsu WWW do obsługi swoich płytek Thread Dev Board, w skrócie TBD.

W sekcji GL DEV BOARD->Devices możemy kliknąć przycisk Add Devices , a następnie Apply. Jeśli naciśniemy przełącznik SW2 na jednej płytce, zostanie ona automatycznie dodana do routera brzegowego Thread GL-S200.

Wybierz typ A0+A1 i nadaj płytce nazwę. Powtórz te czynności dla pozostałych dwóch płytek, aby w panelu administracyjnym zobaczyć temperaturę, ciśnienie, wilgotność i natężenie oświetlenia ze wszystkich trzech płytek.

Aktualizacja oprogramowania układowego GL-S200

W tym momencie przypomniałem sobie, że o czymś zapomniałem… GL.iNet poinformował mnie o nowym oprogramowaniu układowym GL-S200, które trzeba zainstalować ręcznie. Zróbmy to teraz, przechodząc do „SYSTEM->Upgrade”.

Panel administracyjny informuje, że oprogramowanie układowe 4.1.3 release 5 jest aktualne, ponieważ nowej wersji nie udostępniono na serwerze OTA. Otrzymałem jednak odnośnik do pobrania nowszego oprogramowania układowego, skompilowanego 6 marca 2023.

Pobrałem plik, przeszedłem do sekcji Local Upgrade i przesłałem go do routera brzegowego Thread GL-S200.

Weryfikacja zakończyła się pomyślnie, więc kliknąłem Install, a ostatecznie oprogramowanie układowe 4.1.3 Release7 zostało zainstalowane na moim urządzeniu.

Aktualizacja oprogramowania układowego płytek Thread Dev Board

Podczas aktualizacji oprogramowania układowego zauważyłem, że płytki Thread Dev Board też można zaktualizować z wersji 1.1.5 do 1.1.9. Zrobiłem to i wszystko przebiegło bez problemów.

Topologia Thread

Thread korzysta z sieci mesh: węzły blisko routera łączą się z nim bezpośrednio, a przy słabym sygnale lub poza zasięgiem same mogą działać jako routery. Gdy wszystkie urządzenia stały na moim biurku…

… sieć zgodnie z oczekiwaniami miała topologię gwiazdy.

Spróbowałem więc odsunąć płytki od siebie i ustawić je w linii prostej, umieszczając jedną nawet na zewnątrz.

Płytkę na zewnątrz łatwo rozpoznać po wyższej temperaturze i natężeniu oświetlenia.

Po kliknięciu „Self” na diagramie topologii zobaczymy też siłę sygnału węzła połączonego z routerem brzegowym Thread. Nie udało mi się jednak użyć płytki Thread Dev Board jako routera. Wyszliśmy nawet na spacer, próbując znaleźć się poza zasięgiem lub przynajmniej osłabić sygnał, ale sieć mesh nie działała zgodnie z moimi oczekiwaniami. Zapytałem więc inżynierów GL.iNet, którzy odpowiedzieli, że wymaga to oprogramowania układowego routera Thread:

Obecnie nasze domyślne oprogramowanie układowe TBD jest typu urządzenie końcowe Thread i nie umożliwia bezpośredniego połączenia płytek ze sobą. Jeszcze dzisiaj udostępnimy Ci oprogramowanie układowe routera Thread oraz odpowiednią instrukcję instalacji na TBD.

Przesłali mi oprogramowanie układowe routera oraz narzędzie mcumgr dla systemów Linux i Windows.

Podłączyłem jedną płytkę Thread Dev Board do komputera z systemem Linux (Ubuntu 22.04):

print(“Hello World”) zostanie wyświetlone jako print(“Hello World”)`.

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

Port szeregowy został wykryty, więc mogę uruchomić polecenie sprawdzające bieżący stan oprogramowania układowego:

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

Pierwsza próba zakończyła się błędem „NMP timeout”, ale druga się udała. Widzimy, że oprogramowanie układowe 1.1.9 zaktualizowane w panelu administracyjnym jest w slocie 0, a wcześniejsza wersja 1.1.5 w slocie 1. Teraz mogę spróbować wgrać oprogramowanie układowe routera:

$ 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

Sprawdźmy jeszcze raz:

$ 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

Oprogramowanie układowe w slocie 0 jest aktualnie uruchomione, a w slocie 1 znajduje się właśnie wgrana wersja Router. Możemy przełączyć się na nową wersję w następujący sposób:

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

Następnie możemy uruchomić płytkę ponownie i upewnić się, że nowe oprogramowanie układowe z hashem zaczynającym się od 7dbb jest w slocie 0:

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

Po ponownym dodaniu płytki do panelu administracyjnego widzimy Thread Leader (GL-S200), dwa urządzenia końcowe i router (płytkę, na którą właśnie wgraliśmy oprogramowanie Router).

Żadne urządzenie końcowe nie łączy się z routerem Board 1, ponieważ wszystkie stoją na moim biurku i są połączone z GL-S200. Przenoszę więc Board 1 i jedno urządzenie końcowe do innego pokoju, 12 metrów od routera brzegowego Thread GL-S200. Topologia jednak się nie zmieniła. Wygląda na to, że połączenie jest „trwałe”: węzeł Thread połączy się z innym routerem tylko po utracie zasięgu, a nie jedynie na podstawie siły sygnału.

Gdy jednak wyłączyłem i ponownie uruchomiłem GL-S200, oba urządzenia końcowe połączyły się z routerem Board 1, który został teraz „Thread Leader” w sieci.

Zatem to działa. Nie spodziewałem się dokładnie takiego zachowania, ponieważ Board 2 znajduje się 10 centymetrów od routera brzegowego Thread GL-S200 (self), a Board 1 jest oddalona o 12 metrów. Board 2 nie połączyła się jednak ponownie z GL-S200, nawet po pewnym czasie. Innymi słowy, dopóki połączenie działa, węzeł Thread nie przełączy się na inny router, nawet bliższy i z silniejszym sygnałem. Przypuszczam, że ma to sens ze względu na czas pracy na baterii.

Zabrałem więc Board 2 (urządzenie końcowe) i Board 1 (router) na krótki spacer poza zasięg GL-S200. Włączyłem Board 1, a następnie Board 2, aby upewnić się, że się połączą, i wróciłem do domu. Zadziałało: na powyższym diagramie Board 2 łączy się z GL-S200 „Thread Leader” przez Board 1 działającą jako router.

Informacje o GL Thread Dev Board

Po kliknięciu trzech kropek w kolumnie Action przy danym urządzeniu uzyskamy dostęp do opcji Device Detail, View Records, Edit Device, Get Code i Reset Device.

Informacje o urządzeniu

Zobaczymy EUI-64, nazwę, adres IPv6, rozszerzony adres MAC (64-bit zamiast zwykłego 48-bit), wersję oprogramowania układowego i dane czujników.

View Records

Po pozostawieniu płytek włączonych przez ponad 24 godziny zajrzałem do menu „View Records”, aby obejrzeć wykresy wartości czujników dla konkretnej płytki.

Wygląda to przeważnie dobrze, ale w lewym dolnym rogu widać wartości o 9 pm, a wykres z jakiegoś powodu zaczyna się dopiero o 11 pm. Tak samo jest dla wszystkich płytek.

Na wykresie godzinowym wygląda to jeszcze gorzej. To raczej błąd wyświetlania niż brak punktów danych, ponieważ po lewej stronie zawsze możemy odczytać punkt.

Przykłady kodu

Sekcja „Get Code” może być najważniejsza, jeśli zamierzasz monitorować i sterować własnymi urządzeniami Thread. Zawiera pięć przykładów kodu.

Aby uruchomić przykłady, musimy połączyć się z routerem brzegowym Thread GL-S200 przez SSH. Zacznijmy od kodu odczytującego dane czujników.

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

Możemy też wybrać konkretne urządzenie za pomocą jego EUI-64:

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

Oto kod źródłowy do wglądu:

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

Wypróbujmy pozostałe przykłady.

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

Drugi przykład steruje dwiema diodami RGB na płytce wybranej na podstawie identyfikatora EUI-64:

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

Oto krótka demonstracja wideo pokazująca działanie.

Przykład sterowania GPIO ustawia niektóre linie I/O w trybie wyjściowym, a następnie w stan niski i wysoki, ponownie dla konkretnej płytki:

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

Dwa ostatnie przykłady sterowania diodami LED i GPIO korzystają z polecenia coap_cli, „małej implementacji CoAP”, na przykład do wyłączenia diod LED:

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

Użycie 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 -

Demonstracja wyzwalania działań raportuje stan pokrętła:

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

Kod korzysta z pliku wykonywalnego /usr/bin/eco [Aktualizacja: wygląda na to, że jest to interpreter z projektu eco-lua Lua ; zobacz sekcję komentarzy]:

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

Tak samo działa przykład wyzwalania przez czujnik, który monitoruje czujnik PIR na wszystkich płytkach Thread Dev Board połączonych z routerem brzegowym Thread GL-S200:

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.

Wszystkie te przykłady mogą pomóc Ci zacząć tworzyć własne skrypty.

„Automations” w GL-S200

Sekcja GL DEV BOARDS zawiera też sekcję „Automations”.

Spróbuję sterować diodami RGB na dwóch płytkach Thread Dev Board za pomocą pokrętła na trzeciej płytce.

Po nadaniu nazwy automatyzacji możemy wybrać działanie użytkownika, a następnie płytkę z pokrętłem: „Board 2”.

Wybrałem „Turning the knob”, a następnie „Device(s) Action”.

Ponieważ chcę sterować pozostałymi dwiema płytkami, wybrałem „Board 1” i „Board 2”.

Jedyną opcją jest teraz „Change Color”, więc wybierzmy ją i kliknijmy Apply.

Nie działa to jednak: diody RGB pozostają wyłączone niezależnie od kierunku obracania pokrętła. W końcu odkryłem, że przed zmianą kolorów trzeba włączyć diody RGB, więc utworzyłem inną automatyzację, która włącza i wyłącza diody po naciśnięciu pokrętła.

Teraz działa.

Sekcja Automation obsługuje też webhooki, więc postanowiłem utworzyć automatyzację wysyłającą powiadomienie w Discordzie po wykryciu ruchu. Utworzyłem w tym celu serwer Discord i uzyskałem adres URL webhooka(https://discord.com/api/webhooks/xxxx) zgodnie z instrukcjami Discorda.

Następnie utworzyłem kolejną automatyzację, wybierając Sensor Trigger…

… „Human Body Detected” (co po prostu oznacza zadziałanie czujnika ruchu PIR)

… i „Webhook”.

Dodałem tam adres URL webhooka, wybrałem Json i wpisałem treść, na przykład:

{"content":"Ojej! Ktoś właśnie wszedł do sypialni!"}

Na koniec kliknąłem Apply i powtórzyłem te czynności, aby wykrywać ruch w kuchni i biurze.

Teraz mogę otworzyć Discord i przejść się po domu, uruchamiając czujniki ruchu PIR wszystkich trzech płytek.

Udało się! Sekcja automatyzacji jest całkiem przydatna, ale wygląda na to, że działa tylko z płytkami GL.iNet Thread Dev Board. Zapytałem więc, czy kod źródłowy zostanie udostępniony, aby użytkownicy mogli dostosować rozwiązanie do własnych urządzeń Thread, ale nie otrzymałem odpowiedzi na to konkretne pytanie.

Różne

Podobnie jak inne urządzenia sieciowe GL.iNet, GL-S200 obsługuje GoodCloud do zdalnego dostępu. Zastosowanie jest jednak ograniczone, ponieważ funkcje Thread i Bluetooth nie są obsługiwane.

Początkowo sądziłem, że przycisk Mode Switch służy do przełączania między BLE a Thread. Jednak tak jak we wcześniejszych routerach można ustawić go do włączania i wyłączania WireGuard lub OpenVPN.

Ze względu na ograniczony czas nie przetestowałem funkcji Bluetooth, ale spodziewam się interfejsu i działania podobnego do mostka BLE–MQTT GL-S10 który recenzowałem w zeszłym roku.

To było ciekawe doświadczenie. Dziękuję GL.iNet za przesłanie zestawu routera brzegowego Thread GL-S200 do oceny i testów beta. Otrzymany zestaw jest dostępny w przedsprzedaży za $154.00 plus koszty wysyłki, ale jeśli masz już własne węzły Thread, sam GL-S200 jest sprzedawany za $79 w okresie przedsprzedaży, a później będzie kosztować $99.

Jean-Luc Aufranc (CNXSoft) Jean-Luc założył CNX Software w 2010 jako dodatkowe zajęcie. Następnie zrezygnował ze stanowiska kierownika zespołu inżynierii oprogramowania i w 2011 zaczął na pełny etat codziennie pisać wiadomości oraz recenzje.

Przeczytaj tę recenzję w CNX Software