Je vous propose de vous parler un peu d’une partie méconnue du Bluetooth Low Energy : sa version maillée disponible depuis la version 5.0.
Je vous parlerai de sa composition, son fonctionnement, et vous présenterai un petit exemple d’usage avec un tutoriel de mise en pratique sur une carte que j’ai un peu utilisée.
Théorie, philosophie, topologie
Le SIG
Le SIG est l’organisme qui normalise le Bluetooth, composé de fondeurs de puces et d’autres grands acteurs de l’électronique. C’est la source des documents décrivant le protocole : le profil les modèles Mesh (Mesh Profil et Mesh Model). Ces deux documents sont les principales sources d’information pour les développeurs. En les parcourant, on comprend assez vite que cette version du Bluetooth Low Energy (BLE) est très orientée domotique et urbanisme technologique.
La topologie réseau
Le réseau présente donc un aspect de maille de filet. Les équipements qui le composent ne sont pas connectés à un autre en particulier, mais profitent de leurs voisins pour communiquer avec l’ensemble du réseau. Ce modèle présente comme avantage de ne pas dépendre d’un équipement en particulier, et de pouvoir étendre la portée d’un équipement aussi loin que la portée du plus lointain des équipements qui composent le réseau.
Les nœuds et éléments
Les équipements qui composent le réseau sont appelés ‘nœuds’ (nodes), pour rappeler l’analogie avec les mailles du filet. Chaque nœud peut regrouper plusieurs éléments. Les éléments sont un peu comme des "boîtes" dans lequel l’équipement peut exposer plusieurs fonctions.
Les modèles
Les modèles sont les fonctions que l’équipement met dans ses éléments. Il en existe une grande variété et ils sont décrits dans le Mesh Model. On y trouve des fonctions de différents niveaux allant de la gestion de l’alimentation à des outils d’automatisation, en passant par la gestion de la couleur/température d’un éclairage ou encore les sondes de température.
Il est également possible d’en créer des nouveaux pour ajouter de nouvelles fonctions qui ne seraient pas décrites par la norme.
Sécurité
C’est l’un des gros sujets sur lequel le SIG n’a pas fait l’impasse. Toutes les communications sont systématiquement chiffrées. Il est impossible d’envoyer un message "en clair" sur le réseau.
Sans être le protocole le plus sécurisé, il met tout de même en place un chiffrement elliptique sécurisé à l'aide de nombreuses clés et méthodes standards de sécurisation.
Le provisioning
C’est le nom de la procédure d’ajout d’équipement sur un réseau. Une entité vient se connecter à un nœud qui n’appartient pas encore à un réseau (unprovisioned). Les deux pourront alors échanger les éléments de connexion au réseau, sous la forme de plusieurs clés :
- Device key : fournie par l’équipement, c’est sa clé unique, composée, entre autres, à partir de l’adresse MAC. Elle permet de chiffrer les messages envoyés au nœud.
- Net key : fournis par le provisioner, c’est la clé du réseau qui permet d’être compris par les autres entités du réseau.
- App key : fourni par le provisioner, c’est la clé d’un sous-groupe au sein du réseau. Un équipement peut ainsi appartenir et communiquer avec plusieurs sous-groupes.
Durant la provision le nœud donne sa composition au provisioner afin qu’il puisse connaître les fonctions que celui-ci fournit.
La composition (composition data) présente la liste des éléments et des modèles qui composent le nœud.
L’équipement reçoit alors ses paramètres de communication avec le reste du réseau, dont son adresse unicast.
Communication
L’adressage et classes d’adresses
Le nœud possède son adresse unicast propre (node address) ainsi que l’adresse de ses éléments supplémentaires (element address). On dénombre quatre types d’adresse :
- Adresse unicast : représente un élément d’un nœud, la node address étant l’adresse de l’élément 0 du nœud.
- Adresse de groupe : permet de rassembler plusieurs modèles pour les contacter à l'aide d’un seul message.
- Adresses de broadcast : sorte d’adresse du groupe "par défaut", pour contacter tout ou partie du réseau (comme par exemple tous les éléments du réseau, ou uniquement les nodes address ou les proxies).
- Adresses de scénario, qui ne seront pas abordées dans cet article de découverte.
Le flooding
C’est à la fois la force et la faiblesse de ce protocole. Les messages ne sont pas routés, et sont répétés un certain nombre de fois sur le réseau par tous les nœuds relais l’ayant reçu (la fonction relais étant désactivable). Le nombre de rebonds est paramétrable grâce au Time-To-Live (TTL) du message, et les répétitions par chaque nœud sont configurables unitairement dans la fonction relais.
Afin d’éviter les redites, chaque message présente un numéro de séquence (sequence number), lequel sert à l'identification du message sur le réseau ainsi qu’au chiffrement, couplé à l'IV index.
L’IV index a pour utilité de programmer l'obsolescence du chiffrement. Avant que le numéro de séquence n'arrive en valeur maximale, une procédure visant à mettre à jour le matériel de chiffrement est démarrée, de nouvelles clés sont créées, et l’IV index est incrémenté et le numéro de séquence est remis à zéro.
Le modèle client/serveur
Il existe deux grandes familles de modèles. Les clients et les serveurs.
On peut voir les clients comme des donneurs d’ordres. Ils communiquent par commande, généralement des messages de type GET/SET, et attendent en retour des messages de type STATUS.
À l'inverse, les serveurs agiront comme actionneurs selon les ordres des clients, en répondant aux messages GET/SET par des messages STATUS.
Le système de publication/souscription
C’est la pierre angulaire de la communication entre les équipements. Chaque modèle doit envoyer un message (publier) en précisant une adresse de destination. Selon le besoin, cette publication s'effectue directement en unicast, pour cibler un élément ou bien sur une adresse de groupe (ou broadcast) pour une audience plus large.
Le modèle peut en revanche souscrire à plusieurs adresses de groupe, afin d’écouter les événements sur plusieurs canaux.
Ce système, couplé au modèle client/serveur permet à un client d’actionner plusieurs serveurs et au serveur de notifier son statut à plusieurs clients.
Friendship et nœud basse consommation
Cette fonctionnalité du protocole permet de garder un contact et de différer les communications avec un nœud si celui-ci a pour habitude de se mettre hors ligne pour économiser son énergie (LPN, pour Low Power Node). Une relation "d’amitié" peut être initiée par le LPN afin de trouver l'ami (friend) le plus proche. Ces nœuds échangent des identifiants (credentials) et le nœud friend écoutera les messages à destination du LPN alors endormi. À son réveil, le LPN pourra alors demander les messages stockés par le friend (friend poll request), les traiter, puis se rendormir paisiblement.
Cette fonction, bien que très utile, a pourtant une limitation. Le friend ne conserve pas de données en provenance du LPN et ne peut donc répondre à sa place. Il faudra attendre le prochain réveil du LPN pour recevoir un état.
Le proxy
C’est une fonctionnalité qui permet de relier le monde du Bluetooth ‘classique’ au réseau Mesh. En effet, il n’existe pas d’autre moyen de se connecter en tant que tiers à un réseau Mesh. Le proxy fait la passerelle entre les deux mondes en permettant d’encapsuler des messages Mesh dans les messages Bluetooth classiques. Le client du proxy doit alors connaître toutes les clés du réseau ainsi que sa topologie.
Les provisioners
Ils sont les chefs d’orchestre du réseau, capables de le créer et de le modifier. Chaque provisioner s’approprie une gamme d’adresses, à l’image d’un serveur DHCP, et peut attribuer des adresses aux nouveaux nœuds.
Ils ont aussi la responsabilité de la description du réseau sous la forme d’un fichier JSON (normalisé par le SIG) et de sa distribution aux autres clients des nœuds proxy.
Les modèles
Il en existe légion, pour le temps, la lumière, la position GPS, la température, etc. (voir Mesh Profile en source). De plus, la norme permet d'en développer de nouveaux selon nos besoins. Mais une caractéristique se répète, ils vont toujours par deux, le client et le serveur.
On ne peut pas en déclarer plusieurs d’un même type par élément. C'est-à-dire que si on a besoin de deux serveurs lumière dans notre équipement, il faudra les créer dans deux éléments différents afin qu’il soient accessibles par deux adresses unicast différentes.
Cependant, on peut instancier plusieurs modèles de type proche, disons lumière et RGBW. Il est recommandé de lier leurs valeurs (bind values) et de faire en sorte que si un client demande de baisser la lumière, le serveur RGBW publie aussi un statut avec une valeur plus basse, en accord avec le serveur de lumière.
Voilà pour la théorie. Pour ceux qui suivent encore, il est possible de présenter un exemple concret.
Comme dit au début de l’article, le SIG a dans ses membres des fondeurs de puces, qui proposent leurs implémentations de BLE Mesh sous forme de SDK.
Les implémentations
Les SDK des fondeurs
On peut citer par exemple celui de Nordic et celui de Silicon Labs.
Nordic
Il se présente sous la forme d’un dépôt GitHub et de l’outil SEGGER Embedded Studio. C’est proche de FreeRTOS avec une partie propriétaire et une partie ouverte. La plateforme que j’ai utilisée est la puce nRF52840, disponible sous la forme d'un kit de développement et je baserai mon cas pratique dessus. Nordic fournit également des bibliothèques pour le développement d'applications Android/IOS sur le dépôt GitHub.
Silicon Labs
Ce SDK n’est pas ouvert et c’est une boîte noire qui fournit des API et un IDE sur la base d’Eclipse. Leur kit de développement, de la gamme Gecko, est disponible chez les fournisseurs habituels. Silicon Lab, tout comme Nordic propose un support Android/iOS.
Espressif
Il existe une version dérivée de l’ESP qui permet de faire du BLE Mesh, mais nous n'avons pas testé leurs outils.
Zephyr et BlueZ l'implémentent également, mais nous vous renvoyons à leurs documentations respectives pour en savoir plus.
Cas pratique
Pour imager cette synthèse, nous vous proposons la prise en main d’un exemple du SDK Nordic nrRF2840, sur les clients/serveurs basiques, type lumière.
La carte utilisée est le kit nRF52840.
Il faut avant tout effectuer ces deux premières étapes :
Les deux exemples se présentent comme une lampe et un interrupteur.
Le dimming client est le bouton et le dimming serveur est la lampe.
Une fois vos deux cartes prêtes, il est temps de créer un réseau.
Pour cela démarrez nRF Mesh et appuyez sur le bouton “add node”.
Le scanner va écouter les devices qui ne sont pas encore provisionnés. Tapez sur l’un des deux et suivez les instructions.
Listing
Découverte des services
Identification
Provisioning
Composition du node
Faites de même avec la deuxième carte et vous disposerez d'un réseau. Il se compose d’une lumière (le dimming serveur) et des deux boutons (le dimmer client).
Il faut maintenant créer les interactions entre les éléments. pour faire simple, nous allons créer un simple groupe dans lequel ces 3 modèles publieront et souscriront.
Ainsi, les messages SET/GET émis par les clients "level" dans le groupe 0xC000 par le client dimmer seront reçus par le serveur "level" du "Mesh dimmable light".
Inversement, les messages STATUS du serveur "level" seront reçus par les deux clients "level".
Voici comment procéder :
Sélectionnez un équipement, déroulez la description des éléments puis choisissez le/les clients/serveur "level" présent :
Liez (bind) une clé d’application au modèle, afin de lui permettre de communiquer avec un sous-réseau.
Liez (bind) une clé d’application au modèle, afin de lui permettre de communiquer avec un sous-réseau.
Ainsi, tous les modèles sont maintenant capables de communiquer les uns avec les autres.
Dans ces exemples, les boutons 1 et 2 de la carte dimmer sont programmés pour monter ou descendre la luminosité de la LED 1 de la carte dimmable.
L’application nRF Mesh est aussi capable de changer le niveau de luminosité du serveur "level". Si vous ouvrez la page de configuration du "Generic Level Server", vous trouverez trois jauges pour envoyer directement des ordres au serveur.
Conclusion
Vous en savez maintenant un peu plus sur cette version de Bluetooth. Elle apporte un intérêt par rapport aux autres protocoles domotiques comme ZigBee ou Thread, celui d’être capable de s’interfacer directement (sans passerelle) avec une smartphone ou une tablette.
Cette technologie peu connue n’a pas une très grande visibilité auprès des fabricants, elle est cependant assez simple et flexible pour imaginer une grande variété de projets.
En espérant vous avoir divertis.
Sources:
Mesh profile : ici
Mesh Models : ici
How to use groups : ici