CNX Software beoordeelt de eerste stappen met de GL-S200 Thread Border Router-kit

Vorige week bekeken we de hardware van de GL.iNet GL-S200 Thread Border Router-kit met drie nRF52840 Thread Dev Boards. Inmiddels heb ik met de kit kunnen werken; in dit tweede deel van de review beschrijf ik mijn eerste ervaringen.

Eerste configuratie van de GL-S200

Ik verbond de WAN-poort met mijn Ethernet-switch, die op zijn beurt met mijn modemrouter was verbonden, en de LAN-poort met mijn laptop. Zo kon ik de webinterface via het standaard-IP-adres (192.168.8.1) openen. De GL-S200 gebruikt hetzelfde beheerpaneel als andere GL.iNet-routers, zoals de Beryl AX-router die we begin dit jaar beoordeelden.

Een wizard laat u de taal kiezen en een nieuw wachtwoord voor het beheerpaneel instellen. Daarna krijgt u toegang tot het vertrouwde GL.iNet-beheerpaneel 4.x.x.

Na het voltooien van de wizard hoort het systeem automatisch verbinding met internet te maken. De middelste RGB-led op het apparaat wordt dan groen.

Thread-netwerk

Ga vervolgens naar THREAD MESH in het linkerpaneel om het Thread-netwerk in te schakelen.

Zodra u op Enable klikt, krijgt u drie IPv6-adressen:

• Link-Local Address – Alle interfaces die met één radiotransmissie bereikbaar zijn

• Local Address – Alle interfaces die van buiten een Thread-netwerk bereikbaar zijn (dit lijkt Global Address te worden genoemd in de OpenThread-documentatie)

  Update van GL-iNet: toegang tot het wereldwijde IPv6-internet wordt nog niet ondersteund door OT/OTBR.

  U kunt het officiële antwoord van OpenThread raadplegen: https://github.com/openthread/openthread/discussions/8794

  Het lokale adres is een OMR-adres (off-mesh-routable), waarmee u Thread-apparaten vanaf de wifi-/Ethernet-kant kunt bereiken.

• Mesh-Local EID – Alle interfaces die binnen hetzelfde Thread-netwerk bereikbaar zijn

Als u eigen Thread-apparaten hebt, kunt u naar het menu Thread Commissioning gaan en de EUI64 van uw apparaten en de vooraf gedeelde sleutel invoeren. GL.iNet heeft echter een eenvoudiger onderdeel in de webinterface gemaakt voor zijn Thread Dev Boards, afgekort TBD.

In het onderdeel GL DEV BOARD->Devices kunnen we klikken op de knop Add Devices en vervolgens op Apply. Als we op de SW2-schakelaar op een bord drukken, wordt het automatisch toegevoegd aan de GL-S200 Thread Border Router.

We kiezen het type A0+A1 en geven het bord een naam. We kunnen dit voor de andere twee borden herhalen. Vervolgens verschijnen de waarden voor temperatuur, luchtdruk, luchtvochtigheid en verlichtingssterkte van alle drie de borden in het beheerpaneel.

GL-S200-firmware bijwerken

Op dat moment bedacht ik dat ik iets was vergeten… GL.iNet had me laten weten dat er nieuwe firmware voor de GL-S200 was die ik handmatig moest installeren. Dat doen we nu via “SYSTEM->Upgrade”.

Het beheerpaneel meldt dat firmware 4.1.3 release 5 actueel is, omdat de nieuwe firmware nog niet naar de OTA-server is gepusht. Ik kreeg echter een downloadlink voor nieuwere firmware die op 6 maart 2023 was gecompileerd.

Ik downloadde het bestand, ging naar Local Upgrade en uploadde het naar de GL-S200 Thread Border Router.

De verificatie slaagde, dus klikte ik op Install. Uiteindelijk werd firmware 4.1.3 Release 7 op mijn apparaat geïnstalleerd.

Firmware van Thread Dev Boards bijwerken

Tijdens die firmware-update zag ik dat ook de Thread Dev Boards konden worden bijgewerkt van versie 1.1.5 naar 1.1.9. Ik voerde de update uit en die verliep probleemloos.

Thread-topologie

Thread gebruikt meshnetwerken. Nodes dicht bij de router maken rechtstreeks verbinding met de router; buiten het bereik of bij een zwak signaal kunnen ze zelf als router fungeren. Met alle apparaten op mijn bureau…

… had het netwerk zoals verwacht een stertopologie.

Ik probeerde de borden daarom verder uit elkaar te plaatsen, in een rechte lijn, waarbij ik zelfs één bord buiten zette.

Het bord buiten is gemakkelijk te herkennen aan de hogere temperatuur en verlichtingssterkte.

Als we in de topologiegrafiek op “Self” klikken, zien we ook de signaalsterkte van de node die met de Thread Border Router is verbonden. Het lukte me echter op geen enkel moment om de Thread Dev Board als router te gebruiken. We liepen zelfs naar buiten om buiten het bereik te komen of in ieder geval een zwakker signaal te krijgen, maar het meshnetwerk werkte niet zoals ik verwachtte. Ik vroeg het daarom aan de GL.iNet-engineers. Zij antwoordden dat hiervoor Thread-routerfirmware nodig was:

Onze standaard-TBD-firmware is momenteel van het type Thread-eindapparaat en de apparaten kunnen niet rechtstreeks onderling worden verbonden. Later vandaag sturen we u de Thread-routerfirmware en de bijbehorende handleiding om TBD-firmware te flashen.

Ze stuurden me de routerfirmware en het hulpprogramma mcumgr voor Linux en Windows.

Ik verbond één van de Thread Dev Boards met een Linux-pc (Ubuntu 22.04):

print(“Hello World”)will be displayed asprint(“Hello World”)`.

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

De seriële poort wordt herkend, dus kan ik de opdracht uitvoeren om de huidige firmwarestatus te controleren:

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

De eerste poging mislukte met de fout “NMP timeout”, maar de tweede werkte. We zien dat de firmware 1.1.9 die ik via het beheerpaneel heb bijgewerkt in slot 0 staat, en de eerdere firmware 1.1.5 in slot 1. Nu kan ik de routerfirmware proberen te 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

Laten we opnieuw kijken:

$ 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

De firmware in slot 0 is de firmware die momenteel draait. In slot 1 staat de Router-versie die we zojuist hebben geflasht. We kunnen als volgt overschakelen naar de nieuwe firmware:

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

Daarna kunnen we het bord opnieuw opstarten en controleren of de nieuwe firmware met een hash die begint met 7dbb in slot 0 staat:

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

Nadat we het bord opnieuw aan het beheerpaneel hebben toegevoegd, zien we de Thread Leader (GL-S200), twee End Devices en een Router (het bord dat we zojuist met de routerfirmware hebben geflasht).

Geen van de End Devices is verbonden met de Board 1-router, omdat alles op mijn bureau staat en met de GL-S200 is verbonden. Ik verplaats Board 1 samen met één van de End Devices naar een andere kamer, op 12 meter van de GL-S200 Thread Border Router. De topologie verandert echter niet. Het lijkt erop dat de verbinding “blijft hangen”: een Thread-node maakt pas opnieuw verbinding met een andere Router als hij buiten bereik is, niet alleen op basis van de signaalsterkte.

Maar nadat ik de GL-S200 had uitgeschakeld en opnieuw opgestart, waren de twee End Devices verbonden met de Board 1-router, die nu de “Thread Leader” in het netwerk was.

Het werkt dus wel. Ik had niet verwacht dat het precies zo zou werken: Board 2 staat op 10 centimeter van de GL-S200 Thread Border Router (self), en Board 1 op 12 meter afstand. Toch maakte Board 2 ook na enige tijd geen nieuwe verbinding met de GL-S200. Met andere woorden: zolang de verbinding actief is, maakt een Thread-node geen verbinding met een andere router, zelfs als die dichterbij staat en een sterker signaal heeft. Dat lijkt me logisch met het oog op de batterijduur.

Ik nam Board 2 (End Device) en Board 1 (Router) daarom kort mee buiten het bereik van de GL-S200. Ik schakelde eerst Board 1 en daarna Board 2 in, zodat ze zeker met elkaar zouden verbinden, en liep terug naar huis. Het werkte: zoals in het bovenstaande diagram te zien is, verbindt Board 2 zich met de GL-S200 “Thread Leader” via Board 1, die als router fungeert.

Informatie over GL Thread Dev Board

Als we in de kolom Action voor een apparaat op de drie puntjes klikken, krijgen we meer opties: Device Detail, View Records, Edit Device, Get Code en Reset Device.

Apparaatinformatie

We krijgen de EUI-64, naam, IPv6-adres, het uitgebreide MAC-adres (64-bit in plaats van de gebruikelijke 48-bit), firmwareversie en sensorgegevens.

Registraties bekijken

Nadat de borden meer dan 24 uur hadden gedraaid, bekeek ik het menu “View Records” om grafieken van de sensorwaarden van een specifiek bord te zien.

Het ziet er grotendeels goed uit, maar linksonder staan waarden om 9 uur 's avonds, terwijl de grafiek om een of andere reden pas om 11 uur 's avonds begint. Dit geldt voor alle borden.

De uurgrafiek ziet er nog slechter uit. Het lijkt eerder een weergavefout dan ontbrekende meetpunten, aangezien we links altijd een meetpunt kunnen vinden.

Codevoorbeelden

Het onderdeel “Get Code” is wellicht het belangrijkste als u uw eigen Thread-apparaten wilt bewaken en bedienen. Er worden vijf codevoorbeelden aangeboden.

Om de voorbeelden uit te voeren, moeten we via SSH verbinding maken met de GL-S200 Thread Border Router. We beginnen met de code om sensorgegevens uit te lezen.

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

We kunnen ook een specifiek apparaat selecteren via zijn 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

Hieronder staat de broncode ter referentie:

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

Laten we de andere voorbeelden proberen.

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

Het tweede voorbeeld bestuurt de twee RGB-leds op het bord dat via zijn EUI-64-apparaat-ID wordt geselecteerd:

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

Hieronder staat een korte videodemonstratie van het resultaat.

Het GPIO-besturingsvoorbeeld stelt enkele I/O-aansluitingen in als uitgang, eerst laag en daarna hoog, opnieuw voor een specifiek bord:

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

De laatste twee voorbeelden om leds en GPIO's te besturen gebruiken de opdracht coap_cli, een “kleine CoAP-implementatie”. Bijvoorbeeld om de leds uit te zetten:

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

Gebruik van 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 -

De demonstratie van de actietrigger meldt de status van de draaiknop:

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

De code gebruikt het binaire bestand /usr/bin/eco [Update: dit lijkt het eco-lua Lua interpreterproject te zijn; zie de reacties]:

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

Hetzelfde geldt voor het sensortriggervoorbeeld, dat de PIR-sensor bewaakt voor alle Thread Dev Boards die met de GL-S200 Thread Border Router zijn verbonden:

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.

Al deze voorbeelden kunnen u op weg helpen met uw eigen scripts.

GL-S200 “Automations”

Het onderdeel GL DEV BOARDS bevat ook een onderdeel “Automations”.

Ik probeer de RGB-leds op twee Thread Dev Boards te besturen met de draaiknop op het derde bord.

Nadat we de automatisering een naam hebben gegeven, kunnen we een gebruikersactie kiezen en vervolgens het bord selecteren dat we voor de draaiknop gebruiken: “Board 2”.

Ik koos “Turning the knob” en vervolgens “Device(s) Action”.

Omdat ik de andere twee borden wil besturen, selecteerde ik “Board 1” en “Board 2”.

De enige optie is vervolgens “Change Color”. We selecteren die en klikken op Apply.

Het werkt echter niet: de RGB-leds blijven uit, ongeacht in welke richting ik de draaiknop draai. Uiteindelijk ontdekte ik dat de RGB-leds aan moeten staan voordat we de kleur kunnen veranderen. Daarom maakte ik nog een automatisering om de leds bij het indrukken van de draaiknop aan of uit te zetten.

Nu werkt het.

Het onderdeel Automation ondersteunt ook webhooks. Ik besloot daarom een automatisering te maken die me in Discord waarschuwt wanneer beweging wordt gedetecteerd. Daarvoor maakte ik een Discord-server en verkreeg ik een Webhook URL(https://discord.com/api/webhooks/xxxx) volgens de instructies van Discord.

Daarna maakte ik een nieuwe automatisering met Sensor Trigger…

… “Human Body Detected” (dit betekent alleen dat de PIR-bewegingssensor is geactiveerd)

… en “Webhook”.

Daar voegde ik mijn Webhook URL toe, selecteerde ik Json en voegde ik inhoud toe zoals:

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

Tot slot klikte ik op Apply en herhaalde ik dezelfde procedure om beweging in de keuken en op kantoor te detecteren.

Nu kan ik Discord openen en door het huis lopen om de PIR-bewegingssensoren van alle drie de borden te activeren.

Gelukt! Het automatiseringsonderdeel is erg handig, maar lijkt alleen met GL.iNet Thread Dev Boards te werken. Ik vroeg daarom of de broncode zou worden gedeeld, zodat mensen de oplossing voor hun eigen Thread-apparaten kunnen aanpassen. Op die specifieke vraag kreeg ik echter geen antwoord.

Overig

Net als andere GL.iNet-netwerkapparaten ondersteunt de GL-S200 GoodCloud voor externe toegang. Het nut is echter beperkt, omdat de Thread- en Bluetooth-onderdelen niet worden ondersteund.

Ik dacht aanvankelijk dat de Mode Switch-knop bedoeld was om tussen BLE en Thread te wisselen. Net als bij eerdere routers kan hij echter worden ingesteld om WireGuard of OpenVPN aan en uit te zetten.

Vanwege tijdgebrek heb ik het Bluetooth-onderdeel niet getest, maar ik verwacht dat de interface en ervaring vergelijkbaar zijn met de GL-S10 BLE-naar-MQTT-brug die ik vorig jaar beoordeelde.

Dit was een interessante ervaring. Ik wil GL.iNet bedanken voor het toesturen van de GL-S200 Thread Border Router-kit voor evaluatie en bètatests. De kit die ik heb ontvangen is beschikbaar als pre-order voor $154.00 plus verzendkosten. Als u al eigen Thread-nodes hebt, wordt alleen de GL-S200 tijdens de pre-orderperiode verkocht voor $79. Daarna wordt de prijs $99.

Jean-Luc Aufranc (CNXSoft) Jean-Luc begon CNX Software in 2010 als deeltijdactiviteit. Later verliet hij zijn baan als manager softwareontwikkeling en ging hij in 2011 voltijds dagelijks nieuws en reviews schrijven.

Lees deze review op CNX Software