Adoptez une mise en place accélérée du réseau maillé Bluetooth 5

Grâce à la disponibilité de la capacité de réseau maillé pour Bluetooth 5, les développeurs peuvent améliorer la portée et la disponibilité du réseau pour les systèmes à connexion sans fil, comme les dispositifs IoT. Cependant, le réseau maillé présente plusieurs niveaux de complexité entre la conception matérielle sans fil basse consommation et le développement logiciel du réseau maillé, ce qui peut rapidement gêner les développeurs et compromettre la planification du projet.

Avec l'émergence des smartphones Bluetooth 5 et d'autres plateformes mobiles, le temps est devenu un facteur critique, car les développeurs doivent répondre rapidement à l'expansion prévue de la demande pour une capacité de réseau Bluetooth Mesh dans presque tous les secteurs d'activités et toutes les applications. À cet effet, les fournisseurs de puces et de logiciels fournissent des solutions visant à simplifier et accélérer le processus de développement.

Cet article décrit la logique du réseau Bluetooth Mesh, ainsi que les différentes étapes du processus de développement à l'aide d'un dispositif spécifique appartenant à la ligne de modules Bluetooth 5 maillés de Silicon Labs. À l'aide de cette solution Bluetooth 5 intégrée, les développeurs peuvent rapidement déployer des dispositifs et des applications connectés pouvant pleinement exploiter le réseau Bluetooth Mesh.

L'article se termine par une description d'un kit de développement logiciel Bluetooth Mesh de Silicon Labs, avec un aperçu détaillé d'une démonstration du modèle basé sur des événements à l'aide d'un code maillé d'une application d'exemple.

L'avantage du Bluetooth Mesh

Bluetooth Mesh dépasse la capacité de connexion point-à-point de la technologie Bluetooth traditionnelle. Par le transfert des messages via les dispositifs connectés à proximité, le Bluetooth Mesh augmente la portée effective des dispositifs basse consommation au-delà de la portée réelle que permettent la sortie de puissance de l'émetteur et la sensibilité du récepteur. Plus important encore, le Bluetooth Mesh tire parti de l'aspect familier généralisé avec les applications Bluetooth sur les smartphones et d'autres dispositifs mobiles pour fournir une évolution naturelle vers des applications à connexion maillée plus sophistiquées.

Grâce à la prise en charge de la configuration maillée, les développeurs utilisant le Bluetooth peuvent désormais connecter facilement et efficacement plusieurs dispositifs destinés à la domotique, la gestion de bâtiments et de nombreux types d'applications IoT.

Fonctionnement du Bluetooth Mesh

Le Bluetooth Mesh utilise un modèle d'interaction conceptuellement simple entre les nœuds d'un réseau (Figure 1). Les types de nœuds spécialisés fournissent les capacités supplémentaires nécessaires pour relayer les messages entre les nœuds, ce qui étend la portée effective d'un réseau interagissant via un nœud proxy avec un dispositif mobile Bluetooth.

Figure 1 : Outre les nœuds périphériques de base, un réseau Bluetooth Mesh peut utiliser des types de nœuds spéciaux pour transmettre les messages à d'autres nœuds (relais), servir de cache (amis) pour les nœuds basse consommation ou connecter le réseau (proxy) à un dispositif mobile Bluetooth. (Source de l'image : Silicon Labs)

Les autres types de nœuds spécialisés permettent de traiter les exigences de basse consommation, en utilisant les nœuds amis pour mettre en cache les messages régulièrement interrogés par les nœuds basse consommation entre les modes de veille prolongée. Même avec cette fonctionnalité supplémentaire, les dispositifs Bluetooth Mesh peuvent néanmoins utiliser les services GATT (Generic Attribute Profile) pour se connecter aux anciens dispositifs utilisant des versions antérieures de Bluetooth. Par conséquent, les dispositifs maillés peuvent pleinement exploiter les capacités Bluetooth Low-Energy (BLE) comme les balises de génération de messages de zone spécifiques pour les smartphones ou l'identification aux applications de gestion des ressources.

Le Bluetooth Mesh permet également de traiter les préoccupations croissantes relatives au niveau de sécurité des réseaux protégés requis dans l'immotique et d'autres applications IoT. Contrairement au BLE pour lequel la sécurité est facultative pour protéger un dispositif unique, la sécurité est un facteur obligatoire pour le Bluetooth Mesh, afin de protéger l'ensemble du réseau maillé.

L'approche de Bluetooth en ce qui concerne la sécurité du réseau maillé est particulièrement intéressante. Son schéma de sécurité présente le concept de séparation des préoccupations relatives au réseau maillé, à l'aide de mesures de sécurité distinctes pour chaque dispositif, le réseau et l'application globale. Une clé de dispositif privée (DevKey) associée à chaque dispositif fournit la sécurité pour des opérations comme la configuration et le provisionnement qui impliquent uniquement un nœud donné. Chaque dispositif nécessite une clé de réseau (NetKey) pour communiquer avec les autres nœuds du réseau ou du sous-réseau. Enfin, les interactions au niveau des applications, telles que l'envoi d'un message pour allumer une lampe, nécessitent une clé d'application (AppKey). D'autres mesures de sécurité fournissent une protection contre les menaces courantes comme les attaques de l'intercepteur ou par rejeu. Parallèlement, le mécanisme de sécurité du Bluetooth Mesh fournit une base essentielle de la fiabilité requise pour les applications IoT plus sophistiquées.

La mise en œuvre d'une application à connexion Bluetooth Mesh présente néanmoins des difficultés considérables pour les développeurs. La plupart des applications utilisant le réseau maillé se basent sur des dispositifs à puissance limitée, en se fiant au réseau maillé pour étendre la portée effective des sous-systèmes radio basse consommation. Les défis rencontrés dans la création de dispositifs matériels basse consommation adaptés au réseau maillé peuvent bloquer même le plus expérimenté des développeurs de matériel. Même à la fin de la réalisation de leurs conceptions Bluetooth personnalisées, les développeurs peuvent faire face à des coûts considérables et des retards prolongés pour satisfaire aux exigences des certifications nationales. Les développeurs de logiciels font également face à des retards pour trouver les piles Bluetooth Mesh compatibles et pour les utiliser de façon à concevoir les couches logicielles pouvant prendre en charge leurs applications. Grâce au matériel et aux logiciels Bluetooth de Silicon Laboratories, cependant, les développeurs peuvent rapidement déployer la fonctionnalité Bluetooth Mesh dans des dispositifs basse consommation pour leurs applications.

Module Bluetooth

La solution Bluetooth Mesh de Silicon Labs s'appuie sur son module matériel basse consommation Bluetooth BGM13P, qui combine un processeur sans fil et une pile Bluetooth complète pour fournir un système Bluetooth certifié et complet dans un boîtier de 12,9 mm x 15,0 mm x 2,2 mm. Le système sur puce (SoC) sans fil Blue Gecko EFR32BG13, au cœur du module, fournit les fonctionnalités de base. Le SoC EFF32BG13 combine un cœur Arm® Cortex®-M4 32 bits, un sous-système radio de 2,4 GHz, 512 ko de mémoire Flash, 64 ko de RAM et un vaste complément de périphériques analogiques et numériques. Outre un crypto-accélérateur matériel sur puce, le SoC prend en charge la demande croissante d'une sécurité plus stricte grâce à une unité de gestion de la sécurité qui fournit un contrôle d'accès granulaire aux périphériques, similaire à celui que l'unité de protection de mémoire fournit à la mémoire.

Le SoC EFR32BG13 peut servir de base pour une conception matérielle Bluetooth personnalisée. À l'aide du SoC, les développeurs prennent en charge non seulement les exigences de conception, comme le circuit de support du SoC, mais également la certification requise pour la conception réalisée. Le module fournit une conception entièrement certifiée qui inclut l'EFR32BG13 avec les circuits de support requis, y compris plusieurs sources d'oscillateur, deux quartz et des pilotes de port. Simultanément, le module fournit une variété de fonctionnalités écoénergétiques permettant aux développeurs de répondre à la demande continue en dispositifs basse consommation.

Le module consomme uniquement 87 µA/MHz en mode actif et 1,4 µA en mode veille profonde avec une conservation complète de RAM. Pour pouvoir optimiser la durée d'activation du mode de veille profonde basse consommation, les ingénieurs peuvent exploiter des fonctionnalités comme l'interface de capteur basse puissance et le temporisateur basse puissance. À l'aide de l'interface de capteur basse puissance, les ingénieurs peuvent programmer la machine à états finis intégrée au module et les périphériques analogiques pour obtenir et traiter les signaux de capteur même si le processeur reste en mode veille profonde. De même, le temporisateur basse puissance permet aux ingénieurs de générer des formes d'ondes simples et de surveiller l'horloge temps réel/le compteur pour exécuter des actions à des périodes définies, sans impliquer le processeur.

Bien entendu, la consommation énergétique des dispositifs sans fil dépend généralement du rendement du sous-système radio. Dans ce cas, le sous-système radio de 2,4 GHz du module consomme uniquement 9,9 mA en mode de réception et 8,5 mA en mode de transmission, avec une puissance de sortie de 0 dBm. Toutefois, le module fournit une fonctionnalité supplémentaire pour les économies d'énergie via le contrôle RF. Les développeurs peuvent programmer une fonctionnalité de détection RF dans le module pour activer le processeur en cas de détection d'une énergie RF large bande. À l'aide de cette approche, les développeurs peuvent maintenir le module en mode veille profonde pendant les périodes d'inactivité sans interrompre les communications. Selon les indications précédentes, cependant, les développeurs peuvent également configurer un dispositif en tant que nœud Bluetooth 5 basse consommation. Ce dernier sort périodiquement de la veille profonde afin d'interroger un nœud ami pour les messages mis en cache.

Développement de système

Malgré toutes ses fonctionnalités, la mise en œuvre du module présente peu de difficulté. Les développeurs peuvent simplement intégrer le module dans une conception dotée d'un processeur existant pour l'utiliser comme un coprocesseur de réseau Bluetooth (Figure 2A). Par ailleurs, les développeurs peuvent utiliser le module comme une solution système complète (Figure 2B). Dans ce mode autonome, les développeurs peuvent exécuter leur code d'application sur le processeur EFR32BG13 du module et utiliser les périphériques analogiques et numériques intégrés à l'EFR32BG13 pour l'acquisition des signaux dans une conception IoT simplifiée.

Figure 2 : Les concepteurs peuvent utiliser le module BGM13P en tant que coprocesseur Bluetooth pour un CPU hôte (A) ou l'utiliser en tant que système autonome (B), en exploitant le SoC EFR32BG13 intégré au module pour l'exécution du programme d'application et même pour l'acquisition des données de capteur. (Source de l'image : Silicon Labs)

Les développeurs peuvent davantage simplifier leur conception Bluetooth à l'aide du BGM13P22F512GA-V2, une version du module incluant une antenne intégrée. Pour les conceptions ciblant un environnement RF plus complexe, les développeurs peuvent utiliser le BGM13P22F512GE-V2, une version dotée d'un connecteur U.FL pour fixer une antenne patch compatible Bluetooth, comme le FXP74.07.0100A de Taoglas.

Silicon Labs permet même d'éliminer ce niveau de mise en œuvre matériel grâce à son kit de développement SLWSTK6101C. Adapté aux cartes plug-in pour ses nombreux dispositifs Bluetooth, le SLWSTK6101C fournit une conception IoT typique qui inclut une mémoire Flash de 8 Mo MX25R8035F de Macronix, un écran LCD 128 x 128 LS013B7DH03 de Sharp Microelectronics et un capteur d'humidité et de température Si7021 de Silicon Labs. Dans ce cas, les développeurs branchent la carte radio sans fil SLWRB4306A qui inclut le module BGM13P sur la carte SLWSTK6101C.

En plus d'être une conception prête pour la production, l'ensemble complet de la carte fournit une conception de référence éprouvée que les ingénieurs peuvent utiliser pour examiner les différentes approches d'interfaçage des dispositifs, comme la mémoire Flash, l'écran LCD et le capteur.

Par exemple, la mémoire Flash de 8 Mo et l'écran LCD se connectent au module via le bus SPI, l'interface I²C du capteur Si7021 partage le bus avec une embase externe sur la carte de développement. Silicon Labs explique une méthode pour concevoir une interface simplifiée permettant de maintenir régulièrement le capteur à l'état inactif et électriquement isolé du bus partagé. Lorsque l'entrée PD15 du module passe à l'état haut, il en va de même pour la sortie SENSOR_ENABLE, connectant le capteur au rail d'alimentation VMCU 3,3 V et au bus I²C (Figure 3).

Figure 3 : En plus de fournir une plateforme d'évaluation matérielle, le kit de développement SLWSTK6101C de Silicon Labs sert de conception de référence en illustrant les méthodes d'interfaçage avec un dispositif externe, comme le capteur Si7021 de Silicon Labs qui est représenté ici. (Source de l'image : Silicon Labs)

L'embase de bus I²C partagé ne constitue qu'une des nombreuses fonctionnalités conçues pour la prise en charge du développement dans cette plateforme (Figure 4). Outre le débogueur J-Link intégré, la carte fournit une interface PTI (Packet Trace Interface) permettant aux ingénieurs d'analyser les paquets en détail. L'interface PTI s'appuie sur un paquet et une unité de traçage d'état intégrés dans le SoC EFR32BG13 pour fournir une capture non intrusive de tous les paquets envoyés et reçus par le système. Pour analyser les protocoles complexes comme Bluetooth Mesh, la fonctionnalité de traçage de paquets fournit un outil pouvant s'avérer essentiel pour l'optimisation et l'accord des communications réseau de bas niveau.

Figure 4 : Le kit SLWSTK6101C de Silicon Labs propose plusieurs interfaces pour le traçage de paquets, la surveillance de l'alimentation et le traçage ARM ETM (Embedded Trace Macrocell), fournissant ainsi aux ingénieurs une vaste gamme d'outils pour une analyse approfondie du fonctionnement et des performances de la conception. (Source de l'image : Silicon Labs)

Si les experts réseau requièrent des fonctionnalités telles que l'interface PTI pour l'optimisation du réseau, les développeurs de système requièrent des outils qui peuvent les aider à identifier les défauts d'une application pouvant entraîner une consommation énergétique excédentaire. Pour ce type d'optimisation au niveau de l'application, le profileur d'énergie Simplicity Studio de Silicon Labs fournit une analyse du code de la consommation énergétique.

Tout comme l'outil de traçage de paquets, le profileur d'énergie exploite des matériels sous-jacents. Dans ce cas, la carte inclut un circuit de surveillance d'énergie dédié comprenant une résistance de détection de courant, un amplificateur de détection du courant et des étages de gain fournissant leur sortie à un contrôleur de la carte pour offrir un accès à un système hôte de développement (Figure 5). Les étages de gain parallèles permettent au système de surveillance d'énergie de mesurer un courant entre 0,1 μA et 95 mA à deux niveaux de résolution différents : une résolution de 0,1 mA au-dessus de 250 μA et une résolution de 1 μA en dessous du seuil de 250 μA.

Figure 5 : Intégrés au module Bluetooth BGM13P, un circuit de surveillance d'énergie dédié et un contrôleur de traitement peuvent fournir une mesure d'intensité non invasive entre 0,1 μA et 95 mA. (Source de l'image : Silicon Labs)

Si le circuit de surveillance d'énergie génère les mesures du courant, les mécanismes de traçage de bas niveau intégrés dans l'EFR32BG13 peuvent régulièrement échantillonner le compteur du programme du processeur et extraire les résultats sur la broche de sortie du fil série du dispositif. En combinant les résultats du système de surveillance d'énergie et la sortie de traçage du programme, le profileur d'énergie peut fournir un affichage en temps réel de la consommation énergétique associée au code exécuté sur le dispositif (Figure 6).

Figure 6 : Le profileur d'énergie Simplicity Studio combine une sortie de surveillance d'énergie avec les données de traçage de programme pour fournir un affichage en temps réel de la consommation énergétique associée au code réel. (Source de l'image : Silicon Labs)

Développement d'une application maillée

Si les ingénieurs matériels peuvent utiliser le kit de développement pour optimiser leurs conceptions matérielles, les développeurs logiciels peuvent exploiter l'environnement de développement logiciel étendu de Silicon Labs pour pouvoir rapidement créer des applications à réseau maillé. Fournie avec le profileur Simplicity Studio, la pile maillée Bluetooth 5 de Silicon Labs ajoute des ressources maillées spécifiques à la pile Bluetooth de base. Par conséquent, les développeurs peuvent facilement migrer des protocoles Bluetooth plus conventionnels, comme les communications point-à-point ou par balise, vers des topologies maillées complètes (Figure 7).

Figure 7 : La pile Bluetooth Mesh de Silicon Labs ajoute des couches maillées (en vert) à l'ancienne fonctionnalité Bluetooth (en bleu) en permettant aux développeurs d'exploiter toute la gamme de fonctionnalités Bluetooth, des balises aux configurations maillées complètes. (Source de l'image : Silicon Labs)

Utilisé avec les cartes de développement SLWRB4306A et SLWSTK6101C basées sur BGM13P de Silicon Labs, Simplicity Studio permet aux développeurs de configurer leur environnement avec les kits de développement logiciel (SDK) adaptés. Pour le développement Bluetooth, Studio fournit le SDK Bluetooth Mesh de Silicon Labs avec un code source et des fichiers binaires de démonstration pré-intégrés. Dans cet environnement, les développeurs peuvent travailler avec un code d'exemple qui met en œuvre une application Bluetooth Mesh complète.

Conçues pour la démonstration des opérations dans un réseau Bluetooth Mesh, les applications d'exemple peuvent être utilisées avec la carte de développement et une application mobile pour guider le développeur tout au long des opérations maillées typiques, y compris le provisionnement, la configuration et l'utilisation relative à l'application. Pour déployer l'application d'exemple, les ingénieurs exécutent Simplicity Studio sur un ensemble de cartes de développement configurées séparément pour servir en tant que lampe ou commutateur dans une application d'éclairage connecté. En utilisant le code et le matériel d'exemple, les ingénieurs peuvent bénéficier d'une meilleure compréhension de chaque phase opérationnelle d'une application maillée typique à partir du démarrage du dispositif.

Avec l'architecture logicielle de Silicon Labs, les opérations Bluetooth s'exécutent en une série d'événements, en utilisant des ID d'événement prédéfinis pour signaler la nature de l'événement. Dans le pack logiciel d'exemple, la routine main(), qui s'exécute pendant le démarrage ou la réinitialisation, envoie simplement des appels pour une série de routines d'initialisation avant d'entrer dans sa boucle principale, qui comprend uniquement deux lignes de code dans ce cas (Liste 1).

Copier int main() { #ifdef FEATURE_SPI_FLASH /* Put the SPI flash into Deep Power Down mode for those radio boards where it is available */ MX25_init(); MX25_DP(); /* We must disable SPI communication */ USART_Reset(USART1); #endif /* FEATURE_SPI_FLASH */ enter_DefaultMode_from_RESET(); #if (EMBER_AF_BOARD_TYPE == BRD4304A) LNA_init(); #endif gecko_init(&config); #ifdef FEATURE_PTI_SUPPORT APP_ConfigEnablePti(); #endif // FEATURE_PTI_SUPPORT RETARGET_SerialInit(); /* initialize LEDs and buttons. Note: some radio boards share the same GPIO for button & LED.
   * Initialization is done in this order so that default configuration will be button for those * radio boards with shared pins. led_init() is called later as needed to (re)initialize the LEDs * */ led_init(); button_init(); LCD_init(); while (1) { struct gecko_cmd_packet *evt = gecko_wait_event(); handle_gecko_event(BGLIB_MSG_ID(evt->header), evt); } } 

Liste 1 : Simplicity Studio fournit un environnement de développement étendu comprenant un code d'exemple tel que cette routine principale d'éclairage maillé, qui démontre l'initialisation et la mise en boucle pour le traitement des événements. (Source du code : Silicon Labs)

Dans la première ligne de la boucle principale, la fonction gecko_wait_event() est bloquée pendant l'attente de l'apparition d'un événement dans une file d'attente d'événements alimentée par niveaux inférieurs. Même si les développeurs évitent souvent de bloquer les fonctions, cette approche est particulièrement efficace dans ce cas, parce que la pile Bluetooth gère automatiquement les états de veille basse consommation en mode bloqué. Pour les exigences d'application spécifiques ne permettant pas de bloquer les attentes, le SDK fournit également une fonction sans blocage qui renvoie l'événement suivant ou le message NULL (nul) si la file d'attente est vide. Cependant, en utilisant cette fonction, les développeurs doivent personnellement se charger de la gestion du mode veille basse consommation.

Dans la seconde ligne de la boucle principale, la fonction de gestion handle_gecko_event() traite le dernier événement (evt) en fonction de son ID d'événement (Liste 2). Lorsqu'un dispositif démarre, la pile génère un événement de démarrage de système (gecko_evt_system_boot_id). À son tour, le gestionnaire d'événements envoie un appel pour une série de fonctions d'initialisation, y compris gecko_cmd_mesh_node_init(), qui initialise la pile Bluetooth Mesh. Ensuite, le gestionnaire envoie un appel pour d'autres fonctions afin de fournir la fonctionnalité associée au type d'événement indiqué par l'ID d'événement associé.

Copier /** * Handling of stack events. Both Bluetooth LE and Bluetooth mesh events are handled here.
 */ static void handle_gecko_event(uint32_t evt_id, struct gecko_cmd_packet *evt) { struct gecko_bgapi_mesh_node_cmd_packet *node_evt; struct gecko_bgapi_mesh_generic_server_cmd_packet *server_evt; struct gecko_msg_mesh_node_provisioning_failed_evt_t *prov_fail_evt; if (NULL == evt) { return; } switch (evt_id) { case gecko_evt_system_boot_id: // check pushbutton state at startup. If either PB0 or PB1 is held down then do factory reset if (GPIO_PinInGet(BSP_GPIO_PB0_PORT, BSP_GPIO_PB0_PIN) == 0 || GPIO_PinInGet(BSP_GPIO_PB1_PORT, BSP_GPIO_PB1_PIN) == 0) { initiate_factory_reset(); } else { struct gecko_msg_system_get_bt_address_rsp_t *pAddr = gecko_cmd_system_get_bt_address(); set_device_name(&pAddr->address); // Initialize Mesh stack in Node operation mode, wait for initialized event gecko_cmd_mesh_node_init(); // re-initialize LEDs (needed for those radio board that share same GPIO for button/LED) led_init(); } break; .
      .
      .
    case gecko_evt_mesh_node_initialized_id: printf(node initialized\r\n); struct gecko_msg_mesh_node_initialized_evt_t *pData = (struct gecko_msg_mesh_node_initialized_evt_t *)&(evt->data); if (pData->provisioned) { .
      .
      .
      } else { printf(node is unprovisioned\r\n); LCD_write(unprovisioned, LCD_ROW_STATUS); printf(starting unprovisioned beaconing...\r\n); gecko_cmd_mesh_node_start_unprov_beaconing(0x3); // enable ADV and GATT provisioning bearer } break; case gecko_evt_mesh_node_provisioning_started_id: printf(Started provisioning\r\n); LCD_write(provisioning..., LCD_ROW_STATUS); // start timer for blinking LEDs to indicate which node is being provisioned gecko_cmd_hardware_set_soft_timer(32768 / 4, TIMER_ID_PROVISIONING, 0); break; case gecko_evt_mesh_node_provisioned_id: _my_index = 0; // index of primary element hardcoded to zero in this example lightbulb_state_init(); printf(node provisioned, got index=%x\r\n, _my_index); // stop LED blinking when provisioning complete gecko_cmd_hardware_set_soft_timer(0, TIMER_ID_PROVISIONING, 0); LED_set_state(LED_STATE_OFF); LCD_write(provisioned, LCD_ROW_STATUS); break; case gecko_evt_mesh_node_provisioning_failed_id: prov_fail_evt = (struct gecko_msg_mesh_node_provisioning_failed_evt_t *)&(evt->data); printf(provisioning failed, code %x\r\n, prov_fail_evt->result); LCD_write(prov failed, LCD_ROW_STATUS); /* start a one-shot timer that will trigger soft reset after small delay */ gecko_cmd_hardware_set_soft_timer(2 * 32768, TIMER_ID_RESTART, 1); break; .
      .
      .
  } } 

Liste 2 : Les développeurs peuvent examiner le code d'exemple maillé de Silicon Labs pour vérifier les modèles de conception, tels que le provisionnement du traitement des événements qui est indiqué dans cet extrait de la routine de gestion d'événement handle_gecko_event(), appelée dans la routine principale d'éclairage maillé (voir Liste 1). (Source du code : Silicon Labs)

L'une des principales séries d'événements dans un réseau Bluetooth Mesh concerne le processus de provisionnement. Après le démarrage d'un dispositif et la réalisation de sa séquence d'initialisation, ce dernier passe en mode de balisage en s'identifiant au réseau pour le provisionnement. Jusqu'à la réalisation (ou l'échec) du provisionnement, le code d'exemple utilise l'écran LCD et les LED du kit de développement pour indiquer l'état. En examinant le bloc de code du gestionnaire d'événements pour chaque état de provisionnement, les développeurs peuvent rapidement comprendre la séquence de provisionnement et les options disponibles.

De même, les ingénieurs logiciels peuvent utiliser le code d'exemple du gestionnaire comme guide pour créer leur fonctionnalité au niveau de l'application. Par exemple, l'utilisation d'un modèle publication-abonnement pour associer des nœuds ayant une relation fonctionnelle en commun constitue une conception clé dans le réseau Bluetooth Mesh (Figure 8).

Figure 8 : Les développeurs d'application utilisent le modèle publication-abonnement de Bluetooth pour combiner les dispositifs en groupes fonctionnels tels qu'un groupe de lampes contrôlé par un ou plusieurs commutateurs. (Source de l'image : Silicon Labs)

Avec cette approche, plusieurs ampoules intelligentes peuvent être abonnées à un commutateur de publication. Lorsque l'utilisateur final active le commutateur, ce dernier publie l'événement ON/OFF. Cet événement sera mis en cascade dans le réseau maillé sur les ampoules intelligentes abonnées, et les gestionnaires d'événements prendront l'action appropriée. Le code d'exemple de Silicon Labs démontre ce processus – d'abord avec une demande de marche/arrêt publiée dans le commutateur connecté du réseau maillé (Liste 3), puis avec une réponse correspondante dans la lampe connectée (Liste 4).

Copier /** * This function publishes one on/off request to change the state of light(s) in the group.
 * Global variable switch_pos holds the latest desired light state, possible values are * switch_pos = 1 -> PB1 was pressed, turn lights on * switch_pos = 0 -> PB0 was pressed, turn lights off * * This application sends multiple requests for each button press to improve reliability.
 * Parameter retrans indicates whether this is the first request or a re-transmission.
 * The transaction ID is not incremented in case of a re-transmission.
 */ void send_onoff_request(int retrans) { uint16 resp; uint16 delay; struct mesh_generic_request req; req.kind = mesh_generic_request_on_off; req.on_off = switch_pos ? MESH_GENERIC_ON_OFF_STATE_ON : MESH_GENERIC_ON_OFF_STATE_OFF; // increment transaction ID for each request, unless it's a retransmission if (retrans == 0) { trid++; } /* delay for the request is calculated so that the last request will have a zero delay and each * of the previous request have delay that increases in 50 ms steps. For example, when using three * on/off requests per button press the delays are set as 100, 50, 0 ms */ delay = (request_count - 1) * 50; resp = gecko_cmd_mesh_generic_client_publish( MESH_GENERIC_ON_OFF_CLIENT_MODEL_ID, _my_index, trid, 0, // transition delay, 0, // flags mesh_generic_request_on_off, // type 1, // param len &req.on_off /// parameters data )->result; if (resp) { printf(gecko_cmd_mesh_generic_client_publish failed,code %x\r\n, resp); } else { printf(request sent, trid = %u, delay = %d\r\n, trid, delay); } } 

Liste 3 : Cet extrait de l'application d'exemple du commutateur de réseau maillé de Silicon Labs illustre l'utilisation du processus de publication de Bluetooth 5 (gecko_cmd_mesh_generic_client_publish) pour demander un changement d'état (marche ou arrêt) d'une lampe abonnée à ce flux d'événements. (Source du code : Silicon Labs)

Copier static void onoff_request(uint16_t model_id, uint16_t element_index, uint16_t client_addr, uint16_t server_addr, uint16_t appkey_index, const struct mesh_generic_request *request, uint32_t transition_ms, uint16_t delay_ms, uint8_t request_flags) { printf(ON/OFF request: requested state=<%s>, transition=%u, delay=%u\r\n, request->on_off ? ON : OFF, transition_ms, delay_ms); if (lightbulb_state.onoff_current == request->on_off) { printf(Request for current state received; no op\n); } else { printf(Turning lightbulb <%s>\r\n, request->on_off ? ON : OFF); if (transition_ms == 0 && delay_ms == 0) { // Immediate change lightbulb_state.onoff_current = request->on_off; lightbulb_state.onoff_target = request->on_off; if (lightbulb_state.onoff_current == MESH_GENERIC_ON_OFF_STATE_OFF) { LED_set_state(LED_STATE_OFF); } else { LED_set_state(LED_STATE_ON); } } else { // Current state remains as is for now lightbulb_state.onoff_target = request->on_off; LED_set_state(LED_STATE_TRANS); // set LEDs to transition mode gecko_cmd_hardware_set_soft_timer(TIMER_MS_2_TIMERTICK(delay_ms + transition_ms), TIMER_ID_TRANSITION, 1); } lightbulb_state_store(); } if (request_flags & MESH_REQUEST_FLAG_RESPONSE_REQUIRED) { onoff_response(element_index, client_addr, appkey_index); } else { onoff_update(element_index); } } 

Liste 4 : L'exemple de lampe de réseau maillé de Silicon Labs inclut des routines pour les événements spécifiques à l'application, tels que la fonction de marche/arrêt de la LED en réponse à une demande publiée du commutateur (voir Liste 3). (Source du code : Silicon Labs)

Outre la pile Bluetooth et le SDK pour le développement de nœud, Silicon Labs fournit également la pièce finale du puzzle Bluetooth Mesh – la connexion aux dispositifs mobiles. La plupart des dispositifs mobiles prennent en charge Bluetooth 4 et, bien que leurs radios prennent en charge les exigences du Bluetooth 5, ils ne fournissent aucun support de pile pour les couches maillées Bluetooth 5. Silicon Labs répond à cette limitation en fournissant aux développeurs d'applications mobiles une pile logicielle supplémentaire qui fournit une fonctionnalité maillée (Figure 9).

Figure 9 : Les développeurs peuvent ajouter une pile maillée de Silicon Labs dédiée aux dispositifs mobiles sur leurs applications mobiles pour permettre l'utilisation des dispositifs mobiles Bluetooth 4 dans les réseaux maillés Bluetooth 5. (Source de l'image : Silicon Labs)

Conclusion

Le réseau maillé Bluetooth 5 fournit une transition naturelle pour une vaste gamme d'applications qui exploitent déjà les fonctions de communications point-à-point des smartphones et d'autres dispositifs mobiles. Cependant, le déploiement du réseau maillé Bluetooth 5 présente des défis considérables en matière de conception logicielle et matérielle, particulièrement dans les applications à puissance limitée telles que l'IoT. En outre, les ingénieurs matériels doivent répondre aux exigences d'empreinte minimale et de basse consommation ; les ingénieurs logiciels doivent concevoir des logiciels utilisant des ressources minimum pour exécuter les protocoles de communications complexes. En associant le module BGM13P, la carte de développement SLWSTK6101C et les piles Bluetooth pour les nœuds et les dispositifs mobiles, les ingénieurs bénéficient d'une plateforme étendue pour accélérer le développement d'applications à l'aide du réseau Bluetooth Mesh.