Cet article a pour but de lister les différents concepts liés aux applications disponibles sur les différents nœuds d’un réseau ZigBee. Il n’a pas pour but d’expliquer quels sont les différents types de nœuds d’un réseau, comment celui-ci va se constituer, etc. Ces aspects seront traités dans d’autres articles. Nous allons uniquement nous concentrer sur les nœuds terminaux (pouvant effectuer des actions concrètes, directement utiles à l’utilisateur final).
Un réseau de nœuds interagissants
Dans un réseau ZigBee, des nœuds vont communiquer entre eux afin d’effectuer des actions ou de récupérer des informations. Ces interactions auront généralement des buts communs. La ZigBee Alliance les regroupe dans des Application Profiles. Le tout premier profil défini s’appelle « Home Automation ». Son but est de définir un ensemble de ressources communes pouvant être utile pour faire de la domotique dans un cadre domestique. Les fabricants voulant commercialiser des produits prévus dans ce but ont ainsi un standard auquel se raccrocher. Ces profils précisent, pour un type d’application donnée, ce qu’il peut être possible de faire faire à un nœud, et quelles seront les ressources nécessaires pour cela.
On entend par nœud (node) tout appareil connecté au réseau ZigBee. Un nœud ZigBee peut ainsi être un simple interrupteur qui supportera également un mode de mise à jour. Un nœud peut donc avoir différents rôles.
Les Application Profiles définissent ces ensembles de rôles, qu’on appellera device. Un nœud peut ainsi héberger plusieurs devices. On peut par exemple imaginer un nœud comportant deux devices : un capteur de lumière (Light Sensor) et un capteur d’occupation (Occupancy Sensor). Ces deux devices sont par exemple définis dans le profil Home Automation.
Lorsqu’un client (celui qui va faire la demande) fait effectuer à un device (qui a donc un rôle de serveur) une action, on dit que celui-ci effectue une commande. Si le device nous permet d’accéder ou de modifier une information qui lui est relative (exemple : l’intensité d’une ampoule), on parle d’attribut.
Les clusters définissent un ensemble de commandes (et de comportements associés), d’attributs et de dépendances. La ZigBee Cluster Library (ZCL) définit un grand nombre de clusters qui a vocation à suffire dans la plupart des cas. Chaque fabricant peut ensuite décider, comme pour les Application Profiles ou les devices, d’en redéfinir selon ses besoin.
Définir un device revient donc à lister les clusters que ce dernier implémentera de manière obligatoire ou non.
Par exemple, considérons le device « On/Off Light » du profil Home Automation (section 2.4.1 du document cité). Ce dernier doit supporter différents clusters. Il doit par exemple supporter le cluster « Basic ». Cela veut simplement dire qu’il doit pouvoir renseigner le réseau a propos de quelques uns de ses attributs (dont il doit donc disposer, obligatoirement ou non selon les attributs), tels que le nom de son fabricant, la version de l’application, etc. voire permettre d’en modifier, comme par exemple la description de son emplacement. Les attributs peuvent être des chaînes de caractères, des nombres, ou des énumérations, définies dans la ZCL. Ce cluster ne prend qu’une commande, qui est la réinitialisation du device. Ce device implémente aussi le cluster « On/Off« , qui donne accès entre autres à trois commandes, Off, On et Toggle, qui permettront respectivement d’éteindre, allumer, ou faire basculer l’état de la lampe.
Un endpoint est une instance d’un device sur un nœud donné, adressé avec une valeur comprise entre 1 et 240.
Si on reprend l’exemple de la lampe ci-dessus, et qu’un client veut l’allumer, il aura ainsi simplement à envoyer une requête au nœud correspondant à la lampe, avec le profil Home Automation, le numéro d’endpoint repéré lors de la découvert de service (imaginons que c’est 1 et que c’est le seul device présent sur le nœud), le numéro de cluster correspondant à « On/Off Light », 0x0006, et enfin la commande Off, d’identifiant 0x00, d’après la ZCL.
Nous verrons plus tard comment fonctionne la découverte des services et nous verrons aussi qu’il n’est pas nécessaire aux nœuds d’envoyer à chaque fois ces informations pour parvenir à leurs fins.