Análise da CNX Software: primeiros passos com o kit de router de fronteira Thread GL-S200

Na semana passada, analisámos o hardware do kit de router de fronteira Thread GL.iNet GL-S200 com três Thread Dev Boards nRF52840. Entretanto, tive tempo para trabalhar com o kit, pelo que vou relatar a minha experiência inicial nesta segunda parte da análise.

Configuração inicial do GL-S200

Liguei a porta WAN ao meu switch Ethernet, que por sua vez está ligado ao meu modem router, e a porta LAN ao portátil, para poder aceder à interface web através do endereço IP predefinido (192.168.8.1). O GL-S200 utiliza o mesmo Admin Panel que outros routers GL.iNet, como o router Beryl AX que analisámos no início do ano.

Surge um assistente que permite selecionar o idioma e definir uma nova palavra-passe para o Admin Panel. Depois de o concluir, terá acesso ao conhecido Admin Panel 4.x.x da GL.iNet.

Depois de concluir o assistente, o sistema deverá ligar-se automaticamente à Internet, e o LED RGB central do dispositivo passará a verde.

Rede Thread

O primeiro passo é aceder a THREAD MESH no painel esquerdo para ativar a rede Thread.

Depois de clicar em Enable, obterá três endereços IPv6:

• Link-Local Address – Todas as interfaces alcançáveis através de uma única transmissão de rádio

• Local Address – Todas as interfaces alcançáveis a partir do exterior de uma rede Thread (Parece chamar-se Global Address na documentação do OpenThread)

  Atualização da GL-iNet: o acesso à Internet IPv6 global ainda não é suportado por OT/OTBR.

  Pode consultar a resposta oficial do Openthread: https://github.com/openthread/openthread/discussions/8794

  O endereço local é um endereço OMR(off-mesh-routable), através do qual pode aceder a dispositivos Thread a partir do lado wifi/ethernet.

• Mesh-Local EID – Todas as interfaces alcançáveis dentro da mesma rede Thread

Se tiver os seus próprios dispositivos Thread, pode mudar para o menu Thread Commissioning e introduzir o EUI64 dos dispositivos e a chave pré-partilhada, mas a GL.iNet criou uma secção mais simples na interface web para gerir as suas Thread Dev Boards, abreviadamente TBD.

Na secção GL DEV BOARD->Devices , podemos clicar no botão Add Devices e depois em Apply. Se premirmos o interruptor SW2 numa placa, esta será automaticamente adicionada ao router de fronteira Thread GL-S200.

Devemos selecionar o tipo A0+A1 e dar um nome à placa. Podemos repetir o processo para as outras duas placas, e os valores de temperatura, pressão, humidade e iluminância das três placas aparecerão no Admin Panel.

Atualização de firmware do GL-S200

Nessa altura, lembrei-me de que me tinha esquecido de algo… A GL.iNet tinha-me informado de que existia um novo firmware para o GL-S200, que devia aplicar manualmente. Vamos fazê-lo agora, acedendo a «SYSTEM->Upgrade».

O Admin Panel mostra o firmware 4.1.3 release 5 como atualizado, porque o novo firmware não foi enviado para o servidor OTA. Mas recebi uma ligação de transferência para um firmware mais recente, compilado em 6 de março de 2023.

Descarreguei o ficheiro, acedi à secção Local Upgrade e carreguei o ficheiro para o router de fronteira Thread GL-S200.

A verificação foi bem-sucedida, pelo que cliquei em Installe, por fim, fiquei com o Firmware 4.1.3 Release7 instalado no dispositivo.

Atualização do firmware das Thread Dev Boards

Enquanto tratava da atualização de firmware, reparei que as Thread Dev Boards também podiam receber uma atualização da versão 1.1.5 para a 1.1.9. Avancei com o processo e funcionou sem falhas.

Topologia Thread

O Thread assenta em redes mesh, pelo que, quando os nós estão perto do router, se ligam diretamente a ele e, quando estão fora de alcance ou o sinal é fraco, podem funcionar como routers. Com todos os dispositivos na minha secretária…

… a rede tinha uma topologia em estrela, como esperado.

Por isso, tentei afastar as placas umas das outras e dispô-las em linha reta, colocando até uma no exterior.

É fácil identificar a que está no exterior, pelos valores mais elevados de temperatura e iluminância.

Se clicarmos em «Self» no gráfico de topologia, também podemos ver a intensidade do sinal do nó ligado ao router de fronteira Thread. Mas nunca consegui utilizar a Thread Dev Board como router. Chegámos a dar um passeio no exterior para tentar sair de alcance, ou pelo menos obter um sinal mais fraco, mas a rede mesh não funcionava como eu esperava. Perguntei, então, aos engenheiros da GL.iNet, que responderam ser necessário um firmware thread router para que isso funcionasse:

Atualmente, o nosso firmware TBD predefinido é do tipo thread end device e não permite que os dispositivos se liguem diretamente entre si. Iremos fornecer-lhe o firmware thread router e o respetivo guia de gravação do TBD ainda hoje.

Enviaram-me o firmware de router, bem como o utilitário mcumgr para Linux e Windows.

Liguei uma das Thread Dev Boards a um PC Linux (Ubuntu 22.04):

print(“Hello World”) será apresentado como print(“Hello World”)`.

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

A porta série é detetada, pelo que posso executar o comando para verificar o estado atual do firmware:

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

Na primeira tentativa, falhou com o erro «NMP timeout», mas funcionou na segunda. Podemos ver que o firmware 1.1.9, que atualizei no Admin Panel, está no slot 0, e o firmware anterior, 1.1.5, no slot 1. Agora posso tentar gravar o firmware Router:

$ 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

Vamos verificar novamente:

$ 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

O firmware no slot 0 é o que está atualmente em execução, enquanto o firmware no slot 1 é a versão Router que acabámos de gravar. Podemos mudar para o novo firmware da seguinte forma:

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

Podemos depois reiniciar a placa e confirmar que o novo firmware, cujo hash começa por 7dbb, está no slot 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)

Depois de adicionar novamente a placa ao Admin Panel, podemos ver o Thread Leader (GL-S200), dois End Devices e um Router (a placa em que acabámos de gravar o firmware Router).

Nenhum dos End Devices está ligado ao router Board 1, porque estão todos na minha secretária e ligados ao GL-S200. Por isso, levo o Board 1 e um dos End Devices para outra divisão, a 12 metros do router de fronteira Thread GL-S200. Mas a topologia não mudou. Parece que a ligação é «persistente» e um nó Thread só volta a ligar-se a outro Router se ficar fora de alcance, e não apenas com base na intensidade do sinal.

Mas, quando desliguei o GL-S200 e o voltei a ligar, os dois End Devices tinham-se ligado novamente ao router Board 1, que era agora o «Thread Leader» da rede.

Portanto, funciona. Não esperava que funcionasse exatamente assim, porque o Board 2 está a 10 centímetros do router de fronteira Thread GL-S200 (self), e o Board 1 está a 12 metros, mas o Board 2 não voltou a ligar-se ao GL-S200, mesmo passado algum tempo. Por outras palavras, enquanto a ligação estiver ativa, um nó Thread não volta a ligar-se a outro router, mesmo que este esteja mais próximo e tenha um sinal mais forte, e suponho que isso faça sentido para a autonomia da bateria.

Por isso, levei o Board 2 (End Device) e o Board 1 (Router) para um pequeno passeio fora do alcance do GL-S200, liguei primeiro o Board 1 e depois o Board 2 para garantir que se associavam, e voltei a casa. Funcionou: como mostra o diagrama acima, o Board 2 liga-se ao GL-S200 «Thread Leader» através do Board 1, que funciona como router.

Informações da GL Thread Dev Board

Se clicarmos nos três pontos da coluna Action de um dispositivo específico, teremos acesso a mais opções: Device Detail, View Records, Edit Device, Get Code e Reset Device.

Informações do dispositivo

Obtemos o EUI-64, o nome, o endereço IPv6, o endereço MAC estendido (64-bit em vez dos habituais 48-bit), a versão do firmware e os dados dos sensores.

View Records

Depois de deixar as placas a funcionar durante mais de 24 horas, consultei o menu «View Records» para ver os gráficos dos valores dos sensores de uma placa específica.

Parece estar quase tudo bem, mas, como se pode ver no canto inferior esquerdo, há valores às 9 pm e o gráfico só começa às 11 pm, por algum motivo. Acontece o mesmo em todas as placas.

O aspeto é ainda pior no gráfico horário. Parece ser um erro de apresentação e não falta de pontos de dados, pois conseguimos sempre obter um ponto de dados no lado esquerdo.

Exemplos de código

A secção «Get Code» poderá ser a parte mais importante se pretender monitorizar e controlar os seus próprios dispositivos Thread, com cinco exemplos de código disponíveis.

Precisamos de nos ligar ao router de fronteira Thread GL-S200 através de SSH para executar os exemplos. Vamos começar pelo código para ler os dados dos sensores.

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

Também podemos selecionar um dispositivo específico através do seu 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

Eis o código-fonte para referência:

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

Vamos experimentar os outros exemplos.

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

O segundo exemplo controla os dois LEDs RGB da placa selecionada através do seu identificador de dispositivo 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

Eis uma breve demonstração em vídeo do resultado.

O exemplo de controlo de GPIO configura algumas I/O no modo de saída e depois para os níveis baixo e alto, novamente para uma placa específica:

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

Os dois últimos exemplos, para controlar os LEDs e as GPIOs, utilizam o comando coap_cli, uma «pequena implementação de CoAP», por exemplo, para desligar os LEDs:

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

Utilização de 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 -

O exemplo de acionamento por ação comunica o estado do botão rotativo (Knob):

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

O código baseia-se no binário /usr/bin/eco [Atualização: parece ser o projeto de interpretador eco-lua Lua , consulte a secção de comentários]:

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

O mesmo acontece com o exemplo de acionamento por sensor, que monitoriza o sensor PIR de todas as Thread Dev Boards ligadas ao router de fronteira 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.

Todos estes exemplos podem ajudar a começar a escrever os seus próprios scripts.

GL-S200 «Automations»

A secção GL DEV BOARDS também inclui uma secção «Automations».

Vou tentar controlar os LEDS RGB de duas Thread Dev Boards através do botão rotativo da terceira placa.

Depois de dar um nome à automação, podemos selecionar uma ação do utilizador e depois a placa cujo botão rotativo vamos utilizar: «Board 2».

Selecionei «Turning the knob» e depois «Device(s) Action».

Como quero controlar as outras duas placas, selecionei «Board 1» e «Board 2».

Depois, a única opção é «Change Color», por isso vamos selecioná-la e clicar em Apply.

Mas não funciona, e os LEDs RGB permanecem desligados, independentemente do sentido em que rodo o botão. Acabei por descobrir que era necessário ligar os LEDs RGB antes de poder mudar as cores, pelo que criei outra automação para ligar/desligar os LEDs ao premir o botão rotativo.

E agora funciona.

A secção Automation também suporta webhooks, pelo que decidi criar uma automação para me alertar no Discord quando fosse detetado movimento. Para isso, criei um servidor Discord e obtive um Webhook URL(https://discord.com/api/webhooks/xxxx) seguindo as instruções do Discord.

Depois, criei outra automação, selecionando Sensor Trigger…

… «Human Body Detected» (o que significa apenas que o sensor de movimento PIR foi acionado)

… e «Webhook».

Aí, adicionei o meu Webhook URL, selecionei Json e acrescentei conteúdo como:

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

Por fim, cliquei em Apply e repeti o mesmo procedimento para detetar movimento na cozinha e no escritório.

Agora, posso ir ao Discord e andar pela casa para acionar os sensores de movimento PIR das três placas.

Sucesso! A secção de automação é bastante interessante, mas parece funcionar apenas com as Thread Dev Boards da GL.iNet. Por isso, perguntei se o código-fonte seria partilhado para que as pessoas pudessem adaptar a solução aos seus próprios dispositivos Thread, mas não obtive resposta a essa pergunta específica.

Diversos

Tal como outros dispositivos de rede GL.iNet, o GL-S200 suporta GoodCloud para acesso remoto, mas a sua utilidade é limitada, uma vez que as componentes Thread e Bluetooth não são suportadas.

Inicialmente, pensei que o botão Mode Switch pudesse ser utilizado para alternar entre BLE e Thread, mas, tal como nos routers anteriores, pode ser configurado para ligar/desligar WireGuard ou OpenVPN.

Por limitações de tempo, não testei a componente Bluetooth, mas esperaria que a interface e a experiência fossem semelhantes às da ponte GL-S10 de BLE para MQTT que analisei no ano passado.

Foi uma experiência interessante, e gostaria de agradecer à GL.iNet o envio do kit de router de fronteira Thread GL-S200 para avaliação/testes beta. O kit que recebi está disponível para pré-encomenda por $154.00 mais portes, mas, se já tiver os seus próprios nós Thread, o GL-S200 sozinho é vendido por $79 durante o período de pré-encomenda, após o qual custará $99.

Jean-Luc Aufranc (CNXSoft) Jean-Luc criou a CNX Software em 2010 como atividade a tempo parcial, antes de deixar o emprego de gestor de engenharia de software e passar a escrever notícias diárias e análises a tempo inteiro, mais tarde, em 2011.

Leia esta análise na CNX Software