CNX Software analiza los primeros pasos con el kit de router de borde Thread GL-S200

La semana pasada probamos el hardware del kit de router de borde Thread GL.iNet GL-S200 con tres placas de desarrollo Thread nRF52840, y ahora he tenido tiempo de trabajar con el kit, así que contaré mi experiencia inicial en la segunda parte de la reseña.

Configuración inicial de GL-S200

Conecté el puerto WAN a mi conmutador Ethernet, que a su vez estaba conectado al módem router, y el puerto LAN a mi ordenador portátil, para poder acceder a la interfaz web mediante la dirección IP predeterminada (192.168.8.1). El GL-S200 utiliza el mismo panel de administración que otros routers GL.iNet, como el router Beryl AX que analizamos a principios de año.

Un asistente te permitirá seleccionar el idioma y establecer una nueva contraseña para el panel de administración; al terminar, tendrás acceso al conocido panel de administración GL.iNet 4.x.x.

Tras completar el asistente, el sistema debería conectarse automáticamente a Internet y el LED RGB central del dispositivo se pondrá verde.

Red Thread

El primer paso es ir a MALLA THREAD en el panel izquierdo para activar la red Thread.

Al hacer clic en Activar, obtendrá tres direcciones IPv6:

• Dirección de enlace local – Todas las interfaces accesibles mediante una única transmisión de radio

• Dirección local – Todas las interfaces accesibles desde fuera de una red Thread (Parece que se denomina Dirección global en Documentación de OpenThread)

  Actualización de GL-iNet: OT/OTBR aún no admite el acceso a Internet IPv6 global.

  Puedes consultar la respuesta oficial de Openthread: https://github.com/openthread/openthread/discussions/8794

  La dirección local es una dirección OMR(enrutable fuera de la malla), con la que puedes acceder a dispositivos Thread desde el lado wifi/ethernet.

• Mesh-Local EID – Todas las interfaces accesibles dentro de la misma red Thread

Si dispone de tus propios dispositivos Thread, puedes acceder al menú de puesta en servicio de Thread e introducir el EUI64 de tus dispositivos y la clave precompartida, pero GL.iNet ha creado una sección más sencilla en la interfaz web para gestionar sus placas de desarrollo Thread, o TBD para abreviar.

En el PLACA DE DESARROLLO GL->Dispositivos sección, podemos hacer clic en el Añadir dispositivos botón y, a continuación, Aplicar. Si pulsamos el interruptor SW2 de una placa, esta se añadirá automáticamente al router de borde Thread GL-S200.

Debemos seleccionar el tipo A0+A1 y asignar un nombre a la placa. Podemos repetir lo mismo con las otras dos placas; así aparecerán en el panel de administración los valores de temperatura, presión, humedad e iluminancia de las tres placas.

Actualización del firmware GL-S200

En ese momento recordé que había olvidado algo… GL.iNet me informó de que tenían un nuevo firmware para GL-S200 que debía instalar manualmente. Así que vamos a hacerlo ahora, entrando en «SISTEMA->Actualizar».

El panel de administración indica que el firmware 4.1.3, versión 5, está actualizado porque el nuevo firmware no se envió al servidor OTA. Pero me proporcionaron un enlace de descarga con un firmware más reciente que se compiló el 6 de marzo de 2023.

Descargué el archivo, fui a la sección de actualización local y cargué el archivo en el router de borde Thread GL-S200.

La verificación se completó correctamente, así que hice clic en Instalar, y finalmente conseguí la versión de firmware 4.1.37 instalado en mi dispositivo.

Actualización del firmware de las placas de desarrollo Thread

Mientras realizaba esa actualización de firmware, también observé que las placas de desarrollo Thread podían actualizar su firmware de la versión 1.1.5 a la 1.1.9, así que lo hice y funcionó a la perfección.

Topología Thread

Thread utiliza redes de malla, de modo que, cuando los nodos están cerca del router, se conectan directamente a él y, cuando están fuera de su alcance o la señal es débil, pueden actuar como routers. Con todos los dispositivos sobre mi escritorio…

… la red tenía una topología en estrella, como se esperaba.

Así que intenté separar las placas y colocarlas en línea recta, incluso situando una en el exterior.

Podemos identificar fácilmente el que está al aire libre por su mayor temperatura e iluminancia.

Si hacemos clic en “Sí mismo” en el diagrama de topología, también podemos ver la intensidad de la señal del nodo conectado al router de borde Thread. Sin embargo, en ningún momento pude utilizar Thread Dev Board como router. Incluso salimos a caminar para intentar quedar fuera de alcance o, al menos, obtener una señal más débil, pero la red de malla simplemente no funcionaba como esperaba. Así que pregunté a los ingenieros de GL.iNet y me respondieron que se necesitaba un firmware de router Thread para que funcionara:

Actualmente, nuestro firmware TBD predeterminado es de dispositivo final Thread y no se pueden conectar directamente entre sí. Le proporcionaremos el router thread firmware y la correspondiente guía de instalación TBD más tarde hoy.

Me enviaron el firmware del router, así como el mcumgr utilidad para Linux y Windows.

Conecté una de las placas Thread Dev Board a un PC Linux (Ubuntu 22.04):

print(“Hello World”)se mostrará comoprint(“Hello World”)`.

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

El puerto serie se detecta, así que puedo ejecutar el comando para comprobar el estado actual del 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)

Falló la primera vez con el error «NMP timeout», pero funcionó la segunda. Podemos ver que el firmware 1.1.9 que actualicé en el panel de administración está en la ranura 0, y el firmware anterior 1.1.5 está en la ranura 1. Ahora puedo intentar instalar el firmware del 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

Veámoslo de nuevo:

$ 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

El firmware de la ranura 0 es el que se está ejecutando actualmente, mientras que el firmware de la ranura 1 es la versión de router que acabamos de instalar. Podemos cambiar al nuevo firmware de la siguiente manera:

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

Después podemos reiniciar la placa y comprobar que el nuevo firmware cuyo hash comienza por 7dbb está en la ranura 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)

Tras añadir de nuevo la placa al panel de administración, podemos ver el líder Thread (GL-S200), dos dispositivos finales y un router (la placa en la que acabamos de instalar el firmware de router).

Ninguno de los dispositivos finales está conectado al router Board 1 porque todos están en mi escritorio y conectados al GL-S200. Así que traslado Board 1 junto con uno de los dispositivos finales a otra habitación, a 12 metros del router de borde Thread GL-S200. Pero la topología no cambió. Parece que la conexión es «persistente» y que un nodo Thread solo se vuelve a conectar a otro router si queda fuera de su alcance, y no únicamente en función de la intensidad de la señal.

Pero, al apagar y reiniciar el GL-S200, los dos dispositivos finales se habían vuelto a conectar al router de la placa 1, que ahora era el “Líder Thread” de la red.

Así que sí funciona. No esperaba que funcionara exactamente así porque la placa 2 está a 10 centímetros del router de borde Thread GL-S200 (el propio dispositivo) y la placa 1 está a 12 metros, pero la placa 2 no volvió a conectarse al GL-S200, ni siquiera después de un tiempo. En otras palabras, mientras la conexión siga activa, un nodo Thread no volverá a conectarse a otro router aunque esté más cerca y tenga una señal más fuerte, y supongo que eso tiene sentido para ahorrar batería.

Así que llevé la placa 2 (dispositivo final) y la placa 1 (router) a dar un pequeño paseo fuera del alcance del GL-S200. Después, encendí la placa 1 y luego la placa 2 para asegurarme de que se asociaran, y volví caminando a casa. Y funcionó: como muestra el diagrama anterior, la placa 2 se conecta al GL-S200, el «líder Thread», a través de la placa 1, que actúa como router.

Información de la placa de desarrollo Thread de GL

Si hacemos clic en los tres puntos de la columna Acción de un dispositivo concreto, accederemos a más opciones: Detalles del dispositivo, Ver registros, Editar dispositivo, Obtener código y Restablecer dispositivo.

Información del dispositivo

Obtendremos el EUI-64, el nombre, la dirección IPv6, la dirección MAC extendida (64-bit en lugar de los habituales 48-bit), la versión del firmware y los datos del sensor.

Ver registros

Tras dejar las placas funcionando durante más de 24 horas, consulté el menú “Ver registros” para ver gráficos de los valores de los sensores de una placa concreta.

En general parece correcto, pero, como puedes ver abajo a la izquierda, hay valores a las 9 pm y el gráfico empieza a las 11 pm por algún motivo. Ocurre lo mismo con todas las placas.

Se ve aún peor en el gráfico por horas. Parece un fallo de visualización más que una falta de puntos de datos, ya que siempre podemos obtener un punto de datos en el lado izquierdo.

Ejemplos de código

La sección “Obtener código” puede ser la parte más importante si va a supervisar y controlar tus propios dispositivos Thread con los cinco ejemplos de código proporcionados.

Tendremos que conectarnos al router de borde Thread GL-S200 mediante SSH para ejecutar los ejemplos. Empecemos por el código para leer los datos de los 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

También podemos seleccionar un dispositivo concreto mediante su 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

Este es el código fuente como referencia:

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

Probemos los otros ejemplos.

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

El segundo ejemplo controla los dos LED RGB de la placa seleccionada mediante su ID 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

Aquí tiene una breve demostración en vídeo para ver cómo es.

El ejemplo de control GPIO configura algunas I/O en modo de salida y después en nivel bajo y alto, de nuevo para una 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

Los dos últimos ejemplos para controlar los LED y los GPIO utilizan el comando coap_cli, una «pequeña implementación de CoAP», por ejemplo, para apagar los LED:

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

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

La demostración de activación por acciones informa del estado del mando:

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

El código depende del ejecutable /usr/bin/eco [Actualización: parece que es el eco-lua Lua proyecto del intérprete; consulta la sección de comentarios]:

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

Lo mismo ocurre con el ejemplo de activación por sensor, que supervisa el sensor PIR de todas las placas de desarrollo Thread conectadas al router de borde 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 esos ejemplos pueden ayudarte a empezar a crear tus propios scripts.

«Automatizaciones» de GL-S200

La sección GL DEV BOARDS también incluye una sección de «Automatizaciones».

Intentaré controlar los LEDS RGB de dos Thread Dev Boards utilizando el mando de la tercera placa restante.

Una vez que hemos dado un nombre a la automatización, podemos seleccionar la acción del usuario y después la placa que utilizaremos como mando: “Placa 2”.

Seleccioné “Girar la perilla” y después “Acción de los dispositivos”.

Como quiero controlar las otras dos placas, seleccioné “Placa 1” y “Placa 2”.

La única opción es “Cambiar color”, así que seleccionémosla y hagamos clic en Aplicar.

Pero no funciona, y los LEDs RGB permanecen apagados sin importar en qué dirección gire la perilla. Finalmente descubrí que había que encender los LEDs RGB antes de poder cambiar los colores, así que creé otra automatización para encender y apagar los LEDs al presionar la perilla.

Y ahora funciona.

La sección de automatización también admite webhooks, así que decidí crear una automatización para recibir una alerta en Discord cuando se detecte movimiento. Para ello, creé un servidor de Discord y obtuve una URL de Webhook(https://discord.com/api/webhooks/xxxx) siguiendo las instrucciones en Discord.

Después creé otra automatización seleccionando Activación por sensor…

… «Cuerpo humano detectado» (lo que simplemente significa que se ha activado el sensor de movimiento PIR)

… y «Webhook».

Allí añadí mi URL de Webhook, seleccioné Json y añadí contenido como:

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

Por último, hice clic en Aplicar y repitió el mismo procedimiento para detectar movimiento en la cocina y la oficina.

Ahora puedo abrir Discord y caminar por la casa para activar los sensores de movimiento PIR de las tres placas.

¡Funcionó! La sección de automatización está bastante bien, pero parece que solo funciona con las placas de desarrollo Thread de GL.iNet. Por eso pregunté si se compartiría el código fuente para que los usuarios pudieran adaptar la solución a sus propios dispositivos Thread, pero no obtuve respuesta a esa pregunta concreta.

Varios

Al igual que otros dispositivos de red GL.iNet, el GL-S200 admite GoodCloud para el acceso remoto, pero su uso es limitado porque las partes Thread y Bluetooth no son compatibles.

Al principio pensé que el botón de cambio de modo podía servir para alternar entre BLE y Thread, pero, como en routers anteriores, puede configurarse para activar o desactivar WireGuard u OpenVPN.

Por falta de tiempo, no he probado la parte de Bluetooth, pero espero que la interfaz y la experiencia sean similares a las de Puente de BLE a MQTT GL-S10 que analicé el año pasado.

Ha sido una experiencia interesante y quisiera agradecer a GL.iNet el envío del kit de router de borde Thread GL-S200 para evaluación/pruebas beta. El kit que he recibido está disponible en preventa por $154.00 más gastos de envío, pero si ya tienes tus propios nodos Thread, entonces solo el GL-S200 es a la venta por $79 durante el periodo de reserva, tras lo cual costará $99.

Jean-Luc Aufranc (CNXSoft) Jean-Luc creó CNX Software en 2010 como una actividad a tiempo parcial, antes de dejar su puesto como responsable de ingeniería de software y empezar a escribir noticias y reseñas diarias a tiempo completo en 2011.

Leer esta reseña en CNX Software