Historique

EnOcean intervient dans le domaine de la domotique. EnOcean fabrique des modules radio à ultra basse consommation qui mettent en oeuvre des techniques de collecte d'énergie permettant de s'affranchir de l'obligation d'utiliser des piles. EnOcean est également l'inventeur du protocole radio éponyme qui défini les échanges entre les modules.

Les technologies utilisées ont été initialement développées par Siemens qui décida en 2001 de créer une filiale nommée EnOcean détenant tous les brevets et chargée de continuer les développements. Puis en 2008 fut crée l'Alliance EnOcean dans le but de promouvoir la technologie et de fédérer les acteurs (fabricants, intégrateurs). Enfin, en 2012, la Commission Electrotechnique Internationale (CEI) ratifiait la norme ISO/CEI 14543-3-10 promulguant les technologies radio ultra basse consommation et la collecte d'énergie développées par EnOcean au rang de norme internationale.

Dès lors, tous les ingrédients étaient là pour favoriser l'essor de ce standard :

  • La technologie de collecte d'énergie (energy harvesting) qui permet d'éviter les changements de piles. Un gros avantage par rapport aux autres technologies radio du marché, comme le très répandu Z-wave par exemple, dont on peut lire ici ou là que les modules sont assez énergivores.
  • La multiplication des fabricants, attirés par la pérennité d'un protocole normalisé et la facilité d'intégration des modules EnOcean dans leurs produits.
  • L'assurance pour les clients de disposer de multiples sources d'approvisionnement afin de ne pas se lancer dans une installation domotique qui représente un investissement important, sans avoir l'assurance de pouvoir la maintenir et la faire évoluer facilement.

Pourtant, d'autres facteurs limitent encore le développement de ce marché, à commencer par le prix des modules EnOcean qui reste élevé malgré une concurrence relative entre fabricants, ou encore l'esthétique discutable de certains équipements (boutons poussoirs par exemple).

Le prix d'un bouton poussoir EnOcean qui va de moins de 30 € à plus de 50 € selon le fabricant doit cependant être relativisé. J'ai constaté que chez NodOn, qui fabrique des boutons poussoirs EnOcean, mais aussi Z-Wave, le modèle Z-Wave était vendu 5 € plus cher que le modèle EnOcean. Si on ajoute à ce surcoût le fait que NodOn indique une durée de vie de la pile de 18 à 24 mois sur le BP Z-Wave, et que la pile CR2032 vaut 4 € chez Darty, il vous en coûtera 40 à 50 € de piles pour 20 ans d'utilisation, soit le prix du BP EnOcean qui lui ne vous coûtera jamais rien en piles.

Energy harvesting

Derrière ces mots qui peuvent se traduire par collecte d'énergie, on trouve les différents moyens utilisés par les modules EnOcean pour générer leur propre énergie et réussir ainsi à se passer de piles. On trouve par exemple :

  • L'effet mécanique (magnéto-résistif ou piézo-électrique) qui transforme l'énergie d'une pression mécanique en électricité. C'est la technique utilisée par les boutons poussoirs.
  • L'effet photovoltaïque (mini cellule solaire secondée par une batterie miniature) qui transforme la lumière en électricité. C'est la technologie utilisée par les détecteurs d'ouverture, les sondes de température ou d'hygrométrie.
  • L'effet thermo-électrique qui transforme par effet Peltier une différence de température en électricité. C'est la technologie utilisée par les électrovannes de régulation de chauffage.

Si ces principes innovants ont fait la réputation d'EnOcean, il n'en reste pas moins qu'ils peuvent aussi présenter quelques inconvénients. Ainsi, les boutons poussoirs EnOcean sont souvent plus durs à manoeuvrer que les boutons poussoirs classiques. De même, les capteurs équipés de cellules solaires ne peuvent pas toujours être placés la ou la lumière est suffisante. D'autant que si vous fermez la maison pendant vos congés, plus aucune lumière ne pourra recharger vos détecteurs d'ouverture. Plutôt gênant d'un point de vue sécurité. C'est la raison pour laquelle on peut souvent ajouter des piles dans ces capteurs. Mais il n'en reste pas moins très pratique de pouvoir placer une sonde de température et d'humidité en extérieur sans avoir à passer le moindre câble et sans devoir en changer les piles.

Un peu de théorie

Principe

EnOcean utilise un protocole de type Point à Multipoint (1 vers n), ce qui signifie que l’émetteur (le capteur) envoi un message qui sera écouté par tous les récepteurs (les actionneurs), mais traité par les seuls récepteurs qui ont été préalablement appairés avec l’émetteur.

L’émetteur ne se soucie pas de savoir s’il existe un ou plusieurs destinataires. Il n’a donc pas besoin d’être configuré. En revanche, chaque destinataire devra avoir été préalablement appairé avec les émetteurs qui le concernent, afin qu’il puisse les reconnaître.

Appairage

Le processus d’appairage le plus courant consiste à appuyer un bouton ou tourner un petit commutateur sur le récepteur afin de le placer en mode apprentissage. Il suffit ensuite de forcer l’émetteur à envoyer un message pour que le récepteur mémorise l’identifiant de l’émetteur. C’est tout. La même procédure répétée avec le même récepteur et le même émetteur aura l’effet inverse et supprimera l’émetteur de la mémoire du récepteur.

Il est donc possible de commander plusieurs récepteurs avec un même émetteur, de même qu'un récepteur peut mémoriser une trentaine d'émetteurs.

Identification des modules par le CHIP_ID

Chaque module EnOcean possède un identifiant unique sur 32 bits, que l’on nomme CHIP_ID, et qui est généralement imprimé en hexadécimal sur une étiquette collée sur le produit. Parmi les notations courantes on trouve par exemple 19F7D34A, ou 19.F7.D3.4A ou encore 19:F7:D3:4A.

C’est la présence de cet identifiant dans le télégramme (champ SENDER_ID) qui va permettre aux récepteurs d’identifier l’émetteur. Dans le télégramme, on trouvera également un champ DESTINATION_ID pour identifier le destinataire, mais comme celui-ci peut être multiple, ce champ contiendra l’adresse de broadcast FF.FF.FF.FF (sauf cas particuliers).

Le cas particulier des passerelles EnOcean (ex : USB300)

Imaginons que l'installation dispose d’un logiciel de supervision. Il peut s’agir d’une Box domotique, ou encore d’une simple application développée par vos soins pour interagir avec les modules. Votre application va utiliser une passerelle pour dialoguer par radio avec les modules. Prenons le cas de la clé USB/Radio de type USB300. D'un coté, cette passerelle communique par radio en émettant et en recevant les messages EnOcean de type ERP (télégrammes radio), et de l'autre, elle communique avec votre application via un port série virtuel créé par le driver FTTI intégré dans la clé USB. Vous voila donc capable d'émettre et de recevoir des télégrammes EnOcean en écrivant ou en lisant des trames sur un port série, à charge pour la passerelle de convertir les trames en télégrammes radio.

Pour émuler un bouton poussoir et ainsi allumer une ampoule depuis votre application, vous pourriez penser qu’il suffit de placer le CHIP_ID d'un bouton poussoir déjà appairé avec l'actionneur de l'ampoule dans le champ SENDER_ID. Mais pour des raisons de sécurité, vous ne pourrez pas, via la passerelle, envoyer une trame comportant le CHIP_ID d'un autre module. Ce serait de l’usurpation d’identité. C’est la passerelle qui refusera d’émettre cette trame, en constatant qu’il s’agit d’un CHIP_ID qui n’est pas le sien. Car une passerelle est un module EnOcean comme un autre qui dispose par conséquent de son propre CHIP_ID unique

Identification de la passerelle par le CHIP_ID

Puisqu'on ne peut pas usurper le CHIP ID d'un module, la solution qui vient à l’esprit est de renseigner le champ SENDER_ID avec le CHIP_ID de la passerelle. Ainsi, sur le réseau, la passerelle émettra sous sa propre identité. Bien sûr, vous prendrez la précaution d'appairer la passerelle avec le récepteur (en plaçant l'actionneur en mode apprentissage et en envoyant une trame RPS depuis votre application). Cela fonctionne et vous pourrez allumer ainsi votre première ampoule.

Voici une astuce pour vos premiers tests. Pour allumer votre première ampoule sans vous prendre la tête, vous pouvez renseigner le champ SENDER_ID avec 00.00.00.00. Lorsque vous allez envoyer la trame, la passerelle va automatiquement remplacer 00.00.00.00 par son CHIP_ID et recalculer les checksums. De quoi arriver au premier résultat avec le minimum d’effort, puisque vous n'aurez même pas besoin de calculer les checksums.

Mais cette méthode pose très vite un problème de taille car vous voulez sans doute pouvoir allumer plus d'une ampoule, et certainement pas toutes les ampoules à la fois. Or à chaque appairage d'actionneur, c'est le même CHIP_ID de la passerelle qui sera stocké dans l'actionneur. Toute demande d’allumage émis ensuite via la passerelle sera alors prise en compte par tous les actionneurs appairés et toutes les ampoules s'allumeront.

Identification de la passerelle par le BASE_ID

Pour contourner ce problème, on va pouvoir utiliser la notion de BASE ID dans la passerelle en lieu et place du CHIP ID. Chaque passerelle est en effet dotée – en plus de son CHIP ID unique et non modifiable – d'un BASE ID qui peut se substituer au CHIP ID. Pour émettre avec le BASE ID plutôt que le CHIP ID, il suffit que l'application renseigne le BASE ID de la passerelle dans le champ SENDER ID de la trame, plutôt que le CHIP ID. La passerelle reconnaîtra son BASE ID et acceptera d'émettre sous cette identité.

L'intérêt de cette méthode, c'est qu'avec le BASE ID on dispose en fait de 128 adresses d'émission différentes. En effet, les BASE ID codés dans les passerelles sont des identifiants espacés les uns des autres de 128 adresses. Une passerelle est donc autorisée à utiliser son propre BASE ID ainsi que les 127 adresses qui suivent, sans empiéter sur d'autres BASE_ID.

Dans l'application, on pourra donc émuler 128 émetteurs différents en leur attribuant un identifiant interne de 0 à 127. Au moment d'émettre un message, on ajoutera l'identifiant interne de l'émetteur au BASE ID de la passerelle et on sera sûr de toujours utiliser le même BASE ID unique pour un émetteur donné, tout en restant dans la plage autorisée pour la passerelle.

Prenons un exemple. Au moment d’appairer la passerelle avec l’actionneur de l’ampoule #1, on va envoyer via la passerelle une trame dont le champ SENDER_ID contiendra le BASE ID de la passerelle +1, ce qui donnera FF.4C.E7.81 si le BASE ID de la passerelle est FF.4C.E7.80. Et pour l’appairage de l’actionneur qui commande l’ampoule #2, on va envoyer une trame dont le SENDER_ID contiendra le BASE ID de la passerelle +2. Ainsi, les deux actionneurs auront mémorisés des émetteurs différents (FF.4C.E7.81 et FF.4C.E7.82).

Si vous voulez allumer l’ampoule #1 avec votre application, vous placerez le BASE_ID FF.4C.E7.81 dans le champ SENDER_ID. La passerelle reconnaîtra un BASE_ID valide car faisant partie des 127 BASE_ID associés à son propre BASE ID et elle acceptera d’émettre la trame. Du coté des actionneurs, seul celui qui a été appairé avec le BASE_ID FF.4C.E7.81 traitera le message et seule l’ampoule #1 s’allumera.

On pourra donc, via une passerelle émuler 128 émetteurs possibles en ajoutant au BASE ID de la passerelle un identifiant interne à l'application et variant de 0 à 127. A noter que l'identifiant interne 0 aboutira à utiliser le propre BASE ID de la passerelle, tandis que les autres identifiants internes utiliseront les 127 adresses qui suivent le BASE ID. Ceci est tout à fait légal.

Si l'on souhaite émuler plus de 128 émetteurs dans l'application, il faudra utiliser plusieurs passerelles afin d’augmenter le nombre de BASE_ID différents utilisables. Mais n'oubliez pas qu'avec un même BASE_ID, vous pouvez envoyer 4 trames RPS différentes (pour les touches AI, AO, BI, BO). Vous pouvez donc envoyer jusqu'à 512 commandes RPS différentes avec une seule passerelle.

Un peu de pratique

Récupérer le BASE_ID de la passerelle

Par programmation, le BASE_ID de la passerelle peut être récupéré en utilisant la commande CO_RD_BASEID qui est décrite dans la documentation du protocole ESP3..

Voici un exemple d'échange :

        [TX] - 55 00 01 00 05 70 08 38
        [RX] - 55 00 05 01 02 DB 00 FF E6 95 80 0A C0

Ici, le BASE_ID de la passerelle est FF.E6.95.80, il sera possible d'envoyer des commandes vers les actionneurs en utilisant les BASE_ID FF.E6.95.80 à FF.E6.95.FF.

Modifier le BASE ID de la passerelle

Drôle d'idée à priori que de vouloir modifier le BASE ID de la passerelle. Cela peut toutefois être utile, voire quasiment indispensable.

Imaginons que votre installation est terminée et que votre application émule des dizaines de capteurs via les BASE ID transmis par la passerelle et mémorisés dans les actionneurs. Que se passerait-il si votre passerelle tombait en panne. Vous la remplaceriez par une autre bien sûr, mais le BASE ID de la nouvelle passerelle étant différent du BASE ID de l'ancienne, elle émettra désormais vos messages avec une nouvelle plage de BASE ID, et plus rien ne fonctionnera puisque les actionneurs n'auront pas été appairés avec ce nouveau BASE ID. La solution consisterait à ré-appairer tous les actionneurs avec la nouvelle passerelle. Comme les actionneurs sont la plupart du temps encastrés dans les murs ou les faux plafonds, vous comprenez que cela ne se fera pas en 10 minutes.

Pour vous éviter ces tracas, il a été prévu une commande permettant de modifier le BASE ID d'une passerelle.

Pour des raisons de sécurité, on ne peut pas changer le BASE ID plus de 10 fois. N'oubliez pas de noter le BASE ID utilisé par votre passerelle si vous voulez être capable de le réécrire dans une autre passerelle plus tard[.


Retour à l'accueil