CNX Software teste le kit de routeur de bordure Thread GL-S200

La semaine dernière, nous avons vérifié le matériel du kit de routeur de bordure Thread GL.iNet GL-S200 et de ses trois cartes de développement nRF52840. J'ai maintenant pu essayer le kit ; voici la deuxième partie de mon test, consacrée à sa mise en route.

Configuration initiale du GL-S200

J'ai relié le port WAN à mon commutateur Ethernet, lui-même connecté au modem-routeur, et le port LAN à mon ordinateur portable. J'ai ainsi accédé à l'interface Web à l'adresse IP par défaut 192.168.8.1. Le GL-S200 utilise la même interface d'administration que d'autres routeurs GL.iNet, comme le Beryl AX que nous avons testé plus tôt cette année.

L'assistant de démarrage permet de choisir la langue et de définir un mot de passe administrateur. Vous accédez ensuite à l'interface GL.iNet 4.x.x habituelle.

À la fin de l'assistant, le système devrait se connecter automatiquement à Internet et la LED RVB centrale devenir verte.

Réseau Thread

Dans le panneau de gauche, ouvrez « THREAD MESH » pour activer le réseau Thread.

Une fois que vous avez cliqué sur Activer, vous obtiendrez trois adresses IPv6 :

• Adresse Link-Local – Toutes les interfaces accessibles par une seule transmission radio

• Adresse locale – Toutes les interfaces accessibles depuis l'extérieur d'un réseau Thread (on dirait qu'elles s'appellent Global Address dans Documentation OpenThread)

  Mise à jour de GL.iNet : l'accès à Internet mondial IPv6 n'est pas encore pris en charge par OT/OTBR.

  Vous pouvez consulter la réponse officielle d’Openthread : https://github.com/openthread/openthread/discussions/8794

  L'adresse locale est une adresse OMR (off-mesh-routable), à l'aide de laquelle vous pouvez accéder aux appareils Thread du côté wifi/Ethernet.

• Mesh-Local EID – Toutes les interfaces accessibles au sein du même réseau Thread

Pour associer vos propres appareils Thread, ouvrez « Thread Commissioning » et saisissez leur identifiant EUI64 ainsi que la clé prépartagée. GL.iNet propose aussi une section plus simple pour ses cartes de développement Thread, abrégées ici « TBD ».

Dans la section GL DEV BOARD -> Devices, cliquez sur Add Devices, puis sur Apply. Appuyez sur le bouton SW2 d'une carte pour l'associer au routeur de bordure Thread GL-S200.

Sélectionnez le type A0+A1 et donnez un nom à la carte. Répétez l'opération pour les deux autres cartes : leurs mesures de température, de pression, d'humidité et de luminosité apparaîtront dans l'interface d'administration.

Mise à jour du micrologiciel GL-S200

À ce moment-là, je me souviens avoir oublié quelque chose… GL.iNet m'a informé qu'ils avaient un nouveau firmware pour le GL-S200 que je devrais appliquer manuellement. Alors faisons-le maintenant en allant dans « SYSTEM->Mise à niveau ».

Le micrologiciel indique que le micrologiciel 4.1.3 version 5 est à jour dans le panneau d'administration car le nouveau micrologiciel n'a pas été transmis au serveur OTA. Mais on m'a donné un lien de téléchargement avec un firmware plus récent compilé le 6 mars 2023.

J'ai téléchargé le fichier sur mon ordinateur, puis l'ai importé dans la section de mise à niveau locale du routeur de bordure Thread GL-S200.

La vérification a réussi, j'ai donc cliqué sur Installer, et finalement, j'ai obtenu la version 4.1.3 du micrologiciel7 installé sur mon appareil.

Mise à niveau du micrologiciel des cartes de développement Thread

Pendant que je poursuivais cette activité de mise à jour du micrologiciel, j'ai également remarqué que les cartes de développement Thread étaient également éligibles pour une mise à jour du micrologiciel de la version 1.1.5 à 1.1.9, alors j'ai continué et cela a fonctionné parfaitement.

Topologie du réseau Thread

Thread s'appuie sur un réseau Mesh, donc lorsque les nœuds sont proches du routeur, ils se connectent directement au routeur, et lorsqu'ils sont hors de portée ou que le signal est faible, ils peuvent eux-mêmes agir comme des routeurs. Avec tous les appareils sur mon bureau…

… le réseau avait une topologie en étoile comme prévu.

J’ai donc essayé d’éloigner les planches les unes des autres et de les disposer en ligne droite, voire d’en placer une à l’extérieur.

Nous pouvons facilement repérer celui à l’extérieur avec une température et un éclairement plus élevés.

En cliquant sur « Self » dans le graphique de topologie, on voit aussi la puissance du signal du nœud connecté au routeur de bordure Thread. Je n'arrivais toutefois pas à faire fonctionner une carte de développement comme routeur, même en l'éloignant pour affaiblir le signal. Les ingénieurs GL.iNet m'ont expliqué qu'il fallait pour cela un firmware de routeur Thread :

Le firmware installé par défaut sur nos cartes TBD les configure comme appareils terminaux Thread ; elles ne peuvent donc pas communiquer directement entre elles. Nous vous enverrons le firmware de routeur Thread et les instructions pour le flasher sur une carte TBD plus tard dans la journée.

Ils m'ont envoyé le firmware du routeur, ainsi que le mcumgr utilitaire pour Linux et Windows.

J'ai connecté l'une des cartes de développement Thread à un Linux (Ubuntu 22.04) PC :

print("Hello World") sera affiché sous la forme print("Hello World")`.

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

Le port série est détecté, je peux donc exécuter la commande pour vérifier l'état actuel du 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)

Il a échoué la première fois avec l'erreur « NMP timeout », mais a fonctionné la deuxième fois. Nous pouvons voir que le firmware 1.1.9 que j'ai mis à jour dans le panneau d'administration se trouve dans l'emplacement 0, et le firmware 1.1.5 antérieur dans l'emplacement 1. Je peux maintenant essayer de flasher le firmware du routeur :

$ 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

Vérifions-le à nouveau :

$ 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

Le micrologiciel de l'emplacement 0 est le micrologiciel actuellement en cours d'exécution, tandis que le micrologiciel de l'emplacement 1 est la version du routeur que nous venons de flasher. Nous pouvons passer au nouveau firmware comme suit :

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

Nous pouvons ensuite redémarrer la carte et nous assurer que le nouveau firmware commençant par le hachage 7dbb est dans l'emplacement 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)

Après avoir ajouté à nouveau la carte au panneau d'administration, nous pouvons voir le Thread Leader (GL-S200), deux périphériques finaux et un routeur (la carte que nous venons de flasher avec le micrologiciel du routeur).

Aucun des périphériques finaux n'est connecté au routeur Board 1 car tous sont sur mon bureau et connectés au GL-S200. Je déplace donc la carte 1 avec l'un des périphériques finaux dans une autre pièce, à 12 mètres du routeur GL-S200 Thread Border. Mais la topologie n'a pas changé. Il semble que la connexion soit « collante » et qu'un nœud Thread ne se reconnectera à un autre routeur que s'il est hors de portée, et pas uniquement en fonction de la force du signal.

Mais lorsque j'ai éteint le GL-S200 et l'ai redémarré, les deux périphériques finaux s'étaient reconnectés au routeur Board 1 qui était désormais le « Thread Leader » du réseau.

Donc ça marche. Je ne m'attendais pas à ce que cela fonctionne exactement comme ça car la carte 2 est à 10 centimètres du routeur GL-S200 Thread Border (auto) et la carte 1 est à 12 mètres, mais la carte 2 ne s'est pas reconnectée au GL-S200, même après un certain temps. En d'autres termes, tant que la connexion est active, un nœud Thread ne se reconnectera pas à un autre routeur même s'il est plus proche et avec un signal plus fort, et je suppose que cela a du sens pour la durée de vie de la batterie.

J'ai donc pris la carte 2 (appareil final) et la carte 1 (routeur) pour un court voyage hors de portée du GL-S200, puis j'ai allumé la carte 1, suivie de la carte 2 pour m'assurer qu'elles étaient associées, et je suis rentré chez moi à pied. Et cela a fonctionné, comme dans le schéma ci-dessus, la carte 2 se connecte au « Thread Leader » GL-S200 via la carte 1 agissant comme un routeur.

Informations sur la carte de développement Thread GL

Si nous cliquons sur les trois points dans la colonne Action d'un appareil spécifique, nous aurons accès à plus d'options avec les détails de l'appareil, afficher les enregistrements, modifier l'appareil, obtenir le code et réinitialiser l'appareil.

Informations sur l'appareil

Nous obtiendrons le EUI-64, le nom, l'adresse IPv6, l'adresse MAC étendue (64 bits au lieu des 48 bits habituels), la version du micrologiciel et les données du capteur.

Afficher les enregistrements

Après avoir laissé les cartes fonctionner pendant plus de 24 heures, je suis allé consulter le menu « Afficher les enregistrements » pour voir les graphiques des valeurs des capteurs d'une carte spécifique.

Cela semble plutôt bien, mais comme vous pouvez le voir en bas à gauche, il y a des valeurs à 21 heures et le graphique ne commence qu'à 23 heures pour une raison quelconque. C'est pareil pour toutes les planches.

Cela semble encore pire sur le graphique horaire. Cela ressemble à un bug d'affichage plutôt qu'à des points de données manquants puisque nous pouvons toujours obtenir un point de données sur le côté gauche.

Exemples de codes

La section « Obtenir le code » peut être la partie la plus importante si vous souhaitez surveiller et contrôler vos propres appareils Thread avec cinq exemples de code fournis.

Nous devrons nous connecter au routeur Thread Border GL-S200 via SSH pour exécuter les exemples. Commençons par le code permettant de lire les données des capteurs.

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

Nous pouvons également sélectionner un appareil spécifique à l'aide de son 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

Voici le code source pour référence :

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

Essayons les autres échantillons.

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

Le deuxième échantillon contrôle les deux RGB LEDs sur la carte sélectionnée par son dispositif EUI-64 ID :

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

Voici une courte démo vidéo pour montrer à quoi cela ressemble.

L'échantillon de contrôle GPIO définit certaines E/S en mode de sortie, faible et élevé, toujours pour une carte spécifique :

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

Les deux derniers exemples pour contrôler le LEDs et le GPIOs utilisent la commande coap_cli « petite implémentation CoAP », par exemple, pour désactiver le LEDs :

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

Utilisation 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 démo du déclencheur d'action rapporte l'état du bouton :

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

Le code s'appuie sur le binaire /usr/bin/eco [Mise à jour : on dirait que c'est le éco-lua Lua projet d'interprète, voir section commentaires] :

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

Il en va de même pour l'échantillon de déclenchement du capteur qui surveille le capteur PIR pour toutes les cartes de développement Thread connectées au routeur Thread Border 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.

Tous ces exemples pourraient vous aider à démarrer avec vos propres scripts.

GL-S200 « Automatisations »

La section GL DEV BOARDS comprend également une section « Automatisations ».

Je vais essayer de contrôler le RGB LEDS sur deux cartes de développement Thread en utilisant le bouton de la troisième carte restante.

Après avoir donné un nom à l’automatisation, nous pouvons sélectionner l’action de l’utilisateur, puis la carte que nous utiliserons comme bouton : « Board 2 ».

J'ai sélectionné « Tourner le bouton », puis « Action du ou des appareils ».

Puisque je veux contrôler les deux autres cartes, j'ai sélectionné « Carte 1 » et « Carte 2 ».

Ensuite, la seule option est « Changer la couleur », alors sélectionnons-la et cliquez sur Appliquer.

Mais cela ne fonctionne pas et le RGB LEDs reste éteint quelle que soit la direction dans laquelle je tourne le bouton. J'ai finalement découvert que le RGB LEDs devait être allumé avant de pouvoir changer les couleurs, j'ai donc créé une autre automatisation pour allumer/éteindre le LEDs lorsque vous appuyez sur le bouton.

Et maintenant ça marche.

La section Automatisation prend également en charge les webhooks, j'ai donc décidé de créer une automatisation pour m'alerter dans Discord lorsqu'un mouvement est détecté. Pour cela, j'ai créé un serveur Discord et obtenu un Webhook URL(https://discord.com/api/webhooks/xxxx) suivant les instructions sur Discord.

Ensuite, j'ai créé une autre automatisation en sélectionnant Sensor Trigger…

… « Corps humain détecté » (ce qui signifie simplement que le capteur de mouvement PIR a été déclenché)

… et « Webhook ».

Là, j'ai ajouté mon Webhook URL, sélectionné Json et ajouté du contenu tel que :

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

J'ai ensuite cliqué sur Apply et répété l'opération pour détecter les mouvements dans la cuisine et le bureau.

Maintenant, je peux accéder à Discord et me promener dans la maison pour déclencher les capteurs de mouvement PIR pour les trois cartes.

Succès ! La section d'automatisation est plutôt soignée, mais il semble qu'elle ne fonctionne qu'avec les cartes de développement GL.iNet Thread. J'ai donc demandé si le code source serait partagé pour permettre aux utilisateurs de mettre à jour la solution afin qu'elle fonctionne avec leurs propres appareils Thread, mais je n'ai pas obtenu de réponse à cette question spécifique.

Divers

Tout comme les autres périphériques réseau GL.iNet, le GL-S200 prend en charge GoodCloud pour l'accès à distance, mais son utilisation est limitée car les parties Thread et Bluetooth ne sont pas prises en charge.

Au départ, je pensais que le bouton Mode Switch pourrait être utilisé pour basculer entre BLE et Thread, mais tout comme dans les routeurs précédents, il peut être configuré pour activer/désactiver WireGuard ou OpenVPN.

En raison de contraintes de temps, je n'ai pas testé la partie Bluetooth, mais je m'attendrais à ce que l'interface et l'expérience soient similaires à celles de la version Bluetooth. Pont GL-S10 BLE à MQTT J'ai révisé l'année dernière.

Ce test a été intéressant. Merci à GL.iNet de m'avoir envoyé le kit de routeur de bordure Thread GL-S200 pour l'évaluer en version bêta. Le kit reçu est disponible en précommande pour 154,00 $ plus frais d'expédition, mais si vous disposez déjà de vos propres nœuds Thread, alors le GL-S200 seul est vendu 79 $ pendant la période de précommande, après quoi ce sera 99 $.

Jean-Luc Aufranc (CNXSoft) Jean-Luc a lancé CNX Software en 2010 à temps partiel, avant de quitter son poste de responsable de l'ingénierie logicielle et de commencer à rédiger des actualités et des critiques quotidiennes à temps plein plus tard en 2011.

Lire cet avis sur le logiciel CNX