La semaine dernière, nous avons vérifié le matériel du kit de routeur de bordure de thread GL.iNet GL-S200 avec trois cartes de développement de thread nRF52840, et j’ai maintenant eu le temps de travailler avec le kit, donc je vais rapporter mon expérience de démarrage dans le deuxième partie de l’examen.
Configuration initiale du GL-S200
J’ai connecté le port WAN à mon commutateur Ethernet lui-même connecté à mon modem routeur et le port LAN à mon ordinateur portable, afin de pouvoir accéder à l’interface Web en utilisant l’adresse IP par défaut (192.168.8.1). Le GL-S200 utilise le même panneau d’administration que les autres routeurs GL.iNet tels que le routeur Beryl AX que nous avons examiné au début de l’année.
Vous serez accueilli par un assistant pour vous permettre de sélectionner la langue et de définir un nouveau mot de passe pour le panneau d’administration, et une fois que vous avez terminé, vous aurez accès au panneau d’administration familier GL.iNet 4.xx
Une fois l’assistant terminé, le système devrait se connecter automatiquement à Internet et le voyant RVB du milieu passera au vert sur l’appareil.
Réseau de fils
La première étape consiste alors à aller dans THREAD MESH dans le panneau de gauche afin d’activer le réseau Thread.
Une fois que vous aurez cliqué sur Activer, vous obtiendrez trois adresses IPv6 :
- Adresse lien-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’elle s’appelle Global Address dans la documentation OpenThread)
- Mesh-Local EID – Toutes les interfaces accessibles au sein du même réseau Thread
Si vous avez vos propres appareils Thread, vous pouvez passer au menu Thread Commissioning et saisir l’EUI64 de vos appareils et la clé pré-partagée, mais GL.iNet a simplifié la section de l’interface Web pour gérer leurs Thread Dev Boards, ou À déterminer pour les shorts.
Dans la section GL DEV BOARD->Devices, nous pouvons cliquer sur le bouton Add Devices, puis sur Apply. Si nous appuyons sur le commutateur SW2 d’une carte, elle sera alors automatiquement ajoutée au routeur de bordure de fil GL-S200.
Nous devons sélectionner le type A0+A1 et nommer la carte. Nous pouvons répéter la même chose pour les deux autres cartes et nous obtiendrons les valeurs de température, de pression, d’humidité et d’éclairement pour les trois cartes affichées dans le panneau 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. Faisons-le maintenant en allant dans « SYSTEM->Upgrade ».
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 qui a été compilé le 6 mars 2023.
J’ai téléchargé le fichier, dans la section Mise à niveau locale, et téléchargé le fichier sur le routeur de bordure de thread GL-S200.
La vérification a réussi, j’ai donc cliqué sur Installer, et finalement, j’ai installé le firmware 4.1.3 Release7 sur mon appareil.
Mise à jour du micrologiciel des cartes de développement de threads
Pendant que je poursuivais cette activité de mise à jour du micrologiciel, j’ai également remarqué que les cartes de développement de threads é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 de thread
Thread s’appuie sur la mise en réseau Mesh, de sorte que 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 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.
Si nous cliquons sur « Self » dans le tableau de topologie, nous pouvons également voir la force du signal du nœud connecté au Thread Border Router. Mais à aucun moment je n’ai pu utiliser le Thread Dev Board comme routeur. Nous sommes même allés marcher dehors pour essayer de nous mettre hors de portée ou au moins un signal plus faible, mais le réseau maillé ne fonctionnerait tout simplement pas comme je m’y attendais. J’ai donc demandé aux ingénieurs de GL.iNet, et ils m’ont répondu qu’un firmware de routeur de thread était nécessaire pour que cela fonctionne :
Actuellement, notre micrologiciel TBD par défaut est du dispositif d’extrémité de fil type et ne peuvent pas être directement connectés les uns aux autres. Nous vous fournirons le routeur de thread firmware et le guide de brossage TBD correspondant plus tard dans la journée.
Ils m’ont envoyé le firmware du routeur, ainsi que l’utilitaire mcumgr pour Linux et Windows.
J’ai connecté l’une des cartes de développement de threads à un PC Linux (Ubuntu 22.04):
| $ bt -l
port | âge (sec) | appareil | chauffeur | description ——+————+————+———— -+———————- * 0 | 1137 | ttyUSB0 | ch341-uart | USB série |
Le port série est détecté, je peux donc exécuter la commande pour vérifier l’état actuel du micrologiciel :
| $ sudo ./mcumgr –conntype série –connstring=/dev/ttyUSB0,baud=460800 liste d’images
Erreur : délai d’attente NMP jaufranc@cnx-laptop-4:~/edev/GL-S200/TBD upgrade$ sudo ./mcumgr –conntype serial –connstring=/dev/ttyUSB0,baud=460800 liste d’images Images: image=0 emplacement=0 Version : 1.1.9 amorçable : vrai flags : actif confirmé hachage : 88b4725af7975e0b60915c320a82082bb2dda923b736f0e31d2c7d4d67cac3d3 image=0 emplacement=1 Version : 1.1.5 amorçable : vrai drapeaux : hachage : 4d8548e6910e7214d8325a7d1a49a8390fb25cce983bdb0b15bfecc657f7860b Statut partagé : 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. Maintenant, je peux essayer de flasher le firmware du routeur :
| $ sudo ./mcumgr –conntype serial –connstring=/dev/ttyUSB0,baud=460800 téléchargement d’image GL-Thread-Dev-Board-FTD-OTA-v1.1.9.bin
426,58 Kio / 426,58 Kio [========================] 100.00% 8.93 Kio/s 47s Fait |
Vérifions à nouveau:
| $ sudo ./mcumgr –conntype série –connstring=/dev/ttyUSB0,baud=460800 liste d’images
Images: image=0 emplacement=0 Version : 1.1.9 amorçable : vrai flags : actif confirmé hachage : 88b4725af7975e0b60915c320a82082bb2dda923b736f0e31d2c7d4d67cac3d3 image=0 emplacement=1 Version : 1.1.9 amorçable : vrai drapeaux : hachage : 7dbb8a9867a000bb968099593bc1f6c2c7bb28ab458719f499364c4a77feca9f Statut partagé : N/A (0) |
Le micrologiciel de l’emplacement 0 est le micrologiciel 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 série –connstring=/dev/ttyUSB0,baud=460800 test d’image 7dbb8a9867a000bb968099593bc1f6c2c7bb28ab458719f499364c4a77feca9f |
Nous pouvons ensuite redémarrer la carte et nous assurer que le nouveau micrologiciel commençant par le hachage 7dbb est dans l’emplacement 0 :
| $ sudo ./mcumgr –conntype série –connstring=/dev/ttyUSB0,baud=460800 liste d’images
Images: image=0 emplacement=0 Version : 1.1.9 amorçable : vrai flags : actif confirmé hachage : 7dbb8a9867a000bb968099593bc1f6c2c7bb28ab458719f499364c4a77feca9f image=0 emplacement=1 Version : 1.1.9 amorçable : vrai drapeaux : hachage : 88b4725af7975e0b60915c320a82082bb2dda923b736f0e31d2c7d4d67cac3d3 Statut partagé : 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 de la carte 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 de bordure de fil GL-S200. Mais la topologie n’a pas changé. Il semble que la connexion soit « collante » et qu’un nœud Thread ne se reconnecte à un autre routeur que s’il est hors de portée, et pas seulement en fonction de la force du signal.
Mais lorsque j’ai éteint le GL-S200 et que je l’ai redémarré, les deux périphériques finaux s’étaient reconnectés au routeur de la carte 1 qui était maintenant 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 de bordure de fil GL-S200 (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 alors que. 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 (périphérique terminal) et la carte 1 (routeur) pour un court trajet 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. Et cela a fonctionné, comme dans le schéma ci-dessus, la carte 2 se connecte au «thread leader» du GL-200 via la carte 1 agissant comme un routeur.
Informations sur la carte de développement de threads GL
Si nous cliquons sur les trois points dans la colonne Action pour un appareil spécifique, nous aurons accès à plus d’options avec Détails de l’appareil, Afficher les enregistrements, Modifier l’appareil, Obtenir le code et Réinitialiser l’appareil.
Info appareil
Nous obtiendrons l’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é vérifier 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.
C’est encore pire sur le graphique horaire. Cela ressemble à un bogue 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 code
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 de bordure de thread GL-S200 via SSH pour exécuter les exemples. Commençons par le code pour lire les données des capteurs.
| root@GL-S200 :~# /usr/bin/demo_get_sensor_data
1 dev_id=9483c44004df0679 connecté=1 température=31.300811 humidité=43.409729 luminosité=0 pression=97.817392 2 dev_id=9483c47d79c19475 connecté=1 température=32.742767 humidité=53.620910 luminosité=0 pression=97.814472 3 dev_id=9483c4ec736c4f68 connecté=1 température=31.292800 humidité=42.652893 luminosité=0 pression=97.822056 |
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 connecté=1 température=31.300811 humidité=43.409729 luminosité=0 pression=97.817392 |
Voici le code source pour référence :
| 1
2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
#!/bin/ch
# Notez que ce fichier est stocké dans /usr/bin/demo_get_sensor_data # Utilisation : demo_get_sensor_data # Il imprimera toutes les données du capteur si est nul, et le est l’EUI64 du périphérique, qui a été enregistré dans /etc/config/thread_devices . /usr/share/libubox/jshn.sh dev_id=$1 si [ -z « $dev_id » ]; alors res=$(curl -s localhost/rpc -d ‘{« jsonrpc »: »2.0″, »id »: »0″, »method »: »call », »params »:[« », »gw », »get_device_list »,{}]}’) json_init json_load « $res » résultat json_select json_select device_list idx=1 while json_is_a ${idx} objet ; faire json_select ${idx} json_get_var dev_id dev_id json_get_var connecté connecté json_select dev_data json_get_var val_temp température json_get_var val_humi humidité json_get_var val_brightness luminosité json_get_var val_pression pression echo « $idx dev_id=$dev_id connecté=$température connectée=$val_temp humidité=$val_humi luminosité=$val_luminosité pression=$val_pression » json_select .. json_select .. idx=$((idx + 1)) fait autre res=$(curl -s localhost/rpc -d « {\ »jsonrpc\ »:\ »2.0\ »,\ »id\ »:\ »0\ »,\ »method\ »:\ »call\ », \ »paramètres\ »:[\ »\ »,\ »gw\ »,\ »get_device_status\ »,{\ »dev_id\ »:\ »$dev_id\ »}]} ») json_init json_load « $res » résultat json_select json_get_var dev_id dev_id json_get_var connecté connecté json_select dev_data json_get_var val_temp température json_get_var val_humi humidité json_get_var val_brightness luminosité json_get_var val_pression pression echo « dev_id=$dev_id connecté=$température connectée=$val_temp humidité=$val_humi luminosité=$val_luminosité pression=$val_pression » 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 LED RVB sur la carte sélectionnée par son ID d’appareil EUI-64 :
| root@GL-S200 :~# /usr/bin/demo_control_led 9483c44004df0679
LED éteinte CONDUIT SUR LED éteinte BASCULE DEL Changer la couleur de la LED en lumière rouge Changez la couleur de la LED en lumière orange Changer la couleur de la LED en lumière jaune Changer la couleur de la LED en lumière verte Changer la couleur de la LED en lumière bleue Changez la couleur de la LED en lumière Indigo Changez la couleur de la LED en lumière violette Changer la couleur de la LED en lumière blanche |
Voici une courte vidéo de démonstration pour montrer à quoi cela ressemble.
L’échantillon de contrôle GPIO a défini certaines E/S sur le mode de sortie, le bas et le haut, encore une fois pour une carte spécifique :
| 1
2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 |
root@GL-S200 :~# /usr/bin/demo_control_gpio 9483c44004df0679
Obtenir le statut GPIO GPIO 0.15 : 0 GPIO 0.16 : 0 GPIO 0.17 : 0 GPIO 0.20 : 0 Réglez GPIO 0.15/0.16/0.17/0.20 pour sortir le niveau bas Obtenir le statut GPIO GPIO 0.15 : 0 GPIO 0.16 : 0 GPIO 0.17 : 0 GPIO 0.20 : 0 Réglez GPIO 0.15/0.16/0.17/0.20 pour produire un niveau élevé Obtenir le statut GPIO GPIO 0.15 : 1 GPIO 0.16 : 1 GPIO 0.17 : 1 GPIO 0.20 : 1 |
Les deux derniers exemples pour contrôler les LED et les GPIO utilisent la commande coap_cli « small CoAP implementation », par exemple, pour éteindre les LED :
| coap_cli -B 2 -N -e « $ctl_cmd_led_off » -m mettre coap://[$addr]/cmd 1>/dev/null 2>/ |
Utilisation de coap_cli :
| 1
2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 |
root@GL-S200 :~# coap_cli
coap_cli v4.2.1 – une petite implémentation CoAP Copyright (C) 2010-2019 Olaf Bergmann <bergmann@tzi.org> et autres Bibliothèque TLS : Aucune Utilisation : coap_cli [-a addr] [-b [num,]taille] [-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 L’URI peut être un URI absolu ou un URI préfixé avec le schéma et l’hôte Options générales -a addr L’adresse de l’interface locale à utiliser -b [num,]taille Taille de bloc à utiliser dans les requêtes GET/PUT/POST (la valeur doit être un multiple de 16 pas supérieur à 1024) Si num est présent, la chaîne de requête commencera à numéro de bloc -e text Inclure le texte comme charge utile (utiliser le codage en pourcentage pour caractères non ASCII) -f file Fichier à envoyer avec PUT/POST (utilisez ‘-‘ pour STDIN) -l list Échec de l’envoi de certains datagrammes spécifiés par une virgule liste séparée de nombres ou de plages de nombres (uniquement pour le débogage) -l loss% Échec aléatoire de l’envoi de datagrammes avec le probabilité – 100 % tous les datagrammes, 0 % aucun datagramme -m méthode Méthode de requête (get|put|post|delete|fetch|patch|ipatch), la valeur par défaut est ‘obtenir’ -o fichier Sortir les données reçues dans ce fichier (utiliser ‘-‘ pour STDOUT) -p port Ecouter sur le port spécifié -r Utiliser un protocole fiable (TCP ou TLS) -s durée S’abonner à/Observer la ressource pour une durée donnée en secondes -t type Format de contenu pour une ressource donnée pour PUT/POST -v num Niveau de verbosité (3 par défaut, 9 au maximum). Au-dessus de 7, il y a une verbosité accrue dans la journalisation GnuTLS -A type Type de média accepté -B secondes Interrompre l’opération après avoir attendu secondes données (la valeur par défaut est 90) -K intervalle envoie un ping après un intervalle de secondes d’inactivité -N Envoie un message NON confirmable -O num,text Ajoute l’option num avec le texte du contenu à demander. Si la le texte commence par 0x, puis le texte hexadécimal est converti en données binaires -P adresse[:port] Utiliser proxy (ajoute automatiquement l’option Proxy-Uri à demande) -T jeton Inclure le jeton spécifié -U Ne jamais inclure les options Uri-Host ou Uri-Port Options PSK (si pris en charge par la bibliothèque (D)TLS sous-jacente) -k clé Clé pré-partagée pour l’utilisateur spécifié -u user Identité de l’utilisateur pour le mode clé pré-partagée Options PKI (si elles sont prises en charge par la bibliothèque (D)TLS sous-jacente) -c certfile Fichier PEM contenant à la fois le CERTIFICAT et la CLÉ PRIVÉE Cet argument nécessite que (D)TLS avec PKI soit disponible -C cafile Fichier PEM contenant le certificat CA utilisé pour signer le fichier de certificat. Cela déclenchera la validation de le certificat du serveur. Si certfile est auto-signé (comme défini par ‘-c certfile’), alors vous devez avoir sur le ligne de commande le même nom de fichier pour le certfile et cafile (comme dans ‘-c certfile -C certfile’) pour déclencher validation -R root_cafile Fichier PEM contenant l’ensemble des autorités de certification root de confiance qui doivent être utilisés pour valider le certificat du serveur. Le ‘-C cafile’ n’a pas besoin d’être dans cette liste et est ‘de confiance’ pour la vérification. Alternativement, cela peut pointer vers un répertoire contenant un ensemble de fichiers CA PEM Exemples: coap-client -m obtenir coap://[::1]/ coap-client -m obtenir coap://[::1]/.well-known/core coap-client -m obtenir coap+tcp://[::1]/.well-known/core coap-client -m obtenir coaps://[::1]/.well-known/core coap-client -m obtenir coaps+tcp://[::1]/.well-known/core coap-client -m get -T café coap://[::1]/temps echo -n 1000 | coap-client -m put -T café coap://[::1]/heure -f – |
La démo du déclencheur d’action signale 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 : Appuyez sur le bouton. 2023/03/19 17:38:16 info (/usr/bin/demo_user_action_trigger:34) 9483c44004df0679 : Appuyez sur le bouton. 2023/03/19 17:38:18 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679 : Tourner le bouton vers l’avant 2023/03/19 17:38:19 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679 : Tourner le bouton vers l’avant 2023/03/19 17:38:20 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679 : Tourner le bouton vers l’avant 2023/03/19 17:38:20 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679 : Tournez le bouton vers l’arrière 2023/03/19 17:38:21 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679 : Tournez le bouton vers l’arrière 2023/03/19 17:38:21 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679 : Tournez le bouton vers l’arrière 2023/03/19 17:38:23 info (/usr/bin/demo_user_action_trigger:34) 9483c44004df0679 : Appuyez sur le bouton. 2023/03/19 17:38:25 info (/usr/bin/demo_user_action_trigger:32) 9483c44004df0679 : Tournez le bouton vers l’arrière |
Le code repose sur /usr/bin/eco binary [Update: it looks like it’s the eco-lua Lua interpreter project, see comments section]:
| 1
2 3 4 5 6 7 8 9 dix 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 |
#!/usr/bin/env eco
— Notez que ce fichier est stocké dans /usr/bin/demo_user_action_trigger, il écoute les événements signalés lorsque l’utilisateur actionne le bouton. — Utilisation : demo_sensor_trigger ubus local = nécessite ‘eco.ubus’ sys local = nécessite ‘eco.sys’ cjson local = nécessite ‘cjson’ journal local = nécessite « glog » local OPT_TURNING_THE_KNOB = 1 locale OPT_PRESS_THE_KNOB = 2 log.level(log.LOG_INFO) sys.signal(sys.SIGINT, fonction() imprimer(‘ Vous avez SIGINT, maintenant quittez ‘) eco.unloop() fin) con local, erreur = ubus.connect() sinon con alors erreur (erreur) fin con:listen(‘user_active_trigger’, function(ev, msg) local event_data = cjson.encode(msg) log.debug(‘Déclencheur actif de l’utilisateur reçu ‘ .. ev .. ‘ ‘ .. event_data) déclencheur local, opération, direction = msg.trigger, msg.operation, msg.direction si opération == OPT_TURNING_THE_KNOB alors log.info(trigger .. ‘: Tourner le bouton ‘ .. direction) opération elseif == OPT_PRESS_THE_KNOB alors log.info(trigger .. ‘: Appuyez sur le bouton.’) autre log.err(‘Opération inconnue !’) fin fin) |
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 de threads connectées au routeur de bordure de 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 : Corps humain détecté. 2023/03/19 17:47:46 info (/usr/bin/demo_sensor_trigger:31) 9483c4ec736c4f68 : Corps humain détecté. 2023/03/19 17:47:49 info (/usr/bin/demo_sensor_trigger:31) 9483c4ec736c4f68 : Corps humain détecté. 2023/03/19 17:47:52 info (/usr/bin/demo_sensor_trigger:31) 9483c44004df0679 : Corps humain détecté. 2023/03/19 17:48:15 info (/usr/bin/demo_sensor_trigger:31) 9483c47d79c19475 : Corps humain détecté. |
Tous ces exemples pourraient vous aider à démarrer avec vos propres scripts.
GL-S200 « Automatismes »
La section GL DEV BOARDS comprend également une section « Automatisations ».
Je vais essayer de contrôler les LED RVB sur deux cartes de développement de threads en utilisant le bouton sur 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 de périphérique(s) ».
Puisque je veux contrôler les deux autres cartes, j’ai sélectionné « Board 1 » et « Board 2 ».
Ensuite, la seule option est « Changer la couleur », alors sélectionnons-la et cliquez sur Appliquer.
Mais cela ne fonctionne pas et les LED RVB restent éteintes quelle que soit la direction dans laquelle je tourne le savoir. J’ai finalement découvert que les LED RVB devaient être allumées avant de pouvoir changer les couleurs, alors j’ai créé une autre automatisation pour allumer/éteindre les LED lorsque j’appuie 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é. À cette fin, j’ai créé un serveur Discord et obtenu une URL Webhook (https://discord.com/api/webhooks/xxxx) en suivant les instructions sur Discord.
Ensuite, j’ai créé une autre automatisation en sélectionnant Sensor Trigger…
… « Human Body Detected » (ce qui signifie simplement que le capteur de mouvement PIR a été déclenché)
… et « Webhook ».
Là, j’ai ajouté mon URL Webhook, sélectionné Json et ajouté du contenu comme :
| {« content »: »OMG ! Quelqu’un vient d’entrer dans la chambre ! »} |
Enfin, j’ai cliqué sur Appliquer et j’ai répété la même procédure pour détecter le mouvement dans la cuisine et le bureau.
Maintenant, je peux aller sur 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 assez soignée, mais il semble qu’elle ne fonctionne qu’avec les cartes de développement de threads GL.iNet. 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 appareils 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 pouvait ê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’attends à ce que l’interface et l’expérience soient similaires au pont GL-S10 BLE vers MQTT que j’ai examiné l’année dernière.
Ce fut une expérience intéressante, et j’aimerais remercier GL.iNet d’avoir envoyé le kit GL-S200 Thread Border Router pour évaluation/test bêta. Le kit que j’ai reçu est disponible en précommande pour 154,00 $ plus les frais d’expédition, mais si vous avez déjà vos propres nœuds Thread, le GL-S200 seul est vendu 79 $ pendant la période de précommande, après quoi il sera de 99 $. .
Retrouvez l’histoire de Raspberry Pi dans cette vidéo :
